Maybe it went a bit unnoticed because of the many mails the licence issue generated, or then again, maybe the bootprocedure is not that important to most. :) The only response I got was that performance could be a consideration, which I think wouldn't be a problem and another one was that wine shouldn't be forced to reboot entirely in order to make it happen. So if nobdoy has a real objection why this shouldn't be done, then I implement it as I see fit to be most userfriendly (performance is always my consideration so I don't need to mention it explicitly here).
"Gerhard W. Gruber" <sparhawk(a)gmx.at> writes:
Maybe it went a bit unnoticed because of the many mails the licence issue generated, or then again, maybe the bootprocedure is not that important to most. :) The only response I got was that performance could be a consideration, which I think wouldn't be a problem and another one was that wine shouldn't be forced to reboot entirely in order to make it happen. So if nobdoy has a real objection why this shouldn't be done, then I implement it as I see fit to be most userfriendly (performance is always my consideration so I don't need to mention it explicitly here).
Well, if you discard all objections as "not real" then of course there isn't a real objection. But the two mentioned seem very real to me. Another one is that you need to be able to control when bootup processing happens, and this is a policy decision that doesn't belong in the lowest layers. This is why we need a separate app, which can be launched when some higher layer decides it's the right time. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Well, if you discard all objections as "not real" then of course there isn't a real objection. But the two mentioned seem very real to
Sorry, I didn't mean them to be not real. It's only that I doubt that the check for the existence of a registry key and alternatively for a configurable switch is that performance intensive to hinder such an implementation. The other one (forcing an entire reboot) is not a real objection to me as I never wanted to implement it in that way. I don't like the idea to have all applications to stop just because some program needs to rename/delete some files for itself. Especially under Unix where this is no problem anyway. So this was not meant to discard that objection, rather I never intended this solution anyway. :)
me. Another one is that you need to be able to control when bootup processing happens, and this is a policy decision that doesn't belong in the lowest layers. This is why we need a separate app, which can be launched when some higher layer decides it's the right time.
I can understand that as a more "real" objection. :) That's why I posted my first mail, because I wanted to know which reasons could exist to justify that. I hate to code something without understanding it's needs, and even more so when I don't agree with it. The disagreement could be because I don't know about other issues, which I wanted to find out about here. So why is it neccessary for this to be in a seperate app and are there already any plans on how this should have been integrated? Which layer would that be that decides this? If the decision is done in a higher app, why not just implement it in a seperate module (which I would have done anyway) and then execute the code when it is needed?
"Gerhard W. Gruber" <sparhawk(a)gmx.at> writes:
So why is it neccessary for this to be in a seperate app and are there already any plans on how this should have been integrated? Which layer would that be that decides this? If the decision is done in a higher app, why not just implement it in a seperate module (which I would have done anyway) and then execute the code when it is needed?
Well, yes, that's the idea. Only there's no reason to put that separate module in the low layers if it's not needed there. And by moving it to higher layers, like in a separate app, you have access to more functionality; for instance you can popup a confirmation dialog or things like that. As for what layer would call that code, there are many possibilities, which is why it is important to provide the mechanism independently of the policy decisions. For instance you could call it from .xsession so that bootup processing happens when you log in on your desktop; you could also have a script that mounts a CD, runs the installer, then simulates a reboot, all wrapped up in a nice interface; or you could have an option to call it when an app calls ExitWindows(); etc. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
moving it to higher layers, like in a separate app, you have access to more functionality; for instance you can popup a confirmation dialog or things like that.
That's ok but this can also be done in a seperate module. I don't like to have multiple programs if it is not logically seperated. I don't want to stuff everything into a single app but I also don't want to have a myriad of programs all doing almost the same things.
As for what layer would call that code, there are many possibilities, which is why it is important to provide the mechanism independently of the policy decisions. For instance you could call it from .xsession so
Yes. That's my philosophy anyway. :)
that bootup processing happens when you log in on your desktop; you could also have a script that mounts a CD, runs the installer, then
Hm. I don't want the user to be forced to close all currently running applications, much less I want him to be forced to log off just to get the boot procedure finished.
simulates a reboot, all wrapped up in a nice interface; or you could have an option to call it when an app calls ExitWindows(); etc.
That's more my way. :) I want an application that has maximum configurability while being as less as intrusive as needed. That's what I like about Unix and I don't want to introduce Windows behaviour into the Unix world. :) I'll see where the best place is and implement it that way.
On 2002.02.22 08:08 Gerhard W. Gruber wrote: [SNIP]
That's more my way. :) I want an application that has maximum configurability while being as less as intrusive as needed. That's what I like about Unix and I don't want to introduce Windows behaviour into the Unix world. :)
I'll see where the best place is and implement it that way.
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. 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 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? -Dave
On Sat, 23 Feb 2002, David Elliott wrote:
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.
Well, if it is a Winelib program, it would be linked with it, sort of, and loaded by it, but I think that is not what you mean here, is it?
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 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
<wine>/programs/ is a good neighborhood.
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?
-Dave
Right. I like that. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
On Sat, Feb 23, 2002 at 11:49:43PM -0500, lawson_whitney(a)juno.com wrote:
On Sat, 23 Feb 2002, David Elliott wrote:
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.
Well, if it is a Winelib program, it would be linked with it, sort of, and loaded by it, but I think that is not what you mean here, is it?
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 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
<wine>/programs/ is a good neighborhood. Sure, and that's why I chose programs/winebootup/.
Well, it's not submitted in its complete form yet, but I'm going to continue working on it. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Andreas Mohr wrote:
<wine>/programs/ is a good neighborhood. Sure, and that's why I chose programs/winebootup/.
Well, it's not submitted in its complete form yet, but I'm going to continue working on it.
But your wine bootup does much more then just handling the renaming/deletion of files on boot. Considering what you already planned according to the code then it doesn't make sense to have it seperately because it should be run anyway. The keys you are checking there should be started when windows boots. If NT is properly emulated then it should make sense because there will be quite a number of programs that are run as services, which should run everytime wine starts. So did you have plans on how to integrate this best? Or is it as others suggested, that one who will want to have this, should build a script that runs it.
On 2002.02.23 23:49 lawson_whitney(a)juno.com wrote:
On Sat, 23 Feb 2002, David Elliott wrote:
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.
Well, if it is a Winelib program, it would be linked with it, sort of, and loaded by it, but I think that is not what you mean here, is it?
Err, by "the code to do this" I was still referring to the code that does the bootup procedure. And I don't believe that it should be linked to the emulator. It can and will have to be linked to winelib (thus making it a winelib program) but it should definitely not be linked in with the emulator portion of wine. The emulator may use a CreateProcess to call it during startup, but I would prefer a shell script. [SNIP]
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?
-Dave
Right. I like that.
Yeah.. I think that this is a reasonable solution and we let the distributors figure it out from there. -Dave
On Mon, 25 Feb 2002, David Elliott wrote:
Err, by "the code to do this" I was still referring to the code that does the bootup procedure. And I don't believe that it should be linked to the emulator. It can and will have to be linked to winelib (thus making it a winelib program) but it should definitely not be linked in with the emulator portion of wine. The emulator may use a CreateProcess to call it during startup, but I would prefer a shell script.
In case you haven't been watching lately, a winelib program is not any more an elf executable. It is an elf-format PE executable, and AFAIK, it is meant to be run by the emulator. WINEPRELOAD makes it easy to run one from a script, or another *NIX executable. Right, though, it isn't linked to the emulator, I sort of misspoke there.
Yeah.. I think that this is a reasonable solution and we let the distributors figure it out from there.
-Dave
Lawson This letter is brought to you by /usr/local/bin/toj2, which pine runs in lieu of sendmail: #! /bin/sh WINE=/usr/local/bin/wine [[ "$(dirname $0)" == "." ]] && wpl="${PWD}/toj2.so" || wpl="${0}.so" WINEPRELOAD="$wpl" $WINE ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
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.
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?
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.
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
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.
On Tue, Feb 26, 2002 at 12:14:15PM +0100, Gerhard W. Gruber wrote:
David Elliott wrote:
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. Hmm, well, winebootup is supposed to execute everything *at once* on Wine startup (i.e. check in the wine wrapper script whether this is the first wine instance to get started, then run winebootup)
If you don't think this is a good design, then go ahead and change it ! (if it's better, that is ! ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Andreas Mohr wrote:
Hmm, well, winebootup is supposed to execute everything *at once* on Wine startup (i.e. check in the wine wrapper script whether this is the first wine instance to get started, then run winebootup)
If you don't think this is a good design, then go ahead and change it ! (if it's better, that is ! ;)
I think this is a good design when it is the way you are describe it here. What me bothered was, that there is a little bit of startup in loader/main.c and then there is a little bit of startup in winebootup. How can it check wether this is the first instance in a script? As I have seen in loader/main.c there is an if(firstthread) which I supposed to be what you mean with first instance and I thought this would be the natural place to go for that thing. Is winebootup going to replace wine then, once it is finished? Otherwise there would be two boot programs doing almost similar things and that's what I consider a bad design. :)
Could we have the first snapshots ? winebootup is not in CVS for the moment...
Is winebootup going to replace wine then, once it is finished? Otherwise there would be two boot programs doing almost similar things and that's what I consider a bad design. :)
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Sylvain Petreolle wrote:
Could we have the first snapshots ? winebootup is not in CVS for the moment...
The current version has Alexander Mohr and I. I haven't changed anything yet, as I have first implemented the neccessary patches in wine directly and I don't have not that much time right now because my son has been bron a week ago. :) I don't know if this current version will be added to CVS, but I think it would be a good idea to do so.
participants (6)
-
Alexandre Julliard -
Andreas Mohr -
David Elliott -
Gerhard W. Gruber -
lawson_whitney＠juno.com -
Sylvain Petreolle