Live data from Hacker News

Windows API is Successful Cross-Platform API (2024)

retrocoding.net

141–147 of 147 posts

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

#141

Earlier quoted context omitted.

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

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

When they were selling Unix and the alternative was DOS, Unix was better. Except that Microsoft did everything they could to keep everything tied to their own OS.

> Compared to the ridiculous enterprise pricing from Sun and the other UNIX OEMs, the TCO made them very compelling.

Sun was already on the decline by the time Windows 2000 was released. How many people were playing PC games on Sun hardware in the 1990s?

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

#142
post #54

Earlier quoted context omitted.

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 :)

Can’t run most desktops apps that way, nor apps that depend on mesa.

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

#143

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

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

If you use a distro that can provide the software they need, why not?

Or, thinking in a orthogonal way, using a distro that doesn't impose draconian library management requirements, and allows simultaneous use of ABI incompatible versions of a library? Why not? Nixos is out there and has more packages that most other distributions already.

> but how many versions are you realistically going to support indefinitely.

No versions. No indefinite support. And intentionally so. The previous layers just stay there.

The point is to intentionally provide a stable platform - with known bugs and security vulnerabilities frozen forever - something people can build their things upon. And rely on the things the things they have built upon to not be rugpulled from under them at random.

Every now and then, someone might fix a egregious security vulnerability in the platform; someone might fix a egregious usability problem in the platform; someone might implement modern features on a older platform; someone might implement compatibility tweaks - but that should not be considered a given.

I fully expect at minimum to run legacy software on a sandboxed "compatibility mode", if one values the overall safety of the rest of the system. And if you are not legacy software, someone recompiles the software every now and then to the newer platform.

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

#144

Earlier quoted context omitted.

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

> 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. If you use a distro that can provide the software they need, why not? Or, thinking in a orthogonal way, using a distro that doesn't impose draconian library management requirements, and allows simultaneous use of ABI incompatible versions of a library? Why not…

>And rely on the things the things they have built upon to not be rugpulled from under them at random.

So 10 years from now, all popular distros should support versions of Facade 1.0, 1.2, 1.42 through Facade 10.2?

Now do you see the problem?

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

#145

Earlier quoted context omitted.

> 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. If you use a distro that can provide the software they need, why not? Or, thinking in a orthogonal way, using a distro that doesn't impose draconian library management requirements, and allows simultaneous use of ABI incompatible versions of a library? Why not…

>And rely on the things the things they have built upon to not be rugpulled from under them at random. So 10 years from now, all popular distros should support versions of Facade 1.0, 1.2, 1.42 through Facade 10.2? Now do you see the problem?

No, they don't support it. Instead, you need to run it inside a compatibility mode, that probably sandbox or VMs the facade. But your software keeps running.

The current problem is that your software no longer runs. That's a 100% denial of service problem.

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

#146

Earlier quoted context omitted.

>And rely on the things the things they have built upon to not be rugpulled from under them at random. So 10 years from now, all popular distros should support versions of Facade 1.0, 1.2, 1.42 through Facade 10.2? Now do you see the problem?

No, they don't support it. Instead, you need to run it inside a compatibility mode, that probably sandbox or VMs the facade. But your software keeps running. The current problem is that your software no longer runs. That's a 100% denial of service problem.

I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago.

Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?

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

#147

Earlier quoted context omitted.

No, they don't support it. Instead, you need to run it inside a compatibility mode, that probably sandbox or VMs the facade. But your software keeps running. The current problem is that your software no longer runs. That's a 100% denial of service problem.

I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago. Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?

> I want to run a modern OS with modern features and still run any software that I already paid for 5, 10, 20 years ago.

I already have a bunch of software that I paid for more that 20 years ago and I can't use most of it outside of full VMs. Microsoft didn't ask me if I didn't use them anymore before removing Win16 support.

> Out of curiosity, have you asked customers to run your software in a VM? How did that conversation go?

Customers never got a choice "where to run your software" when all software I develop ends up hidden inside a SaaS service or being delivered via representational state transfer code on demand. They either run it on a browser sandbox or it doesn't run.

Post reply on HN