I recently requested a copy of the wineboot program, which i obtained from the mailing list, however this code is somewhat old. Does anyone have a newer version of this code, or has it not been changed since the version I have (6/02, i think). Either way i am considering improving parts of this program, and would like to know if i will be duplicating any work.
Matthew Davison wrote:
I recently requested a copy of the wineboot program, which i obtained from the mailing list, however this code is somewhat old. Does anyone have a newer version of this code, or has it not been changed since the version I have (6/02, i think). Either way i am considering improving parts of this program, and would like to know if i will be duplicating any work.
I have vulenteered to do likewise. I have not, however, managed to get any statement from Andy regarding the current state, or any other replies. If he replies to this email, great. If not, I suggest we work on it together.
Shachar
On December 11, 2002 03:51 pm, Shachar Shemesh wrote:
I have vulenteered to do likewise. I have not, however, managed to get any statement from Andy regarding the current state, or any other replies. If he replies to this email, great. If not, I suggest we work on it together.
I also did not get any response to my (potentially silly) proposal: http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html
At 10.42 12/12/2002 -0500, you wrote:
On December 11, 2002 03:51 pm, Shachar Shemesh wrote:
I have vulenteered to do likewise. I have not, however, managed to get any statement from Andy regarding the current state, or any other replies. If he replies to this email, great. If not, I suggest we work on it together.
I also did not get any response to my (potentially silly) proposal: http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html
Personally, I would still prefer an external utility, to mimic the case when the installer asks you "do you want me to reboot now?" and you say "no, I'll do it later". In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx).
Alberto
On December 12, 2002 11:16 am, Alberto Massari wrote:
Personally, I would still prefer an external utility, to mimic the case when the installer asks you "do you want me to reboot now?" and you say "no, I'll do it later". In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx).
Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it. The reason I proposed to invoke it from the server rather than from the process is because: -- it seems that's the place that's equivalent to rebooting windows -- it avoids a bunch of nasty race conditions -- it is very simple
So yeah, what you say does not conflict in any way with what I was proposing. Indeed, the wine_need_reboot() function should behave as you say. In fact, if we should exit the server of system shutdown for this to work as I see it...
On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote:
Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it.
Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons? Can they be fixed? Should they be fixed?
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Joerg Mayer wrote:
On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote:
Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it.
Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons?
In a nutshell - some operations are delayed until reboot due to file locks, running processes, services and drivers, and a host of other reasons. The reasons you don't see such things in Unix are: a. Seperate functionality is better seperated into seperate process, thus making restarting a specific aspect of the system easier. b. Files are never locked, and therefor can always be replaced.
Can they be fixed?
Maybe. That's a pretty serious question and one for two minor startups.
Should they be fixed?
I don't think so. Wine restart is far less painful than a Windows restart. Sometime in the future, maybe.
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
At 21.16 12/12/2002 +0100, Joerg Mayer wrote:
On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote:
Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it.
Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons? Can they be fixed? Should they be fixed?
The "reboot" in question is not the reboot of the Linux machine, it should be a command that executes the operation done by Windows upon startup. The need comes from APIs like MoveFileEx (when a special flag is used to say "move or delete this file when the system starts, so I am sure this file is not in use"), and from registry settings like Run and RunOnce.
Ciao, Alberto
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Personally, I would still prefer an external utility, to mimic the case when the installer asks you "do you want me to reboot now?" and you say "no, I'll do it later". In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx).
So yeah, what you say does not conflict in any way with what I was proposing. Indeed, the wine_need_reboot() function should behave as you say. In fact, if we should exit the server of system shutdown for this to work as I see it...
If the reboot gets delayed and I just quit the program, is the reboot still called at wine exit? Or would it be better if wine checks on every start if there are things necessary to complete (copy files...)? Maybe already too late.
bye Fabi
I want to speak out against Dimi's idea. It is fine as far as renaming files in Wininit.ini, and maybe performing the delayed RenameFileEx. It is not the right place, however, for performing the Run and RunOnce sections.
The reason is that Run and RunOnce may rely on future events happening. I know places where RunOnce was a full fledge GUI program which required further user intervention. Do we really want to pop that up when wine EXITS?
Fabian Cenedese wrote:
If the reboot gets delayed and I just quit the program, is the reboot still called at wine exit? Or would it be better if wine checks on every start if there are things necessary to complete (copy files...)? Maybe already too late.
I think that is the right thing to do. If someone clicked "do not reboot Windows", maybe becasue that's what they are used to have to click, they still expect the windows to be ok the next time.
bye Fabi
On December 13, 2002 02:48 am, Shachar Shemesh wrote:
I want to speak out against Dimi's idea.
Gee, thanks, that gives me a warm and fuzzy... :)
The reason is that Run and RunOnce may rely on future events happening. I know places where RunOnce was a full fledge GUI program which required further user intervention. Do we really want to pop that up when wine EXITS?
And where exactly did you get this idea from? Please reread my message:
http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html
It clearly states "on server startup"...
Dimitrie O. Paun wrote:
On December 13, 2002 02:48 am, Shachar Shemesh wrote:
I want to speak out against Dimi's idea.
Gee, thanks, that gives me a warm and fuzzy... :)
The reason is that Run and RunOnce may rely on future events happening. I know places where RunOnce was a full fledge GUI program which required further user intervention. Do we really want to pop that up when wine EXITS?
And where exactly did you get this idea from? Please reread my message:
http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html
It clearly states "on server startup"...
Sorry, my misunderstanding, then.
I am not at all familiar with the wineserver (maybe it's time, eh?). I got the impression it will be difficult to perform this task both without race conditions, and in a way that will put the entire power of Win32 at our disposal.
If you (or anyone else who has better familiarity with the server) can recommend a specific source file and line number where such a change can be performed, we can start testing right away.
Shachar
On December 13, 2002 03:13 am, Shachar Shemesh wrote:
I am not at all familiar with the wineserver (maybe it's time, eh?). I
Welcome to the club <g>
got the impression it will be difficult to perform this task both without race conditions, and in a way that will put the entire power of Win32 at our disposal.
Well, the resonal I suggest we put it in there is to avoid races. The wineserver is analogous to the kernel in Unix, so it's startup is the closes thing to a boot.
If you (or anyone else who has better familiarity with the server) can recommend a specific source file and line number where such a change can be performed, we can start testing right away.
I was thinking we add it at the very end of the initialization:
Index: server/main.c =================================================================== RCS file: /var/cvs/wine/server/main.c,v retrieving revision 1.28 diff -u -r1.28 main.c --- server/main.c 2 Oct 2002 23:49:30 -0000 1.28 +++ server/main.c 13 Dec 2002 14:48:25 -0000 @@ -126,6 +126,7 @@
if (debug_level) fprintf( stderr, "wineserver: starting (pid=%ld)\n", (long) getpid() ); init_registry(); + if (wine_needs_reboot()) fork(wineboot); /* asynchronously */ select_loop();
#ifdef DEBUG_OBJECTS
But as I said, I have no idea if this is feasible, it just _seems_ to me that it's the closes thing to a reboot, that's all. In fact, chances are it's not the right thing to do, but what a heck! :) Maybe Alexandre can comment on it?
I was thinking we add it at the very end of the initialization:
- if (wine_needs_reboot()) fork(wineboot); /* asynchronously */
I know nothing about wineserver :) I was just wondering about this asynchronously. Of course it shouldn't get locked up. But who will be faster then, wine or wineboot? I mean what if a program relies on these actions being finished (they usually do), is it sure that wineboot has finished when the app gets started?
Just my worthless 2 cents :)
bye Fabi
Fabian Cenedese wrote:
I know nothing about wineserver :) I was just wondering about this asynchronously. Of course it shouldn't get locked up. But who will be faster then, wine or wineboot? I mean what if a program relies on these actions being finished (they usually do), is it sure that wineboot has finished when the app gets started?
Most of these ops takes place asynchroniously in Windows as well, so that's not the issue.
I'm thinking that we should get the wininit.ini processed before the first Win32 program starts (and synchroniously, just like on Windows). Then, the delayed renames using RenameFileEx, also synchroniously. Next should come the RunServicesOnce, RunServices, RunOnce and Run, asynchroniously.
If we have the concept of "Explorer" in the future, we should defenitely seperate them a little (i.e. - get RunServices and RunServicesOnce over with before starting RunOnce and Run). We will also have to address the concept of Windows NT services at some point (in the future).
As for running things on ExitWindows - I don't think that's a good idea. It MAY work for wininit.ini stuff, but not the other stuff.
Shachar
"Dimitrie O. Paun" dpaun@rogers.com writes:
But as I said, I have no idea if this is feasible, it just _seems_ to me that it's the closes thing to a reboot, that's all. In fact, chances are it's not the right thing to do, but what a heck! :) Maybe Alexandre can comment on it?
I don't think the server is the right place for that. IMO it should be called when the app explicitly requests a reboot (ExitWindows and friends), and probably added to the X11 desktop init files to run once when the user logs in. But at this point the important thing is to get that tool into the tree, even if it has to be launched manually at first; we can worry about automating it later.
-
Alberto Massari -
Alexandre Julliard -
Dimitrie O. Paun -
Fabian Cenedese -
Joerg Mayer -
Matthew Davison -
Shachar Shemesh -
Shachar Shemesh