Hi Alexander,
Just wanted to know whether this fell through the cracks, or whether there was another reason this was not commited to CVS.
Shachar
Shachar Shemesh wrote:
Changelog: Andreas Mohr
programs/wineboot
- Initial implementation
Shachar Shemesh wine-devel@sun.consumer.org.il writes:
Just wanted to know whether this fell through the cracks, or whether there was another reason this was not commited to CVS.
I was hoping you would clean it up, not simply resubmit Andi's stuff. As discussed with Andi already, this thing is much too complex and over-engineered. It has to be a simple application that doesn't require user interaction or a dozen configuration parameters.
Ok, I was under the impression that we want something in so that we can start working on it.
As this is the way you feel about the current wineboot, I think I'll go a completely new route. Please let me know your thoughts about the new proposed process.
In windows, some of the boot operations are done by the core "windows". These include wininit processing, win.ini, rename registry keys, and the services (can probably wait with these, however). Other things are performed by explorer when it first starts. These include the run and runonce keys.
What I'm thinking is incorporating the first group into the wine code itself (I'm thinking the server startup, synchroniously done). For the second group, create a wineboot program, and have a single option saying whether the wineserver should run it on startup or not.
Ideas, comments, opinions are welcome.
Shachar
Alexandre Julliard wrote:
Shachar Shemesh wine-devel@sun.consumer.org.il writes:
Just wanted to know whether this fell through the cracks, or whether there was another reason this was not commited to CVS.
I was hoping you would clean it up, not simply resubmit Andi's stuff. As discussed with Andi already, this thing is much too complex and over-engineered. It has to be a simple application that doesn't require user interaction or a dozen configuration parameters.
On Sun, 22 Dec 2002, Shachar Shemesh wrote: [...]
What I'm thinking is incorporating the first group into the wine code itself (I'm thinking the server startup, synchroniously done). For the second group, create a wineboot program, and have a single option saying whether the wineserver should run it on startup or not.
It is my understanding that if you put these in the wine server you will not be able to use the Windows APIs. This will make it unnecessarily complex to handle the move and renames since the paths will be windows paths.
Putting this code in a standalone utility will allow you to use the Windows API and then calling it from the Wine server (if that is the way we go) is just a fork away. It also makes the 'when is it called' more flexible which can come in handy.
-
Alexandre Julliard -
Francois Gouget -
Shachar Shemesh