Bootprocedure again

[David Elliott]

First of all, it'd be nice if you used "Reply All" so I wouldn't have to 
comb through the list to respond.. but no biggie really.

On 2002.02.24 09:03 Gerhard W. Gruber wrote:
> David Elliott wrote:
> 
> > To really follow the UNIX philosophy you want to put it in a seperate
> > application.  Save yourself a lot of trouble trying to figure out where
> to
> > place a hook in wine and simply write it into a completely seperate
> > program.  You can then have wine actually run that program with a
> > CreateProcess call or similar at whatever point.  The code to do this
> > should NOT be in the wine emulators source code itself, nor do I
> believe
> > it should be linked in with it.
> 
> But one argument was that it would be to performance intensive. Creating
> a seperate process is much more intensive then checking for a single
> registry key.
> 
First and foremost should be good design.  Good design means you don't do 
anything in the wine emulator startup except get the emulator running.  
Eventually I think Alexandre wants to remove all of the code that is run 
in the address space of the first loaded process somewhere more 
appropriate.  Adding code here is probably the last thing he wants someone 
to do.

> > Windows itself (win9x/me at least) actually has this code in
> WININIT.EXE
> > which is loaded early on in the boot process.  It is not necessary or
> even
> 
> But this has to be loaded every time. Or at least there must be some
> check done every time in order to determine wether it should be run. Do
> you know how Windows handles this?
> 
Well, WININIT does other stuff I believe like actually setup the GDI/USER 
structures.  I may not be correct about that though.  For the most part 
though, WININIT is something that is started when windows is booted.  I 
think eventually we want to have a similar thing and this is where Andi's 
wineboot is going.  I could be wrong though as I am not Andi.

It would be highly appropriate to process these files in the wineboot 
program.  I also think it would be desirable to have a way to process the 
files while wine is still running so a quick'n'dirty solution to that 
problem is something like a "--processfilesonly" switch to the wineboot 
program.  A better solution would be to simply check if wine has already 
been booted and if it has then only do stuff which would make sense to do 
while wine is already booted up (like process the rename files list).

> > desirable to have the code in the emulator itself.  It is much more
> > desirable to have it be a completely seperate program.  Leave it to the
> > distributors of Wine to implement the actual policy and only provide
> the
> > mechanism.  This is what Alexandre has been saying, and I am saying the
> > same thing.  Policy decisions do not belong in Wine, even as
> configuration
> > options when it can be helped.  If you feel you absolutely MUST have
> this
> > run every time a wine program is started or every time a wine program
> > finishes (maybe this would be better) then write a shellscript like so:
> >
> > #!/bin/sh
> > wine "$@"
> > wine_movefiles
> >
> > This is so simple, why would you even waste your time trying to hack it
> > into the boot code for wine?
> 
> My prefered way of doing this, independently of having it as a seperate
> program or included in wine, is to find a way to start it exactly when
> it is needed. I hate to run it everytime when wine starts/ends or in a
> batchscript or such. The ideal solution would be to start it when it is
> really needed.
> 
I think you are much too concerned with performance and not concerned 
enough with good design.  Actually, my script was a little off as if no 
other background wine processes are running it will stop the wineserver 
after the first program finishes and then start it up again to run 
wine_movefiles.

You'll notice that if you run wineserver -p and then start up some program 
and quit it to get the bootup code executed that every wine program you 
run after that will actually start pretty quickly.

The important thing is to get the code implemented in something like 
wineboot.  Leave it to the distributors/users to decide how this gets 
executed.

On your system you may want the file processing code to run directly after 
you have run a program.  In this case you simply use something like the 
shell script above or you put in a CreateProcess call somewhere in the 
process exit code for wine.  If you feel that you must you can only run 
the program after checking to see if the registry keys exist.  However, I 
think you will notice that running a small program is not going to take 
more than a second or two and since you'd be running that on process exit 
as opposed to startup you'd probably never even notice it.

Anyway, on a personal note, don't get disheartened that the wine 
developers don't like you.  Believe me, EVERYBODY who has contributed code 
to Wine has had some code or some ideas frowned upon.  Just think about it 
and you'll eventually realize that most of the time Alexandre is dead-on 
so unless you can prove that the way he, most of the other developers, and 
I have been suggesting to do this is just dead-ass wrong then I would 
suggest not fighting it.

-Dave