Bug 2131 - 16-bit support?
andi at rhlx01.fht-esslingen.de
Mon May 9 10:06:31 CDT 2005
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
> >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
> >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.
More information about the wine-devel