Ok I changed my mind, I want to disable it for now. What is going to be the best way to go about doing it? We currently have the -DNO_WINEWINSOCK should I just #ifndef the code out with -DNO_WIN16 ?
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
"Steven Edwards" Steven_Ed4153@yahoo.com wrote:
Ok I changed my mind, I want to disable it for now. What is going to be the best way to go about doing it? We currently have the -DNO_WINEWINSOCK should I just #ifndef the code out with -DNO_WIN16 ?
It's much larger work than just #ifdef'ing the code. First of all, all 32-bit code should be rewritten to not rely on the 16-bit counterparts.
It's much larger work than just #ifdef'ing the code. First of all, all 32-bit code should be rewritten to not rely on the 16-bit counterparts.
Does that much of the Win32 code depend on Win16? I thought they were mostly indepenant of each other in the WINE sources.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
"Steven Edwards" Steven_Ed4153@yahoo.com wrote:
It's much larger work than just #ifdef'ing the code. First of all, all 32-bit code should be rewritten to not rely on the 16-bit counterparts.
Does that much of the Win32 code depend on Win16? I thought they were mostly indepenant of each other in the WINE sources.
Yes, most of the 32-bit code doesn't rely on the 16-bit APIs, so you can start your work with truely separated 16/32 dlls. But *there are* places where 32-bit code relyes on the 16-bit parts.
And what is more important, is to decide how 32-bit and 16-bit code should be separated. I vote for moving them to separate files as Alexandre did it for dlls/user/wnd16.c and dlls/user/wnd16.c for instance.
Yes, most of the 32-bit code doesn't rely on the 16-bit APIs, so you can start your work with truely separated 16/32 dlls. But *there are* places where 32-bit code relyes on the 16-bit parts.
And what is more important, is to decide how 32-bit and 16-bit code should be separated. I vote for moving them to separate files as Alexandre did it for dlls/user/wnd16.c and dlls/user/wnd16.c for instance.
I agree with moving the win16 support to its own files. Once that is done it will be easy to have a configure option to not build win16 support. If Alexandre will accept patches for it I will begin to do it.
Thanks Steven
"Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson
-
Dmitry Timoshkov -
Steven Edwards