David Elliott wrote:
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.
No Problem. I prefer to use the NGs instead, and there I hate to receive emails about threads I participate in.
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
Agreed.
anything in the wine emulator startup except get the emulator running.
Is there somewhere a design paper or such that shows the starting phases of Wine? Would help quite a bit if such design documents existed and it would have saved me to start this thread, as my intention was to get a good design that fits nicely into wine.
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.
If everything that doesn't belong there is removed to a more suitable and designed place then this is ok for me. I only hate to have some stuff here and some there because this isn't good design and makes the maintainence of the code much harder and also harder to understand.
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.
OK. That's the point I wanted to know more, because it seemed weird to me to have one program (wine) that starts up and than another program (winebootup) that also does some startup. Actually I adressed that point in one of my previous mails because I thought that it makes sense to either use the one or the other instead of having to startup programs.
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
I thought of that anyway. Otheriwse the user would have either to run everything that winebootup does instead of simply finishing a setup request.
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).
There has to be some mechanism that should start the processing. Either the user has to start it manually (which I consider ugly) or some other way that is more transparent and doesn't require the user to do something.
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
No. Actually I consider it a good design when code is run that is needed to run instead of polling. At least whne a solution is possible where polling is not required.
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.
I didn't notice that because I don't use wine much yet and I didn't know about this switch. I only run one program that I'm working on to implement the features, so I wouldn't have noticed that.
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
I think this is the prefered way to do. Even windows went that way because it is annoying to having to reboot the entire system for a stupid file delete or such.
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
If you consider this as the appropriate way to do then I'll do it this way. Maybe this will be usefull for other things as well when there is a program that can do some things on startup/exit.
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
Good to know. :) Of course I know that someone, who works for a long time on a project, has some ideas as to how something has should be done. Sometimes this is good and somtimes this is bad, but I don't want to throw everything around when there are already plans on how something should be integrated. That's why I started that thread.