4 ms·

So we invented Java again?

deleted 4y ago
[deleted]
jart 4y ago
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.
- actionfromafar 4y ago
  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.
  - jart 4y ago
    In this blog post https://justine.lol/sizetricks/#elf 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.
    - actionfromafar 4y ago
      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.
      - enriquto 4y ago
        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.
    - vidarh 4y ago
- jcul 4y ago
  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.
- pjmlp 4y ago
  Which ironically were invented before Java was even an idea. https://en.wikipedia.org/wiki/EM_intermediate_language https://en.wikipedia.org/wiki/EM_intermediate_language https://en.wikipedia.org/wiki/TenDRA_Compiler https://en.wikipedia.org/wiki/TenDRA_Compiler
- IcePic 4y ago
  > 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!
- dekhn 4y ago
  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)
- cpu_ 4y ago
  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!
actionfromafar 4y ago
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.
- simiones 4y ago
  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.
  - actionfromafar 4y ago
    Wait, where is WASM used here? I thought that was a possible future development?
  - TJSomething 4y ago
    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.
- pjmlp 4y ago
  They cared about the commercial third party ones, just not about the free beer ones.
peoplefromibiza 4y ago
no, we reinvented Smalltalk. It only took 45 years EDIT: to realize it
- actionfromafar 4y ago
  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.
  - peoplefromibiza 4y ago
    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? :)
    - pjmlp 4y ago
      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.
- thangalin 4y ago
  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).

deleted 4y ago

[deleted]

jart 4y ago

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.

actionfromafar 4y ago
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.
- jart 4y ago
  In this blog post https://justine.lol/sizetricks/#elf 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.
  - actionfromafar 4y ago
    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.
    - enriquto 4y ago
      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.
  - vidarh 4y ago
jcul 4y ago
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.
pjmlp 4y ago
Which ironically were invented before Java was even an idea. https://en.wikipedia.org/wiki/EM_intermediate_language https://en.wikipedia.org/wiki/EM_intermediate_language https://en.wikipedia.org/wiki/TenDRA_Compiler https://en.wikipedia.org/wiki/TenDRA_Compiler
IcePic 4y ago
> 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!
dekhn 4y ago
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)
cpu_ 4y ago
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!

actionfromafar 4y ago

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.

simiones 4y ago
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.
- actionfromafar 4y ago
  Wait, where is WASM used here? I thought that was a possible future development?
- TJSomething 4y ago
  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.
pjmlp 4y ago
They cared about the commercial third party ones, just not about the free beer ones.

peoplefromibiza 4y ago

no, we reinvented Smalltalk. It only took 45 years EDIT: to realize it

actionfromafar 4y ago
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.
- peoplefromibiza 4y ago
  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? :)
  - pjmlp 4y ago
    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.
thangalin 4y ago
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).