Hi,
On Sun, May 08, 2005 at 04:11:56PM -0500, Dustin Navea wrote:
Andreas Mohr wrote:
Do we want to throw out the baby with the bath water? In this case it's an obvious conflict between 16bit and 32bit, and note that it's even with a very rarely used DLL, thus it's easy to give up on it.
In all other cases in which 16bit and 32bit can happily co-exist I don't see much reason why we should discard 16bit support.
hmm. I see your point, but at the same time, if we are trying to mimic windows, while still keeping the 16-bit code in there, shouldnt we just not work on it as much (like we are doing currently)?
Sure, but that's a moot point, since everybody will work as much on stuff as he wants to see it progress, and that won't be too much in the Win16 case since it's of not too much interest as compared to Win32 (or probably even Win64 relatively soon).
Basically, the way I see it, vendors are stressing themselves with making 64-bit versions of their programs, as well as keeping their 32-bit versions going, so they are probably going to scrap 16-bit support in the near future, if they haven't already. Why should we continue developing something that is being phased out by the guys that create the need for this project in the first place?
You're already sounding like the new marketing director of some random major software company... "we need FEATURES, FEATURES! Who cares about all that old crap..."
I don't really need to tell you that this attitude is rather wrong in the Wine case, do I?
Hmm, well, let me do it anyway :-) People are often migrating to Linux PRECISELY BECAUSE newer Windows versions are no alternative to them any more (old machines with insufficient performance/compatibility with newer Windows versions). And we better make sure we support their *older* Windows applications to some extent in that case.
Andreas