Something not to do with licencing, I hope that poeple have time for this as well. :)
I've submitted a patch that is the preliminary for processing the files that are installed with a setup in order to be deleted/renamed when windows boots. The files are now entered into the registry as I have seen how it is done on NT4.0. I have now some questions regarding this.
1.) When I verified this with a testprogram on NT I noticed that the MoveFileEx code enters the names like this ??\D:\test.exe[0] !??\D:\Test_renamed.exe[0] [0]
Does anybody know what the ??\ stands for and wether the '1' for the renaming entry has some function? I coudn't find anything regarding this and I hardcoded this as to now.
2.) I've looked into the program winebootup from Andreas Morh and I could finish this (at least regarding the boot processing for now). BUt I don't see the advantage of having a seperate program that does some stuff that should be done when a wine process starts up.
When I check if there is something to process this takes a trivially small time, so performance can't be the issue. I don't really like the idea of having a seperate program for this because in my opinion it belongs into the wine startup code to do this sort of work. Also I think that this will lead to additional questions because people will install programms and then wonder why it doesn't work after successfull installation, so they will ask whats wrong (and I gues this will happen again and again). Furthermore I bet that most people may forget about this secondary program that is needed to run because setup is not done that often once a system is set up properly so people might tend to forget about it. The other thing could be that this secondary program will substitute the startupe program in which case there is no need for a second program in the first place.
Any opinions on how to best integrate the boot processing?
Gerhard W. Gruber wrote:
Does anybody know what the ??\ stands for and wether the '1' for the
I cannot answer the second part, but the ??\ is Windows NT's answer to / - it is the root of the filesystem that is visible from within the NT kernel. Various device files, and mounted file systems are visible here, like a Unix "/" directory.
"David D. Hagood" wrote:
I cannot answer the second part, but the ??\ is Windows NT's answer to / - it is the root of the filesystem that is visible from within the NT kernel. Various device files, and mounted file systems are visible here, like a Unix "/" directory.
Ok. Thanks. So it is save to hardcode this I guess.
"Gerhard W. Gruber" wrote:
Does anybody know what the ??\ stands for and wether the '1' for the
This was a typo. It should read '!' instead of '1'.
On 2002.02.18 11:58 Gerhard W. Gruber wrote:
[SNIP]
When I check if there is something to process this takes a trivially small time, so performance can't be the issue. I don't really like the idea of having a seperate program for this because in my opinion it belongs into the wine startup code to do this sort of work. Also I think that this will lead to additional questions because people will install programms and then wonder why it doesn't work after successfull installation, so they will ask whats wrong (and I gues this will happen again and again). Furthermore I bet that most people may forget about this secondary program that is needed to run because setup is not done that often once a system is set up properly so people might tend to forget about it. The other thing could be that this secondary program will substitute the startupe program in which case there is no need for a second program in the first place.
The problem with doing it in the wine startup code is that it means you will have to shut down all wine processes and the server and then start something up again for it to do the changes. That means essentially doing a "reboot" of wine. Yes, I know that the whole point of this functionality is to do this on reboot but on UNIX this is not necessary. It is conceivable to have one program running in wine, to install another program, and when the installer finishes to simply run the winebootup or whatever Winelib program to do the processing while still having whatever other apps open in the background.
Any opinions on how to best integrate the boot processing?
Well, for one thing you could always use a wrapper shell script around wine or something. Or maybe you could have the wine startup code run the wineboot program (I'd suggest not, but if you feel you must then make it configurable).
It's conceivable that one would want to start a wineserver -p (persistent mode) when logging into the GUI which would then allow the user to start up windows applications as quickly as UNIX applications start. With some binfmt_misc magic it's conceivable that a user could run a windows program as easily has she runs a Linux program.
-Dave
David Elliott wrote:
The problem with doing it in the wine startup code is that it means you will have to shut down all wine processes and the server and then start something up again for it to do the changes. That means essentially doing a "reboot" of wine. Yes, I know that the whole point of this
I wouldn't be glad with such a solution, as it is most often not neccessary to really shut down all applications in order to get a reboot working. In the loader/main.c I'm not sure if this function I think it shouldn't be neccessary as there is a if clause which asks if the thread starting up is the first one. So my guess was that, if it is placed outside the if it would be run through for every application, but I hadn't had time to verify this yet.
functionality is to do this on reboot but on UNIX this is not necessary. It is conceivable to have one program running in wine, to install another program, and when the installer finishes to simply run the winebootup or whatever Winelib program to do the processing while still having whatever other apps open in the background.
I prefer this approach. Matter of fact it is mostly in windows also that it isn't often neccessary to reboot. Another idea was to place the reboot code for that particular thing in the exit code of an application thread. This way it is done when the application exits. This has another advantage because it is not neccessary to start wine up one tim ein order to do the processing, nor is it neccessary to have another application starting.
Well, for one thing you could always use a wrapper shell script around wine or something. Or maybe you could have the wine startup code run the wineboot program (I'd suggest not, but if you feel you must then make it configurable).
That could be a solution. The problem with wineboot is that it doesn many things as well, not only preparing the filenames ready for deleting/moving.
It's conceivable that one would want to start a wineserver -p (persistent mode) when logging into the GUI which would then allow the user to start up windows applications as quickly as UNIX applications start. With some
That's not a problem. As I said, the check for bootfiles is not really a performance issue and if all the other things are implemented as well, that are put into wineboot it might still be a problem because this program also processes the RunOnce and the other registry keys that are used to start applications in the background (which would certainly decrease the startup time). And thinking of that it is quite logical to put that stuff into the wineserver startup code because this is the place where we know that it is starting for the first time. We don't want to run all the background processes everytime another application is started, anyway.
binfmt_misc magic it's conceivable that a user could run a windows program as easily has she runs a Linux program.
Is application startuop really a performance problem? I don't think that many users would run batch files or something in wine, where it would matter. Most apps will be started once and then used for some time, but that depends on the user behaviour.
-
David D. Hagood -
David Elliott -
Gerhard W. Gruber