Valve’s “Steam Deck” handheld PC has caused quite a stir among PC gaming geeks, but the biggest shakeup might not be its Nintendo Switch-like form factor. The software running inside of it is the real surprise. Why does the Steam Deck run Linux? Blame Windows.
The Steam Deck and the software inside of it are the culmination of a nearly decade-long “hedging strategy” embarked upon by Valve chief Gabe Newell and company many moons ago, when Microsoft tried exerting more control over developers with Windows 8.
But it’s also the next phase of Valve’s escape plan.
Also, Windows is simply a terrible choice for the Steam Deck. The base model only has 64GB of storage, and Windows 10 will easily take up two-thirds of that.
Valve should have funded ReactOS.
Seriously, in the past 2 years, with their minimal funding and devs, they have made giant strides.
Funding Proton was the much smarter move, maybe it is for that reason why they did that 😛
But maybe Valve next step should be to invest in a new Open Source Runtime that is just a thin layer over existing tech (Vulkan, Audio? and input) and that would abstract the OS away for games.
So a game developed for this runtime would just work on Linux, mac and Windows.
WTF?
You already got SDL2, SML, OpenAL, Vulkan, OpenGL, etc. Valve already invested in SDL2, so why reinvent the wheel?
They also made SteamInput(working trough SDL2 for causal apps), OpenVR(SteamVR, hope it will be replaced by OpenXR at some point, as it’s Khronos standard now)
In the past Direct3D was the biggest problem, now it’s mostly WinRT apps and DRM.
Microsoft and Apple forced vendors to not provide their own OpenGL drivers, and Apple boycotted Vulkan, with their Metal API (so 99% of stuff on Apple is Vulkan native, going trough Mantle translation layer…)
If you need portable full game engines, there already are commercial UnrealEngine, Unity and even OSS ones, like Godot and Defold (both are used in commercial games too)
Well actually no. Microsoft provided the OpenGL ICD mechanism. (They didn’t have uch choice if they wanted to keep government or big industry contracts as so much high end niche software runs on OpenGL) They just refused to include OpenGL drivers in the base install of Windows. IHV’s usually supplied OpenGL in their own driver installs along with Direct3D. If your installed the IHV’s driver pack you’d get both.
Pretty much every graphics API is driven by IHV’s. OpenGL/Vulkan is a consortium of vested interests. Direct3D and Metal are Microsoft and Apple propriatory, respectively.
Apple got NIH. Forcing vendors to go via an abstraction is a bit of a pest but the hardware is going to be the same whatever they do. Microsoft always hated OpenGL/Vulkan.
How does that differ from what Wine already provides?
A portability from step one approach allows you to produce native code for any current or future platform. It is quite a bit of work to do it properly if you’re starting from scratch but it is a very very thin layer. On top of this abstracting gets you away from platform dependencies and quirks and there’s a lot of value in this as you develop a better knowledge of what is happening at a low level with respect to OS, compilers, and SDK’s. You can provide basic “factory” functions and/or layer on top a more specialised framework.
There’sa whole slew of issues when you begin approaching higher layers like GUI’s an none of the established frameworks handle this terribly well. A lot of game engines are very portable but not really geared to being a basis for cross platform general purpose development.
As for Wine I don’t know. My portability layer included LInux stuff along with consoles and Windows and, I think, BeOS and other OS. I didn’t have much of a reason to focus on Wine but there’s no reason why Wine can’t be dealt with in a portability layer. The basic issue is Wine isn’t 100% feature complete or up to standard and you have to pick through these areas and check everything and put warning flags in if you want to do a compile which plays nice with Wine, or Wine and native Windows.
There’s actually quite a bit of work in this and anyone wanting to do a serious industrial grade “run time” has a lot of things to ponder. The main thing in my mind is getting it done right from the start. If you do this then you get very few if any problems later.
What you end up with is basically a framework built on top of a lower layer with portability baked in that you can use to target business applications or games or anything, and that is cross platform and can cope with shipping multiple binaries to run on multiple platforms. Just don’tspecialise too early. That’s really for when you are doing a project and all the more specialised stuff goes in that layer whether you’re designing a business application ro server appcliation, or a game engine. There’s huge overlap but enough different and enough different needs of the developers you need to be careful where exactly you draw the line between different domains.
I think there’s a massive scope issue there. Even with full funding, getting ReactOS to beta level would probably take 8 years. Then there was that time when they had to audit the entire source code and stop development. ReactOS would be good in the long term, but it would be a total money pit for a large organization expecting serious results anytime soon.
No, that would be a losing strategy. ReactOS is a monumental achievement, but it’s nature is to be a full blown Windows clone. Valve doesn’t need a full blown Windows clone. They need Win32/DirectX compatibility and Wine as a base for Proton gave them precisely that. Added bonus is that you can treat it as a fairly platform agnostic runtime layer. If you have something *nixy running, you can easily port Proton.
Proton is a brilliant strategy. It pulls Microsoft’s crown jewel (application environment) out of MS’s control and decouples it from the rest of the Windows OS. Microsoft has never sued Wine for infringement and we all know if something shady was going on with the Wine codebase, Balmer’s Microsoft would have sued it into a crater. Microsoft can’t pull an Extend/Extinguish either, because their own success hinges on keeping Win32 compatible (for the largest part).
If Valve plays it’s cards right (and they seem to be), they will create a game development environment that is MS compatible and they will be in a position to deploy it everywhere and MS will have little recourse to thwart it, lest they sink their own environment.
What’s good in ReactOS?
– windows apps compatiblity is not better than wine/proton, because it’s wine userspace
– poor drivers compatbility, so with small exceptions, much worse hardware compatibility. So say goodbye to games.
Linux is much better and mature OS, both on kernel and userspace side. There’s no real reason to use ReactOS, maybe except ATMs and some other rare scenarios.
All in all Linux is better suited for the task Valve is after. Windows for such task doesn’t make much sense to anybody else but Microsoft. For their own console.
Gabe Newell is an ex Microsoft manager and we all know including Gabe what Microsoft did to Nokia and a long string of other companies. Microsoft used their monopoly to force X-Box and in the process ripped off and sucker punched SGI with the joint venture “Fahrenheit” project and set out to destroy OpenGL. Borland was cratered not long afterwards as Microsoft pulled the same stunts with huge bribes to poach Borland’s staff. Nice company they are not.
Any developer who doesn’t begin with a portability layer and abstract away from the API as quickly as possible is asking for trouble.
Holly:
Just curious: Are you referring to the Windows 9x era DirectX software, or the hardware Xbox itself?
Both. There was the Opengl v Direct3D wars. Fahrenheit and later doubling down on Direct 3D was Microsoft being Microsoft. The X box thing sort of trundled on later but also in parallel. With the Windows platform Microsoft tried to shake off OpenGl more than once fairly recently including Windows 10 and tried to make out Vulkan was D.O.A before it got started which is a blasted cheek.
HollyB:
Thanks!