smartroad wrote:I accidentally pressed the wrong button on a shutdown on my desktop and it installed the update for me
Not hit any major issues but not played ED since the update. I hate Microsoft, I really wish Valve would push SteamOS more, it would be great for Linux gaming in general.
Valve had the Linux metrics for years (users running under WINE), but dared not challenge Microsoft until the EA fiasco. Windows Live [for Gaming] (Windows 8.x app [and gaming] store strategy) failed, and Valve now was going full-bore Linux as a result of the prior threat of extinction at the hands of Microsoft.
Corel ran into this before, when they bought WordPerfect. They were cut-off by Microsoft overnight, locked out entirely, and were forced to Linux. Unfortunately it was the '90s, before mass Linux adoption and heavy hardware support that we enjoy on Linux today (to the point any Linux installs better out-of-the-box, with more hardware support, than the Windows media since about '07 -- but most people don't know that because they get Windows pre-installed, and not have to install it themselves with all the driver non-sense of Windows).
smartroad wrote:Also if they could come up with an API interface for DirectX that could mean playing Windows games on Linux.
Huh?
First off, DirectX is really just a set of wrappers to hardware calls. Software DirectX implementations have long fallen behind hardware. OpenGL has suffered similarly, despite trying to keep up with v2, v3 and now v4 releases. Eventually the OpenGL Architectural Review Board (ARB) reviews AMD and nVidia extensions, and documents them, much like how the IEEE tries to operate for 802 (document proprietary vendor extensions, and find commonality). But still, most hardware calls rarely get implemented in software OpenGL, which is why Mesa libGL continues to be well behind either Catalyst or nVidia libGL.
So ...
Secondly, both AMD and nVidia
simultaneously release
both proprietary
DirectX and
OpenGL extensions, and this has been the case since '99-'00, where nVidia and Microsoft acquired most of the SGI patents. I.e., after 2000 no longer did AMD and nVidia have to worry about some patent or other IP limiting what they could release for either, and the "unified" kits came out at that time. That's why DirectX v. OpenGL doesn't matter for the most part.
DirectX itself was never supposed to exist, as Microsoft had committed itself to OpenGL in 1993.
► Show Spoiler
But because Windows 95 absolutely sucked at OpenGL (long story), Direct DOS Memory Map (DirectMM), later known as Direct2D, was created. Eventually as more Direct "blah" APIs were created, DirectX came to be. OpenGL is all-encompassing. I.e., it's not just for 3D, but 2D, windows, etc... It goes back to SGI's IrisGL, which is where OpenGL came from. OpenAL was then created in the late '90s to provide the spatial audio support, and is used by many Windows games too.
As far as input, those layers of abstraction have long been there in POSIX device interfaces. In fact, far less coding was required on Linux platforms to support most things (input, printing, scanning, etc...) than Windows subsystems, especially versus pre-NT6 (XP and earlier) platforms that utterly lacked the rich, standard subsystems of Linux (e.g., udev, Postscript-CUPS, SANE, et al). Most enterprises use these open source solutions, including their Windows clients, on enterprise networks for a reason. I mean, Apple acquired the copyright holders of the Common UNIX Printing System (CUPS) for a reason, and most enterprises moved to Scanner Access Now Easy (SANE) because it supports network scanning and standardizes interfaces (it's cake compared to TWAIN, let alone avoids inter-device conflicts that TWAIN has).
The same goes for input devices under Linux. Unlike Windows, out-of-the-box, with a simple configuration change, you can use a single Linux system with dozens of input devices, output devices (displays) for multiple, simultaneous users. Windows was always designed for a single user, with a single device input set, and over time they've had to hack in solutions to allow multiple input devices, just for a single user (don't get me started on NT).
In fact ...
By 2004, with the availability of Linux/x86-64, Linux became the premier gaming development platform, and that hasn't been relinquished ... to anyone. From Disney to Hollywood to Epic to Sony, that's the reality now.
► Show Spoiler
In the '90s, both Nintendo and Sony moved to Linux for their official devkits, but the run-times also started to become mainstay by the '00s, as Linux/x86-64 provided the dev + run-time synergy with huge heap options, radically improving the dev-test cycle. That's when most major game titles starting having peer-developed Linux clients (yes, Linux versions), even if they were never released publicly.
I.e., it's none-too-difficult to develop a Linux version, and even easier to support given Linux's strong platform interfaces (unlike Windows' undocumented and sometimes unmaintained ones). Loki Entertainment proved this by the late '90s, and 64-bit literally changed everything in Linux's favor. No, the main problem is the cost of a 2nd platform at all, not the cost of supporting Linux.
E.g., Windows is not going away any time soon, so supporting Linux means adding a 2nd platform to support. But as more MacOS X games are also added, Linux now becomes a typical consideration too, because there is already a 2nd platform.
So ...
Lastly (what you might be
indirectly referring to), even when a vendor has produced a 100% WinForms toolkit game with undocumented Windows interfaces, even ones that break under Windows 10, like Windows 7 from XP before it, there is a Linux option, which is also used by MacOS X ports too.
► Show Spoiler
There is both the WINE Run-time and WINElib Porting Kit. The former is able to emulate the GDI, Windows Executive and other things, while the latter allows all Win32/DirectX calls to be 1:1 translated to ELF64/OpenGL calls.
In fact, many MacOS X versions games leverage WINE and WINElib too, for these capabilities, for the few things that are Windows-only. As the WINE project says ... they emulate Windows, bug for bug, version by version. I used to run Elder Scrolls III: Morrowind under WINE under Linux, instead of Windows 7 (at least before Bethesda did the engine update that made it more compatible with Windows 7), because it would just crash constantly under Windows 7 for me.
Linux already has everything it needs. It's just a matter of game houses deciding to piss Microsoft off, and supporting a 2nd platform. That's really it.
Again, understand the history since 2004, accelerated in 2010+, and why we are now here ...Valve was forced into the Linux strategy, because they pissed off EA (over DRM, Valve refusing to add more DRM EA wanted on DLCs), and EA went running to Microsoft, asking them to create a competitor and destroy Valve and its Steam platform. That was the Windows Live non-sense with Windows 8.x, where I had to move several dozens of my games off of Steam, and over to Microsoft's app front. It was a chronic failure, and Microsoft soon had to abandon it, by the damage was done. Valve had already publicly released all of its Linux support, which they had been working on since 2004 (had a native Steam client as early as 2007), and the rest is history.
It mirrors why Oracle, Sybase and other database vendors went Linux in 1999, and database solutions (other than small-time SMB stuff) on Windows have been dying for the past decade.
► Show Spoiler
In 1998, Microsoft outlawed all PC OEMs from shipping Windows Server with non-MS SQL database server software, trying to leverage its OS monopoly to gain MS SQL marketshare, which was only 6% of the database market at the time. So ... 6 months later, Gates was on the floor of a tradeshow, and everyone had their databases on Dell, HP and IBM PC Servers running Linux -- total backfire! Microsoft keeps trying to control the distribution channel, and shooting themselves in the foot, and MS SQL is not used as a major enterprise database today as a result.
Correspondingly, in 2004, the head of Epic Megagames was the first to point out the fact that Microsoft was chronically failing game development houses, and that the industry was switching to Linux/x86-64 for high-end development.
► Show Spoiler
NT/x64 was well behind, not viable, and Microsoft didn't have the "64-bit clean" experiences that Linux worked out on Alpha over the past decade, despite NT being on Alpha too (but only 32-bit, and eventually dropped by 1999). He later predicted Microsoft Live would utterly fail for gaming, and Electronic Arts (among others Microsoft was able to draw in with them) would crawl back to Valve and be on Steam again. He was right.
Most recently Microsoft has been strong-arming all Hardware and Software Vendors to
only support their app store for Windows 10. Most now predict that between 2020 to 2023, you'll have to unofficially "side load" applications on Windows, guaranteeing they'll break regularly, because Microsoft will require all hardware and software to only come from its app store. Which is why Valve is moving to Linux. And they aren't alone.
And for those of you who haven't hear ... Windows 10 Enterprise Edition cannot be "bought," only "rented" for US$7 per user per system. They are moving to the 1-3 year subscription model, like Red Hat. Microsoft is trying to get home consumers to move to this with Office 365, and would like non-Enterprise versions of Windows to have the same sustainment. Which is why there will be no Windows 11, just sustained Windows from now on (based on Windows 10).
► Show Spoiler
But unlike Red Hat, who only targets enterprise customers who need years 2-13 (post-initial release) sustained long-term, leading edge aka "Upstream" Linux (within 1-2 years of release) remains free for everyone (basically until those versions are abandoned by maintainers). Or as Red Hat's CEO said almost a decade ago, "I don't think home consumers should have to pay for their software." When pressed, the CEO clarified he doesn't see how Red Hat can make money on home consumers, and it's cheaper to give away 100% of its development for free, via the Upstream. It goes to the long-standing view that Red Hat will only target large customers for money, even if it puts a lot of developers on the desktop and related applications that home consumers also use. In other words, "big business" pays for the sustainment, and that feeds into a lot of Upstream development.
Canonical's Shuttleworth has said similarly, although Canonical has subsidized for-profit PC OEMs like Dell in the past, whereas Red Hat flatly refuses to do so, saying they'd rather pay software developer salaries to create more GPL open source. And Red Hat is profitable, while Canonical has never been -- which is another debate, because many of us how Canonical will find a way to make money. If they find a way to do so with home users, that would be good for Linux. But I don't think they ever will. Hopefully they'll find an enterprise model that works. Until then, their UK filings explain a lot (as the UK also requires non-UK cashflows and financials to be documented). And understand even though it's smaller than Red Hat, even evaluating per-employee, they don't develop and maintain as much as Red Hat or (at least until recently, pre-shrinkage) Novell-SuSE AG (now Attachmate once again).
I.e., even Microsoft's Ballmer admitted in 2011 that it's enterprises where they make even desktop money, as it's extremely costly to subsidize the PC OEMs and other, for-profit entities that distribute to consumers.
Disclaimer: I have many colleagues who are developers and managers at Canonical, Red Hat and SuSE AG.
So the
Windows-based PC platform is becoming closed, like Apple, and Microsoft is slowly, but surely, becoming the #1 PC OEM itself, replacing Dell. Meaning the only open PC platform available by early next decade ... will be running Linux. It's over, Microsoft owns the PC platform, if you want to run Windows, you will have to get all your drivers, hardware support and all application and gaming software from the Microsoft store.
Although one cool option, that is not possible with Windows (especially since they dropped all non-x86 development over a year ago now), will be ARM.
► Show Spoiler
Linux/aarch64 (64-bit ARMv8) with uEFI is a peer tree to Linux/x86-64, and there's now reason anything that runs on Linux/x86-64 cannot run on Linux/aarch64, with uEFI (and its dependencies in platform) solving the hardware support issue (PCIe is platform-agnostic, but the register/POST-time setup is the main, commodity detail). Considering the 8-core, superscalar, out-of-order A57 and later solutions smack any Atom silly (to the point Intel wants to drop Atom entirely), don't be surprised when you see some innovative, SteamOS gaming consoles with 32-cores next decade. Heck, I think the only reason Intel is still keeping Atom roadmaps going is because Microsoft requires them.
Insiders have all but confirmed that the next round of Windows phones will have 2 versions. One will be Atom, 4GiB RAM with Windows 10. The other will be ARM, 2-3GiB RAM, with ... wait for it, Android (Linux). Yes, non-x86 Windows is dead. The question is, will they release an ARM unit. If they do, it will be Android.
