Board index » cppbuilder » Ending 16-bit support in OWLNext

Jogy

CBuilder Developer
 

Ending 16-bit support in OWLNext


2006-03-09 05:49:52 PM
cppbuilder37
Hello,
In the mailing lists there are no recent messages from people developing
16-bit windows applications with OWL/OWLNext.
Also, the only compiler which can build 16-bit OWL is BC5.01/BC5.02.
I agree, it is reasonable to stop supporting Win16, but as this is a
serious change, and there will be no easy going back, I have posted
an announcement on the main page of www.owlnext.org/ and I can
wait a bit to see if there is anyone still needing 16-bit support.
If the 16-bit support will be ended, as a first step,
I can go through the code, remove all occurrences of
the NEAR, near, FAR and far keywords,
and edit all occurrences of
#if defined(BI_PLAT_WIN32), #if !defined(BI_PLAT_WIN32),
#if defined(BI_PLAT_WIN16), #if !defined(BI_PLAT_WIN16), etc.
A next step would be to remove the 16-bit emulation of the win32 common
controls, which may lead to excluding unnecessary files from the build.
Jogy
Vidar Hasfjord wrote:
Quote
Ending Win16 support gets my vote too --- although I have assumed
that was the current state anyway.
Quote

Of course, cleaning up the source code is easier said than done and
would require someone to make a heroic effort to remove all the Win16
stuff. So I'd expect that Win16 specifics will linger in the code, even
if deprecated and unsupported. We could clean it out piecemeal, though,
like Domenico suggests.
Quote

Regards,
---
Vidar Hasfjord

Perfect opportunity to tear out the WIN16 stuff.



I would be shocked and amazed if there’s anyone running Win16
anymore. If they are, they really need to do something about that.
Microsoft hasn’t supported a Win16 platform for quite a long time.
Hell, they’ve stopped or are stopping support for Windows 2000 now.
Quote



I’m all for reducing the OWLNExt source footprint.





Jay B





I was trying to have the Microsoft Layer for Unicode (see short
description wikipedia) works with owlnext but I did find out that there
quite a lot of code that need to be changed. The problem is related to
the fact that some functions calls, in order to maintain compatibility
with the BI_PLAT_WIN16, are called through function pointers and so are
invisible to the linker and do not end up calling the MSLU.
Quote
The are two way to fix the problem:
- inserting specific code for handling the build with the ifdef
USE_UNICOWS. The approach followed up to now but it will introduce a lot
more complication.
Quote
- remove the code that is relative to the BI_PLAT_WIN16 and use
the normal way of calling the winapi function without the use of
intermediate functions pointers (TModuleProc1 ..).
Quote

Removing the code for the WIN16 platform will have this advantages:
- The MSLU will work with the same UNICODE compiled library
without the need to build a specific USE_UNICOWS library.
Quote
- The removal of the BI_PLAT_WIN16 code will make the whole
owlcode more readable and easy to maintain.
Quote
- The end code will run faster (no need to intermediate functions
pointer).
Quote

It would be interesting to know if there is still interest in
maintaining the compatibility with the BI_PLAT_WIN16.
Quote

Domenico Zucchetti

 
 
Sebastian Ledesma [Solidyne Labs]

CBuilder Developer

2006-03-09 08:34:43 PM

Re:Ending 16-bit support in OWLNext

Hi Jogy:
I agree 16 bits it's 'legacy', but before declare obsolete I suggest to
release an 'oficial' 6.20 version: the last one with 16 bit support.
Saludos
Sebastian
"Jogy" < XXXX@XXXXX.COM >escribi?en el mensaje
Quote
Hello,

In the mailing lists there are no recent messages from people developing
16-bit windows applications with OWL/OWLNext.

Also, the only compiler which can build 16-bit OWL is BC5.01/BC5.02.

I agree, it is reasonable to stop supporting Win16, but as this is a
serious change, and there will be no easy going back, I have posted
an announcement on the main page of www.owlnext.org/ and I can
wait a bit to see if there is anyone still needing 16-bit support.


If the 16-bit support will be ended, as a first step,
I can go through the code, remove all occurrences of
the NEAR, near, FAR and far keywords,
and edit all occurrences of
#if defined(BI_PLAT_WIN32), #if !defined(BI_PLAT_WIN32),
#if defined(BI_PLAT_WIN16), #if !defined(BI_PLAT_WIN16), etc.


A next step would be to remove the 16-bit emulation of the win32 common
controls, which may lead to excluding unnecessary files from the build.


Jogy








Vidar Hasfjord wrote:
>Ending Win16 support gets my vote too --- although I have assumed
 that was the current state anyway.
>
 >Of course, cleaning up the source code is easier said than done and
 would require someone to make a heroic effort to remove all the Win16
stuff. So I'd expect that Win16 specifics will linger in the code, even if
deprecated and unsupported. We could clean it out piecemeal, though, like
Domenico suggests.
>
 >Regards,
 >---
 >Vidar Hasfjord
 >
 >Perfect opportunity to tear out the WIN16 stuff.
 >
 >
 >
 >I would be shocked and amazed if there’s anyone running Win16
 anymore. If they are, they really need to do something about that.
Microsoft hasn’t supported a Win16 platform for quite a long time. Hell,
they’ve stopped or are stopping support for Windows 2000 now.
>
 >
 >
 >I’m all for reducing the OWLNExt source footprint.
 >
 >
 >
 >
 >
 >Jay B
 >
 >
 >
 >
 >
 >I was trying to have the Microsoft Layer for Unicode (see short
 description wikipedia) works with owlnext but I did find out that there
quite a lot of code that need to be changed. The problem is related to the
fact that some functions calls, in order to maintain compatibility with
the BI_PLAT_WIN16, are called through function pointers and so are
invisible to the linker and do not end up calling the MSLU.
>The are two way to fix the problem:
 >- inserting specific code for handling the build with the ifdef
 USE_UNICOWS. The approach followed up to now but it will introduce a lot
more complication.
>- remove the code that is relative to the BI_PLAT_WIN16 and use
 the normal way of calling the winapi function without the use of
intermediate functions pointers (TModuleProc1 ..).
>
 >Removing the code for the WIN16 platform will have this advantages:
 >- The MSLU will work with the same UNICODE compiled library
 without the need to build a specific USE_UNICOWS library.
>- The removal of the BI_PLAT_WIN16 code will make the whole
 owlcode more readable and easy to maintain.
>- The end code will run faster (no need to intermediate functions
 pointer).
>
 >It would be interesting to know if there is still interest in
 maintaining the compatibility with the BI_PLAT_WIN16.
>
 >Domenico Zucchetti
 >
 
Jogy

CBuilder Developer

2006-03-09 08:55:31 PM

Re:Ending 16-bit support in OWLNext

Sebastian Ledesma [Solidyne Labs] wrote:
Quote
Hi Jogy:

I agree 16 bits it's 'legacy', but before declare obsolete I suggest to
release an 'oficial' 6.20 version: the last one with 16 bit support.

Saludos
Sebastian

Hello, Sebastian,
I thought about releasing 6.20 before stopping support for 16-bit,
but almost all of the changes since 6.19 are in the areas of
Unicode/Unicows support, the 64-bit DEP problem,
or fixes in the common controls (which are emulated for 16-bit),
and they do not affect 16-bit applications.
So, the last official version with 16-bit support can be 6.19,
and also 6.20rc5 can be kept visible as a latest code before the change.
Jogy
 

{smallsort}