If I ever get the time, I’d like to make Wine as good as possible for UI app distribution - native UI bindings and the ability to slim down and bundle the runtime. Alas!
Windows API is Successful Cross-Platform API (2024)
121–130 of 147 posts
Re: Windows API is Successful Cross-Platform API (2024)
#122Hasn't it taken gargantuan multi decade efforts of hundreds of developers, multiple open source projects and the backing of major corporations to make it work at all, let alone well, on Linux? How is that successful cross platform?
A good answer is “it’s successful because of the mileage we’ve gotten out of Wine” - whether it’s Valve or Apple. The costs are relative to the benefits, no?
Re: Windows API is Successful Cross-Platform API (2024)
#123Re: Windows API is Successful Cross-Platform API (2024)
#124Earlier quoted context omitted.
Uh, no, a Win32 binary will run in Wine because of the concerted effort of thousands of talented developers for more than a decade, painstakingly reimplemting Win32 into a a compatibility layer for it to run on Linux. There has been little to no interest in doing the reverse, at least until WSL, which is just containers anyways. (WSfU barely counts as an "attempt.") I would hardly consider anything relying on a compa…
glibc is the main reason linux on the desktop has such a low adoption rate. you cant just go and download a precompiled blob from a website and run it everywhere, like you can with macOS and Windows. glibc only targets one audience, one which can recompile its apps when needed. What linux badly needs is a stable ABI for Userspace Apps, and Win32 is just that sadly.
Use statically compiled musl :)
Re: Windows API is Successful Cross-Platform API (2024)
#125Earlier quoted context omitted.
> Proton represents Valve's failure to make Linux gaming attractive to game studios. > Not even those that have Android/Linux NDK builds, bother with porting to GNU/Linux. It is a huge hassle to make a new build to a new platform. You double build system, release management, and testing. Compared to just one plat. Games are complicated, and testing all the dynamic behaviour is also complicated. Making just a Win32 bu…
That reasoning fails flat given the same studios have no issues supporting iOS, PlayStation, Swift and XBox, which are completely alien to what is used on Android NDK, APIs that are GNU/Linux compatible for 3D rendering, audio and asset loading. Valve basically failed to provide the business value for those studios.
All of those platforms are HUGE and well worth the hassle.
I think Valve is trying to leverage the Steam Storefront into a full-fledged Platform. It is not quite there yet.
As such, they have invested a lot of effort into the compatibility layers, which allows gamedevs to support Steam Devices with no extra effort, or minimal effort, which is very important business vise.
As a gamedev, you essentially get a bonus platform for your game without extra dev effort!
Re: Windows API is Successful Cross-Platform API (2024)
#126Earlier quoted context omitted.
> " Their problem was that Microsoft excluded them from the market and starved them for money... " That is not what happened. Sun Microsystems had immense revenue and clout in the server and enterprise space because of the dotcom boom, so much so that their advertising declared "We're the dot in dotcom." Microsoft was trying to duke it out with them in the server space but Windows Server was just barely starting to b…
> Sun Microsystems had immense revenue and clout in the server and enterprise space because of the dotcom boom, so much so that their advertising declared "We're the dot in dotcom." Which is why Microsoft had to use such dirty tricks to prevent them from making inroads into workstations and desktops at the point that they still had competitive hardware. > With no way to compete with free as in beer software, Sun was…
> "Which is why Microsoft had to use such dirty tricks to prevent them from making inroads into workstations and desktops at the point that they still had competitive hardware."
Huh? Sun Microsystems pretty much owned the workstation market by the mid to late 1990s, having beat out HP, DEC, IBM, etc. It was their game to lose, which they did. And I can't think of anything Sun ever offered in the desktop market in their heyday that was credible; their lunchbox SparcStations cost too much and delivered too little.
The main buoyancy behind Microsoft's push into the workstation market around Y2K is that Windows 2000 was much cheaper and ran on also much cheaper Intel processors. Compared to the ridiculous enterprise pricing from Sun and the other UNIX OEMs, the TCO made them very compelling.
Re: Windows API is Successful Cross-Platform API (2024)
#127Earlier quoted context omitted.
I don't need to imagine a made-up scenario that doesn't make sense. We can look at what has happened at face value. The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides. It is not uncommon for indie games on custom engi…
> The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides. Companies end up not doing profitable things all the time, for many reasons. One rational reason is that while action 1 might be profitable, action 2 is even more…
You are correct. You're talking about "opportunity cost"
I kinda touched on it with "and long-term maintenance". For video game ports you can bypass the direct opportunity cost by doing a rev-share deal with one of a million port houses. They'll do 100% of the work to port to a new platform, and then you split revenue. It's not totally free because of course there's overhead. And if you want to do patches, DLC, sequels, etc etc there's the maintenance cost.
Which is to say yes you're basically correct and I agree with you.
Re: Windows API is Successful Cross-Platform API (2024)
#128Earlier quoted context omitted.
That reasoning fails flat given the same studios have no issues supporting iOS, PlayStation, Swift and XBox, which are completely alien to what is used on Android NDK, APIs that are GNU/Linux compatible for 3D rendering, audio and asset loading. Valve basically failed to provide the business value for those studios.
All of those platforms are HUGE and well worth the hassle. I think Valve is trying to leverage the Steam Storefront into a full-fledged Platform. It is not quite there yet. As such, they have invested a lot of effort into the compatibility layers, which allows gamedevs to support Steam Devices with no extra effort, or minimal effort, which is very important business vise. As a gamedev, you essentially get a bonus pla…
Doesn't change the fact that Valve failed to create a business proposition to make native Linux a platform that is well worth the hassle.
Re: Windows API is Successful Cross-Platform API (2024)
#129Earlier quoted context omitted.
XDK, GDK and Agility SDK are also part of API updates.
And Unreal Engine 5 needs the Agility SDK, creating problems where games wouldn't run if your Windows version wasn't new enough. (Same as the typically encountered glibc problem of the user having an older version than the build needs, really.) (I think most of those particular issues were "solved" now with Win10 being EOL and so the developers just rub their hands of it and say "upgrade". Or use Linux and Steam, whe…
A consequence of The Year of Desktop Linux Fragmentation.
Re: Windows API is Successful Cross-Platform API (2024)
#130Earlier quoted context omitted.
Speaking of portability, As a developer who has shipped software on Windows for over a decade, and then some on Linux. Targeting Windows is insanely easy, because of the ABI. You compile once and you have an extremely high chance that it just works on every Windows version. Not perfect, but better than any other platform ever made. Heck I've used software from CDROMS where the binary was compiled 20 years ago and it…
>do something insane like a giant bundle of everything, or static linking But isn't this exactly what shipping on Windows looks like? I've just checked my Windows partition and there are 43 instances of sqlite dll and 16 instances of Qt5Core.dll because every program that uses those libs needs to include them in their "giant bundle of everything".
The issue on Linux is that the distro's package manager decides which versions of shared libraries exist system wide, and this works well when you install everything through the package manager. Windows SxS is specifically designed to allow multiple incompatible versions of the same shared component to coexist without forcing the entire Windows install to use it.
But okay, I accept your point. However I'd like to point out that "the OS allows you do something in multiple ways" is different from "this is the only way to do it"