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.