The rationale for this change is simple: the version sniffing code is unreliable and gets it wrong frequently. Out of the box, you can't run "WINEDLLOVERRIDES=msi,msiexec.exe=n wine InstMsiA.exe" because of this code. You just get silence. It turns out that even though this is the Win98 version of the installer, it's detected as a Windows XP binary.
It's a lot simpler to have a single, sane default. This makes it easier for users to understand, easier for us to control, and avoids the case where different processes in the same program get different version information.
This patch defaults us to Win98 mode.
Shouldn't we default to WinXP? I know no apps except Win98 specific system files like InstMsiA.exe and dcom98.exe which fail with Winver=winxp. Contrary many apps need winver=winxp(or win2k or nt40) to work, like the setup programs for MS Visual Studio and Microsoft Office 2003.
Anyone who has an app which doesn't work with winver=winxp but works with real Windows XP?
I think we should at least target Winver=winxp and fix broken apps.
Stefan
Hi,
On Sun, Jun 05, 2005 at 09:03:21PM +0000, Stefan Dösinger wrote:
This patch defaults us to Win98 mode.
Shouldn't we default to WinXP? I know no apps except Win98 specific system files like InstMsiA.exe and dcom98.exe which fail with Winver=winxp. Contrary many apps need winver=winxp(or win2k or nt40) to work, like the setup
It is easily imaginable that a program does "oh, that's an NT system" and then calls all sorts of crazy NT APIs that Wine sometimes hasn't even heard of. ;-)
At least that used to be the case some time ago, which is why we largely defaulted to Win98 operation since our NT layer used to be very weak (it should be much better already, though).
I don't know specific example programs any more, but there have been several.
Still,
I think we should at least target Winver=winxp and fix broken apps.
yup, I think we should try to go for that for now, despite some quite system specific programs overwhelming us in case of an NT version. If it turns out that it is in fact too much for us to handle soon, then we should probably scale back to Win98 until our NT API support is strong enough.
Andreas Mohr
On Sun, 05 Jun 2005 21:24:10 +0200, Andreas Mohr wrote:
yup, I think we should try to go for that for now, despite some quite system specific programs overwhelming us in case of an NT version.
Well, Win98 was a deliberate choice. Just before WineConf we set the Crossover nightlies to Win2k by default and all our tests immediately went RED FAIL ;)
Basically, when you set win2k by default, tons and tons of stuff breaks because apps become a lot more demanding. For now it makes sense to leave WineHQ at win98 and let CodeWeavers take the brunt of the pain. In fact it looks like we may not be able to get the whole thing running in win2k mode by default for Crossover Office 5, we'll see.
Once we succesfully make the transition a ton of bugs and new functions will already have been implemented, and maybe it'll make sense to go win2k by default in regular Wine there too.
Of course AJ may decide that the only way to get the bugs fixed is to change the default right away :)
Well, Win98 was a deliberate choice. Just before WineConf we set the Crossover nightlies to Win2k by default and all our tests immediately went RED FAIL ;)
Basically, when you set win2k by default, tons and tons of stuff breaks because apps become a lot more demanding. For now it makes sense to leave WineHQ at win98 and let CodeWeavers take the brunt of the pain. In fact it looks like we may not be able to get the whole thing running in win2k mode by default for Crossover Office 5, we'll see.
Once we succesfully make the transition a ton of bugs and new functions will already have been implemented, and maybe it'll make sense to go win2k by default in regular Wine there too.
Of course AJ may decide that the only way to get the bugs fixed is to change the default right away :)
Agreed.
Stefan
On Sun, 05 Jun 2005 21:24:10 +0200, Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
Still,
I think we should at least target Winver=winxp and fix broken apps.
yup, I think we should try to go for that for now, despite some quite system specific programs overwhelming us in case of an NT version. If it turns out that it is in fact too much for us to handle soon, then we should probably scale back to Win98 until our NT API support is strong enough.
Andreas Mohr
Quite agree. No sense in wine trying run before it can walk.
When there are still issues with modal dlgs coming up hidden behind other windows and so many unresolved issues it does not seem to make sense to open a whole new can of worms.
There have also beem many regressions in wine over the last 6 to 9 mths that are still having fall-out.
It is close to reaching critical mass as win98 emulation and is coming together nicely. It makes sense for it to default to a reasonably working winver .
If a prog requires specifically xp and wont work on 98 then there is a strong likelyhood that it is calling for features that are a long way from being supported anyway.
Sniffing aside , winver=win98 makes more sense to me.
Regards.
-
Andreas Mohr -
Mike Hearn -
peter＠piments.com -
Stefan Dösinger