Live data from Hacker News

Convert Linux to Windows

philipbohun.com

281–290 of 459 posts

Re: Convert Linux to Windows

#281
post #6

I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.

I hit quirks with glib semi-regularly (~1/year)

For example, recently I tried to run Emacs' Appimage and it has a glib issue

https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...

Re: Convert Linux to Windows

#282
post #193
post #88

Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…

You mean ABI issues like not being able to run a java 11 jar on a java 8 runtime?

No, I mean ABI issues like not being able to change the order of fields in a struct.

Re: Convert Linux to Windows

#283

Earlier quoted context omitted.

Why Libre Office takes much more time to start than MS Office? Why does it feel sluggish? At least you didn't propose to write everything in Javascript.

While the Java implementation is suboptimal, there is really no need for it to be that way. I think the ideal way to go about it would be to run the compiler optimisations and whatnot then generate something semantically similar to C89 as output. Then you invoke a simple compiler with few optimisations on the target machine the first time the program is run, and cache the results somewhere. On all subsequent runs, yo…

Do you know any software that does that?

Re: Convert Linux to Windows

#284

Earlier quoted context omitted.

But who is "we"? It might have been valuable to games makers, but Wine/Linux based systems seems to be adequate for them. So who is left?

>So who is left? People who like and need Windows apps, people who want to have an out of the box experience when running those apps, people who don't like the loss of performance when using Wine, people who generally like Windows but want to have an alternative in case that dislike where Microsoft is heading with Windows development. That is a lot of people, me included. But since Windows experience is somehow still…

Any people who prefer Windows' primary design choices over Unix ones too.

> Another sponsor for ReactOS can be a state actor like China or EU, somebody with deep pockets who wants and needs to run Windows software but don't want their desktop to be under US control.

I would love to see EU to do this actually. Maybe we should pitch this as citizens.

Re: Convert Linux to Windows

#285

> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between app…

This is like the in-soviet-union joke about shouting "down with the US president" in front of the Kremlin. In this case, I too can run a 20 year old Windows binary on Linux wine.

Re: Convert Linux to Windows

#286

This problem is related to the fact that Linux distos typically dynamically link executables and don’t retain older versions of those libraries vs Windows which does. It’s on of the many reasons Windows base install is so much heavier than a typical Linux base install. The reason Windows retains older versions of executables while Linux doesn’t is because Windows doesn’t have a package manager like Linux distros. Ok,…

It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades.

As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to:

- Bump vm.mmap_min_addr from 65536 down to 4096, a privileged operation ;

- Use an a.out loader because the Linux kernel dropped support for a.out back in 2022 ;

- Possibly use qemu-user if your system doesn't support 32-bit x86.

That's the best-case scenario, because some of the old Atari Jaguar SDK Linux binaries are dynamically-linked a.out executables and you're basically stuck running ancient Linux kernels in a VM. It's at a point where someone at the AtariAge forums was seriously considering using my delinking black magic to port some of these old programs to modern Linux. It's quite telling when reverse-engineering an executable with Ghidra in order to export relocatable object files to relink (with some additional steps I won't get into) is even an option on the table.

Sure, given enough determination and piles of hacks you can probably forcefully run any old random Linux program on modern systems, but odds are that Windows (or Wine or ReactOS) will manage to run a 32-bit x86 PE program from thirty years ago with minimal compatibility tweaks. Linux (both distributions and to a lesser degree the kernel) simply don't care about that use-case, to the point where I'd be pleasantly surprised if anyone manages to run Tux the Penguin: A Quest for Herring as-is on a modern system.

Re: Convert Linux to Windows

#288
Why so complicated? Wine is cool if you need to run an existing binary but when you're writing your own software, why not just compile the platform independent part into a binary and make the platform dependent part a little library (open-source)?

Re: Convert Linux to Windows

#290

I've read the article and the comments with interest. I just have a question: if Windows ABI is so stable that 20-year-old programs are guaranteed to run, why are there computers with Win95 or NT that nobody dares touching lest some specific software stops working? I see plenty of these in industrial environments, but also in public libraries, corporate databases, etc.

why touch it? these are usually not directly connected to the internet. some possibly virtualized. "updating" to use wine on linux is a ton of work on its own, you will run into unforseeable issues. nobody wants to pay for that and nobody wants to be responsible for the problems when the net benefit is zero. but a real update/replacement of all these systems is too expensive, hence the status quo.
Post reply on HN