question about WINEPREFIX

[Phobos]

I wanted to ask to the wine experts something about WINEPREFIX or the crossover bottles...

how does the concept of "bottles" compares/differs with the concept of application virtualization used by VMware's Thinstall (aside for the .exe container*) and Microsoft's Softgrid/Application Virtualization?

*I have used Thinstall a bit and it encapsulates all the files required by the app to work in an exe, including the registry keys (they call it "virtual registry")

aside from these two products, how does it compares to the portableapps process (which is in turn similar to thinstall but it's not an automated process and doesn't have the "virtual registry")?... why do the bottles need a "whole" c: drive?

[Dan Kegel]

On Fri, Mar 7, 2008 at 11:37 AM, Phobos <[email protected]> wrote:

how does the concept of "bottles" compares/differs with ... Thinstall ...
and http://portableapps.com ?

Each bottle, or WINEPREFIX, is just a virtual C: drive, a windows
registry, and a
set of drive letter mappings. In theory one could move a WINEPREFIX
around; in practice, the unix location leaks through into .lnk files
(that's bug http://bugs.winehq.org/show_bug.cgi?id=11797 ).

Thinstall is that plus the machinery to make it easy to use
one of those on any Windows system, all bundled up in a .exe.
I'm not really sure about portableapps, haven't looked at those.

But the main difference is that nobody has put the effort into
making WINEPREFIXes portable between systems. Oh, wait,
I think some Chinese company has done that, and made
a thinstall-like thing for Linux that rolls up Wine plus a WINEPREFIX
into a single linux executable. Lessee... nope, I can't recall what
they're called. I think they were mentioned on wine-devel
as a possible wine license violator a few years ago.
(Not specops, not unified kernel, can't recall...)
- Dan

[Jim]

I wanted to ask to the wine experts something about WINEPREFIX or the crossover bottles...

how does the concept of "bottles" compares/differs with the concept of application virtualization used by VMware's Thinstall (aside for the .exe container*) and Microsoft's Softgrid/Application Virtualization?

*I have used Thinstall a bit and it encapsulates all the files required by the app to work in an exe, including the registry keys (they call it "virtual registry")

aside from these two products, how does it compares to the portableapps process (which is in turn similar to thinstall but it's not an automated process and doesn't have the "virtual registry")?... why do the bottles need a "whole" c: drive?

Apples, oranges, and bananas.

PortableApps focuses on making applications run on an external medium such as a flash drive. It does this by modifying the application itself to make it store all its settings, data files, and binaries on a path relative to some folder (eg. on a flash drive). In many cases to make an application a "PortableApp" the source code for the application is modified. The applications themselves get tweaked. For PortableApps to run on Linux/Mac environments Wine is used.

Thinstall technically doesn't modify the application itself rather it packages it and everything it needs in a single executable file. When you create a Thinstall application you create a snapshot world for your application to run in. Again, in order to run on Unix environments Wine is used.

More over, both PortableApps and Thinstall depend on having access to a Windows runtime environment (a.k.a Windows APIs). Wine provides an alternative implementation of Windows APIs, which can then be used to run PortableApps and Thinstalled software.

All three tackle their respective goals in very different ways, but only one of them can stand by itself on a Unix platform.

[vitamin]

I wanted to ask to the wine experts something about WINEPREFIX or the crossover bottles...
... why do the bottles need a "whole" c: drive?

Don't confuse WINEPREFIX with what C: drive means on windows. Wine IS NOT installed in WINEPREFIX. All you have there are "fake" Wine DLLs. Whole new WINEPREFIX is a whopping 3.3MB. With Wine-Gecko - it's 21MB

So the WINEPREFIX is something like a complete "windows" environment ... without windows (or Wine).

[Dan Kegel]

On Fri, Mar 7, 2008 at 11:37 AM, Phobos <[email protected]> wrote:

why do the bottles need a "whole" c: drive?

Because it was easier that way?
And as Vitamin said, the c: drive is to some extent fake, lots of Wine
isn't really in there.

[Jim Hall]

On Sat, Mar 8, 2008 at 8:30 AM, Dan Kegel <[email protected]> wrote:

On Fri, Mar 7, 2008 at 11:37 AM, Phobos <[email protected]> wrote:

why do the bottles need a "whole" c: drive?

Because it was easier that way?
And as Vitamin said, the c: drive is to some extent fake, lots of Wine
isn't really in there.

Does all of this mean that it is possible to have a program run on a
"platform of choice/need" without actually installing it??

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm

[vitamin]

Does all of this mean that it is possible to have a program run on a
"platform of choice/need" without actually installing it??

No you still have to install it one way or the other.

[Jim Hall]

On Sat, Mar 8, 2008 at 12:11 PM, vitamin <[email protected]> wrote:

Jim Hall wrote:

Does all of this mean that it is possible to have a program run on a
"platform of choice/need" without actually installing it??

No you still have to install it one way or the other.

Darn, another one for the "to good to be true" file, sigh.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm

[Phobos]

Apples, oranges, and bananas.

All three tackle their respective goals in very different ways, but only one of them can stand by itself on a Unix platform.

I know... after all your comment, it seems like they are not really apples, oranges and bananas, do they?

As you noted, they do the same, but each on it's own approach... Softgrid uses it's own way too, but in the end is the same... application containment, so it can run without modifying the real files/registry... or application virtualization

this kind of virtualization is really useful to do testing without compromising other programs or for using the apps in a portable way... so I'm very interested on it.

(Btw, not all the portable apps get tweaked by changing the code, many are made in a similar fashion as thinstall, intercepting the registry keys that it uses, adding them to the registry and then deleting them after the app closes)

Again, in order to run on Unix environments Wine is used.

More over, both PortableApps and Thinstall depend on having access to a Windows runtime environment (a.k.a Windows APIs). Wine provides an alternative implementation of Windows APIs, which can then be used to run PortableApps and Thinstalled software.

I know, I never said the apps would run outside windows/wine

Don't confuse WINEPREFIX with what C: drive means on windows. Wine IS NOT installed in WINEPREFIX. All you have there are "fake" Wine DLLs. Whole new WINEPREFIX is a whopping 3.3MB. With Wine-Gecko - it's 21MB

So the WINEPREFIX is something like a complete "windows" environment ... without windows (or Wine).

I'm not confusing anything, that's why I put "whole" inside the quotation marks... don't you get confused

why do the bottles need a "whole" c: drive?

Because it was easier that way?

easier is better?... were there other ways to do the same?

Each bottle, or WINEPREFIX, is just a virtual C: drive, a windows
registry, and a set of drive letter mappings. In theory one could move a WINEPREFIX around; in practice, the unix location leaks through into .lnk files

Thinstall is that plus the machinery to make it easy to use
one of those on any Windows system, all bundled up in a .exe.
I'm not really sure about portableapps, haven't looked at those.

But the main difference is that nobody has put the effort into
making WINEPREFIXes portable between systems.

so, I guess it can be done then... nobody has done it, but would it be too hard to implement?... would it mean many changes or something?


another question, if it is finally done, could there be a way to make those portable WINEPREFIXes run in windows too?

[vitamin]

I know... after all your comment, it seems like they are not really apples, oranges and bananas, do they?

It seems you still don't get it. Scroll up and read again what each does.

another question, if it is finally done, could there be a way to make those portable WINEPREFIXes run in windows too?

No no no. You not getting the whole concept. WINEPREFIX is for Wine ONLY. It has no meaning nor will it even have a meaning on windows!

Wine is to run windows applications. Because windows applications need some windows environment - Wine has WINEPREFIX to simulate that environment. The major two parts of it are a) c: drive structure (files, directories) b) registry. Neither interchangeable with windows.

