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