The Object Windows Library (OWL) is a C++ object-oriented application framework designed to simplify desktop application development for Windows.

OWL was introduced by Borland in 1991 and eventually deprecated in 1997 in favor of their Visual Component Library(VCL). Its primary competitor was the Microsoft Foundation Class Library (MFC). OWLNext, an open-source project driven by the OWL user community, has continued the maintenance of OWL, ensuring that the library and applications that use it work with the latest version of Windows and modern C++ compilers.

For additional OWL history see:  https://en.wikipedia.org/wiki/Object_Windows_Library

In 1997, Borland released C++Builder and deprecated Borland C++. OWL was included on the Companion CD that shipped with C++Builder, but Borland ended maintenance and further development of the library.

In late 1999, Borland stopped selling Borland C++ and OWL.

The current C++Builder IDEs do not have any native support for the OWL. That is to say, the newer Borland C++ Builder (BCB) does not ship with the OWL and does not contain any wizards to create OWL projects.

But, support for OWL has been taken up by a user group named OWLNext. They periodically release patches to the OWL and have a version of OWL that does work with many of the newer C++ Builders (BCB).  Check out their website here: https://owlnext.sourceforge.net

There are two basic challenges you must address in getting your OWL application to compile with C++ Builder.

2. Re-create your project file in the newer C++ Builder format. For example, you can open a .bdsproj or a .cbproj project type in the current C++ Builder IDE.  If your project is simply a makefile, you may be able to use the command line compiler, but if you want to compile in the IDE, you will need to create a new project file of the same project type (console and/or VCL) and add your OWL source code to it. You should also make sure your project contains include and library path information for the OWL.

Customers have reported that OWLNext has done a great job in carrying OWL and making sure it is compatible with many different versions of BCB. With a little persistence and patience, your OWL project can be built with BCB.

Items to consider converting OWL apps to Visual Component Library (VCL) for C++Builder 10.2.2 are mainly on how to handle:

1.    OWL TDC (Device Context).  The TDC to TCanvas conversion is fairly easy.

The VCL’s TCanvas is the device context that is an ensemble of the tools needed to draw lines, shapes, and other graphics. It includes the platform you draw on, the dimensioning of the platform, the orientation and other variations of your drawing, the tools you need to draw on the platform, the colors, and various other accessories that can complete your imagination.

2.    OWL Response Table transition (CEnable, etc).  The response table conversions may require some work.  

The CEnable will also require work, but you may be able to use the TActionList.  The VCL’s TActionList maintains a list of actions that can be used by components and controls such as menu items and buttons.

3.    OWL IDE transition. Depending on how much you rely on the OWL Doc/View architecture this may need to be redesigned?

Additional help, if needed:
1) Embarcadero provides an .IDE project converter that converts the BCx+ projects to BCBx format, which C++ Builder 10.2.2 should be able to read and bring into the present MSBuild file format.

2. Depending on your schedule, you might want to consider going with OWLNext (this is an opensource OWL project that was brought up to date and enhanced for the new Operating Systems and works with current C++ Builder IDEs) and run a VCL conversion of the application in parallel.  The more you can decouple the core functionality from the UI the easier this process will be.

3. No migration tool for OWL to VCL that I know of. OWL is primarily code based, and the VCL is visual - they are much less convertible than even VCL and FireMonkey (FMX).

For example to display a Windows Form from a C++ Builder Console application using OWL with the Form.Caption = My Main Form, the OWL code looks like this:

4. Using OWLNext does not solve the problem of migrating off OWL completely.  OWL was already outdated around 1997 when the VCL become available to C++, and uses a very old design style in that it describes and builds UIs in code; OWLNext will get you modern compiler support and new controls, but it won't make the UI any more maintainable or easy to change and design. It's suitable for upgrading to C++ Builder 10.2.2 Tokyo and getting the codebase working, moving to Unicode, etc. So OWLNext is a good step for upgrade and migration, but long term, it’s recommended that you move to the VCL or FMX.  Certainly doing that in two steps, using OWLNext for the first step, would be a great approach.

5. With OWLNext, you might be able to get in touch with the developers via their SourceForge page, and they may have advice for you.

1. Upgrade to OWLNext and then rebuild the VCL in C++Builder.  First get your projects to compile in current C++ Builder with OWLNext, then move over the app and document classes, and step by step starting with the main window migrate to VCL.

2. OWL TDC (Device Context).  The TDC to TCanvas conversion is fairly easy.

3. OWL Response Table transition (CEnable, etc).  The response table conversions may require some work.  

The CEnable will also require work, but you may be able to use the TActionList.

4.  OWL IDE transition. Depending on how much you rely on the Doc/View architecture this may need to be redesigned?  With both this and the OWL application and document classes, you can write new classes keeping the same interface, i.e. same methods (of all the methods in the classes, there may be a lot but most likely you aren't using all of them.)  This will give you stub classes, i.e. completely empty methods, but allow you to compile.  Create your singleton instance of your replacement-OWL application where the main TApplication is created, too, so it has the same lifetime.

5. Next, start implementing the classes.  CEnable should be straightforward and you can code something so it gets updated in OnIdle, or possibly hooked into an action list's events. 

6. Document and Application should also be straightforward and often quite small code. 

7. The biggest thing may be reworking the UI, and redo the main window in VCL.  Here you will need to recreate menus, toolbars, and using actions and action lists.  This will let you eliminate a lot of CEnable objects, though many may remain for other windows, e.g. child windows.  Also can code a CEnable -> action layer too, which allows actions to be created but the code to still use a CEnable API, or events, or something. 

8. Dialogs for a while were still OWL (you can call them, parented, since you can access the Handle) and ported bit by bit.  It's a reasonable amount of work, but straightforward.  The goal is to get the app to compile in C++ Builder 10.2.2, then iteratively replace code, as needed.  Do not be fearful to comment out large sections of code, have many empty stub methods, etc., and come back and uncomment or rewrite that code over time.  It'll be considerably easier if the UI and logic are separated, but often this isn't the case.

9. C++ Builder has SDI and MDI wizard projects if needed.  SDI is a single-document interface, is an application primarily made of a form equipped with a menu. An example is Notepad.  In some cases, an SDI can also have a toolbar and/or a status bar. An example is a Microsoft Works Spreadsheet.

MDI is a multiple-document interface, is an application that primarily has a form and a menu. Some, if not most MDIs also have one or more toolbars and/or a status bar.  Like a normal application, to use an MDI, the user must launch it. In some cases, when the application starts, it is empty; that is, no document is created and the title bar displays a caption, usually the name of the application.  Usually, there are steps the user must follow to create a document. In some other cases, when the application is launched, it automatically creates a document. A document resides inside the parent frame of the application. That is, a child document can use only the area reserved for it. The child document has its own system icon, its own title bar, and its system buttons (Minimize, Maximize/Restore, and Close).

For SDI and MDI details and examples see:  http://www.functionx.com/cppbuilder/topics/sdimdi.htm

6. Graphics/Bitmap APIs.  As far as graphics are concerned you need to consider the platforms you are targeting as the Graphics Device Interface (GDI) seems to be going away.  You would need to consider Direct2D which we support in XE2 on Win7.

I'd suggest this as a second step.  Get your OWL app working first, then consider things like upgrading graphics APIs.

And remember Embarcadero is here to help!

[DownloadButton Product='Cbuilder' Caption='To get started migration your Borland OWL applications to the current C++ Builder VCL, please download the C++ Builder 10.2.2 Trial '] 

and OwlNext can be downloaded from Embarcadero Code Central here and install OWLNext into your C++ Builder 10.2.2 IDE.