Bug in MoveFileEx

David Elliott dfe at tgwbd.org
Thu Jan 31 23:20:52 CST 2002


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.
> 
> 
> 
> 




More information about the wine-devel mailing list