I'm saying this as Java developer. Delphi eventually proved itself to be the true "compile once, run everywhere". Can imagine others who wrote executables for Windows before the .NET times can relate to similar experiences.
Barely - most bigger programs did not adhere to all standards, but got custom fixes under the hood in follow-up windows versions.
Also, around 2001 was the big architectural change for desktop from DOS to NT, so this might seem like cherry-picking the timeframe selected.
It's true that the entire Windows product family converged onto the NT codebase with the release of Windows XP, but this isn't really relevant -- Windows executables and DOS executables were always different things, and despite being built on top of a DOS-based kernel, Windows 9x still supported the same Win32 binaries that ran under NT.
There was even an extension called Win32S that allowed Win32 executables to be run under Windows 3.1. The Win32 API dates to the early '90s, and modern implementations do support executables dating all the way back to the beginning.
I do that all the time. Just link to a static glibc or musl.
Maybe just don't use that library then? Or don't do that ridiculous thing where you fumble around at runtime desperately looking for executable pages that should just be included in your binary.
Some of these have a long history: https://en.wikipedia.org/wiki/Linspire
They have never been all that successful.
I suspect there is not enough overlap between people who want to use Linux and people who need to run Windows apps that badly for it to be viable.
The biggest problem is games, and even with Steam's best efforts not all Windows games will run on Linux, AFAIK.
I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
You might get lucky, but it sounds like you've not been lucky.
My current laptop, Thinkpad P16s AMD Gen 2, was pretty straightforward to get working with NixOS. No special drivers, and everything, including WiFi and function buttons on the keyboard, worked fine without any kind of special concessions.
This was also the case for my last non-Mac, from 2017-2020, I got Ubuntu installed on there without many headaches, and it wasn’t a specific Linux laptop, though again it was AMD.
Just transforming Windows syscalls into Linux syscalls is not enough. There should be some form of emulation involved.
Many apps, like games are using hardware, that means some additional layers of emulation.
>Imagine we made a new Linux distro. This distro would provide a desktop environment that looks close enough to Windows that a Windows user could use it without training. You could install and run Windows applications exactly as you do on Windows; no extra work needed.
I a rough user experience, some loss of performance and many bugs.
But I hope I am wrong, because the idea sounds really promising.
Aren't .class and .jar files "binaries"?
> Java already solved this problem, for the most part
Maybe, just maybe, there are some drawbacks that mean that in fact it's not solved. Otherwise perhaps Java would've completely obsoleted C, C++. Some of us design applications which can't tolerate the worst case GC pauses, for example. Some of us design applications which we can't afford to spend extra time heap-allocating nearly everything.
Not at all. jar is just a zip with a different extension +some metadata in META-INF (including dependencies). class are compiled java files but they do contain all kinds of metadata, including variable names and debug info (if you choose to retain it). they contain all methods and fields with their original names (along with annotations), so the reflection APIs work. Decompiling a class file is trivial to a point the original line numbers can be restored.
>Otherwise perhaps Java would've completely obsoleted C
Java does require a managed runtime written mostly in C/C++.
>Some of us design applications which can't tolerate the worst case GC pauses
The current breed or low latency GCs w/o a stop-the-world phase should suffices for a large set of applications.
>we can't afford to spend extra time heap-allocating nearly everything.
That has not been an issue for quite some time, heap allocation can be elided, and under normal condition is just a pointer bump. Per thread private allocation is by far the most common case - the garbage collection of non old-gen referenced objects is totally trivial too (i.e. memset). Even shared (cross thread/area) allocation is a CAS'd bump in most cases. Note: copy/generational garbage collectors copy objects that are referenced by non-young-gen ones to another area, then zero the original area.
With that being said - Java (and managed languages) are no panacea.
Java also deprecated all sorts of things over the years. Not to mention applets being completely killed off. I have Java binaries from 25 years ago that could no longer run at all with a contemporary run-time already 10-15 years ago.
Not to mention much of real-world Java is platform-specific. Not often native code perhaps, but more subtle things like hardcoded paths or forgetting to properly use the correct path-separator. Installers used to often be platform-specific as well. Maybe that has been solved, but you would still run into trouble trying to install an old Java application that has an installer only supporting contemporary Windows and Mac systems.
I am not sure how that works, Java is all about JIT. Bytecode almost doesn't matter. Personally I can read assembly (and years [decades] back could just read hex). So even obfuscated (not optimizied) Java is quite readable. Still, the class files do retain all method declarations, all constant pool entries and all bytecode (again trivial to decompile). There have been few changes in the class format of course.
> Java binaries from 25 years ago that could no longer run at all with a contemporary run-time already 10-15 years ago.
Need a shorter frame, Java 8 (10y back) could run pretty much anything from java 1.0 (or even 0.9). It's quite more recent - Java 9 (2017) that introduced project jigsaw. Prior that Java was by far the most backward compatible platform. Still is, for most applications. Do note deprecation mean(t) - do not use in new projects, not it has been removed; again those are more recent changes.
>Not to mention much of real-world Java is platform-specific.
Again, that's super rare nowadays. Stuff like zstd might load a library but even then the native code interfaces are the same across pretty much all platforms. If you talk about native UIs you might have some point, of course.
>to properly use the correct path-separator.
Windows with its backslash is notorious, yet - there is no reason to use backslash any longer, for like 25years now. All Windows paths do work with forward slash (aside that the separator is readily available in java.io.File)
First of all, I should like to point out that such people are overwhelmingly deluded and come to this belief without ever actually having tested the hypothesis. But at any rate, the idea of a JAR file doesn't require garbage collection. We can already see this with things such as Wasm, though it doesn't quite achieve what I would want.
I think you are just suggesting to replace binary blobs with other binary blobs e.g. CLR/.NET assemblies/executables or WebAssembly files.
Or do it the JavaScript way: distribute compressed minified (kinda compiled) source code and the runtime JIT compiles it at runtime (e.g. V8 engine Turbofan compiler).
At least you didn't propose to write everything in Javascript.
Precisely correct. Linux should never have allowed system calls from outside libc or a big vdso.
They seem to not be interested in locking the hardware and they don't make much money from selling Windows and it shows. There aren't many strong improvements in Windows and it feels like Windows is a platform they use to sell other stuff they make money with - they are with Windows in a similar position Google is with Android.