Windows version autodetection
Hi There are some older applications out there, which don't install or run correctly unless Wine is emulating the correct Windows version (eg. Windows 9x). At least Windows XP has the ability to use certain heuristics to make an educated guess as to which version of Windows the application expects, and then lie in GetVersion() and behave like that version in relevant APIs. Should we do something like that for Wine? It would allow many applications to work out of the box. Damjan Jovanovic
2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>:
There are some older applications out there, which don't install or run correctly unless Wine is emulating the correct Windows version (eg. Windows 9x).
At least Windows XP has the ability to use certain heuristics to make an educated guess as to which version of Windows the application expects, and then lie in GetVersion() and behave like that version in relevant APIs.
Should we do something like that for Wine? It would allow many applications to work out of the box.
You can change the version of Windows reported for different applications, and the default version using winecfg -> Applications. I'm not sure that adding heuristics would be the correct approach, as those can lead to incorrect results. The winecfg option supports the user being able to change the version of Windows reported for the specified application. The workflow could be better, though (e.g. supporting an option on an exe's right-click menu). What would be better is to have AppDB keep track of what version of Windows works best with a particular application. This could then be queried on install of the application, or downloaded in bulk. It would be easy to take the data and create a registry file like what winecfg will be saving to. That way, AppDB becomes the place where this is maintained (so it is up to the individual maintainers to set the Windows version if it doesn't work with the default version) and there are no ugly heuristics involved. - Reece
On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>:
There are some older applications out there, which don't install or run correctly unless Wine is emulating the correct Windows version (eg. Windows 9x).
At least Windows XP has the ability to use certain heuristics to make an educated guess as to which version of Windows the application expects, and then lie in GetVersion() and behave like that version in relevant APIs.
Should we do something like that for Wine? It would allow many applications to work out of the box.
You can change the version of Windows reported for different applications, and the default version using winecfg -> Applications.
I know, but bugs coming up from the wrong default version aren't always obvious (in my case they were registry keys that don't get created during installation).
I'm not sure that adding heuristics would be the correct approach, as those can lead to incorrect results. The winecfg option supports the user being able to change the version of Windows reported for the specified application. The workflow could be better, though (e.g. supporting an option on an exe's right-click menu).
Heuristics aren't necessarily wrong: File Header Machine: 014C (i386) Number of Sections: 6 TimeDateStamp: 31104C75 (Thu Feb 1 07:15:33 1996) offset 136 Feb 1 1996 can't be later than Windows 95.
What would be better is to have AppDB keep track of what version of Windows works best with a particular application. This could then be queried on install of the application, or downloaded in bulk. It would be easy to take the data and create a registry file like what winecfg will be saving to. That way, AppDB becomes the place where this is maintained (so it is up to the individual maintainers to set the Windows version if it doesn't work with the default version) and there are no ugly heuristics involved.
The bulk download would only work if you install applications to their default location, but it seems like a good idea.
- Reece
Damjan
2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>:
On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: You can change the version of Windows reported for different applications, and the default version using winecfg -> Applications.
I know, but bugs coming up from the wrong default version aren't always obvious (in my case they were registry keys that don't get created during installation).
This is where having people contributing to AppDB would be useful. They would know what version of Windows being reported by Wine would work best - even when that changes in the future. This will take some experimentation, but after some investigation it can be figured out.
I'm not sure that adding heuristics would be the correct approach, as those can lead to incorrect results. The winecfg option supports the user being able to change the version of Windows reported for the specified application. The workflow could be better, though (e.g. supporting an option on an exe's right-click menu).
Heuristics aren't necessarily wrong:
File Header Machine: 014C (i386) Number of Sections: 6 TimeDateStamp: 31104C75 (Thu Feb 1 07:15:33 1996) offset 136
Feb 1 1996 can't be later than Windows 95.
Sure. But what if an application was shipped after Vista or Windows Server 2008, but only worked on XP and earlier. Your detection would not work here. Also, what if an application supported XP, but crashed on Wine as it was using some unimplemented call in GDI+. Setting it to Windows 2000, the application works fine. These two cases are where your simple heuristic will break (TimeDateStamp ==> Windows version).
What would be better is to have AppDB keep track of what version of Windows works best with a particular application. This could then be queried on install of the application, or downloaded in bulk. It would be easy to take the data and create a registry file like what winecfg will be saving to. That way, AppDB becomes the place where this is maintained (so it is up to the individual maintainers to set the Windows version if it doesn't work with the default version) and there are no ugly heuristics involved.
The bulk download would only work if you install applications to their default location, but it seems like a good idea.
IIUC, Wine goes by the executable name (e.g. notepad.exe) and not where the application is installed to. The only problems I can see with this is in different versions of applications requiring different reported versions of Windows and any name clashes (if any). - Reece
Reece Dunn wrote:
2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>:
On Sun, Dec 21, 2008 at 11:49 AM, Reece Dunn <msclrhd(a)googlemail.com> wrote:
2008/12/21 Damjan Jovanovic <damjan.jov(a)gmail.com>: You can change the version of Windows reported for different applications, and the default version using winecfg -> Applications. I know, but bugs coming up from the wrong default version aren't always obvious (in my case they were registry keys that don't get created during installation).
This is where having people contributing to AppDB would be useful. They would know what version of Windows being reported by Wine would work best - even when that changes in the future. This will take some experimentation, but after some investigation it can be figured out.
I'm not sure that adding heuristics would be the correct approach, as those can lead to incorrect results. The winecfg option supports the user being able to change the version of Windows reported for the specified application. The workflow could be better, though (e.g. supporting an option on an exe's right-click menu). Heuristics aren't necessarily wrong:
File Header Machine: 014C (i386) Number of Sections: 6 TimeDateStamp: 31104C75 (Thu Feb 1 07:15:33 1996) offset 136
Feb 1 1996 can't be later than Windows 95.
Sure. But what if an application was shipped after Vista or Windows Server 2008, but only worked on XP and earlier. Your detection would not work here.
In that case the user is no worse off - they'd still need to look up AppDB and change their settings with winecfg. I don't see how these two ideas are in contest - we can have both good heuristics and good means for coping with failure (AppDB lookup, right click preferences setting for windows version, etc.) Right now the current heuristic is "always try wine's default", which could easily be improved upon. Thanks, Scott Ritchie
2008/12/21 Scott Ritchie <scott(a)open-vote.org>:
Reece Dunn wrote:
Sure. But what if an application was shipped after Vista or Windows Server 2008, but only worked on XP and earlier. Your detection would not work here.
In that case the user is no worse off - they'd still need to look up AppDB and change their settings with winecfg.
I was intending to have some programming logic to download the data from AppDB and apply this to winecfg/the registry. That way the user does not have to look it up, it becomes something that is updated as part of the install process. For the case where there isn't any AppDB data, the default version of Windows is reported as is done at the moment. - Reece
Reece Dunn wrote:
2008/12/21 Scott Ritchie <scott(a)open-vote.org>:
Reece Dunn wrote:
Sure. But what if an application was shipped after Vista or Windows Server 2008, but only worked on XP and earlier. Your detection would not work here. In that case the user is no worse off - they'd still need to look up AppDB and change their settings with winecfg.
I was intending to have some programming logic to download the data from AppDB and apply this to winecfg/the registry. That way the user does not have to look it up, it becomes something that is updated as part of the install process.
For the case where there isn't any AppDB data, the default version of Windows is reported as is done at the moment.
Right, but none of that would be necessary if the heuristic worked in the first place. By having a good heuristic we could at least dramatically cut down on the apps needing this logic. Thanks, Scott Ritchie
On Sunday 21 December 2008 02:46:37 pm Scott Ritchie wrote:
Right, but none of that would be necessary if the heuristic worked in the first place. By having a good heuristic we could at least dramatically cut down on the apps needing this logic.
But how do you tell when an app needs the Windows version changed because it won't work in the default mode, and it's not just hiding a Wine bug? For example, Wine is buggy with some device drivers, which some games will load in XP mode. Set the Windows version to 98 (or Vista, or sometimes even 2k), and they may not, allowing the game to work. In such a case, you don't want to change the Windows version, you want to fix the bug.
On Mon, Dec 22, 2008 at 1:27 AM, Chris Robinson <chris.kcat(a)gmail.com> wrote:
On Sunday 21 December 2008 02:46:37 pm Scott Ritchie wrote:
Right, but none of that would be necessary if the heuristic worked in the first place. By having a good heuristic we could at least dramatically cut down on the apps needing this logic.
But how do you tell when an app needs the Windows version changed because it won't work in the default mode, and it's not just hiding a Wine bug? For example, Wine is buggy with some device drivers, which some games will load in XP mode. Set the Windows version to 98 (or Vista, or sometimes even 2k), and they may not, allowing the game to work. In such a case, you don't want to change the Windows version, you want to fix the bug.
The heuristic isn't "app works on this Windows version", it's "app is designed for this Windows version". If a heuristic tells you a game needs 98 when it needs XP, the heuristic is broken, even if the game works better in 98 because it doesn't load a driver. Also, the existence of driver loading APIs in DLL imports is probably a good heuristic to tell that an app needs XP. Damjan
On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote:
The heuristic isn't "app works on this Windows version", it's "app is designed for this Windows version".
Should that matter? Plenty of Win95 apps will work in WinXP. Sometimes better, due to the improved functionality/bugfixes XP implicitly provides (I can't say I know which of these features are handled by Wine, but theoretically..). Why force it to Win95 mode when it'll work in WinXP? The apps that don't work in a newer version than they were designed for are a problem, but not one so easilly discovered or solved. I'd imagine most don't have a problem with newer versions, so forcing them to use those older versions for no reason will just end up hiding Wine bugs more than helping buggy apps.
Am 22.12.2008 um 05:16 schrieb Chris Robinson:
On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote:
The heuristic isn't "app works on this Windows version", it's "app is designed for this Windows version".
Should that matter? Plenty of Win95 apps will work in WinXP.
... because WinXP has such a version heuristic already in place? I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
2008/12/22 Markus Hitter <mah(a)jump-ing.de>:
Am 22.12.2008 um 05:16 schrieb Chris Robinson:
Should that matter? Plenty of Win95 apps will work in WinXP.
... because WinXP has such a version heuristic already in place?
I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough.
You could possibly do that for Windows 95 applications (unless the application was written for Windows 3.1 and released in 96), and put an upper version limit on the application, but that doesn't mean that it will work best using the latest version of Windows as reported by Wine. The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say "Vista", but the application will fall over if it is not designed for some of Vista's behaviour. For Wine, this may not be too big an issue as Wine tries to work as any version of Windows, so shouldn't differ in behaviour. Also, it does not matter how well the application works on a Windows box, but how well it currently runs on Wine. If an application supports Vista, but is making some calls that Wine does not support yet, the application is going to break if the Windows version is reported as Vista. Similarly if the application supports XP and GDI+ or themes, but has a fallback path for 2000 and happens to call an API that is missing or broken on Wine. Older applications designed for earlier versions of Windows are more likely to work on Wine, as it is designed to be version independent and doesn't completely change it's implementation with every other release. The only case where this will not work is if the application writers have got the version detection logic wrong and bail out. The main issue is for applications written for newer versions of Windows, or Windows components that are not yet supported, or not completely supported in Wine. These applications may work when set to earlier versions of Windows because they have a fallback to support older versions. - Reece
Am 22.12.2008 um 11:51 schrieb Reece Dunn:
The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say "Vista",
... just like the current-heuristic-less assumption. Undoubtly, there are many cases where a date heuristic doesn't help, but it won't worsen matters either. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/
Markus Hitter <mah(a)jump-ing.de> writes:
Am 22.12.2008 um 11:51 schrieb Reece Dunn:
The same goes for applications released after Vista was released, but only work well on XP. The date heuristic will say "Vista",
... just like the current-heuristic-less assumption. Undoubtly, there are many cases where a date heuristic doesn't help, but it won't worsen matters either.
It definitely will. There are many cases where reporting Win9x even for an old app will actually break things, because we don't (and can't) implement the Win9x architecture. -- Alexandre Julliard julliard(a)winehq.org
On Sunday 21 December 2008 07:48:58 pm Damjan Jovanovic wrote:
The heuristic isn't "app works on this Windows version", it's "app is designed for this Windows version".
Should that matter? Plenty of Win95 apps will work in WinXP.
... because WinXP has such a version heuristic already in place?
I think it's perfectly possible to do an heuristic which is sometimes useful, but never harms. As already mentioned, the age of the installer/installed files is such a data point: Apps written in 1996 are never ever designed to run on WinXP. It's a matter of being conservative enough.
The way Windows solves application compatibility is way, way, way more involved then a date check or checking the build id an app. Basically microsoft ships its own 'appdb' which contains the windows version an app wants to see and in general much, much more things. For instance their appdb allows windows to override the return values of functions, it can fake the presence of certain files/directories/registry keys, it can perform memory hacks and so on. Adding an automatic mechanism to Wine creates much more issues thant it solves. If someone wants to create something like this the best thing would be to have a proper appdb which can somehow be exported to lets say a xml file. Just look for a page on windows application compatibility / shim engine and you see how huge it is. (http://technet.microsoft.com/en-us/library/bb457032.aspx for instance see the application management console shot there) Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
2008/12/22 Roderick Colenbrander <thunderbird2k(a)gmx.net>
Basically microsoft ships its own 'appdb' which contains the windows version an app wants to see and in general much, much more things. For instance their appdb allows windows to override the return values of functions, it can fake the presence of certain files/directories/registry keys, it can perform memory hacks and so on.
Something like that, not necessarily as a core part of wine but a side project in the manner of winetricks, might actually be a good idea from a user's point of view. A wine app launcher that maintains a list of known applications and the compatibility tweaks that are required in order to get them to run, or at least offer sensible advice (eg, where an app requires a native dll that is missing in order to work correctly). Its database would, I guess, be against app name and wine version, and then as wine improved it would need to do less and less. -- Chris
On Sun, Dec 21, 2008 at 11:19:35AM +0200, Damjan Jovanovic wrote:
Hi
There are some older applications out there, which don't install or run correctly unless Wine is emulating the correct Windows version (eg. Windows 9x).
At least Windows XP has the ability to use certain heuristics to make an educated guess as to which version of Windows the application expects, and then lie in GetVersion() and behave like that version in relevant APIs.
Should we do something like that for Wine? It would allow many applications to work out of the box.
We had this ;) It was removed for being mostly unnecessary and that one Wine session should report one Windows version (even when different Windows programs run). Ciao, Marcus
participants (10)
-
Alexandre Julliard -
Austin English -
Chris Howe -
Chris Robinson -
Damjan Jovanovic -
Marcus Meissner -
Markus Hitter -
Reece Dunn -
Roderick Colenbrander -
Scott Ritchie