Recent changes to Upgrading_from_OWL

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Fri, 03 Apr 2026 12:28:26 -0000

--- v171
+++ v172
@@ -245,6 +245,14 @@
 See [OWL Compatibility Modes](OWL_Compatibility_modes) for a list of revertible API changes and our [release documentation](OWLNext_Stable_Releases) and [bug tracker](http://sourceforge.net/p/owlnext/bugs) for details on the bigger issues. 

 Also see [FAQ | Porting issues](https://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#porting-issues).
+
+

+### Regressions
+
+Despite our best efforts, sometimes we make mistakes and break things, and unfortunately such issues may slip undetected into our releases. For the supported versions of OWLNext, we strive to repair such issues as quickly as possible, so let us know if you encounter any regressions. See our bug tracker for the full list of [tickets with label Regression](https://sourceforge.net/p/owlnext/bugs/search/?q=labels:Regression). For fixed issues, the ticket discussion section should document the release in which the issue was fixed.
+
+Also see release details in our full [release history](OWLNext_Stable_Releases).
+
 


 ---

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sun, 15 Mar 2026 06:13:37 -0000

--- v170
+++ v171
@@ -44,18 +44,18 @@

 To port an OWL 5 legacy application to OWLNext, we recommend a series of stepping stones to make the porting process as painless as possible: 


-  1. Install [OWLNext 6.30](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series). This is the last version that supports Borland C++ 5.02.
+  1. Install [OWLNext 6.30](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series) (last version with support for Borland C++ 5.02).
   *  Adapt your project files and code, and build it with OWLNext using the [OWL5_COMPAT](OWL_Compatibility_modes) mode.
-  *  Upgrade to [Borland C++ 5.5](Tools) and adapt your project files. Using a makefile-based build solution is recommended at this point.
-  *  Upgrade to [OWLNext 6.36](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series), and adapt your code as necessary. *Note: It is recommended to use OWLNext 6.36 only as a stepping stone to newer versions and not for production, as there are some known problems, like applications crashing on exit.*
+  *  Upgrade to [Borland C++ 5.5](Tools) and port your IDE project files to a makefile-based build solution.
+  *  Upgrade to [OWLNext 6.36](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series), and adapt your code as necessary.
   *  Switch to any of the modern [supported compilers](Supported_Compilers) and tools, and port the project files and code. 
   *  Stop using the OWL5_COMPAT mode, and make the required changes to your code, if any.
-  *  Upgrade to [OWLNext 6.44](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#640-series). Temporarily activating OWL5_COMPAT again may be useful to deal with changes.
+  *  Upgrade to [OWLNext 6.44](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#640-series) (temporarily activate OWL5_COMPAT again to deal with changes).
   *  Modernise your C++ code and upgrade to the latest version of OWLNext.

-Note that OWLNext 6.36 is a strategic version in the upgrade process. It is an official [LTS](Frequently_Asked_Questions/#h-do-you-provide-long-term-support) version supported as a migration stepping stone, and hence has the widest compiler support, including support for the latest compiler versions. So with 6.36, you can switch to modern development tools.
-
-However, if your code base is small, and you have a good understanding of the changes in OWLNext, you may be able to skip some of the intermediate steps above. The best path may also depend on the destination. In particular, for more information on porting your OWL application to the Microsoft compiler, see [Migrating from Borland C++ 5.02 to Visual C++](Migrating_from_BC_to_VC).
+Note that OWLNext 6.36 is a strategic version in the upgrade process. It is an official [LTS](Frequently_Asked_Questions/#h-do-you-provide-long-term-support) version supported as a migration stepping stone, and hence has the widest compiler support, including support for the latest compiler versions. So with 6.36, you can switch to modern development tools. It is recommended to use OWLNext 6.36 and prior versions only as stepping stones to newer versions and not for production, as there are known problems (like applications crashing on exit).
+
+If your code base is small, and you have a good understanding of the changes in OWLNext, you may be able to skip some of the intermediate steps above. The best path may also depend on the destination. In particular, for more information on porting your OWL application to the Microsoft compiler, see [Migrating from Borland C++ 5.02 to Visual C++](Migrating_from_BC_to_VC).

 See our [Installation Guide](Installing_OWLNext) for instructions on how to install any version of OWLNext. See the sections below for information about the changes you may have to make to your code.

Upgrading_from_OWL modified by Ognyan Chernokozhev

Ognyan Chernokozhev — Thu, 26 Feb 2026 04:25:54 -0000

--- v169
+++ v170
@@ -47,7 +47,7 @@

   1. Install [OWLNext 6.30](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series). This is the last version that supports Borland C++ 5.02.
   *  Adapt your project files and code, and build it with OWLNext using the [OWL5_COMPAT](OWL_Compatibility_modes) mode.
   *  Upgrade to [Borland C++ 5.5](Tools) and adapt your project files. Using a makefile-based build solution is recommended at this point.
-  *  Upgrade to [OWLNext 6.36](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series), and adapt your code as necessary.
+  *  Upgrade to [OWLNext 6.36](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#630-series), and adapt your code as necessary. *Note: It is recommended to use OWLNext 6.36 only as a stepping stone to newer versions and not for production, as there are some known problems, like applications crashing on exit.*
   *  Switch to any of the modern [supported compilers](Supported_Compilers) and tools, and port the project files and code. 
   *  Stop using the OWL5_COMPAT mode, and make the required changes to your code, if any.
   *  Upgrade to [OWLNext 6.44](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#640-series). Temporarily activating OWL5_COMPAT again may be useful to deal with changes.

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sun, 26 Oct 2025 18:14:22 -0000

--- v168
+++ v169
@@ -150,6 +150,17 @@
 The changes in OWLNext 6.40 also affect how response tables and dispatch functions are implemented, so if you have custom response table entries, such as custom DocView notifications (see [FAQ](http://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#why-do-my-custom-docview-notifications-fail-to-compile)), or any other code that depends on the implementation of the response table macros, table layout or dispatch functions, you will have to update your code.

 For more information about the dispatch machinery and the changes, see [Windows Message Dispatch in OWLNext](Windows_Message_Dispatch_in_OWLNext).
+
+

+### Natural structure member alignment
+
+OWLNext requires natural structure member alignment (packing) — same as the Windows API. Natural alignment is the default in modern compilers.
+
+Note that custom alignment is *not* supported and may lead to inconsistent alignment, data corruption and crashes (see [FAQ](https://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#h-what-is-the-correct-structure-member-alignment-packing-can-i-use-custom-alignment)). Make sure your project configuration uses the same global alignment setting as the library build scripts.
+
+**Tip:** Do not change the global alignment setting. Use specific alignment only where absolutely necessary (e.g. for [transfer buffers](#h-transfer-buffers-safety)), and always restore alignment afterward.
+
+For more information, see [Data Structure Alignment](https://en.wikipedia.org/wiki/Data_structure_alignment) at Wikipedia.

 

 ### Transfer buffers safety

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sun, 28 Sep 2025 21:59:29 -0000

--- v167
+++ v168
@@ -217,6 +217,8 @@
 Many obsolete OWL features that no longer make sense today have been removed. For example, OWLNext now only supports modern themed Windows, and the BWCC and CTL3D control libraries are hence outdated. However, up until OWLNext 6.34, BWCC support can be reinstated by using the [OWL5_COMPAT](OWL_Compatibility_modes) mode.

 In 6.32 we also removed the custom implementation of the Windows controls. OWL 5 offered this feature to provide emulation of the Windows 95 controls in Windows 3.x. Since we no longer support Win16, this feature was removed, thereby simplifying the maintenance of the source code. The control classes encapsulating the Windows controls now always use the native Windows implementation. The related class TNativeUse was removed, as well as the related functions, such as TControl::GetNativeUse and TSlider::SetNativeUse. As a special case, to maintain support for legacy code, TGauge was changed to a pure OWL control and deprecated (it has since moved to OWLExt [r5913]). A new class, [TProgressBar](http://owlnext.sourceforge.net/help/html/d5/de7/classowl_1_1_t_progress_bar.html), was introduced to encapsulate the Windows common control ([Progress Bar](http://msdn.microsoft.com/en-us/library/windows/desktop/bb760818.aspx)). For details, see [r1084].
+
+In version 7, TUrlLink was deprecated and moved to OWLExt. It has been replaced by the new class [TSysLink](https://owlnext.sourceforge.net/help/html/d7/d54/classowl_1_1_t_sys_link.html), which encapsulates the Windows common control ([SysLink](https://learn.microsoft.com/en-us/windows/win32/controls/syslink-overview)). See [FAQ](http://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#h-where-is-turllink).

 Other features that have been removed include the support for Win16 (16-bit compilation), [Unicows](Using_the_Microsoft_Layer_for_Unicode_with_OWLNext) (Microsoft Layer for Unicode) and [static library sectioning](OWL_Static_Library_Sectioning) (piecemeal compilation of source files).

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sun, 31 Aug 2025 10:48:41 -0000

--- v166
+++ v167
@@ -40,15 +40,7 @@
 ---
 ## Recommended step-by-step approach

-[[img src="OWLNext-recommended-upgrade-path.svg" alt="OWLNext recommended upgrade path" width="100%"]]
-
-~~~text
-OWL 5 → OWLNext 6.30 → [6.36] (allows switching to modern tools)
-                          │
-                          ├── Stay on 6.36 (not recommended)
-                          ├── Upgrade to 6.44 (LTS) for C++98 and Windows XP or later
-                          └── Upgrade to 7.0 (latest) for C++17 and Windows Vista or later
-~~~
+[[[img src="https://mermaid.ink/img/pako:eNp1kFtPwkAQhf_KZB4MBCiltPSiIZGiT0SN9RYpDwu7lCbtbrPdBpDw391WRXzwbWfOnO_M7AFXgjIMcJ2J7WpDpILZY8wBruf3rzNwFtDrjWFSF3dsp2BkDM1FrU8aIZzHeCaNYPYUXS1lfxwpVhQpTyBSgjPdgv64VVZFIaQqIdeZkoMSIivbMTbAsAFONTBSZA-CnwNrNxcKJFuJPGecMvrXdzN_LhJJKNNQbbTtX-NaSAg7Hd8DwulX6zXlVGzLC74si8u3B9ATGVFMngFv9SJnSNcwoVXPlKrdHPhNHbj_UF_SUpETuNkVu5jIlGKgZMW6mDOZk7rEQx0bo9qwnMUY6Cdla1JlKsaYH7WtIPxdiPzHKUWVbDBYk6zUVVVQHTFNiV42P3Vl_UkyFBVXGAxMz2ooGBxwh4HjGiPL9n3PtkeW4w28Lu711NAzhp4_tCzLtF3T8q1jFz-aXNPwXOf4CZW2qvo?type=png" alt="OWLNext Recommended Upgrade Path" width="85%"]]](https://mermaid.live/edit#pako:eNp1kFtPwkAQhf_KZB4MBCiltPSiIZGiT0SN9RYpDwu7lCbtbrPdBpDw391WRXzwbWfOnO_M7AFXgjIMcJ2J7WpDpILZY8wBruf3rzNwFtDrjWFSF3dsp2BkDM1FrU8aIZzHeCaNYPYUXS1lfxwpVhQpTyBSgjPdgv64VVZFIaQqIdeZkoMSIivbMTbAsAFONTBSZA-CnwNrNxcKJFuJPGecMvrXdzN_LhJJKNNQbbTtX-NaSAg7Hd8DwulX6zXlVGzLC74si8u3B9ATGVFMngFv9SJnSNcwoVXPlKrdHPhNHbj_UF_SUpETuNkVu5jIlGKgZMW6mDOZk7rEQx0bo9qwnMUY6Cdla1JlKsaYH7WtIPxdiPzHKUWVbDBYk6zUVVVQHTFNiV42P3Vl_UkyFBVXGAxMz2ooGBxwh4HjGiPL9n3PtkeW4w28Lu711NAzhp4_tCzLtF3T8q1jFz-aXNPwXOf4CZW2qvo)

 To port an OWL 5 legacy application to OWLNext, we recommend a series of stepping stones to make the porting process as painless as possible:

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sun, 31 Aug 2025 10:17:50 -0000

--- v165
+++ v166
@@ -39,6 +39,8 @@

 ---
 ## Recommended step-by-step approach
+
+[[img src="OWLNext-recommended-upgrade-path.svg" alt="OWLNext recommended upgrade path" width="100%"]]

 ~~~text
 OWL 5 → OWLNext 6.30 → [6.36] (allows switching to modern tools)

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sat, 30 Aug 2025 15:48:13 -0000

--- v164
+++ v165
@@ -74,6 +74,22 @@
 

 ### Strict namespaces

+~~~C++
+// Your header file "MyWindow.h"
+//
+#include <owl window.h="">
+
+class TMyWindow : public owl::TWindow { /*...*/ };
+
+// Your implementation file "MyWindow.cpp"
+//
+#include "MyWindow.h"
+
+using namespace owl;
+
+//...
+~~~
+
 The core of OWLNext now lives in the "owl" namespace. OWLNext 6.32 renamed the namespace from "OWL" to "owl". A macro for the old namespace is available in OWL5_COMPAT mode. Unlike the original OWL, the use of namespaces is now mandatory, and the old macros related to namespaces have been removed (BI_NAMESPACE etc.). If your legacy code does not already use namespaces, you must qualify (by "owl::") all OWL types etc. in your headers and add a using directive ("using namespace owl;") to your implementation files. Similar changes apply to the extension libraries (OCFNext, OWLExt, CoolPrj). 

 See the [FAQ](http://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#do-i-now-need-to-put-owl-on-all-owlnext-symbols) for some tips on how to efficiently apply namespace qualification in your headers using search-and-replace. 
@@ -81,11 +97,32 @@
 

 ### Standard exceptions

+~~~C++
+try 
+{
+  //...some code...
+}
+catch (const owl::TDiagException&) { throw; } // Let diagnostics through.
+catch (const owl::TXOwl& x) { WARN(x.why()); } // Handle OWL exception.
+catch (const std::runtime_error& x) { WARN(to_tstring(x.what())); }
+catch (const std::exception& x) { WARN(to_tstring(x.what())); }
+~~~
+
 Originally, OWL used the old exception class xmsg as the base class for TXBase, which in turn is the base class for TXOwl and the derived exception classes, TXWindow etc. OWLNext now uses std::exception as the base class for TXBase. For more information about exception handling, see [Exceptions and OWLNext](Exceptions_and_OWLNext).

 

 ### Borland C++ Class Libraries replacement

+~~~C++
+// Before:
+TArrayAsVector<int> values;
+values.Add(42);
+
+// After:
+std::vector<int> values;
+values.push_back(42);
+~~~
+
 OWLNext has transitioned to the standard C++ library, and hence no longer uses the Borland C++ Class Libraries. The required functionality from these libraries, such as the persistent streams framework, has been moved directly into OWLNext. 

 For legacy application support and compatibility with non-Borland compilers, OWLNext contains code that simulates parts of the Borland libraries. But please note that this code is **incomplete**, **unreliable** and **no longer maintained**. In particular, beware that detailed requirements for class copy construction and assignment etc. may not be 100% compatible, and this may introduce bugs in your code that are hard to pinpoint. 
@@ -97,6 +134,21 @@
 

 ### Message dispatch overhaul

+~~~C++
+// No base fallback for handlers since 6.40.
+//
+DEFINE_RESPONSE_TABLE1(TMyWindow, TWindow)
+  EV_WM_LBUTTONDOWN, // TMyWindow::EvLButtonDown is now required (no fallback to TWindow::EvLButtonDown).
+END_RESPONSE_TABLE;
+
+void TMyWindow::EvLButtonDown(uint modKeys, const TPoint& p) // NOTE: Const-correct signature!
+{
+  TWindow::EvLButtonDown(modKeys, p); // Forward to base, if applicable.
+  const auto pScreen = MapClientToScreen(p); // Convert from p, don't mutate it.
+  //...
+}
+~~~
+
 Over the years we have made numerous improvements to the Windows message dispatch framework at the core of OWLNext. Most of these changes concern low-level implementation, such as an overhaul of the implementation of window procedures (thunks) to support [DEP](OWLNext_and_Data_Execution_Prevention) and [64-bit](64-bit_OWLNext) compilation. These changes do not affect the API.

 However, we have made many corrections to the event handler signatures, and this may require changes in your program. In particular, [OWLNext 6.40](OWLNext_Stable_Releases#640-series) introduced a major overhaul of the message dispatch machinery, and many event handler signatures were updated in the process. In addition, OWLNext 6.40 now requires that the event handler for a response table entry is declared in the class owning the table. Using a base class function is no longer allowed (see [FAQ](http://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#i-get-response-table-errors-has-something-changed)).
@@ -108,6 +160,21 @@
 

 ### Transfer buffers safety

+~~~C++
+// Ensure buffer is byte-packed.
+//
+#include <pshpack1.h>
+struct TMyTransferBuffer
+{
+// ...
+};
+#include <poppack.h>
+
+//...
+
+SetTransferBuffer(&myTransferBuffer); // Size deduced and checked.
+~~~
+
 The OWL transfer buffer mechanism, designed to transfer data to and from dialog boxes, inherently requires byte packing. Byte packing was the default in Borland C++, so this was then not an issue. Modern compilers, on the other hand, align structure members on the natural (most efficient) boundaries for the primitive CPU data types, thus potentially introducing gaps between members. You must hence ensure byte packing explicitly by adding compiler pragma directives around your transfer buffer structures (see [FAQ](http://sourceforge.net/p/owlnext/wiki/Frequently_Asked_Questions/#how-do-i-resolve-transfer-buffer-issues)). 

 OWLNext 6.32 replaces the TWindow::SetTransferBuffer (void\*) function by overloads that infer or accept the size of the buffer. The size is used to check for packing compliance, buffer overruns and field type mismatches. If you have defined the transfer buffer as a struct, class or array then the new function template overloads will automatically deduce the size of the buffer, provided you pass an argument of the corresponding type. Alternatively, you can pass the size explicitly as the second argument. The old function signature is available in [OWL5_COMPAT](OWL_Compatibility_modes) mode, but note that it will disable the buffer checks. 
@@ -115,6 +182,42 @@
 Transfer buffers suffer from poor design and implementation making them unsafe. For this reason the [Safe Transfer Buffers](Safe_Transfer_Buffers) feature was introduced in OWLNext 6.32. By using this feature you can make your legacy transfer buffers fully safe with very little effort. Alternatively, you may want to rewrite your code to use the new [Dialog Data Transfer](Dialog_Data_Transfer) framework. 

 

+### Replacement of the protected TWindow::GetClassName overload
+
+~~~C++
+// Before OWLNext 7:
+//
+class TMyCtrl : public TWindow
+{
+protected:
+  LPCTSTR GetClassName() override
+  { return _T("MyCtrl"); }
+};
+
+// Since OWLNext 7:
+//
+class TMyCtrl : public TWindow
+{
+protected:
+ auto GetWindowClassName() -> TWindowClassName override
+ { return TWindowClassName{_T("MyCtrl")}; }
+};
+
+~~~
+
+OWLNext 6.44 and earlier versions have two very different overloads of TWindow::GetClassName. The public one,  [TWindow::GetClassName (LPTSTR className, int maxCount)](http://owlnext.sourceforge.net/help/html/d0/d5f/classowl_1_1_t_window.html#a88fa7b82e8808ac6d856e31e61aeefd2), is just a wrapper around the Windows API function of the same name, [GetClassName](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getclassname), and it can be used to get the class name as a string.
+
+However, the protected one, [GetClassName ()](https://sourceforge.net/p/owlnext/code/6706/tree/branches/644/include/owl/window.h#l1374), is *not* a wrapper around the Windows API. In OWLNext 6.44 and earlier, the protected GetClassName overload is a virtual function that allows derived classes to override it and specify the class name to be used to register the window class. It is called by [TWindow::Register](https://sourceforge.net/p/owlnext/code/6706/tree/branches/644/source/owlcore/window.cpp#l2790) and [TWindow::GetWindowClass](https://sourceforge.net/p/owlnext/code/6706/tree/branches/644/source/owlcore/window.cpp#l2280), and in the latter it is used to set [WNDCLASS::lpszClassName](https://learn.microsoft.com/en-gb/windows/win32/api/winuser/ns-winuser-wndclassa#members). Note that according to the Windows API the value of this field can be a C-string or an [ATOM](http://msdn.microsoft.com/en-us/library/windows/desktop/ms649053.aspx). This means that the protected GetClassName () may not return a valid string. If it returns an ATOM, and you treat it as a string, you will get a crash. The protected overload should hence not be used to get the window class name in general. Use the public overload for that.
+
+In OWLNext 7, we have resolved this ugly overload and return-type problem by renaming the protected function to [GetWindowClassName](http://owlnext.sourceforge.net/help/html/d0/d5f/classowl_1_1_t_window.html#a73e11f1a261cef21fb127b3f4d1db013) and changing the return type to [TWindowClassName](http://owlnext.sourceforge.net/help/html/d4/d7d/classowl_1_1_t_window_class_name.html). This new and safe return type encapsulates the class name union type (in much the same way as [TResId](http://owlnext.sourceforge.net/help/html/d6/d00/classowl_1_1_t_res_id.html) encapsulates the union between a C-string and an integer resource identifier).
+
+See "GetClassName is not type-safe" [bugs:#348] for more information about this resolution.
+
+This change in the API means that you will need to update your code if you have custom controls, dialogs or windows that override the old protected GetClassName to return a custom window class name. For OWLNext 7 compatibility, you must rename your override to GetWindowClassName and change the return type to TWindowClassName. In general, we also recommend you use the override keyword (since C++11), to ensure that you get override signatures correct.
+
+Note that the public [TWindow::GetClassName (LPTSTR className, int maxCount)](http://owlnext.sourceforge.net/help/html/d0/d5f/classowl_1_1_t_window.html#a88fa7b82e8808ac6d856e31e61aeefd2) is still present in OWLNext 7, and as before, it is just a low-level wrapper around the Windows API function.
+
+

 ### Removal of obsolete features

 Many obsolete OWL features that no longer make sense today have been removed. For example, OWLNext now only supports modern themed Windows, and the BWCC and CTL3D control libraries are hence outdated. However, up until OWLNext 6.34, BWCC support can be reinstated by using the [OWL5_COMPAT](OWL_Compatibility_modes) mode.
@@ -122,21 +225,6 @@
 In 6.32 we also removed the custom implementation of the Windows controls. OWL 5 offered this feature to provide emulation of the Windows 95 controls in Windows 3.x. Since we no longer support Win16, this feature was removed, thereby simplifying the maintenance of the source code. The control classes encapsulating the Windows controls now always use the native Windows implementation. The related class TNativeUse was removed, as well as the related functions, such as TControl::GetNativeUse and TSlider::SetNativeUse. As a special case, to maintain support for legacy code, TGauge was changed to a pure OWL control and deprecated (it has since moved to OWLExt [r5913]). A new class, [TProgressBar](http://owlnext.sourceforge.net/help/html/d5/de7/classowl_1_1_t_progress_bar.html), was introduced to encapsulate the Windows common control ([Progress Bar](http://msdn.microsoft.com/en-us/library/windows/desktop/bb760818.aspx)). For details, see [r1084].

 Other features that have been removed include the support for Win16 (16-bit compilation), [Unicows](Using_the_Microsoft_Layer_for_Unicode_with_OWLNext) (Microsoft Layer for Unicode) and [static library sectioning](OWL_Static_Library_Sectioning) (piecemeal compilation of source files).
-
-

-### Replacement of the protected TWindow::GetClassName overload
-
-OWLNext 6.44 and earlier versions have two very different overloads of TWindow::GetClassName. The public one,  [TWindow::GetClassName (LPTSTR className, int maxCount)](http://owlnext.sourceforge.net/help/html/d0/d5f/classowl_1_1_t_window.html#a88fa7b82e8808ac6d856e31e61aeefd2), is just a wrapper around the Windows API function of the same name, [GetClassName](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getclassname), and it can be used to get the class name as a string.
-
-However, the protected one, [GetClassName ()](https://sourceforge.net/p/owlnext/code/6706/tree/branches/644/include/owl/window.h#l1374), is *not* a wrapper around the Windows API. In OWLNext 6.44 and earlier, the protected GetClassName overload is a virtual function that allows derived classes to override it and specify the class name to be used to register the window class. It is called by [TWindow::Register](https://sourceforge.net/p/owlnext/code/6706/tree/branches/644/source/owlcore/window.cpp#l2790) and [TWindow::GetWindowClass](https://sourceforge.net/p/owlnext/code/6706/tree/branches/644/source/owlcore/window.cpp#l2280), and in the latter it is used to set [WNDCLASS::lpszClassName](https://learn.microsoft.com/en-gb/windows/win32/api/winuser/ns-winuser-wndclassa#members). Note that according to the Windows API the value of this field can be a C-string or an [ATOM](http://msdn.microsoft.com/en-us/library/windows/desktop/ms649053.aspx). This means that the protected GetClassName () may not return a valid string. If it returns an ATOM, and you treat it as a string, you will get a crash. The protected overload should hence not be used to get the window class name in general. Use the public overload for that.
-
-In OWLNext 7, we have resolved this ugly overload and return-type problem by renaming the protected function to [GetWindowClassName](http://owlnext.sourceforge.net/help/html/d0/d5f/classowl_1_1_t_window.html#a73e11f1a261cef21fb127b3f4d1db013) and changing the return type to [TWindowClassName](http://owlnext.sourceforge.net/help/html/d4/d7d/classowl_1_1_t_window_class_name.html). This new and safe return type encapsulates the class name union type (in much the same way as [TResId](http://owlnext.sourceforge.net/help/html/d6/d00/classowl_1_1_t_res_id.html) encapsulates the union between a C-string and an integer resource identifier).
-
-See "GetClassName is not type-safe" [bugs:#348] for more information about this resolution.
-
-This change in the API means that you will need to update your code if you have custom controls, dialogs or windows that override the old protected GetClassName to return a custom window class name. For OWLNext 7 compatibility, you must rename your override to GetWindowClassName and change the return type to TWindowClassName. In general, we also recommend you use the override keyword (since C++11), to ensure that you get override signatures correct.
-
-Note that the public [TWindow::GetClassName (LPTSTR className, int maxCount)](http://owlnext.sourceforge.net/help/html/d0/d5f/classowl_1_1_t_window.html#a88fa7b82e8808ac6d856e31e61aeefd2) is still present in OWLNext 7, and as before, it is just a low-level wrapper around the Windows API function.

 

 ### Other minor API and behavioural changes
</poppack.h></pshpack1.h></int></int></owl>

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sat, 30 Aug 2025 14:35:44 -0000

--- v163
+++ v164
@@ -40,13 +40,12 @@
 ---
 ## Recommended step-by-step approach

-[[img src="OWLNext-upgrade-path.png" width="100%" alt="OWLNext Upgrade Path"]]
 ~~~text
-OWL 5  →  6.30  →  [ 6.36 LTS ]
-                         │
-                         ├── Stay on 6.36 (LTS)
-                         ├── Upgrade to 6.44 (LTS)
-                         └── Upgrade 7.0 (latest)
+OWL 5 → OWLNext 6.30 → [6.36] (allows switching to modern tools)
+                          │
+                          ├── Stay on 6.36 (not recommended)
+                          ├── Upgrade to 6.44 (LTS) for C++98 and Windows XP or later
+                          └── Upgrade to 7.0 (latest) for C++17 and Windows Vista or later
 ~~~

 To port an OWL 5 legacy application to OWLNext, we recommend a series of stepping stones to make the porting process as painless as possible: 
@@ -60,9 +59,9 @@
   *  Upgrade to [OWLNext 6.44](https://sourceforge.net/p/owlnext/wiki/OWLNext_Stable_Releases/#640-series). Temporarily activating OWL5_COMPAT again may be useful to deal with changes.
   *  Modernise your C++ code and upgrade to the latest version of OWLNext.

-Note that OWLNext 6.36 is a strategic version in the upgrade process. It is officially supported as a migration stepping stone, and hence has the widest compiler support, including support for the latest compiler versions. So with 6.36, you can switch to modern development tools.
+Note that OWLNext 6.36 is a strategic version in the upgrade process. It is an official [LTS](Frequently_Asked_Questions/#h-do-you-provide-long-term-support) version supported as a migration stepping stone, and hence has the widest compiler support, including support for the latest compiler versions. So with 6.36, you can switch to modern development tools.

-However, if your code base is small, and you have a good understanding of the changes in OWLNext, you may be able to skip some of the intermediate steps above. The best path may also depend on the destination. For example, if you plan to use Microsoft Visual Studio development tools, then after making sure your project builds successfully with Borland C++ 5.02 and OWLNext 6.30, you can immediately switch to Visual Studio 2012 (this is the latest version supported by OWLNext 6.30). Afterwards, you can upgrade to later versions of OWLNext and Visual Studio as you see fit. For more information on porting your OWL application to the Microsoft compiler, see [Migrating from Borland C++ 5.02 to Visual C++](Migrating_from_BC_to_VC).
+However, if your code base is small, and you have a good understanding of the changes in OWLNext, you may be able to skip some of the intermediate steps above. The best path may also depend on the destination. In particular, for more information on porting your OWL application to the Microsoft compiler, see [Migrating from Borland C++ 5.02 to Visual C++](Migrating_from_BC_to_VC).

 See our [Installation Guide](Installing_OWLNext) for instructions on how to install any version of OWLNext. See the sections below for information about the changes you may have to make to your code.

Upgrading_from_OWL modified by Vidar Hasfjord

Vidar Hasfjord — Sat, 30 Aug 2025 14:17:11 -0000