Direct3D Takes First Steps In Wine 1.7.50

Status
Not open for further replies.

ohim

Distinguished
Feb 10, 2009
1,195
0
19,360
I know i`m going to get rage down votes for this but here it goes ...

Linux people be like "Oh Windows is buggy and crap, i`m gonna install Linux and run Windows app trough an emulator and have even a more crappier experience"
 

HeavyHDx

Reputable
Aug 22, 2015
1
0
4,510
WINE Is No Emulator. It is a compatibility layer that provides libraries and patches that allow applications to run semi-natively on Linux and Mac. An Emulator would have Windows running in the background, essentially.
 

paulbatzing

Reputable
Apr 11, 2014
156
0
4,760
The reason WINE differentiates itself from emulators is that it doesn't emulate any CPU/GPU architecture. Emulators have usually a virtual cpu implemented, meaning that they have a program that takes e.g. PPC commands as input, and then simulate what a PPC would output given that input. In extreme cases of old architectures that are non standardized, they might even model the complete cpu logically. WINE doesn't need to do that, it runs natively on x86, just as Windows. It only needs to provide library's.
 

kryptylomese

Distinguished
Oct 17, 2011
2
0
18,510
If Linux guys have to run a Windows app then we would rather do on a good operating system and not have to go anywhere near Windows and WINE actually does a very good job of it too!
 

scoutme

Reputable
Aug 22, 2015
1
0
4,510
NO, it's not an emulator. An emulator is an application that simulates a low level layer in order to resolve native calls in artificial way. Wine simply adds win32/dx apis to Linux. It's similar to .NET and Java runtimes, if you can feel the subtle difference
 
Wine and emulation:

Take 15 seconds and do some research (some here have it right):

"The phrase "wine is not an emulator" is a reference to the fact that no processor code execution emulation occurs when running a Windows application under Wine. "Emulation" usually refers to the execution of compiled code intended for one processor (such as x86) by interpreting/recompiling software running on a different processor (such as PowerPC). Such emulation is almost always much slower than execution of the same code by the processor for which the code was compiled. In Wine, the Windows application's compiled x86 code runs at full native speed on the computer's x86 processor, just as it does when running under Windows. Windows system services are also supplied by Wine, in the form of wineserver."
 

eriko

Distinguished
Mar 12, 2008
212
0
18,690
WINE Is No Emulator. It is a compatibility layer that provides libraries and patches that allow applications to run semi-natively on Linux and Mac. An Emulator would have Windows running in the background, essentially.

