I cant believe anyone would still be running XP and on the internet ??? If you have to run XP for god sake dont let it loose on the internet , lol it more then likely wont last very long.
Uncle Fester (17-07-17)
Maybe a typo and you mean 'isn't'. Wine basically as an emulator just adds a compatibility layer between Linux/MacOS/BSD and the Win programs which you wish to run on them (as per the original WINdowsEmulator). If the API calls aren't understood they are converted into POSIX calls which the foreign OS can understand and utilize. It's done on-the-fly which may mean that everything happens slower than on a native Win OS or indeed a Win visualizer such as Virtualbox or VMware. Wine isn't an emulator of the other ilk, i.e. a CPU emulator like Unicorn (This is where the current WineIsNotanEmulator acronym comes from). Therefore although maybe it's a little simplistic to call it an interpreter or translator really from the average user's point of view that's what it does.
Yes, they do still run it in numerous cases. A different version of XP to that used in home, business or server versions however. It should be appreciated that Windows Embedded POSReady 2009, based on Win XP SP3, is still fully officially supported until at least 2019. The earlier WEPOS based on SP2 lost support early in 2016 but I seriously doubt any major players would still be using that and would have updated older hardware to WE POSReady 2009 or later long ago, or have replaced the hardware completely if for any reason it wasn't compatible with at least the SP3 based OS.
From here:. It matters not whether Wine is a VM or an Em, to the hardware that it is attempting to communicate with, it may still be a bridge too far.And just to complicate things, is also more a hypervisor/virtual machine (albeit at a higher ABI level) than an emulator (hence "Wine Is Not an Emulator").
I'm out of my mind, but feel free to leave a message...
I do get your point, but semantics are important there. That reference you've quoted [Wine is not an emulator] is to CPU emulators exactly as i also said above. For instance as reference by that stackoverflow poster and as i mentioned above are both CPU Emulators. The Wine website itself describes Wine as a compatibility layer, which means it sits between the non-native software and an OS to interpret commands into something that can be understood by that OS. Therefore, it's absolutely not a VM in the normal sense that's taken to be i.e. a functioning guest OS on a host OS. Wine basically [over-simplistically] acts as a 'go-between and translator' and in that sense it's emulating understandable commands. Just like some printers have HP LaserJet Emulation built into their software. I think the poster in stackoverflow was trying to 'keep it simple sam' at the end but forgot the precise semantics in that final sentence. The rest of the thread and his complete post makes it plainer what he was conveying. His entire post:
From the Wine mob themselves:Virtual machines make use of CPU self-virtualization, to whatever extent it exists, to provide a virtualized interface to the real hardware. Emulators emulate hardware without relying on the CPU being able to run code directly and redirect some operations to a hypervisor controlling the virtual container.
A specific x86 example might help: Bochs is an emulator, emulating an entire processor in software even when it's running on a compatible physical processor; qemu is also an emulator, although with the use of a kernel-side kqemu package it gained some limited virtualization capability when the emulated machine matched the physical hardware — but it could not really take advantage of full x86 self-virtualization, so it was a limited hypervisor; kvm is a virtual machine hypervisor.
A hypervisor could be said to "emulate" protected access; it doesn't emulate the processor, though, and it would be more correct to say that it mediates protected access.
Protected access means things like setting up page tables or reading/writing I/O ports. For the former, a hypervisor validates (and usually modifies, to match the hypervisor's own memory) the page table operation and performs the protected instruction itself; I/O operations are mapped to emulated device hardware instead of emulated CPU.
And just to complicate things, Wine is also more a hypervisor/virtual machine (albeit at a higher ABI level) than an emulator (hence "Wine Is Not an Emulator").
My emphasis in red above. Ref:Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
This is prob getting way OT now so i won't be further drawn on the differences between or similarities of VMs, Emulators and compatibility layers. I guess it's all so much horse feathers to many ppl anyway.
Bookmarks