IBM killed OS/2, because they hate end users. IBM has a long history of making great end user products (awesome keyboards, great laptops, still good software) only to sell them to the highest bidder. All IBM execs can see are penguins with suitcases full of dollar bills. OS/2? End users loved it, but it didn’t run on mainframes. Killed. The Model M keyboard? End users loved it, but it was too durable, so it did not guarantee many sold units (because why would anyone buy a new Model M while the old one is still good?) -> rebranded as Unicomp and left to rot. (Typing this on a Unicomp PC122, but that’s a different story.) Thinkpads? Ah well, those are expensive. And they aren’t mainframes. Sold to the Chinese because ugh! End users! Lotus (SmartSuite, Notes)? Nice to have, but nope, too many end users. Ugh! End users!
Most people game on windows. It’s monolithic nature also means that they will mostly encounter the same bugs.
Linux has a wider base of functionality. A bug might only show up on Debian, not Ubuntu.
End result, they spend 60% of their effort solving bugs, for 2% of their base. That’s not cost viable.
Compatibility means they just have to focus on 1 base of code. All we ask is that they don’t actively break the compatibility. This is far less effort, and a lot easier to sell to the bean counters.
Once Linux has a decent share, we can work on better universal standards. We likely need at least 10% to even get a chance there.
I don’t want to start that extremely old flame war of native VS jit code but…
Proton is not an emulation, it is a translation to native code, and while it has some drawbacks (more memory usage, more time at start up to compile things) it can unlocks a lot of potential when the hw support new capabilities, this is the reason that some dx10 games run faster on Linux…
I might be wrong, but I don’t think proton is either? It’s running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.
As far as I know for the new Vulkans layers and dx12 implementation there is a “translation layer” from the old dx implementation to the most updated one. This is the main reason why old games runs faster on Proton than in w7 for the same hw. Even if they were designed for w7 specifically.
Last time I checked this was done during the booting of the game, but i have to admit this was time ago and it could have been changed.
It is a translation layer, but the bit you added “to native code” sounds like you’re misunderstanding what translation layer means.
Games use a collection of APIs (DirectX is a set of APIs, but there’s others to handle offer operations like network access and such) to interact with OS functionality, and also receive communicarion back from the OS (the windows message loop). Proton and wine are implementations of those APIs that translate the API calls to their equivalent in linux, as well as setting up their own message loop that translates messages from the linux kernel and UI system into their windows equivalent before sending them to the registered windows messaging loop functions.
A simple example would be if a function header in windows looks like int32 SomeFuncWin( int64 index, char* name ), but looks like int32 SomeFuncLinux( std::string name, int64 index ), then the translation would be something like:
int32 SomeFuncWin( int64 index, char* name ) {
std:string TranslatedName( name );
return SomeFuncLinux( TranslatedName, index );
}
So it doesn’t change/translate any of the code of the program itself, it just provides the environment that behaves exactly like a windows environment by translating the “hey could the OS do this for me?” requests from windows to linux. Note that not all translations are that simple, there might need to be more processing on the values, missing arguments might need to be filled in, irrelevant arguments ignored, sometimes data needs to be translated to another format, etc.
The speed ups can come from improved efficiency in the underlying implementations (which Vulkan has, as I understand even using a translation layer from DX to Vulkan in windows can result in better performance) or having fewer services running in the background.
You are partially right, I was fast and sloppy and I gave the impression all is jitted and it is not the reality.
The part of the translation is fine. However there are parts that are compiled beforehand (shaders for example and I can recall something about arm or other architectures, not sure now). And this is a crucial point of the extra performance, because some parts can be ported to more updated/efficient implementations, not because there are less services in the background.
Good, but native would be better. At least they can’t kill Linux the way they did os/2
IBM killed OS/2, because they hate end users. IBM has a long history of making great end user products (awesome keyboards, great laptops, still good software) only to sell them to the highest bidder. All IBM execs can see are penguins with suitcases full of dollar bills. OS/2? End users loved it, but it didn’t run on mainframes. Killed. The Model M keyboard? End users loved it, but it was too durable, so it did not guarantee many sold units (because why would anyone buy a new Model M while the old one is still good?) -> rebranded as Unicomp and left to rot. (Typing this on a Unicomp PC122, but that’s a different story.) Thinkpads? Ah well, those are expensive. And they aren’t mainframes. Sold to the Chinese because ugh! End users! Lotus (SmartSuite, Notes)? Nice to have, but nope, too many end users. Ugh! End users!
To be fair, nobody loved Notes
I’ll take compatible.
Most people game on windows. It’s monolithic nature also means that they will mostly encounter the same bugs.
Linux has a wider base of functionality. A bug might only show up on Debian, not Ubuntu.
End result, they spend 60% of their effort solving bugs, for 2% of their base. That’s not cost viable.
Compatibility means they just have to focus on 1 base of code. All we ask is that they don’t actively break the compatibility. This is far less effort, and a lot easier to sell to the bean counters.
Once Linux has a decent share, we can work on better universal standards. We likely need at least 10% to even get a chance there.
Ummmm sure?
I don’t want to start that extremely old flame war of native VS jit code but…
Proton is not an emulation, it is a translation to native code, and while it has some drawbacks (more memory usage, more time at start up to compile things) it can unlocks a lot of potential when the hw support new capabilities, this is the reason that some dx10 games run faster on Linux…
I might be wrong, but I don’t think proton is either? It’s running x86 instructions either way, wine just provides a way to load it from the windows executable and library formats, and together with proton they provide implementations of windows libraries for those executables to use.
I guess most of the process is just using a wrapper to translate the call to a Windows library to the equivalent call to a Linux library.
As far as I know for the new Vulkans layers and dx12 implementation there is a “translation layer” from the old dx implementation to the most updated one. This is the main reason why old games runs faster on Proton than in w7 for the same hw. Even if they were designed for w7 specifically.
Last time I checked this was done during the booting of the game, but i have to admit this was time ago and it could have been changed.
It is a translation layer, but the bit you added “to native code” sounds like you’re misunderstanding what translation layer means.
Games use a collection of APIs (DirectX is a set of APIs, but there’s others to handle offer operations like network access and such) to interact with OS functionality, and also receive communicarion back from the OS (the windows message loop). Proton and wine are implementations of those APIs that translate the API calls to their equivalent in linux, as well as setting up their own message loop that translates messages from the linux kernel and UI system into their windows equivalent before sending them to the registered windows messaging loop functions.
A simple example would be if a function header in windows looks like int32 SomeFuncWin( int64 index, char* name ), but looks like int32 SomeFuncLinux( std::string name, int64 index ), then the translation would be something like:
int32 SomeFuncWin( int64 index, char* name ) {
std:string TranslatedName( name );
return SomeFuncLinux( TranslatedName, index );
}
So it doesn’t change/translate any of the code of the program itself, it just provides the environment that behaves exactly like a windows environment by translating the “hey could the OS do this for me?” requests from windows to linux. Note that not all translations are that simple, there might need to be more processing on the values, missing arguments might need to be filled in, irrelevant arguments ignored, sometimes data needs to be translated to another format, etc.
The speed ups can come from improved efficiency in the underlying implementations (which Vulkan has, as I understand even using a translation layer from DX to Vulkan in windows can result in better performance) or having fewer services running in the background.
You are partially right, I was fast and sloppy and I gave the impression all is jitted and it is not the reality.
The part of the translation is fine. However there are parts that are compiled beforehand (shaders for example and I can recall something about arm or other architectures, not sure now). And this is a crucial point of the extra performance, because some parts can be ported to more updated/efficient implementations, not because there are less services in the background.
“Perfect is the enemy of good.”