[Phobos]

why are they not interchangeable?... they are just files after all.. of course, you will need to make windows know what they are, but they could be made interchangeable, right?

[vitamin]

why are they not interchangeable?... they are just files after all.. of course, you will need to make windows know what they are, but they could be made interchangeable, right?

And where did you put windows itself into that picture? And registry?

[Phobos]

huh?

that's really what is interesting.... wine puts the registry and windows fake dlls and exes as files inside the prefix... there's no real registry... (then again, all of windows in wine is artificial, so it is not to wonder..)

something like this is what thinstall does, it makes the apps use an artificial registry, so they don't completely interact with the real one (only to read some keys... like the window's ones)... I'm still not sure how they do this...

if the prefixes are done to work in this way (and the .lnk bug is fixed), they could be portable not only in wine, but also windows... I think that the main difference with the current implementation would be the fake dlls and stuff, since wine (and the fakes) needs a unix-like system underneath.. but I'm sure this can be solved

the difference of wine (and that is why I asked) with thinstall, portableapps and softgrid all target a per-app container... that is, they put only the registry keys and files the app uses together... while wine targets a per-drive container (virtualizes a "whole" drive c with a "whole" windows")

the difference with thinstall and portableapps is that thinstall automates all the process so the user can make their own containers, while portableapps do each app by hand and distribute them

each idea have their advantages, but in the end work very similarly... (ok, you don't believe me.... read how codeweavers promotes the bottles feature http://www.codeweavers.com/products/cxmac/bottles/ and now read what thinstall shows as their features http://www.thinstall.com/solutions/solutions.php and notice how they are very alike)

note: I'm writing via the forum, so you probably didn't notice that I modified one of my posts saying this:

"(Btw, not all the portable apps get tweaked by changing the code, many are made in a similar fashion as thinstall, intercepting the registry keys that it uses, adding them to the registry and then deleting them after the app closes)"

there are times when they can't change the code not to use the registry... so, the portableapps also make a "virtual" registry as a text file that gets loaded on the real registry using a NSIS script (that works as a wrapper) that later removes it when the app closes... and they come with their own files configuring the app to use a relative path instead of an absolute one

as you see, what portableapps do sounds easier than what the others do, as they do modify the app a little... while the others don't.... but is almost the same idea...

so, no one in the community is interested in this?.... maybe codeweavers will and enhance the bottles .... just look how well did thinstall and softgrid (the first sold each single license at $5000) that they got bought by vmware and microsoft respectively... seems like a good commercial product... if it's cheaper than that, I would buy it hehe

please, do tell me where I'm wrong or correct and what you think about this

[Dan Kegel]

Phobos <[email protected]> wrote:

so, no one in the community is interested in this?....
... just look how well did thinstall and softgrid (the first sold
each single license at $5000) that they got bought by
vmware and microsoft respectively... seems like a good
commercial product... if it's cheaper than that, I would buy it hehe

Codeweavers offers something very similar already.
With Crossover, you can package a bottle as an .rpm (or .deb?)
file for easy distribution to everyone at your site.

OK, now go buy Crossover
- Dan

[Phobos]

no windows option, I guess? hehe..

maybe I'll try to work on it and see what can be done when I get some free time...

[Dan Kegel]

On Sun, Mar 9, 2008 at 8:02 AM, Phobos <[email protected]> wrote:

no windows option, I guess? hehe..

If you've been looking for a way to use wine to do
a thinstall-like thing *on windows*, that's a lot harder.

[Phobos]

not *on windows* but a way to make the prefixes work in both wine and windows... increased portability, perhaps?

[vitamin]

not *on windows* but a way to make the prefixes work in both wine and windows... increased portability, perhaps?

Wine doesn't run on windows. This is outside the scope of Wine project. If you need this functionality - you are welcome to start sending some patches in.

[Jim]

Apples, oranges, and bananas.

All three tackle their respective goals in very different ways, but only one of them can stand by itself on a Unix platform.

I know... after all your comment, it seems like they are not really apples, oranges and bananas, do they? :

Sure they can all be used for application containment. PortableApps and Thinstall even do that as their primary goal. Although the scope of applications covered by PortableApps is a bit more limited.

To a large extent that's where the similarities end. Especially where Wine is concerned. I can use a hacksaw to open up a can of soup. However, I'd hardly call the hacksaw a can opener. Wine is an alternative implementation of the services and APIs provided by Windows. It just happens that you can use it to contain an application. Just like it happens that you can open a can with a hacksaw.

I'm just saying that they all have different implementations and as a result have different limitations. This isn't a bad thing; all three are great tools. However they are different and understanding how they differ can be useful.

[Phobos]

aha!...

I have not had much time yet to see what I can do... but with a little investigation, I found something interesting for the naysayers here ...

you see, Jonathan Clark (founder of Thinstall, in 1999 and who also worked on the Doom and Quake ports to UNIX) thinks about the same lines as I mentioned before. In this blog you will find one of is post titled "Thinstall and WINE": http://communities.vmware.com/blogs/Opu ... l-and-wine. From the post:

"For people who see Thinstall for the first time, it seems like magic and they wonder how it works. But Thinstall isn't new - most of the concepts for Thinstall are a decade old and have been implemented by various open source projects such as Wine and UML.

...

Although Thinstall and Wine do not share any code internally and they are targeting different operating systems the underlying designs have many similarities. Both systems use a combinations of API translation and API emulation to achieve their goals.

Thinstall's primary goal is to allow Windows applications to run on the Windows operating system without installation and with limited changes to the host PC. The primary goal of Wine is to allow Windows applications to run on unix operating systems.

...

Wine was originally designed for Linux but was quickly ported to FreeBSD and today supports many other operating systems. While it never came to fruition, cygwin and Wine developers have contemplated porting wine to the Windows operating system using cygwin.

...


Design-wise, Thinstall has many similarities with Wine. Thinstall emulates and translates the Win32 API on a more selective basis to achieve its stated goals. With Thinstall the vast majority of the Win32 API passes directly to Windows with no emulation or translation. For example, when an application calls BitBlt, a function used to draw a bitmap to the screen, the call passes directly to Windows. Because Thinstall only replaces about 600 of the 10,000+ or so Win32 APIs it can achieve much higher levels of compatibility than are possible with Wine and generally it automatically supports newer operating systems and kernel updates. Because Thinstall is already running on top of Windows, we can use the existing operating system where possible rather than needing to reimplement everything.

...

Like wine, Thinstall can support multiple data directories so that applications can be separated from each other and the changes made by one application do not affect another application. In Thinstall, the default model is to give each application it's own private data directory. In Wine, the default model is to use one virtual environment for all Windows application. Also like wine, this data directory can be copied to other machines or users and used as "snapshot" and thus eliminating some or all installation steps normally needed to use the application. Thinstall takes this a bit further by implementing a compressed read-only file system that can be directly embedded in the original EXE file so distributions can occur via a single file.

Thinstall uses another concept called Copy on Write (COW) which is not present in Wine. COW has been a key concept in operating system design and CPU design over the years.

Thinstall uses COW to allow read-only access to parts of the file system and registry such that any operations that would cause modifications will copy the data to a private sandbox area where modifications occur without affecting the rest of the PC. The first implementations for COW occurred in microprocessor and OS design in the 1980's and soon after it was adopted by virtualization/emulation solutions such as Bochs, QEMU, and UML for virtual disk storage. As well, numerous older file systems implemented the concept of snapshots and COW at the file granularity level.

...

Summary

Thinstall and wine share a lot of common design ancestry that goes back more than a decade. This design commonality evolved naturally and independently because both projects were targeting the same standard which was defined by Microsoft - otherwise known as the Win32 API. Thinstall and wine are not unique in targeting this platform, IBM's OS/2, ReactOS, Windows 9X, and Windows NT also implement the Win32 API as a standard."

So yes, the projects do share a lot of ideas even if the final targets are a bit different... that cygwin part might be what I was searching for to make wine run on windows, but I'll have to test it and see what happens

PS. a mail by Jonathan Clark on wine-devel could also be of interest to some, as he was searching for wine coders to work on thinstall (due to the similarities shared by both) at the time (for the current 3.x version)... it's here: http://www.winehq.org/pipermail/wine-de ... 8806.htmlp