Sorry, I misunderstood what you were saying. I thought you were talking about running Prison Architect under a windows virtual machine. This is typically what is meant by virtualization.
I don't think wine is usually regarded as virtualization as such, but I guess in terms of it being a sort of virtual OS, you may not be wrong.
Linux Build?
Moderator: NBJeff
- paktsardines
- level5
- Posts: 1752
- Joined: Mon Oct 01, 2012 11:10 am
- Location: Australia
xander wrote:paktsardines wrote:virtualization seems to be the only alternative.
What? No, wine is an excellent alternative... Prison Architect will run much faster under wine than it will under any kind of virtualization. In fact, I think Prison Architect runs faster under wine than it does under windows (although this in itself is often the case with wine).
Isn't Wine a form of virtualization? I understand that it doesn't emulate the entire machine, but it passes Windows API calls to the OS as POSIX calls, adding a layer of virtualization between the program and the OS. Or is my use of the word incorrect?
xander
Wine stands for "Wine Is Not an Emulator"
it just implements all the libraries a typical windows program would rely on, but in linux...
emulation/virtualization is entirely different.
- paktsardines
- level5
- Posts: 1752
- Joined: Mon Oct 01, 2012 11:10 am
- Location: Australia
Unless you're talking software virtualization (as opposed to hardware virtualization, of which virtual machines are the example). I think you could, at a stretch, argue that wine is a form of software virtualization.
So yes, while xander might not be right, he may well not be wrong.
So yes, while xander might not be right, he may well not be wrong.
Last edited by paktsardines on Sat Nov 10, 2012 5:30 am, edited 1 time in total.
- paktsardines
- level5
- Posts: 1752
- Joined: Mon Oct 01, 2012 11:10 am
- Location: Australia
Carmelle wrote:Wine stands for "Wine Is Not an Emulator" :P
it just implements all the libraries a typical windows program would rely on, but in linux...
emulation/virtualization is entirely different.
I am aware of what Wine stands for. in fact, that is why I used the word "virtualization" to refer to Wine, rather than "emulation." Emulation and virtualization are not the same thing:
Virtualization is more about creating virtual barriers between multiple virtual environments running in the same physical environment. The big difference is that the virtualized environment is the same architecture. A virtualized application may provide virtualized devices that then get translated to physical devices and the virtualization host has control over which virtual machine has access to each device or portion of a device. The actual execution is most often still executed natively though, not through software. Therefore virtualization performance is usually much better than emulation.
Source: http://stackoverflow.com/questions/6044 ... ualization
My understanding is that Wine allows Windows software to run natively on the hardware, with Wine translating some of the system calls on the fly. Assuming that the above quoted comment is accurate, Wine seems to be the very model of virtualization (rather than emulation).
xander
- paktsardines
- level5
- Posts: 1752
- Joined: Mon Oct 01, 2012 11:10 am
- Location: Australia
Hmm, from what I understand, Wine is none of the above. A hypervisor, by definition, is emulating some sort of hardware.
Virtualization is when you have the abstraction of one layer from another. For example, a java virtual machine provides an abstraction, such that the byte code written in Java can be run any lots of different hardware configurations. Generally you have strict separation in these cases. That is, keeping with the java example, a java program wouldn't be able to access the underlaying hardware directly (you're not going to be writing x86 assembly in java). Conceptually, virtualization is similar to sandboxing, at least in that by using a virtualizing model you end up creating a seperate entity/system/whatever for the software to run in seperately from the rest of the host system.
Wine is simply translating the calls. So as you call a windows api call to check the permissions on a file, Wine calls the corresponding posix call and then translates the result into what the windows api call would have looked like. There's no strict separation or abstraction here though.
Effectively, it's just a set of libraries that have the same API signature as the windows ones, but the underlying code uses posix-specific calls rather than windows-specific calls to function. This is why sometimes using Wine is faster, because the underlying equivalent posix calls or the code Wine uses is faster than the Windows code. And they follow the same principle in their implementation of directx; it's not emulating, they actually created it all themselves.
I'm not sure what the exact term to use to categorize Wine...but I'd say it's something of like a translation or compatibility layer I guess?
Anyways, wayyyyyyy off topic, but it's interesting to discuss
*edit* CodeWeaver's site describes it pretty aptly: "Unlike other emulators, Wine is a re-implementation of the Win32 API, allowing applications to run natively on the target OS", emphasis mine.
Virtualization is when you have the abstraction of one layer from another. For example, a java virtual machine provides an abstraction, such that the byte code written in Java can be run any lots of different hardware configurations. Generally you have strict separation in these cases. That is, keeping with the java example, a java program wouldn't be able to access the underlaying hardware directly (you're not going to be writing x86 assembly in java). Conceptually, virtualization is similar to sandboxing, at least in that by using a virtualizing model you end up creating a seperate entity/system/whatever for the software to run in seperately from the rest of the host system.
Wine is simply translating the calls. So as you call a windows api call to check the permissions on a file, Wine calls the corresponding posix call and then translates the result into what the windows api call would have looked like. There's no strict separation or abstraction here though.
Effectively, it's just a set of libraries that have the same API signature as the windows ones, but the underlying code uses posix-specific calls rather than windows-specific calls to function. This is why sometimes using Wine is faster, because the underlying equivalent posix calls or the code Wine uses is faster than the Windows code. And they follow the same principle in their implementation of directx; it's not emulating, they actually created it all themselves.
I'm not sure what the exact term to use to categorize Wine...but I'd say it's something of like a translation or compatibility layer I guess?
Anyways, wayyyyyyy off topic, but it's interesting to discuss
*edit* CodeWeaver's site describes it pretty aptly: "Unlike other emulators, Wine is a re-implementation of the Win32 API, allowing applications to run natively on the target OS", emphasis mine.
Who is online
Users browsing this forum: No registered users and 9 guests