Hacker News Reader

Comment by mati365 | Hacker News Reader

So we invented Java again?

Author of Blink here. Yes. Absolutely. I've always wanted to have Java's tools (e.g. "build once run anywhere" simplistic development) except I want to program in C / C++ instead of Java. The main platform I target is x86_64 desktops and servers, on which I want to run natively (rather than Java, which would force my code to always be virtualized) and Blink lets me pull out the virtual machine trick when I need it (e.g. someone wants to run the apps I've released on an esoteric platform like MIPS OpenBSD). All the x86_64 Linux executables I spent the past several years writing and releasing are suddenly able to be enjoyed by users on platforms I'd never dreamed of, like Haiku, and I didn't have to do anything to "port" and re-release those binaries on my website in order to do that. We just had to build one tiny 180kb virtual machine (unlike the JVM which is more like 100mb and might bundle a browser toolbar in the installer) and I made it open source (ISC, unlike Qemu which is GPL) so that you can enjoy these benefits too.

I still find it surreal that these operating systems share so many mechanisms that these portable EXEs are even possible.

Someone should write some kind of historical explanation of how this could have happened. And how critical is it for the "APE" scheme to work? Could APE binaries work on AROS x86_64 for instance? (Without emulation.)

I also find it surreal that it took this long for someone to do something like Actually Portable Executable. I mean, it's slick and easy to use, but I haven't even seem assembler demos of this.

Is the same polyglot EXE possible also on 32-bit x86? If so, I find it even weirder this have not been done long ago, considering the strange hacks people have pulled over the years.

I'm fascinated by the whole thing, as you can tell. Back in the day, Windows and Unix seemed so far from each other, like oil and water.

In this blog post https://justine.lol/sizetricks/#elf I talk about how simple it is to create a single file binary from scratch that runs on Linux, FreeBSD, OpenBSD, and NetBSD. All Actually Portable Executable does is it takes that trick three steps further, to support Windows, MacOS, and BIOS from a single file binary too. That requires a bit more effort.

These are simply the operating systems I knew best, because I grew up using them, and as a result was able to discover the right combination of tricks to get it to work. I'm sure someone else who loves AROS and knows AROS would also be able to discover a way to trick it out so that APE could support it too. Same goes for other platforms. For example, one of the things on my TODO list this year is to find out if the APE x86_64 hacks are replicable for the ARM64 architecture.

The closest thing to a scientific theory behind what APE is would be what the information security community calls a "polyglot". Researching that is another great way to learn more similarly inspired tricks.

> Is the same polyglot EXE possible also on 32-bit x86? If so, I find it even weirder this have not been done long ago, considering the strange hacks people have pulled over the years.

It's actually even easier to do for i386 than it is for x86_64. The blog post above explains why that's the case, due to the syscall magic numbers being more similar. Also I'm equally astonished no one did this before I came along. I think part of why that's the case, is that I couldn't just write APE. Doing this project meant that I had to implement a C library from scratch too, which is a years long coding marathon.

Thanks, great explanations. I think the most astonishing thing to me is that I never saw such a polyglot EXE even print "hello" on stdout, written in assembler.

Nobody dared to eat the fruit of the unknown tree. What if it was poisonous? Until a brave soul tried it, and saw that it was good.

I think for something like AROS the combination of support for ELF and such a small community would mean that if someone wanted to do this for AROS the easier path might well be to add support directly in the loader.

Reading this, I began to think about cosmopolitan libc, and the "actually portable executable".

I haven't played around with it, but I remember being in awe of its ambition.

I haven't been following cosmopolitan, nor blink closely, but I just looked up cosmopolitan and realized you are the author of both.

Just want to say amazing work! Hope to get a chance to try out blink soon.

Which ironically were invented before Java was even an idea.

https://en.wikipedia.org/wiki/EM_intermediate_language

https://en.wikipedia.org/wiki/TenDRA_Compiler

> Blink lets me pull out the virtual machine trick when I need it (e.g. someone wants to run the apps I've released on an esoteric platform like MIPS OpenBSD).

Me and the other user of Mips on OpenBSD are both glad you do!

Somebody should write fanfic where jart goes back in time and forestalls the Java revolution in ~roughly 1995 by releasing Blink. Instead of the entire several decades of Java (and Javascript), Blink becomes the technology underlying web (the browser is really just a portable presentation layer) server and client programming. Lightweight phones with long battery life and portable architectures revolutionize mobile computing 5 years earlier. World GDP is 35% higher, and life is generally happier, and much easier.

(seriously though, thanks for doing all this. I like your philosophy compared to what the world ended up with as the dominant paradigm)

curious about "except I want to program in C / C++ instead of Java", does that mean that you prefer writing C code instead of e.g. Rust or Zig? In other words, what is your sincere opinion about Rust or Zig? Thank you!

Theoretically, if Sun and Oracle would have cared for the experimental runtimes which compiled to native instead of JVM. I think GNU had one going, but RMS hated that too, so there was kind of a gap in the marketplace for such a thing. You can sort of do it with .NET now.

Edit: I completely misunderstood what Blink is in relation to WASM. I'm leaving my original comment below, but it is quite wrong.

Still, Blink is a VM in the same sense as the JVM, and it does JIT compilation (or it can interpret program ASM) just as much as that. As far as I understand from the git page, it is using x86_64 assembly as the "bytecode" though, so the JIT step may be quite trivial if running on the same arch and/or OS.

Old post:

This isn't compiling to native either, not ahead of time anyway. It is compiling C or C++ to WASM, and then running that in a browser. The browser will JIT compile the WASM, just like the JVM would.

The biggest difference is that everyone has a browser, while not everyone has a JVM pre-installed.

Wait, where is WASM used here? I thought that was a possible future development?

This doesn't use WASM or a browser at all. This is an new, original x86-64 machine code interpreter with a JIT compiler that supports x86-64 and aarch64. This is an extension of Justine's APE project to use x86-64 ELF as the core of write-once-run-anywhere software.

They cared about the commercial third party ones, just not about the free beer ones.

no, we reinvented Smalltalk. It only took 45 years

EDIT: to realize it

We did, but not in this project. :-) This is indeed more like an embedded JVM, not totally unlike early J2ME, but with x86_64 instead of JVM instructions.

Ruby is more like Smalltalk.

not at all a critique on your project, if that was the impression I gave :)

