"Gerhard W. Gruber" wrote:
On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart aric@codeweavers.com wrote:
Windows 95 and Windows 98: The MoveFileEx function is not supported. To rename or delete a file at reboot, use the following procedure.
To rename or delete a file on Windows 95 and Windows 98 Check for the existence of the WININIT.INI file in the Windows directory. If WININIT.INI exists, open it and add new entries to the existing [rename] section. If the file does not exist, create the file and create a [rename] section. Add lines of the following format to the [rename] section: DestinationFileName=SourceFileName
Both DestinationFileName and SourceFileName must be short filenames. To delete a file, use NUL as the value for DestinationFileName.
The system processes WININIT.INI during system boot. After WININIT.INI has been processed, the system names it WININIT.BAK. <<
So we have exactly what we should do.
I didn't check the NT version, but I already investigated the W95/98 behaviour and tried to implement it as described above.
When I implemented it I noticed a problem with the WritePrivateProfileSection. If I interpret the MSDN description correctly then this function should write all the strings in the buffer to the specified section without doing much processing. Therfore it is possible to create multiple key/value pairs with the same keyname. This is neccessary in the case of wininit.init because the files that are to be deleted all have the key NUL=value. With the current implementation the function uses PROFILE_SetString whch checks for duplicate keys and overwrites it if a key already exists. If I have time tomorrow I will write a small test app for Windows to see how it really behaves, but I thin kthat my interpretation is correct. Otherwise there would have to be some code in windows that handles the wininit.ini file specifically in order to add the same key more than once to the file.
Ok I interpret the MSDN paragraph differently. I read it as meaning that the MoveFileEx function would FAIL. if used with that flag. And that it was the Programs responsibility to write to the WinInit.ini file. In my experience with installers this has been the case. So there is not alot wine has to do, just do a version check and if in Windows 95/98 mode fail. I dont think it is proper for the function to do the writing to wininit.ini.
This i have seen alot, andreas (and others) are working on a utility that will process this wininit file. I have talked to alexandre and we both agree that it is something that probably should not be in wine itself.
Why not? In Win98 there is a Wininit.exe that surely will do this because certain files can't be moved when windows is already running. Since Wine doesn't have this restriction I added the code to process this in the startup somewhere after "if(isbootthread)" because I thought it appropriate there.
The problem is sort of two fold. #1) this is not processing you want to have happen every time wine is started. Only after a reboot or when signaled to do so. There is alot of reboot / windows startup processing that happens (WinInit.ini, RunOnce etc..) and it is best to keep all that processing together. So wine startup starts to get bigger and messy.
#2) Wine does load a number of libraries on boot and if it is one of those libraries that is to be moved then MoveFile will fail. Additionally because the library has already loaded, even if you move the new library into place you would still be using the old version. This would be devastating for programs that run after an install to register new version of dlls.
Take a look at andreas' utility he sent out. It has alot it does but you can see how the wininit.ini processing works. It is also a very easy (maybe 1 hour) project to write up a smaller winelib/unix utility that does the same if that is all you need for you particular situation.
-aric