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