Ove Kaaven wrote: > You shouldn't have to. That's not how Wine is meant to work. Since it's unsupported and not recommended, there's no need to make it clean and workaround-free. Even a simple Hello World made in VB would need MSVBVM60.DLL copied into system32. So you would prefer that I download winetricks and use it to download and install the entire VB runtime engine, when simply copying the MSVBVM60 would do? If this is unsupported, then I would rather do the unsupported method of copying MSVBVM60 if that is what it takes to run Hello World. Ove Kaaven wrote: > > > > another is some installers need to be run from inside the prefix. > > > > That's not at all a reason. In fact, it is my *counter*-reason exactly: > just set WINEPREFIX and run the installer, no need to do an additional > step. Easy as pie. > You obviously jumped in without reading the original post and the other arguments made. I mentioned that some installers need to be INSIDE the prefix. How can the installer be in the wine prefix if running the installer creates the prefix? An example is vcredist_x86.exe which extracts itself into the folder it is found in. Let's say I do Code: env WINEPREFIX="/home/bamm/apps/starrynight" wine vcredist_x86.exe And then vcredist_x86.exe as everyone knows extracts itself into the folder it is found in. But this folder is not in the starrynight folder because /home/bamm/apps/starrynight is created precisely by running it. My experience is that the install.exe program will fail to see the files it needs. Now let's take a look at how I would do it. Code: env WINEPREFIX="/home/bamm/apps/starrynight" wineprefixcreate cp vcredist_x86.exe into /home/bamm/apps/starrynight cd /home/bamm/apps/starrynight env WINEPREFIX="/home/bamm/apps/starrynight" wine vcredist_x86.exe I hope I'm clearer now. I know I can use wineboot in its place, e.g., Code: env WINEPREFIX="/home/bamm/apps/starrynight" wineboot cp vcredist_x86.exe into /home/bamm/apps/starrynight cd /home/bamm/apps/starrynight env WINEPREFIX="/home/bamm/apps/starrynight" wine vcredist_x86.exe but I find this very counterintuitive. I have been using wineboot for a long time so don't tell me I don't know what it does. And most of the time I use it to simulate a reboot. That wineboot now also creates a prefix does not make it a command to create a prefix. I argue that for clarity we should still have a wineprefixcreate command, even if all it does it to run wineboot. (which is really what it does). Ove Kaaven wrote: > > > People may have their reasons why they would want to modify an environment before running a program there. > > > > So they use winecfg or something. Big deal. > Sure, except that I am too lazy to want to open and close the winecfg window unless I really intend to use it. I can see that you don't mind opening another program just to create a prefix. Well I do. And just because you don't mind doesn't mean you can tell me that I shouldn't mind either. Ove Kaaven wrote: > > > For me, the name of a command is just as important as what it does. > > > > Well, in that case, wineboot might be perfect. Bootstraps a new Wine > prefix. Powering on a computer makes it boot up, load, and usually > autoconfigure the operating system, and running wineboot makes it set up > and autoconfigure the simulated operating system instance. Following your analogy that wineboot is booting Windows, then wineprefixcreate is installing Windows (and deleting the prefix is like formatting Windows, but leaving behind the shortcuts it created).
