Bootprocedure again

Gerhard W. Gruber sparhawk at gmx.at
Tue Feb 26 05:14:15 CST 2002


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.




More information about the wine-devel mailing list