Hi
I'm writing a small application to automate the process of setting Windows version for executables that are known to require a specific one. I'd like it to use the knowledge about defining Windows versions contained in winecfg/appdefaults.c instead of duplicating/forking code from it.
Would it be ok to move on_winver_change() and some of its friends like win_versions[] and set_reg_key() to libwine.so.1 for this purpose ?
Hi,
On Dec 27, 2007 4:50 PM, Robert Millan rmh@aybabtu.com wrote:
I'm writing a small application to automate the process of setting Windows version for executables that are known to require a specific one. I'd like it to use the knowledge about defining Windows versions contained in winecfg/appdefaults.c instead of duplicating/forking code from it.
Would it be ok to move on_winver_change() and some of its friends like win_versions[] and set_reg_key() to libwine.so.1 for this purpose ?
How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like
winecfg foo.exe --winver win98 --dll=gdiplus.dll=n
Then all you need is a script for your known bad applications....
Thanks Steven
On Dec 28, 2007 5:43 AM, Steven Edwards winehacker@gmail.com wrote:
How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like
winecfg foo.exe --winver win98 --dll=gdiplus.dll=n
Then all you need is a script for your known bad applications....
Actually, another way you could do it is to use inf files and store them in a database. We discussed something like this for the appdb. Using inf's would be a cleaner method than hacking winecfg to automate importing this data in to the registry and then everyone can use it. I'd suggest if you know of an application thats buggy, needs the version and dll information hard set, you try the inf route and submit it to appdb if its an application listed there.
Thanks
On Fri, Dec 28, 2007 at 05:49:39AM -0500, Steven Edwards wrote:
On Dec 28, 2007 5:43 AM, Steven Edwards winehacker@gmail.com wrote:
How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like
winecfg foo.exe --winver win98 --dll=gdiplus.dll=n
Then all you need is a script for your known bad applications....
Actually, another way you could do it is to use inf files and store them in a database. We discussed something like this for the appdb. Using inf's would be a cleaner method than hacking winecfg to automate importing this data in to the registry and then everyone can use it. I'd suggest if you know of an application thats buggy, needs the version and dll information hard set, you try the inf route and submit it to appdb if its an application listed there.
I was thinking in doing something like this already, but you still need a way to set winver, so it boils down to either sharing code with winecfg or duplicating it.
I'd like to avoid duplication if possible.
On Dec 29, 2007 10:45 AM, Robert Millan rmh@aybabtu.com wrote:
I was thinking in doing something like this already, but you still need a way to set winver, so it boils down to either sharing code with winecfg or duplicating it.
I'd like to avoid duplication if possible.
I am not sure where the global winver is set but I am sure its still in the registry so you can change it with a registry key as Julliard said. For just running per-application all you need to do is set it as HKCU\Software\Wine\AppDefaults\foo.exe\Version which is a string resource, again this can be done via a reg file that regedit can import. Thats even less complicated then then inf route I suggested.
Do you mean you have a situation like a broken application AND installer that only works under win98 but the default version is win2000? Maybe you only want that installer to run in win98 mode but the rest of wine to run in win2000 mode? Wine used to have the -winver option I think and CrossOver has this setting but I can't see anyway to set the windows version on the command line for a buggy installer. The solution (which I also think kind of sucks) would be to do something like script
wine regedit add-setup.exe-version.reg wine setup.exe wine regedit remove-setup.exe-version.reg wine regedit add-foo.exe-version.reg wine foo.exe
Of course steps 3 and 4 could be combined in one registry file and 1 and 3 would not even be needed if you could set the version on the command line but we don't seem to support that anymore for quite a long time. I think the solution to have multiple appdefaults with programs having generic names like setup.exe and install.exe is to enhance the support in wine and winecfg application/dlloverrides to use md5sum/sha hashes. I don't know how julliard really feels about this but this is similar to what was discussed with having a custom Wine shim engine for application compatibly. If you were going to change some code and he approves I think this is the route to go.....
So say rather than having
HKCU\Software\Wine\AppDefaults\setup.exe\Version win98
you would have something like
HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version win98 HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename setup.exe
HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\Version win2000 HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\filename setup.exe
This way two installers both named setup.exe can have their own windows version and dlloverrides set.
Thanks Steven
On Dec 29, 2007 10:45 AM, Robert Millan rmh@aybabtu.com wrote:
I was thinking in doing something like this already, but you still need
a
way to set winver, so it boils down to either sharing code with winecfg
or
duplicating it.
I'd like to avoid duplication if possible.
I am not sure where the global winver is set but I am sure its still in the registry so you can change it with a registry key as Julliard said. For just running per-application all you need to do is set it as HKCU\Software\Wine\AppDefaults\foo.exe\Version which is a string resource, again this can be done via a reg file that regedit can import. Thats even less complicated then then inf route I suggested.
Do you mean you have a situation like a broken application AND installer that only works under win98 but the default version is win2000? Maybe you only want that installer to run in win98 mode but the rest of wine to run in win2000 mode? Wine used to have the -winver option I think and CrossOver has this setting but I can't see anyway to set the windows version on the command line for a buggy installer. The solution (which I also think kind of sucks) would be to do something like script
wine regedit add-setup.exe-version.reg wine setup.exe wine regedit remove-setup.exe-version.reg wine regedit add-foo.exe-version.reg wine foo.exe
Of course steps 3 and 4 could be combined in one registry file and 1 and 3 would not even be needed if you could set the version on the command line but we don't seem to support that anymore for quite a long time. I think the solution to have multiple appdefaults with programs having generic names like setup.exe and install.exe is to enhance the support in wine and winecfg application/dlloverrides to use md5sum/sha hashes. I don't know how julliard really feels about this but this is similar to what was discussed with having a custom Wine shim engine for application compatibly. If you were going to change some code and he approves I think this is the route to go.....
So say rather than having
HKCU\Software\Wine\AppDefaults\setup.exe\Version win98
you would have something like
HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version win98 HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename setup.exe
HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\Version win2000 HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\filename setup.exe
This way two installers both named setup.exe can have their own windows version and dlloverrides set.
Thanks Steven
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
The system on windows doesn't use the md5sum (I think it has one) but it looks for the product ID which is burried into most executables first. It also checks for other things but in a hackier way. As there are a lot of different versions of a program but which all need the same override.
Roderick
On Sat, Dec 29, 2007 at 08:51:26PM +0100, Roderick Colenbrander wrote:
The system on windows doesn't use the md5sum (I think it has one) but it looks for the product ID which is burried into most executables first. It also checks for other things but in a hackier way. As there are a lot of different versions of a program but which all need the same override.
I think it's a bad idea to do that:
- Product IDs may not necessarily be unique identifiers for every given program. Hashes are.
- It's easier for users to submit information about their apps if they can use tools they're familiar with such as md5sum / sha1sum.
On Sat, Dec 29, 2007 at 11:18:26AM -0500, Steven Edwards wrote:
you would have something like
HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\Version win98 HKCU\Software\Wine\AppDefaults\b83fd2e8b34ba6b6f59e9f9cfbe129d9\filename setup.exe
HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\Version win2000 HKCU\Software\Wine\AppDefaults\912672566150fd7663fba3a927f79fca\filename setup.exe
Sounds good. It could also be a good idea to have some mechanism so that multiple hashes can point to the same description / setup. Think of the same versioning problem shared by a dozen of different localised versions of an app, etc.
How about something like:
HKCU\Software\Wine\AppDefaults\md5\b83fd2e8b34ba6b6f59e9f9cfbe129d9 foomatic_installer HKCU\Software\Wine\AppDefaults\md5\912672566150fd7663fba3a927f79fca foomatic_installer [ ... ] HKCU\Software\Wine\AppDefaults\foomatic_installer\Version win98 HKCU\Software\Wine\AppDefaults\foomatic_installer\filename setup.exe
(as a bonus, this gives us a short description of what these hashes are referring to)
On Dec 29, 2007 10:45 AM, Robert Millan rmh@aybabtu.com wrote:
I'd like to avoid duplication if possible.
Also as a follow-up again, you can also just hack Dan's winetricks script for your needs as it does the winversion magic with the registry I was talking about. I think doing that would be a hack and if you want to properly fix the problem (if I understand what you need correctly) is to enhance the entire application default override system like I described in the last email.
On Sat, Dec 29, 2007 at 11:23:11AM -0500, Steven Edwards wrote:
On Dec 29, 2007 10:45 AM, Robert Millan rmh@aybabtu.com wrote:
I'd like to avoid duplication if possible.
Also as a follow-up again, you can also just hack Dan's winetricks script for your needs as it does the winversion magic with the registry I was talking about.
I looked at this before, and the winversion magic in that script seems to be just a minor part of what winecfg does.
I think doing that would be a hack and if you want to properly fix the problem (if I understand what you need correctly) is to enhance the entire application default override system like I described in the last email.
Yes. I want to do it right. Should I start working in that direction?
On Dec 29, 2007 5:13 PM, Robert Millan rmh@aybabtu.com wrote:
Yes. I want to do it right. Should I start working in that direction?
I'd like to hear Alexandre's comments for my suggestions. The current application override system bothers me but maybe he has other ideas or I am missing something. The entire system seems to depend too much on the applications name which seems limited to me but maybe he has ideas for a more robust way of tracking dlloverrides and version settings when the application name conflicts.
On Fri, Dec 28, 2007 at 05:43:40AM -0500, Steven Edwards wrote:
Hi,
On Dec 27, 2007 4:50 PM, Robert Millan rmh@aybabtu.com wrote:
I'm writing a small application to automate the process of setting Windows version for executables that are known to require a specific one. I'd like it to use the knowledge about defining Windows versions contained in winecfg/appdefaults.c instead of duplicating/forking code from it.
Would it be ok to move on_winver_change() and some of its friends like win_versions[] and set_reg_key() to libwine.so.1 for this purpose ?
How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like
winecfg foo.exe --winver win98 --dll=gdiplus.dll=n
Yes, I suppose that'll do. Want a patch for --winver ?
Robert Millan rmh@aybabtu.com writes:
On Fri, Dec 28, 2007 at 05:43:40AM -0500, Steven Edwards wrote:
How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like
winecfg foo.exe --winver win98 --dll=gdiplus.dll=n
Yes, I suppose that'll do. Want a patch for --winver ?
It's only a matter of setting a registry key, that can be done easily by calling regedit, there's no need to involve winecfg.
On Sat, Dec 29, 2007 at 01:04:50PM +0100, Alexandre Julliard wrote:
Robert Millan rmh@aybabtu.com writes:
On Fri, Dec 28, 2007 at 05:43:40AM -0500, Steven Edwards wrote:
How about rather than writing another application to do this, you make winecfg take arguments on the command line so you could set something like
winecfg foo.exe --winver win98 --dll=gdiplus.dll=n
Yes, I suppose that'll do. Want a patch for --winver ?
It's only a matter of setting a registry key, that can be done easily by calling regedit, there's no need to involve winecfg.
Looking at winecfg/appdefaults.c, there seems to be several keys involved.
-
Alexandre Julliard -
Robert Millan -
Roderick Colenbrander -
Steven Edwards