I just played around with Thandor trying to install it and see what the differences are between Win98 and Wine because I noticed a slightly different behaviour. Now I discovered that MoveFileEx is not even available in Windows 98 but wine supplies it nevertheless. I suspect that the Setup doesn't check the windows version, but rather calls MoveFileEx and if that fails with not implemented returncode continues with other code to supply the functionality. I wrote a small test app to confirm this and this returns an error code when calling MoveFileEx on a native win98 whiel wine executes it.
How shall I fix this? Shall I simply call GetVersion() to determine if MoveFileEx should be allowed or is there a different way with wine to determine which functions are available for which version (a global variable or such)? I looked through the sources but I couldn't find anywhere something where a versioncheck has been used to switch code but then again I don't know much functions where I know for sure that they are available in one version and not in the other.
On 2002.01.31 18:37 Gerhard W. Gruber wrote:
I just played around with Thandor trying to install it and see what the differences are between Win98 and Wine because I noticed a slightly different behaviour. Now I discovered that MoveFileEx is not even available in Windows 98 but wine supplies it nevertheless. I suspect that the Setup doesn't check the windows version, but rather calls MoveFileEx and if that fails with not implemented returncode continues with other code to supply the functionality. I wrote a small test app to confirm this and this returns an error code when calling MoveFileEx on a native win98 whiel wine executes it.
Okay, so wine supplies the MoveFileEx function (like NT) for all versions. If you had read the archives you'd know that the chances of hell freezing over are greater than the chances of version specific behavior being added to Wine.
If MoveFileEx actually works and puts the info in the registry the NT way, then the only problem you'd have is if an application happened to actually check the windows version and use that to decide if it should call MoveFileEx or write to WININIT.INI directly.
I suspect that most applications are going to behave like you suggest. That is that they will call MoveFileEx and if it succeeds then they will assume the file is going to get replaced (which see below for how Wine will do that). If MoveFileEx fails then they will add an entry to wininit.ini. That's not a problem because Wine's call should always succeed.
Now, for the latter case where the app checks the windows version. Well, if it happens to write directly to WININT.INI instead of calling MoveFileEx, then no big deal. We will have code that reads both WININIT.INI and the NT-style registry entries.
Considering that on Windows 9x/ME the WININIT.EXE program takes care of this, might I suggest that we create a winelib application (placed in the programs/ directory of the sourcetree) that reads in the registry entries and the WININIT.INI flle and process the entries and deletes them. Such a program I think would be aptly named simply "wininit".
Now the trick is to somehow actually get the user to run the wininit winelib program when needed. Personally I feel that this is secondary. It could simply be accomplished by a wrapper shell script. The important thing is to get the functionality described above implemented, and document that when an installer asks for a reboot you should close all wine applications and run the wininit command to cause the files to be copied. Of course with Wine more than likely you will not need to close anything and can simply run wininit while other unrelated processes are still running.
I assume whatever Andi's program does would probably be similar to what I am describing.
-Dave
How shall I fix this? Shall I simply call GetVersion() to determine if MoveFileEx should be allowed or is there a different way with wine to determine which functions are available for which version (a global variable or such)? I looked through the sources but I couldn't find anywhere something where a versioncheck has been used to switch code but then again I don't know much functions where I know for sure that they are available in one version and not in the other.
-- Bye, Gerhard If you think education is expensive, try ignorance.
David Elliott wrote:
Okay, so wine supplies the MoveFileEx function (like NT) for all versions. If you had read the archives you'd know that the chances of hell freezing over are greater than the chances of version specific behavior being added to Wine.
Is this a principle decision for wine or is this just resignation that it would be almost impossible to promise such a thing? I think this may be also a philosophical question but I think that wine tries to emulate windows. This means to me that we should emulate windows where we know how it is to be done. Of course there will be a great many places where this is not the case, but this should be considered a bug IMO. I didn't read the archives, because it's quite some text to read, so if you could be a more specific if this has already been decided on, then I would appreciate a pointer.
If MoveFileEx actually works and puts the info in the registry the NT way, then the only problem you'd have is if an application happened to actually check the windows version and use that to decide if it should call MoveFileEx or write to WININIT.INI directly.
On the other hand, if we know that MoveFileEx exhibits a certain behaviour then we should do it as it is implemented in the real thing, because you can never know what else may depend on it. I think it is much harder to trakc such a bug down, when it is "fixed" wrongly but everyone thinks it is good enough. Especially since we have to implement both ways anyway, it doesn't hurt and will improve compatibillity, which I think should be the goal of wine. If it's just enough to satsify one application then my first approach works as good as any other, even if it is ugly. But I don't want to get my specific app running just to try a few months later another app and it has to start all over again. Analyze the problem and realize that it is the same thing that would have been fixed if it were done properly the first time. Especially since we know that the behaviour should be different.
I suspect that most applications are going to behave like you suggest. That is that they will call MoveFileEx and if it succeeds then they will assume the file is going to get replaced (which see below for how Wine will do that). If MoveFileEx fails then they will add an entry to wininit.ini. That's not a problem because Wine's call should always succeed.
In that particular case, but MoveFileEx has more features and I don't think that you can say for sure that there is not quite a number of applications that will crash or destroy something because it doesn't work as it should.
Now, for the latter case where the app checks the windows version. Well, if it happens to write directly to WININT.INI instead of calling MoveFileEx, then no big deal. We will have code that reads both WININIT.INI and the NT-style registry entries.
Right.
Considering that on Windows 9x/ME the WININIT.EXE program takes care of this, might I suggest that we create a winelib application (placed in the programs/ directory of the sourcetree) that reads in the registry entries and the WININIT.INI flle and process the entries and deletes them. Such a program I think would be aptly named simply "wininit".
The sources, that Andreas provided are more or less that.
Now the trick is to somehow actually get the user to run the wininit winelib program when needed. Personally I feel that this is secondary. It could simply be accomplished by a wrapper shell script. The important thing is to get the functionality described above implemented, and
That's what I try to do. :)
On Fri, Feb 01, 2002 at 11:58:51AM +0100, Gerhard W. Gruber wrote:
David Elliott wrote:
Okay, so wine supplies the MoveFileEx function (like NT) for all versions. If you had read the archives you'd know that the chances of hell freezing over are greater than the chances of version specific behavior being added to Wine.
Is this a principle decision for wine or is this just resignation that it would be almost impossible to promise such a thing? I think this may
This is a principle decision.
Adding version checks leads to certain madness and insanity, and creates undebuggable problems.
be also a philosophical question but I think that wine tries to emulate windows. This means to me that we should emulate windows where we know how it is to be done. Of course there will be a great many places where this is not the case, but this should be considered a bug IMO. I didn't read the archives, because it's quite some text to read, so if you could be a more specific if this has already been decided on, then I would appreciate a pointer.
Apply common sense and clean implementation first.
Use version checks only when absolutely needed.
Ciao, Marcus
On Fri, 1 Feb 2002, Gerhard W. Gruber wrote:
I just played around with Thandor trying to install it and see what the differences are between Win98 and Wine because I noticed a slightly different behaviour. Now I discovered that MoveFileEx is not even available in Windows 98 but wine supplies it nevertheless. I suspect that the Setup doesn't check the windows version, but rather calls MoveFileEx and if that fails with not implemented returncode continues with other code to supply the functionality. I wrote a small test app to confirm this and this returns an error code when calling MoveFileEx on a native win98 whiel wine executes it.
How shall I fix this? Shall I simply call GetVersion() to determine if MoveFileEx should be allowed or is there a different way with wine to determine which functions are available for which version (a global variable or such)? I looked through the sources but I couldn't find anywhere something where a versioncheck has been used to switch code but then again I don't know much functions where I know for sure that they are available in one version and not in the other.
Why is it a problem? There is no guarantee Wine will be run with the same --winver next time, so the "boot" utility or startup code has to handle both idiotic mechanisms. It is not important to _me_ that Wine should be exactly as Windows, only that it should work well.
If an app that people find useful refuses to work at all if it finds functions that it thinks should not be there, I guess we might have to cater for it, but I'd rather not.
Lawson
-
David Elliott -
Gerhard W. Gruber -
lawson_whitney＠juno.com -
Marcus Meissner