Death to win9x?

[Joerg-Cyril.Hoehle at t-systems.com]

Dan Kegel wrote:
>I'm all for removing stuff that nobody needs anymore.
Who said nobody needs Win9x anymore?

>  I imagine there
>are still a few popular older apps that will force us to keep some old
>win9x behaviors around, though, so we probably won't be able
>to remove the 'emulate win98' choice from winecfg any time soon.

Probably half of the apps I bought during the last years work with
Win9X.  Just the other day I saw a mciSendCommand16 in a log.
Well, 16bit != win9x.  Is it "Death to 16bit" you meant?


What's the motivation behind removing stuff *now* suddenly?  Is it the
perceived effort needed to fix the tests to all green colour on
testbot's win9x machines?
Why was this topic not discussed recently at Wineconf?


It would be a very bad idea to remove win9x from testbot. We need
these old systems to understand what behaviour old apps expect.
And I'm very thankful to Greg for his testbot service.

Without it, we would know next to nothing about win9x.  The fact that
a random old app works in native XP (in compatibility mode) teaches us
nothing for Wine.  Unless we start to run winetest in compatibility mode!


I've already mentioned in the past the idea to run testbot sometimes with all
broken() disabled, to assess failures on newer systems.  broken() may
shadow errors in the tests and lull Wine developers into wrong beliefs.


Paul Vriens wrote:
>The little bits and pieces we have in our code should stay as we 
>probably need that to cope with old apps that expect a different behavior.

Actually, I've even been thinking about implementing the opposite
behaviour: Old APIs are mostly used by old apps, while newer apps
moved to newer ones (e.g. DirectSound, then mmdev).  Therefore it
would make a lot of sense to have old APIs (e.g. WINMM/MCI/VfW) mimic the
behaviour observable when these apps were developed: win9x! (win3.x?)

We don't even know whether MS' compatibility mode does precisely that.

Regards,
	Jörg Höhle