But it must obviously running a Windows environment of sorts (as far as the software can 'see', to allow the code to run at all... Or it wouldn't run...
 
Ahh this old discussion.

The guys who came up with the WINE acronym were under the false assumption that emulation was only something that happened with hardware. There is such a thing known as environmental emulation upon which one set of software emulates the environment of another by intercepting and translating libraries and function calls. MS Windows does this natively by emulating the environments of previous versions of Windows. It even does with this with older versions of Direct X.

So technically speaking, WINE is definitely an emulator. It emulates the application environment of MS Windows and thus enables binaries and libraries written for MS Windows to execute in a different host environment. Environmental Emulation isn't nearly as expensive as platform emulation (CPU / GPU / architecture / ect..) but neither is it completely free as there is still a layer that interprets the guest environment and translates into the host environment.
 

planetacancun

Distinguished
Apr 25, 2009
13
0
18,510
A drop of WISDOM for you all:
Wine is Not an Emulator.

Think of it as the JIT compiler on Android. It creates a "Virtual Machine" (is not) to run JAVA code on ANY processor. Not for that is an "emulator" right? It's just "translating" one code into another. Wine translates win32/64 machine code to *nix machine code "Just In Time" in x86-64, ARM, Elbrus and God knows in what other platforms we don't even know.

An emulator "emulates" the complete functions of a guest OS such as OSX, Unix, AMIGA OS, Windoze, etc. Examples: VirtualBox, VMWare, OPENEmu, Parallels.

“For those who understand, no explanation is necessary; for those who don't understand, no explanation is possible” ;)

 

planetacancun

Distinguished
Apr 25, 2009
13
0
18,510
I think only the WINE "devs" emulate the windows apps to "code in" the translations so you DON'T have to emulate nothing when using it. Just "translating" Just In Time for you. Devs Emulate, you don't. Got it?



 

g00ey

Distinguished
Aug 15, 2009
470
0
18,790
I think I'll side with paladin on that the concept of emulation is a little more abstract than just hardware. I don't think that Wine works that well on ARM as the binaries are compiled for the x86 architecture.

Wine basically relies on that Windows .exe files run on x86 hardware. The problem is that Linux don't know how to execute windows binaries so Wine has a routine that parses the Windows binaries properly into the CPU the way the Windows kernel would do it.

But Windows binaries also relies on API calls to different frameworks in the Windows environment. We're talking frameworks such as Visual(X) Runtimes, .net frameworks etc. So Wine has reconstructed this framework so that the interface can handle those framework specific API calls. One such example would be to translate Direct3D specific API calls into something that the OpenGL framework that resides in Linux can handle.

In a way one could argue that Virtualization is not emulation as also here, machine instructions are parsed directly to the CPU. But some hardware components are still emulated, such as the GPU, Network and other hardware that is not the CPU.
 

bimbam360

Reputable
Mar 3, 2014
38
0
4,560
The whole Emulator debate is like arguing that to sauté something isn't the same as frying it. Yes to sauté has a more specific definition, but plenty of people will not know what 'sauté-ing' is, so calling it 'frying' to the masses makes perfect sense. Ultimately, the end result is the same.

Same is true here, as 80%+ of the time the end goal of an emulator is to run applications from one system, on another system. I imagine to the vast majority of the IT world that is the first thing they think of when they think 'emulator' rather than the semantics of compatibility layers.

For most people glancing over this article, 'WINE is an emulator' is all they need to know. For everyone who knows better....you know better, you don't need to rag on the writer for saying it. He probably knew better too.

The main problem is the literal definition of 'emulate' in this instance contradicts the computing definition a bit. To emulate, is to imitate. WINE does exactly that and describing it as an emulator, as much as the fan boys may hate it, is the simplest way to explain it to the most people. It may not be entirely accurate, but I imagine at some point those who write articles got sick of copying and pasting the entire (https://www.winehq.org/about/) and just used 'it's an emulator'.

;tldr - get over yourself.
 

kenjitamura

Distinguished
Jan 3, 2012
195
3
18,695
Hey guys, if developers start building applications with cross-platform tools from the start we may never need to argue whether WINE is an emulator or not again :p

Especially in regards to games. OpenGL 4.5 isn't in any way inferior to Direct3D 11.3 and I highly doubt Vulkan will be much different from Direct3D 12. Though at this point in time I don't think negative of any of the games already switching over to Direct3D 12 as it came out quite a bit before Vulkan but when it's out here within the next 3 months I'll be pretty darn disappointed if game developers are still opting to start their games from scratch with Direct3D 12 instead of Vulkan.
 

Haravikk

Distinguished
Sep 14, 2013
317
0
18,790
The main problem is the literal definition of 'emulate' in this instance contradicts the computing definition a bit. To emulate, is to imitate. WINE does exactly that
See this isn't really true either; WINE isn't exactly "imitating" these APIs either, what it does is provide native Linux/Unix APIs that conform to existing Windows APIs. While Windows executable running via WINE may not notice the difference because they haven't been written to do-so, but they could be if they wanted to know the difference.

Even when you select compatibility modes for WINE (e.g- Windows XP, Windows 7 etc.) you're really just tweaking the exact version of those native APIs, the features that they implement and the behaviours that they implement in order to conform to what a program might expect.

While you can argue degrees of mimicry, the fact is that WINE is not actively pretending to be a legitimate copy of Windows, but instead is simply providing Windows executables with the APIs that they need in order to run.


In true emulation you are running an actual copy of Windows (which WINE does not require) within a virtual machine that's actively pretending to be genuine hardware, despite actually sharing hardware with another host OS. To both Windows and your programs the virtual machine is a legitimate PC, WINE does not provide that.

The most fun difference between WINE and emulation is that software running under emulation is universally worse than running natively under the same guest OS, even if it's just a tiny performance difference that you won't really notice. However programs under WINE can actually run better than they would under Windows; this is the case with Skyrim which can actually run provably better via WINE under Mac OS X than it does when running under Windows under emulation, and even runs better (for me at least) than restarting into Windows 7 to run it natively, albeit without true controller support as I don't think anyone has really been working on that for WINE.
 

Eric Swenson

Honorable
Mar 16, 2013
12
0
10,510
This is great news - kudos to the Wine Devs!!!

I use Wine for a few applications, including somewhat older games such as Starcraft 2 for the kids and v1.7.x works flawlessly, unlike previous versions. This is a great, high-quality project.

Nobody should be complaining that Wine isn't emulating DX12, as there must be 10,000 DX11 titles compared to 0 DX12 at this point. The real-world benefits of emulating DX11 on linux will be huge and could save a lot of native porting.

Of course, as future games are developed on Vulkan then Linux ports will be much simpler.
 
. . . except that it is indeed an emulator.

So is the "compatibility mode" in windows that allows you run older windows programs in newer windows a "emulator" as well?

Wine and that are similar to each other.... and we dont call Compatibilty mode an emulator......
 
Status
Not open for further replies.