I'm old enough to remember when Java applets were invented, grew up using Visualage Smalltalk on OS/2 at school, and am still bitter that nobody ever said: but this is Smalltalk, why don't we use Smalltalk then? :)

Because Smalltalk big supporters like IBM, decided to repurpose their Smalltalk offerings into Java.

Visual Age Smalltalk had a role similar to .NET on the OS/2 ecosystem, SOM (OS/2 version of COM) supported Smalltalk, implementation inheritance and meta-classes, so yeah it didn't help to go full on Java.

Also another Visual Age thing, Visual Age for C++ v4 also had a Smalltalk like experience for C++, unfortunely it was too demanding in resources.

Smalltalk was ahead of its time. So much so that its VM was unbearably slow. Thirsting for CPU power that just wasn't there. I recall using a Pentium-based machine and waiting up to five seconds to open a context menu, and the IDE (VisualWorks?) could not keep pace with my typing. I could type in a message name and watch the letters appear one-at-a-time. Compared with Borland's TurboPascal and similar IDEs of the day, Smalltalk was a slog, albeit a powerful one.

There are other issues with Smalltalk that we know now that we didn't then. Such as broad and deep class hierarchies are hard to use. Smalltalk didn't enforce type-safety when I used it (i.e., you can have runtime faults because you can send any message to any class and if you didn't implement "does not understand", you won't know until exercising that branch).

> So much so that its VM was unbearably slow

AFAIR Java applets, and the JVM in general, were not better.

My experience with Smalltalk is from high school in the middle 90s, Java came out in 1996 and it was much slower than Smalltalk in my opinion.

Also JavaScript in the browser was basically a joke and a nightmare to write and debug.

Type safety is over-hyped IMO, JavaScript isn't type safe, look were it arrived.

Even C++ is partially type safe and Java type safety is unsound

https://dl.acm.org/doi/10.1145/3022671.2984004

Reply on news.ycombinator.com