I just wrote a fix for a fixme located in MoveFileExA. Since this is the first time I'm writing something for wine I wanted to ask how I shall proceed now. Shall I simply add it into the CVS or does it have to go somewhere for revision?
Also I don't want to submit it right now because my current fix is a bit ugly. The fix is applied for files that should be moved or deleted when windows boots after an application is installed. Currently there was a message telling the user that he has to delete/rename the specified files. Now I added some code that writes an entry in (WINECONFIG)/bootmove and (WINECONFIG)/bootdel when these functions are called. I also added some code in loader/main.c that checks if these files exists and if they do it will open them and deletes/renames the specified files. I hope this solution is acceptable. :) The only ugly thing about this is that the filenames for bootmove and bootdel are curerntly hardcoded where I need them. I don't know if there is a global space somewhere where I can add some fixed names so I did it this way for now, but this is not the best way in case the names should be changed or something and also I don't like hardecoded names.
Another drawback of this approach is that it would be possible that more than one process is writing or reading at the same time there could be potential problems, so I'd like to hear some opinions if this is ok.
On Wed, 30 Jan 2002, Gerhard W. Gruber wrote:
I just wrote a fix for a fixme located in MoveFileExA. Since this is the first time I'm writing something for wine I wanted to ask how I shall proceed now. Shall I simply add it into the CVS or does it have to go somewhere for revision?
Only Alexandre has commit access to the CVS. To submit code for inclusion in Wine you should post a 'diff -u' patch to '[email protected]'. There everyone will be able to review it and Alexandre will apply it if he thinks it's ok. The Wine Developpers Guide has slightly more detailed instructions:
http://wine.codeweavers.com/docs/wine-devel/patches.shtml
Also I don't want to submit it right now because my current fix is a bit ugly.
You can also post your patch to wine-devel if you want help. There we can all discuss what 'the right fix' is :-)
The fix is applied for files that should be moved or deleted when windows boots after an application is installed. Currently there was a message telling the user that he has to delete/rename the specified files. Now I added some code that writes an entry in (WINECONFIG)/bootmove and (WINECONFIG)/bootdel when these functions are called. I also added some code in loader/main.c that checks if these files exists and if they do it will open them and deletes/renames the specified files. I hope this solution is acceptable. :)
I believe that Windows stores the list of files to move/delete somewhere in the registry. We should probably do the same... It seems that adding keys in the registry would be better than creating new files in any case.
-- Francois Gouget [email protected] http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
On Wed, 30 Jan 2002, Gerhard W. Gruber wrote:
Also I don't want to submit it right now because my current fix is a bit ugly. The fix is applied for files that should be moved or deleted when windows boots after an application is installed. Currently there was a message telling the user that he has to delete/rename the specified files. Now I added some code that writes an entry in (WINECONFIG)/bootmove and (WINECONFIG)/bootdel when these functions are called. I also added some code in loader/main.c that checks if these files exists and if they do it will open them and deletes/renames the specified files. I hope this solution is acceptable. :) The only ugly thing about this is that the filenames for bootmove and bootdel are curerntly hardcoded where I need them. I don't know if there is a global space somewhere where I can add some fixed names so I did it this way for now, but this is not the best way in case the names should be changed or something and also I don't like hardecoded names.
Another drawback of this approach is that it would be possible that more than one process is writing or reading at the same time there could be potential problems, so I'd like to hear some opinions if this is ok.
Windows stores this information in c:\windows\wininit.ini, and several installers access this file directly. Using Get/SetPrivateProfileString should make accessing the file better protected from simultaneous access. Format of wininit.ini:
[rename] c:\newfilename=c:\oldfilename nul=c:\filetodelete
I think Andreas Mohr may already have done some work on this though?
On Wed, 30 Jan 2002 10:21:57 -0800 (PST), Francois Gouget [email protected] wrote:
Only Alexandre has commit access to the CVS. To submit code for inclusion in Wine you should post a 'diff -u' patch to '[email protected]'. There everyone will be able to review it and Alexandre will apply it if he thinks it's ok. The Wine Developpers Guide has slightly more detailed instructions:
Thanks for the link. I would have thought it a bit weird anyway if anybody would have write access to such a big project. :)
You can also post your patch to wine-devel if you want help. There we can all discuss what 'the right fix' is :-)
Basically it is just the question if there is a file where global names or variables are collected. I don't know if such a thing exists, but I think it has to because I guess that certain parameters like the command line switches have to be available almost anywhere.
I believe that Windows stores the list of files to move/delete somewhere in the registry. We should probably do the same... It seems that adding keys in the registry would be better than creating new files in any case.
OK. I take a look at how windows handles this. Of course it is a better way to do it the way, windows handles it to be as compatible to the original as possible.
Actually I would have preferred to start with a different function, but then I thought this functions is nice and easy to start working on wine. :) It's a bit complex. :)
"Francois" == Francois Gouget [email protected] writes:
Francois> On Wed, 30 Jan 2002, Gerhard W. Gruber wrote: ... Francois> I believe that Windows stores the list of files to Francois> move/delete somewhere in the registry. We should probably do Francois> the same... It seems that adding keys in the registry would be Francois> better than creating new files in any case.
At least Win95 and decendants store the file in <windows>/wininit.ini.
Bye
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am Wednesday 30 January 2002 21:41 schrieb Uwe Bonnes:
"Francois" == Francois Gouget [email protected] writes:
Francois> On Wed, 30 Jan 2002, Gerhard W. Gruber wrote:... Francois> I believe that Windows stores the list of files to Francois> move/delete somewhere in the registry. We should probably do Francois> the same... It seems that adding keys in the registry would be Francois> better than creating new files in any case.
At least Win95 and decendants store the file in <windows>/wininit.ini.
Yes, because registry access isn't available yet when wininit.ini is handled during booting. That's what happens during the "Configuration files are being updated" ... "Done" (roughly translated from German, guess you know what I mean) while the boot logo is displayed. BTW, no idea why they call it "configuration files" :) Imagine kernel32, advapi or something else is being replaced...can't use the registry for it. The format of wininit.ini is pretty simple: ever line is like newname=oldname and causes the file named oldname to be renamed to newname. If newname is nul, the file is deleted. - -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]
My turn to chime in, I have done a fair bit of reboot processing stuff.. first here is what msdn says
If the dwFlags parameter specifies MOVEFILE_DELAY_UNTIL_REBOOT, MoveFileEx stores the locations of the files to be renamed at reboot in the following registry value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
The function fails if it cannot access the registry.
The PendingFileRenameOperations value is of type REG_MULTI_SZ. Each rename operation stores a pair of NULL-terminated strings. The system uses these registry entries to complete the operations at reboot in the same order that they were issued. For example, the following code fragment creates registry entries that delete szDstFile and rename szSrcFile to be szDstFile at reboot:
MoveFileEx(szDstFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT); MoveFileEx(szSrcFile, szDstFile, MOVEFILE_DELAY_UNTIL_REBOOT);
The system stores the following entries in PendingFileRenameOperations:
szDstFile\0\0 szSrcFile\0szDstFile\0\0
Because the actual move and deletion operations specified with the MOVEFILE_DELAY_UNTIL_REBOOT flag take place after the calling application has ceased running, the return value cannot reflect success or failure in moving or deleting the file. Rather, it reflects success or failure in placing the appropriate entries into the registry.
The system deletes a directory tagged for deletion with the MOVEFILE_DELAY_UNTIL_REBOOT flag only if it is empty. To ensure deletion of directories, move or delete all files from the directory before attempting to delete it. Files may be in the directory at boot time, but they must be deleted or moved before the system can delete the directory.
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.
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.
-aric
Malte Starostik wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am Wednesday 30 January 2002 21:41 schrieb Uwe Bonnes:
> "Francois" == Francois Gouget [email protected] writes:
Francois> On Wed, 30 Jan 2002, Gerhard W. Gruber wrote:... Francois> I believe that Windows stores the list of files to Francois> move/delete somewhere in the registry. We should probably do Francois> the same... It seems that adding keys in the registry would be Francois> better than creating new files in any case.
At least Win95 and decendants store the file in <windows>/wininit.ini.
Yes, because registry access isn't available yet when wininit.ini is handled during booting. That's what happens during the "Configuration files are being updated" ... "Done" (roughly translated from German, guess you know what I mean) while the boot logo is displayed. BTW, no idea why they call it "configuration files" :) Imagine kernel32, advapi or something else is being replaced...can't use the registry for it. The format of wininit.ini is pretty simple: ever line is like newname=oldname and causes the file named oldname to be renamed to newname. If newname is nul, the file is deleted.
Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE8WJWMVDF3RdLzx4cRApncAKCFLIv32C+97uaTRq4UfXpFYFBASQCfezGw R80SYovvkyrywtu94xj+PnU= =NmRY -----END PGP SIGNATURE-----
Hi everybody,
Is anyone working on implementation of SetupAPI? Otherwise I'm thinking about taking a look at it...
Best Regards,
Stefan Görling
On Thu, Jan 31, 2002 at 03:39:11PM +0100, Stefan Görling wrote:
Hi everybody,
Is anyone working on implementation of SetupAPI? Otherwise I'm thinking about taking a look at it...
Not at the moment.
I used to implement some parts of SETUPX (and thus some SETUPAPI stuff, too), but I don't have time for "real" stuff right now.
So just go ahead immediately :)
On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart [email protected] 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.
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.
On Thu, Jan 31, 2002 at 07:50:53PM +0100, Gerhard W. Gruber wrote:
On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart [email protected] wrote:
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.
Please, please, please not even more duplication ! I really don't want to know how many times wininit.ini stuff has been implemented/semi-implemented/...
If you *really* want to do some stuff, then get http://home.nexgo.de/andi.mohr/download/winebootup.tar.bz2 and start improving its wininit.ini handling (this needs improving, AFAIK).
Questions ? Just ask.
Dear Andreas,
So just go ahead immediately :)
I'm right on it.
A Simple stupid question. Is there a simple way to read a line from a HANDLE or a unixhandle? I've looked a bit at ReadFile (file/file.c) but I'm lazy, so if there is a better way :)
/Stefan
On Thu, 31 Jan 2002 20:25:32 +0100, Andreas Mohr [email protected] wrote:
Please, please, please not even more duplication ! I really don't want to know how many times wininit.ini stuff has been implemented/semi-implemented/...
I didn't knew that there is already something.
If you *really* want to do some stuff, then get http://home.nexgo.de/andi.mohr/download/winebootup.tar.bz2 and start improving its wininit.ini handling (this needs improving, AFAIK).
OK. I just downloaded it. I hope I know how to open bz2. :)
Questions ? Just ask.
Why is the To: field or the Reply-To: not set to the mailinglist instead of the poster?
"Gerhard W. Gruber" wrote:
On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart [email protected] 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
On Thu, 31 Jan 2002 15:36:55 -0600, Aric Stewart [email protected] wrote:
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
You are right. I just looked up the MSDN paragraph and it says that this function is not supported on W95/98.
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.
I have a program "Thandor" which installer uses this function. I check if it creates the wininit.ini file manually. I only noticed the fixme message that told me to rename files manually and I thought that annyoing so I tried to fix it. At that time I didn't knew about that wininit.ini file so I didn't check if it exists. What I also noticed now is that there appears to be a difference between wine win98 and real win98. When I install this program under Win98 it simply installs and I can run it immediatly. When I install it under wine with --winver win98 at the end a dialog pops up that tells me if I want to reboot or not. Since I have only win98 and NT installed I can't check if this behaviour is under win95 but there is obviously something different here.
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.
I already checked that file Andreas showed me and I'll work on this now instead. I agree that the code should be seperated as cleanly as possible so I have no problem with that.
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.
I don't want to do it for me specifically because I don't need that program to run under linux. If I work on it then I want it to be integrated in wine. I have no problem parsing the wininit.ini file myself, as this is a rather easy job, as you said. I think I already wrote some years ago a function that does this because windows wasn't so popular then. :)
On 2002.01.31 16:02 Gerhard W. Gruber wrote: [snip]
OK. I just downloaded it. I hope I know how to open bz2. :)
I assume that was a joke.
[snip]
Why is the To: field or the Reply-To: not set to the mailinglist instead of the poster?
hehehee.... READ THE ARCHIVES!
We need to have an FAQ on this somewhere on the website.
-Dave
On Thu, Jan 31, 2002 at 10:21:34PM -0500, David Elliott wrote:
On 2002.01.31 16:02 Gerhard W. Gruber wrote: [snip]
OK. I just downloaded it. I hope I know how to open bz2. :)
I assume that was a joke.
[snip]
Why is the To: field or the Reply-To: not set to the mailinglist instead of the poster?
hehehee.... READ THE ARCHIVES!
We need to have an FAQ on this somewhere on the website.
OK, added to www.winehq.com/FAQ
Unfortunately checking my WD archive did NOT help. I know that there's been a rather longish thread about this, but grepping for e.g. list.*Reply-To Reply-To.*list Reply-To " Reply-To" reply.*list list.*reply " reply"
yielded - you guessed it - nothing.
-
Andreas Mohr -
Aric Stewart -
David Elliott -
Francois Gouget -
Gerhard W. Gruber -
Malte Starostik -
Ove Kaaven -
Stefan Görling -
Uwe Bonnes