Re: Bootprocedure again
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 MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Bootprocedure again
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. :)
Re: Bootprocedure again
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
Re: Bootprocedure again
On 2002.02.23 23:49 [EMAIL PROTECTED] 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
Re: Bootprocedure again
On Sat, Feb 23, 2002 at 11:49:43PM -0500, [EMAIL PROTECTED] 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 MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Bootprocedure again
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.
Re: Bootprocedure again
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.
Re: Bootprocedure again
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.
Bootprocedure again
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).
Re: Bootprocedure again
Gerhard W. Gruber [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Bootprocedure again
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?
Re: Bootprocedure again
Gerhard W. Gruber [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
