brettholcomb@charter.net wrote:
Just run wine. The first time it will create the directory.
From: Shachar Shemesh wine-devel@shemesh.biz Date: 2004/07/08 Thu AM 11:35:21 GMT To: Wine Development wine-devel@winehq.org Subject: Initial creation of directory and config with ttydrv
Hi all,
I need to create the initial environment for wine (the .wine directory) in an environment where no X11 server is available. Once the directory is up (for example, if I copy it from somewhere), there is no problem to add a config file that chooses the ttydrv driver. However, I cannot create the initial directory.
Is there any solution to this problem, or should I just copy the initial config from somewhere?
Shachar
Wine won't run if it is set to use the X11drv driver, and there is no X11 display. Then again, the only way I can tell it to use the ttydrv is by placing a config file in the .wine directory, which does not exist until I run wine once.
Shachar
Le jeu 08/07/2004 à 08:03, Shachar Shemesh a écrit :
Wine won't run if it is set to use the X11drv driver, and there is no X11 display. Then again, the only way I can tell it to use the ttydrv is by placing a config file in the .wine directory, which does not exist until I run wine once.
I suppose it's a headless server/workstation. Would using ssh X forwarding be possible for initial run?
Else, unless you modify the default value in the source code for ttydrv to be the default value, I don't see another solution than copying the config from, eg., /etc/wine/wine.conf (I think the default is ${prefix}/etc/wine.conf), modifying the "GraphicsDriver" value while copying (sed is your friend here).
Note that some of the DX dlls will have problems registering (via wine.inf) with ttydrv. Ove has a patch for his debian packages to work around that issue (which I also use for RH packages).
Vincent
Vincent Béron wrote:
Le jeu 08/07/2004 à 08:03, Shachar Shemesh a écrit :
Wine won't run if it is set to use the X11drv driver, and there is no X11 display. Then again, the only way I can tell it to use the ttydrv is by placing a config file in the .wine directory, which does not exist until I run wine once.
I suppose it's a headless server/workstation. Would using ssh X forwarding be possible for initial run?
Actually, it's a little more complicated than that. I am creating the initial config from an RPM, giving the winehq RPM as a dependancy. For the time being, I solved this problem by having my RPM create a new user (which it has to anyways), and copy over a complete .wine directory. However, I'm afraid that if things change in the future, the config may no longer work as it does. For that reason, I would really prefer to have the vanilla config auto-created, and then just add the files and registry necessary for my application.
Else, unless you modify the default value in the source code for ttydrv to be the default value, I don't see another solution than copying the config from, eg., /etc/wine/wine.conf (I think the default is ${prefix}/etc/wine.conf), modifying the "GraphicsDriver" value while copying (sed is your friend here).
But what about the initial directories? dosdevices? windows/system etc.?
Note that some of the DX dlls will have problems registering (via wine.inf) with ttydrv. Ove has a patch for his debian packages to work around that issue (which I also use for RH packages).
Like I said, that's what I'm using anyways.
Vincent
Shachar
Le ven 09/07/2004 à 00:19, Shachar Shemesh a écrit : [snip]
Actually, it's a little more complicated than that. I am creating the initial config from an RPM, giving the winehq RPM as a dependancy. For the time being, I solved this problem by having my RPM create a new user (which it has to anyways), and copy over a complete .wine directory. However, I'm afraid that if things change in the future, the config may no longer work as it does. For that reason, I would really prefer to have the vanilla config auto-created, and then just add the files and registry necessary for my application.
Running wineprefixcreate manually should fix your problem. Try this: mkdir ~/.wine sed -e "s/\"x11drv\"/\"ttydrv\"/g" /etc/wine/wine.conf
~/.wine/config
wineprefixcreate
You should then have a populated registry and fake C drive, all using ttydrv.
Else, unless you modify the default value in the source code for ttydrv to be the default value, I don't see another solution than copying the config from, eg., /etc/wine/wine.conf (I think the default is ${prefix}/etc/wine.conf), modifying the "GraphicsDriver" value while copying (sed is your friend here).
But what about the initial directories? dosdevices? windows/system etc.?
You're right, those are not all correctly created/populated. Maybe we need more finely-grained tests than [ -d ~/.wine ]?
Vincent
Vincent Béron wrote:
Running wineprefixcreate manually should fix your problem.
Try this: mkdir ~/.wine sed -e "s/\"x11drv\"/\"ttydrv\"/g" /etc/wine/wine.conf
That's ugly. I cannot touch a file that doesn't belong to me.
~/.wine/config
wineprefixcreate
You should then have a populated registry and fake C drive, all using ttydrv.
But what about the initial directories? dosdevices? windows/system etc.?
You're right, those are not all correctly created/populated. Maybe we need more finely-grained tests than [ -d ~/.wine ]?
I propose testing for the existance of system.reg and user.reg.
Vincent
Shachar
On Sat, 10 Jul 2004 09:55:20 +0300, Shachar Shemesh wrote:
That's ugly. I cannot touch a file that doesn't belong to me.
Just submit a patch that lets you override the video driver in use via an environment variable.
thanks -mike
On Sat, Jul 10, 2004 at 01:54:30PM +0100, Mike Hearn wrote:
On Sat, 10 Jul 2004 09:55:20 +0300, Shachar Shemesh wrote:
That's ugly. I cannot touch a file that doesn't belong to me.
Just submit a patch that lets you override the video driver in use via an environment variable.
Can't we just try to load the ttydrv if the x11drv fails to load? (That is, when there's no explicit driver setting).
Le sam 10/07/2004 à 08:54, Mike Hearn a écrit :
On Sat, 10 Jul 2004 09:55:20 +0300, Shachar Shemesh wrote:
That's ugly. I cannot touch a file that doesn't belong to me.
Just submit a patch that lets you override the video driver in use via an environment variable.
I'll do it.
Vincent