Why is wineprefixcreate deprecated?

[Bamm]

I understand that it is applied automatically when needed, but there are times when one would want to run it manually. An example is when I want to literally create a new wine prefix such as

env WINEPREFIX="/home/bamm/apps/myprog" wineprefixcreate

to prepare a clean profile for future installation of myprog. I know that running setup with a WINEPREFIX would create the clean profile, but sometimes I would want to copy a few needed files into the system32 folder before running setup. Hence, in this case, I would want the wine prefix to exist before I run

env WINEPREFIX="/home/bamm/apps/myprog" wine setup.exe

I was surprised to see the message when I ran wineprefixcreate:

"Note: wineprefixcreate is deprecated and shouldn't be needed anymore.
WINEPREFIX creation and updates now happen automatically when needed."

I am afraid they might soon remove this useful command (this is what "deprecated" means right?).

I hope they decide otherwise and "undeprecate" it. Most people won't need to know about it anyway, but those who do will find it useful if the situation calls for it.

[Chad]

I understand that it is applied automatically when needed, but there are times when one would want to run it manually. An example is when I want to literally create a new wine prefix such as

env WINEPREFIX="/home/bamm/apps/myprog" wineprefixcreate

to prepare a clean profile for future installation of myprog. I know that running setup with a WINEPREFIX would create the clean profile, but sometimes I would want to copy a few needed files into the system32 folder before running setup. Hence, in this case, I would want the wine prefix to exist before I run

env WINEPREFIX="/home/bamm/apps/myprog" wine setup.exe

I was surprised to see the message when I ran wineprefixcreate:

"Note: wineprefixcreate is deprecated and shouldn't be needed anymore.
WINEPREFIX creation and updates now happen automatically when needed."

I am afraid they might soon remove this useful command (this is what "deprecated" means right?).

I hope they decide otherwise and "undeprecate" it. Most people won't need to know about it anyway, but those who do will find it useful if the situation calls for it.

I also used it quite a bit. However, I guess it is just as easy to do

env WINEPREFIX="/path/to/winebottles" winecfg

Which will create said directory without having to launch an app. However, doing 'wineprefixcreate --prefix /path/to/winebottles' was convenient.

[vitamin]

I understand that it is applied automatically when needed, but there are times when one would want to run it manually. An example is when I want to literally create a new wine prefix such as

env WINEPREFIX="/home/bamm/apps/myprog" wineprefixcreate

Replace "wineprefixcreate" with any of the Wine's own programs. Such as winecfg or notepad for example.

I am afraid they might soon remove this useful command (this is what "deprecated" means right?).

Doubt it will go away. Something still needs to create an environment. But you should stop using anything that's marked deprecated.

[L. Rahyen]

On Saturday May 24 2008 17:04:03 Chad wrote:

env WINEPREFIX="/path/to/winebottles" winecfg

Which will create said directory without having to launch an app.

But you are running an application - winecfg; winecfg definitely isn't
replacement for wineprefixcreate.

However, doing 'wineprefixcreate --prefix /path/to/winebottles' was
convenient.

Better (and I think proper) way:

WINEPREFIX=$PATH_TO_NEW_WINEPREFIX wineboot

Have no idea if current docs/FAQ/Wiki mention a replacement command for
deprecated wineprefixcreate but if they don't they should.

And message:

"Note: wineprefixcreate is deprecated and shouldn't be needed anymore.
WINEPREFIX creation and updates now happen automatically when needed."

...should mention a replacement, for example: "Use wineboot instead if you
need to force Wine prefix creation".

[Timeout]

I hope it will not go away.

