The discussion on 16-bit support for cards.dll led me to an interesting theory.
If the big name vendors are dropping support for 16-bit programs, they must be doing it for a reason, right? The only reason I can come up with is because they dont have the resources (or maybe just the desire) to maintain 2 separate trees (1 16-bit and 1 32-bit), and soon to be 3 trees including 64-bit.. We have the desire to allow any windows program to run, whether it runs in a current version of windows or not.
The problem with this is that over time, dos support has faded damatically, as well as win16 support. Soon we will start writing more win64 conformance code, and less win32. Where will that leave all of the people that dont jump on the 64-bit bandwagon any time soon?
<flame war first shot>
I think we are getting to that point, from a maintenance perspective, where we should seriously consider reorganizing the project into a more hierarchal (sp?) structure, where we have some people that can take some time off from contributing 32 or 64-bit code when need be, to contribute some 16-bit code for a user who wants to use an older program.
Possibly (just an idea) we should make a dedicated project page on sourceforge specifically for 16-bits.
As I said, soon we will be not necessarily abandoning 32-bits, but writing more 64-bits.. Sure we have separation to keep things apart, but wine is starting to get loaded down with things that only a small minority of users need anymore.. Perhaps it is time (just another idea) to copy out the 16-bit code into it's own project? That way we can organize things more efficiently, and at the same time, reduce 1) download time of wine, and 2) compile time.
Of course, we would still leave 16-bit support in the main project, but we would no longer maintain it there.. We could maintain it in wine16....
</flame war first shot>
Comments? Suggestions? Flames??? Bring it ;-)
Dustin
On Tue, May 10, 2005 at 11:44:03PM -0500, Dustin Navea wrote:
The discussion on 16-bit support for cards.dll led me to an interesting theory. As I said, soon we will be not necessarily abandoning 32-bits, but writing more 64-bits.. Sure we have separation to keep things apart, but wine is starting to get loaded down with things that only a small minority of users need anymore.. Perhaps it is time (just another idea) to copy out the 16-bit code into it's own project? That way we can organize things more efficiently, and at the same time, reduce 1) download time of wine, and 2) compile time.
Of course, we would still leave 16-bit support in the main project, but we would no longer maintain it there.. We could maintain it in wine16....
</flame war first shot>
Comments? Suggestions? Flames??? Bring it ;-)
16bit support is deeply integrated into the WINE core and not easy to extract.
And it is usually not touched by current work anyway, so I really see no need to split it off.
Ciao, Marcus
On Wed, 11 May 2005, Marcus Meissner wrote: [...]
16bit support is deeply integrated into the WINE core and not easy to extract.
Furthermore a lot of '32bit applications' actually use 16bit code either directly or indirectly (although that may be getting less common these days). What this means is that if you remove 16bit support it's quite likely a lot of 32bit applications will stop working.
On Tue, 10 May 2005 23:44:03 -0500, Dustin Navea wrote:
If the big name vendors are dropping support for 16-bit programs, they must be doing it for a reason, right?
Actually 16 bit support is very important to Microsoft, they are continuing to support it in Longhorn. I wouldn't read too much into a simple naming goof over a cards DLL, it's just a one-off.
thanks -mike
-
Dustin Navea -
Francois Gouget -
Marcus Meissner -
Mike Hearn