Live data from Hacker News

Windows API is Successful Cross-Platform API (2024)

retrocoding.net

131–140 of 147 posts

Re: Windows API is Successful Cross-Platform API (2024)

#131
post #98

Earlier 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…

> With Linux, you have to target specific distros, do something insane like a giant bundle of everything, This is what you do for Flatpack, Steam, or Docker. All these are popular options. > Oh and I almost forgot.. install scripts that detect distros, install dependencies. Most distros offer tooling to make packages for their package managers. With them you declare the dependencies you want and the package manager d…

>This is what you do for Flatpack, Steam, or Docker. All these are popular options.

Yes, Flatpak is decent, but its a separate runtime with its own sandbox and perms that can sometimes make things more awkward for things like accessing host components installed outside of flatpak e.g. IDE running installed compilers, and compilers accessing project files inside the sandbox. But yes, its nice when it works.

Docker is the nuclear option. Fundamentally, I don't see Docker as a good and legitimate way to ship software (I already ranted about the giant bundle of everything approach!). I can also image my entire dev box as a VM and ship software that way too :P

Re: Windows API is Successful Cross-Platform API (2024)

#132

Earlier 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…

You can also simply use Flatpak with the Freedesktop Runtime. It runs everywhere regardless of the distribution. For games Steam offers something similar with the Steam Runtimes. You simply develop for that one container and the software will still be running in 20 years. Even though, of course, making software proprietary isn’t best practice. If you make everything open source from the start the various Linux distri…

If my employer would still pay me the same salary, I couldn't care less about the license. I'm all for outsourcing this problem to the package managers.

Re: Windows API is Successful Cross-Platform API (2024)

#133
post #89

Earlier quoted context omitted.

>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 poi…

> 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.

Linux takes the lead: make code that depends directly on `kernel32.dll` exposed interfaces and you're in a world of hurt.

The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.

> Windows SxS

Now that's one very good Windows idea.

Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).

On the other hand, almost _nobody_ and _nothing_ should be touching "libraries" or "utilities" or whatever on my base system!

Re: Windows API is Successful Cross-Platform API (2024)

#134
post #46

Earlier quoted context omitted.

> It's Linux's failure that one of the world's biggest corporations outspent it on marketing by orders of magnitude? No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API.

> No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API. Careful, some people are too hell bend on idealogies than making a reliable product. They'd never understand this. This is one of the reasons why open source (free as in beer) will never work for anything serious. When my work depends upon a software someone made for free, there's an unnecessary power dynamic in play…

> When my work depends upon a software someone made for free, there's an unnecessary power dynamic in play where since I didn't pay for it, they can rugpull me anytime.

I would daresay one of the reasons why Win32 is so stable, is because Microsoft itself rugpulls even stuff they offer as "improvements" and "better" (WinForms, WPF, UWP, WinUI 3, MAUI, Blazor Hybrid, WebView2 come to mind), so everyone else can't trust anything but the basics.

AKA: When my work depends upon a software I paid for, they still rugpull me.

Re: Windows API is Successful Cross-Platform API (2024)

#135

Earlier quoted context omitted.

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 poi…

> 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. Linux takes the lead: make code that depends directly on `kernel32.dll` exposed interfaces and you're in a world of hurt. The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a L…

>The problem pointed out is a distro, library compatiblity, packaging, or sand-boxing problem, not a Linux problem.

Are you suggesting Windows users switch to Linux and not use a popular distro that can provide software they need? Otherwise, its simply a pedantic argument.

>Nothing should prevent your favourite packaging/sandbox tool to present a facade that the file system has some specific files (your specific version of libraries) over some more generic files (say, Flatpak: freedesktop SDK, Steam Pressure Vessel: Steam Runtime) over some even more generic files (your actual distro libraries).

If you introduce a new library in facade 2.0, its not going to work in facade 1.0. You can backport, but how many versions are you realistically going to support indefinitely? Its a good idea, but it doesn't solve the full problem.

Re: Windows API is Successful Cross-Platform API (2024)

#136
post #46

Earlier quoted context omitted.

> It's Linux's failure that one of the world's biggest corporations outspent it on marketing by orders of magnitude? No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API.

> No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API. Careful, some people are too hell bend on idealogies than making a reliable product. They'd never understand this. This is one of the reasons why open source (free as in beer) will never work for anything serious. When my work depends upon a software someone made for free, there's an unnecessary power dynamic in play…

> Everytime I try to switch, I can't find a single userspace application that works half as good as windows applications.

And if you do find one and update the package, suddenly you find the application has been severely rewritten with the new UI toolkit du jour and the developers dropped a bunch of features they didn't feel like supporting because reasons. Then these same folks act like it's all the fault of Microslop and Fapple that people don't use Linux distros.

Re: Windows API is Successful Cross-Platform API (2024)

#137
post #82
post #26

Earlier quoted context omitted.

He means the Internet runs on the Internet Protocol Suite and not the "superior" OSI Protocol Suite (that people under age 50 have never heard of because it failed).

The OSI model still gets taught in networking classes to people in their teens and 20s.

That was baffling a quarter of a century ago and it's even more baffling now.

Re: Windows API is Successful Cross-Platform API (2024)

#138
post #109

Earlier quoted context omitted.

WINE was not the first Windows on *nix implementation. Sun had Wabi which was Win16 and was also released for AIX, HPUX, and Caldera Linux. While Linux may be a pain to release software for, had anyone been interested enough, a solution could have been found. No one cared because Windows was the market and everything else was a rounding error.

Yes, and? Which game studios were targeting Solaris?

No my point is, there were Solaris targeted proprietary applications despite Solaris also making a Windows compatibility layer. Linux is solid, and it is gaining some market share and such, but for a games maker it's simply not worth the investment. Finding a packaging solution and all that would be possible, but why? For 4% of the market, why?

Essentially, this is a financial decision within a business. It's no failure of Valve or anyone else. If the Linux desktop market share continues to grow, I fully expect this to change, but perhaps the answer will still be just using Win32 and DirectX.

Re: Windows API is Successful Cross-Platform API (2024)

#139
post #117

Earlier quoted context omitted.

I'm eternally confused by what an ABI actually is. Especially now that people say the win 32 api is the stable Linux ABI. Genuine question, what is the difference as they both seem to be conflated.

A library with a stable ABI means that newer releases of that library do not break compatibility with old binaries linked against it. This is why old Windows apps still work on newer OSes. For example in a typical C library, as long as you don't rename or remove any existing functions/exports (or change their signatures), you can continue to add new ones over time without breaking forwards compatibility (old binaries…

Thank you. So windows historically has been careful to ensure that it's abi is stable where as Linux relies more on users recompiling against binaries, which is a problem if you are shipping binaries rather than source code? Presumably package managers try to handle this by ensuring you dependencies are up to date?

Re: Windows API is Successful Cross-Platform API (2024)

#140
post #139

Earlier quoted context omitted.

A library with a stable ABI means that newer releases of that library do not break compatibility with old binaries linked against it. This is why old Windows apps still work on newer OSes. For example in a typical C library, as long as you don't rename or remove any existing functions/exports (or change their signatures), you can continue to add new ones over time without breaking forwards compatibility (old binaries…

Thank you. So windows historically has been careful to ensure that it's abi is stable where as Linux relies more on users recompiling against binaries, which is a problem if you are shipping binaries rather than source code? Presumably package managers try to handle this by ensuring you dependencies are up to date?

Correct.
Post reply on HN