Some softwares are not installing properly when the installer is not prompted from within the prefix (due to copying installation temporary files next to the place where the installation .exe is located.

Running winecfg instead of wineprefixcreate is really be going from London to Paris via Moscow.
If I use an installing script, should I then add a line closing the winecfg Window just because I don't need any configuration but to create the prefix to add some dlls and the exe file?

[L. Rahyen]

On Saturday May 24 2008 17:52:08 Timeout wrote:

I hope it will not go away.

It is deprecated and personally I see no reason why it should stay. It was
for manual update of a WINE prefix. Now it is automatic and therefore it
isn't needed anymore.

Running winecfg instead of wineprefixcreate is really be going from London
to Paris via Moscow.

This is true, especially for scripts.

If I use an installing script, should I then add a
line closing the winecfg Window just because I don't need any configuration
but to create the prefix to add some dlls and the exe file?

As I already said above just use "wineboot" instead of "wineprefixcreate".

[Bamm]

It is deprecated and personally I see no reason why it should stay. It was for manual update of a WINE prefix. Now it is automatic and therefore it isn't needed anymore.

I do.

It's ironic that the wineboot is suggested to "create" a wine prefix, while wineprefixcreate is deprecated because the "update" occurs automatically.

In the past, I've always thought that the practice of using wineprefixcreate to "update" (as opposed to create) an already existing prefix is a kind of workaround for the absence of a "wineprefixupdate". Now that updating is automatic, we deprecate wineprefixcreate, and then suggest wineboot to create the prefix. We're creating another misnomer.

Commands should reflect what they are supposed to do. Telling people that we create wine prefixes by using the wineboot command creates more confusion.

And I mentioned that sometimes we actually need to create a wine prefix, as opposed to updating an existing prefix (such as when needing to run the installer from within the prefix or needing to add some dlls).

[austin987]

On 5/24/08, Bamm <[email protected]> wrote:

In the past, I've always thought that the practice of using wineprefixcreate
to "update" (as opposed to create) an already existing prefix is a kind of
workaround for the absence of a "wineprefixupdate". Now that updating is
automatic, we deprecate wineprefixcreate, and then suggest wineboot to
create the prefix. We're creating another misnomer.

The problem was that people would not use wineprefixcreate to update
their prefixes when using new wine versions, which led to false bug
reports.

And I mentioned that sometimes we actually need to create a wine prefix, as
opposed to updating an existing prefix (such as when needing to run the
installer from within the prefix or needing to add some dlls).

The need to create a new prefix before running an actual program is a
rarity nowadays. In that event, use winecfg/wineboot/notepad/etc.

[Bamm]

The need to create a new prefix before running an actual program is a rarity nowadays. In that event, use winecfg/wineboot/notepad/etc.

I understand, and it's just the way I do things. I create a new "bottle" for each app I want, and then make sure the environment is suitable before running setup.exe. So most people would not need it, but the command should stay there for the sake of people who do. Using winecfg/wineboot/notepad aren't solutions, they are workarounds. Its great that there is a command specifically for creating a prefix.

[perryh]

The need to create a new prefix before running an
actual program is a rarity nowadays. In that event,
use winecfg/wineboot/notepad/etc.

... Using winecfg/wineboot/notepad aren't solutions,
they are workarounds. Its great that there is a command
specifically for creating a prefix.

Given that simply starting a program now has a useful side effect
-- creating a prefix if it does not already exist -- is it time
for a wine equivalent of the OS/370 do-nothing utility IEFBR14?

[Bamm]

Given that simply starting a program now has a useful side effect -- creating a prefix if it does not already exist -- is it time for a wine equivalent of the OS/370 do-nothing utility IEFBR14?

If you just want to create a prefix and do nothing else, then yes. I did mention a couple of situations when it is desirable to create a prefix and do nothing else. Why start a program to create a prefix when you can just create a prefix?

[L. Rahyen]

On Sunday May 25 2008 00:59:12 Bamm wrote:

It's ironic that the wineboot is suggested to "create" a wine prefix, while
wineprefixcreate is deprecated because the "update" occurs automatically.

In the past, I've always thought that the practice of using
wineprefixcreate to "update" (as opposed to create) an already existing
prefix is a kind of workaround for the absence of a "wineprefixupdate".

Command "wineprefixcreate" has misleading name. It actually is (and always
was) wineprefixupdate. In other words, one of primary goal of
wineprefixcreate was to update WINE prefix. In the reality however (almost)
no one used it for update of existing WINE prefix (and its confusing name was
one of the reasons).

Commands should reflect what they are supposed to do.

I agree but as you can see name "wineprefixcreate" was much bigger
confusion - most people didn't understand that it might be (and should be)
used for updating existing WINE prefixes after each WINE upgrade.

Telling people that
we create wine prefixes by using the wineboot command creates more
confusion.

For old users (actually very small percentage of them) who used
wineprefixcreate it should be quite simple to use wineboot instead. IMO
wineboot much better describes all its purposes by its name than
wineprefixcreate.
It seems to me that you was confused by "wineprefixcreate" too - you think
that it serves specifically for creating WINE prefixes but it is not its only
purpose; wineboot as a replacement is very similar: it can serve to create
WINE prefixes but it is not its only purpose.
So I see no problem here except maybe we need to update the documentation
accordingly and just mention wineboot instead of wineprefixcreate.

we actually need to create a wine prefix, as
opposed to updating an existing prefix

Yes, this is *exactly* what happens if you run wineboot in non-existing WINE
prefix.
And BTW, there was never existed a command to just create WINE prefixes. As I
explained above wineprefixcreate served both purposes, create if not exist
and update if exist. Now wineboot can do the same: create if not exist and
update if exist.

So you have two options now:

1) Go ahead and just use wineboot instead of wineprefixcreate everywhere - it
should work (recommended).
2) Keep using deprecated wineprefixcreate for now (not recommended).

