APE - Actually Portable Executable

Something I just read: the APE file format.

https://justine.lol/ape.html

This would be cool to have on Haiku as well!

1 Like

Maybe I just don’t get it but this doesn’t actually sound new to me.

2 Likes

Since it only works on AMD64 instruction set, (or x86_64 as it is also known) it’s sadly, not a replacement for WebAssembly or any other bytecode.

2 Likes

I never saw an executable that runs without modifications on 6 different OSses, including Windows and MacOS. But maybe I missed something.

1 Like

Pretty sure someone linked it on the forums a month or two ago, maybe that’s why its familiar

1 Like

It was @leavengood Idea: userland virtual machine to allow running binaries on any platform - #4 by leavengood

1 Like

If I can find time I do want to dig into this more. The main ape.S assembly file is pretty well documented with ASCII art and everything, though maybe not that easy to read if you don’t know assembly. And of course the whole concept is somewhat mind blowing.

Getting it to work on Haiku is probably possible but might involve work more on their end then Haiku’s. It might be fun to mess with. I’m sure a first attempt to run one of these would fail in some way on Haiku.

It might even be in the interest of the author to try to get it to work on Haiku, though someone might need to ask. Though certainly there is no obligation and maybe a Haiku fan could try too. I don’t expect to have time for this anytime soon.

Java?

Extra characters because of the 12 characters minimum rule that I find really annoying :slight_smile:

Java needs a JVM installed.

Well, APE needs the browser, right? Also a prerequisite :wink:
Anyway, what I meant by nothing really new was that it uses bytecode and a vm like quite a few other projects too. Still, APE might be a good thing, I´ve got nothing against it. To be really interesting for Haiku it needs to have more useful apps first (that can´t be run natively), in my opinion.

No, it has nothing to do with a browser. Maybe check out the second link I posted:
https://justine.lol/ape.html

2 Likes

Sorry, must have misread that. I stand corrected :slight_smile:

Not a problem :slightly_smiling_face:

It also doesn’t use bytecode or a vm… It compiles to native code (x86_64 instructions) and uses clever executable format and custom c library tricks to make the executable run everywhere. It can be executed on other CPU architectures by going through qemu (though it invokes qemu automatically if required and if its installed).

2 Likes

Alright, thanks for correcting me and pointing that out. I did skim over the article and the second link @Akakor provided, but it’s now obvious that I didn’t really pay that much attention to it. Not one of my brighter moments, sorry :wink:

1 Like

This is a contradiction, isn’t it? Qemu is a VM.

1 Like

No worries, easy mistake to make when skim reading! Just thought to be clear for other readers that it isn’t bytecode :slight_smile:

1 Like

Yeah good point. But the “standard” mode of operation is to run natively. And it is a VM for native code not bytecode (so less efficient than a “normal” VM for a higher level bytecode :smiley:). The native mode of execution doesn’t use a VM and doesn’t have any of the features you might expect of a VM (like sandboxing for example).

By the way “Write once run everywhere” is possible with portable source code. No need for a portable executable for this. Could be C or Python or whatever.

When it comes to “Compile once run everywhere” I’m quite sceptical if this a good thing for low-level stuff. It might be cool, but only for high-level applications. For that there are already a lot of solutions. Like .NET, maybe WASM, maybe Docker. And lots of other solutions, for example other containers and of course scripting languages like Python. And Java/Kotlin.

Greetings
Peter

1 Like

I’m not a cheerleader for APE or cosmopolitan libc either, and I don’t know if I’m a fan of the other technologies mentioned either, but the construction of APE/cosmopolitan is impressive from a technical standpoint. What I will say is that for C programming it would be nice not to have to jump through a load of hoops to add source compatibility for windows and then work with a separate toolchain like cygwin or something on top of that. I am not sure if I would actually trust this setup in a production environment though.