Concerning the boot procedure for renaming/deleting files

[Gerhard W. Gruber]

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.