[Jim]

If you just want to create a prefix and do nothing else, then yes. I did mention a couple of situations when it is desirable to create a prefix and do nothing else. Why start a program to create a prefix when you can just create a prefix?

Why don't you have a look at wineprefixcreate:

less `which wineprefixcreate`

Ultimately wineprefixcreate calls wineboot and optionally wineserver -w.

Give it a try:

WINEPREFIX=~/.someprefix wineboot

So what's wrong with calling wineboot? It certainly is much easier to type than "wineprefixcreate." wineboot really does have the functionality you seek.

[Ove Kaaven]

Bamm skrev:

perryh wrote:

Given that simply starting a program now has a useful side effect -- creating a prefix if it does not already exist -- is it time for a wine equivalent of the OS/370 do-nothing utility IEFBR14?

If you just want to create a prefix and do nothing else, then yes. I did mention a couple of situations when it is desirable to create a prefix and do nothing else. Why start a program to create a prefix when you can just create a prefix?

Perhaps because, presumably, you want that prefix in order to actually
do something, like run a program. Then why not just *run* that program
already, instead of going through the extra step of manually creating
the prefix?

WINEPREFIX=~/.whatever wine setup.exe

The WINEPREFIX variable won't change, it has to be used when actually
running the program too, whether or not you initialize the files
separately. I don't see a benefit of doing it separately. Even if you
need to change winver etc before running setup.exe, then you'd start
with winecfg, which would similarly initialize the files.

[Bamm]

Perhaps because, presumably, you want that prefix in order to actually do something, like run a program. Then why not just *run* that program already, instead of going through the extra step of manually creating the prefix?

You miss that point of the original post: that situations exist where one would want to create a prefix before running a program. One reason is needing to copy some dlls before running setup.exe, another is some installers need to be run from inside the prefix. People may have their reasons why they would want to modify an environment before running a program there.

I was not confused by the name of wineprefixcreate. I am aware that wineprefixcreate has two purposes: to create and update. Now updating is automatic, wonderful; I won't need wineprefixcreate to update anymore; it was a poor name for it anyway. But to replace a misnomer with another misnomer will not solve the confusion as to what the commands do. Wineprefixcreate is a perfect name for creating prefixes that you would want to modify before you actually do something, like run a program.

For me, the name of a command is just as important as what it does.

[Ove Kaaven]

Bamm skrev:

One reason is needing to copy some dlls before running setup.exe,

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.

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.

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.

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.

[James McKenzie]

Bamm wrote:

Ove Kaaven wrote:

Perhaps because, presumably, you want that prefix in order to actually do something, like run a program. Then why not just *run* that program already, instead of going through the extra step of manually creating the prefix?

You miss that point of the original post: that situations exist where one would want to create a prefix before running a program. One reason is needing to copy some dlls before running setup.exe, another is some installers need to be run from inside the prefix. People may have their reasons why they would want to modify an environment before running a program there.

Which programs require this? Are they listed in the Applications
Database and is there a bug report for each and every one of them? If
the last two do not exist, don't ever expect them to be fixed and that
is a 'bad thing'.

For me, the name of a command is just as important as what it does.

As it is for a majority of us. However, wineboot does sound like it
boots wine. Maybe that is the program needing to be renamed? I too was
confused by its name and never would have thought to use it for the
functions it provides.

James McKenzie

[dimesio]

Which programs require this? Are they listed in the Applications
Database and is there a bug report for each and every one of them?

Office 2007. Yes and yes. And it's a program that a lot of people want to run. Sure, ideally all setup programs should just run, but let's be realistic here. If Wine never needed dll overrides, the option to do them wouldn't be there in the first place. Personally, I'm fine with running winecfg instead of wineprefixcreate, because I would do that anyway to set the dll overrides. The change actually makes things easier for me. But what I gather from this thread is that people accustomed to doing their configuring from the command line see it as adding an unnecessary extra step.

However, wineboot does sound like it
boots wine. Maybe that is the program needing to be renamed? I too was
confused by its name and never would have thought to use it for the
functions it provides.

I always thought wineboot was used to simulate a Windows reboot for programs that demand it; I never would have thought of using it before installing a program either. I think the advice to use it instead of winecfg is simply because it's quicker for those who don't actually use winecfg to change settings. Bottom line, from what I gather, is that running anything with the wineprefix variable set will now force creation of the wineprefix if it doesn't already exist (and update an existing one).

[Timeout]

Which programs require this? Are they listed in the Applications
Database and is there a bug report for each and every one of them? If
the last two do not exist, don't ever expect them to be fixed and that
is a 'bad thing'.

