dfe at tgwbd.org
Mon Feb 25 20:05:59 CST 2002
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
> > 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
> > 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
> > Windows itself (win9x/me at least) actually has this code in
> > which is loaded early on in the boot process. It is not necessary or
> 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
> > mechanism. This is what Alexandre has been saying, and I am saying the
> > same thing. Policy decisions do not belong in Wine, even as
> > options when it can be helped. If you feel you absolutely MUST have
> > 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
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
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.
More information about the wine-devel