No they are not listed and they are not applications per se and will not be a target for Wine to fix it.
First application that caused troubles when starting from outside of the prefix was windows scripting. Second application causing trouble is the licensing utility (from the days it was working). it is putting installations files near the main installation exe and if this is not in the prefix it can't find them again (problem registering a file outside C:??).
For dlls override it don't see that it would be sorted out.
fusion.dll and secur32.dll are in Wine but not in System32 and as long as they appear I will add them (note that for all the dlls I add, a dummy dll would be fine too, since even without registering it serves my purpose).

[Bamm]

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.

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: Select all

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: Select all

env WINEPREFIX="/home/bamm/apps/starrynight" wineprefixcreate
cp vcredist_x86.exe /home/bamm/apps/starrynight/drive_c
cd /home/bamm/apps/starrynight/drive_c
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: Select all

env WINEPREFIX="/home/bamm/apps/starrynight" wineboot
cp vcredist_x86.exe /home/bamm/apps/starrynight/drive_c
cd /home/bamm/apps/starrynight/drive_c
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).

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.

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).

[austin987]

You still have yet to give a reason why using wineboot instead of
wineprefixcreate is a bad idea. If you're pursuing a course that is
off the beaten path, you shouldn't expect for things to work out of
the box, and if things are improved for the majority of users, it's a
good thing. A simple sed /wineprefixcreate/wineboot/ will 'fix' your
problem, while complaining and asking for wineprefixcreate to be
maintained/updated will not.

[James McKenzie]

Austin English wrote:

You still have yet to give a reason why using wineboot instead of
wineprefixcreate is a bad idea. If you're pursuing a course that is
off the beaten path, you shouldn't expect for things to work out of
the box, and if things are improved for the majority of users, it's a
good thing. A simple sed /wineprefixcreate/wineboot/ will 'fix' your
problem, while complaining and asking for wineprefixcreate to be
maintained/updated will not.

Austin:

A simple symlink between wineprefixcreate and wineboot will solve this
and end the confusion on what program performs what function.

Elegant and simple. Symlinks are also easy to maintain.

James McKenzie

[Ove Kaaven]

Bamm skrev:

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?

Yes, that would. If you're smart (or happy-go-lucky) enough to know that
one DLL will be enough, then presumably you're smart enough to use
wineboot... without complaining about it.

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.

Claiming that someone who disagrees hasn't read/understood the arguments
is a clear logical fallacy. Even Bill Gates has been guilty of it, so
you're not alone, I guess. (Though I'm starting to suspect that unlike
him, you actually want to be a troll.)

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?

Because everything has to execute inside the prefix anyway. That's why
you need one, you know.

An example is vcredist_x86.exe which extracts itself into the folder it is found in. Let's say I do

Oh, so you *don't* mean that it needs to run inside the prefix. You mean
that the *current directory* should be inside. Why didn't you say so in
the first place?

If you had actually said what you meant, my answer could have been
simpler and more accurate: set WINEPREFIX and run winetricks.

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.

Of course not. It seems more productive to consider you either a victim
of force of habit, or maybe a troll, since I can't see how an ordinary
user would consider wineprefixcreate an easier command than wineboot,
and "extraordinary" users would also know better than this.

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).

To make the lives of most users easier, Windows comes preinstalled. And
many users happen to be thankful for it. Of course, many of us Linux
people feel differently. Can't please everyone, I guess.

[L. Rahyen]

On Monday May 26 2008 04:30:53 Bamm wrote:

env WINEPREFIX="/home/bamm/apps/starrynight" wineprefixcreate
...
I know I can use wineboot in its place, e.g.,
...
env WINEPREFIX="/home/bamm/apps/starrynight" wineboot
...
but I find this very counterintuitive.

Well I guess for most of old advanced users this is intuitive. For example, I
personally often create a lot of WINE prefixes and have some scripts that use
wineprefixcreate. After wineprefixcreate became deprecated all of my scripts
are using wineboot now (and I didn't asked anyone because it was obvious to
me that wineboot is the replacement; I don't say that this should be obvious
for everyone - reread my first message in this topic), and I use wineboot in
the terminal too when I need to create WINE prefix manually. Works perfectly.
For new users use of wineboot is as intuitive as use of wineprefixcreate so
no problem here either.

That wineboot now also creates a prefix does not make it a command to create
a prefix.

Wrong. It does. And this is very intuitive - first boot bootstraps
WINE prefix if it doesn't exist.

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).

Then why not try to send a patch or if you are unsure ask on IRC/wine-devel
is this acceptable or not.

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.

Then use wineboot.

I can see that you don't mind opening another program just to create a
prefix. Well I do.

Again, use wineboot. It doesn't open any program and works as fast (or even
faster) than wineprefixcreate.