
αcτµαlly pδrταblε εxεcµταblε - Pneumaticat
https://justine.storage.googleapis.com/ape.html
======
modeless
I believe that scripts without a shebang line cannot be executed by execve.
They will only run if the shell sees them before the kernel does. It's an
annoying limitation of this approach and it wasn't clear to me whether this
technique includes a workaround for this. Also the push for code signing
everywhere is going to make this harder in the future as well. (I heard a
rumor that the workaround to run unsigned executables on macOS no longer works
when running on Apple Silicon.) Otherwise, I love it!

My approach was slightly different; I created a polyglot script header you can
paste at the beginning of a C _source_ file to make it essentially a C script
which is just-in-time compiled when it is executed. Works on Windows, Linux,
and Mac as long as a C compiler is installed.
[https://gist.github.com/jdarpinian/6860ddfd92b5b458a20ab6055...](https://gist.github.com/jdarpinian/6860ddfd92b5b458a20ab6055583bc3e)

~~~
jart
Author here. I considered doing that. Then I learned about things like how
MSVC 2017 would wrap the main() function of C programs with telemetry. The
push for code signing, retpoline, aslr, etc. worries me too, from a software
freedom standpoint, and the same goes for how difficult it's become to build
native software from scratch, thanks to the shift from autotools to a whole
new set of competitors like bazel, cmake, ninja, gin, etc. Secure boot is
another red flag. By 2018 it almost felt like we were entering a world in
which, for all practical purposes, we couldn't share native software easily in
either source or binary forms. If PC platforms ever do manage to get consumers
to accept the iPhone App Store restriction model, it'll likely stay that way.
Best way to prevent that from happening is to use Actually Portable
Executable. The more people who continue to depend directly on canonical long-
standing stock platform abis, the more impossible it becomes for platforms to
re-imagine them every few years. I'll take UNIX+WIN32 over things like XUL any
day, since I don't want to fall into the JS dev trap of having to rewrite my
app with each passing moon.

Also note that the execve() shebang thing is a one-time cost. The printf
statement in the header will overwrite the first 64-bytes of the executable,
the first time it's invoked, so it becomes a canonical ELF or Mach-O
executable for subsequent invocations. The one-time cost is also cheap. The
shell script only needs three system calls (open, write, and execve) to patch
the binary appropriately. The generation of this header is also abstracted by
the GNU ld script, which made it easy for me to encode the ELF header
relocations as octal printf codes!

~~~
nitrogen
_Then I learned about things like how MSVC 2017 would wrap the main() function
of C programs with telemetry._

Could you provide a link to learn more? This seems bad.

~~~
naikrovek
Seems like it was removed around 4 years ago.

If that's true, it's just further proof that once people learn something, they
never think to check if it's still true later. This entire industry churns
over and over so quickly. To me, it's borderline negligence in public forums
like this one to make statements which could no longer be true without a quick
verification that they are still true, especially for particularly egregious
statements, because of the scaling factor.

The 1000 people reading the comments can do the checking, or the one person
making the statement can do the checking. To me, it's a moral failure to get
one person's jimmies in a rustle over something that isn't true anymore,
nevermind 1000 people.

------
schoen
The source code equivalent of this is a polyglot program:

[https://en.wikipedia.org/wiki/Polyglot_(computing)](https://en.wikipedia.org/wiki/Polyglot_\(computing\))

Apparently people on Stack Exchange have been working together on a single
polyglot program for four years and have gotten a single codebase up to
validity in nearly 300 languages.

[https://codegolf.stackexchange.com/questions/102370/add-a-
la...](https://codegolf.stackexchange.com/questions/102370/add-a-language-to-
a-polyglot?answertab=oldest#tab-top)

Edit: also, Yusuke Endoh is a master at this art form

[https://github.com/mame/quine-relay](https://github.com/mame/quine-relay)

and has even written a book about it

[http://uguu.org/words/2015_10_01.html](http://uguu.org/words/2015_10_01.html)

which I would still love to have available in English!

~~~
chrisdalke
+1 for the mention of Endoh's work -- Yusuke Endoh's YouTube channel with many
of his quines is really fantastic:
[https://www.youtube.com/c/YusukeEndoh/videos](https://www.youtube.com/c/YusukeEndoh/videos)

A quine that prints itself as scrolling text in an AVI file:
[https://www.youtube.com/watch?v=rMlJy5He-
Tk](https://www.youtube.com/watch?v=rMlJy5He-Tk)

A self-similar quine that behaves like a fractal zooming out infinitely:
[https://www.youtube.com/watch?v=6J7u2G52scc](https://www.youtube.com/watch?v=6J7u2G52scc)

A quine with source code that contains sheet music to a Bach song in comments
and plays it:
[https://www.youtube.com/watch?v=OryXKUgRVOg](https://www.youtube.com/watch?v=OryXKUgRVOg)

------
celrod
> the x86_64 patents should expire this year. Apple could have probably made
> their own x86 chip without paying royalties. The free/open architecture that
> we've always dreamed of, might turn out to be the one we're already using.

I've never seen anyone mention this before. Is this really in the cards? Or
are all the extensions patented as well, so that a hypothetical Apple (or
whoever else takes it on) x86 wouldn't be able to use x86 without licensing
it?

~~~
rkv
[https://www.blopeur.com/2020/04/08/Intel-x86-patent-never-
en...](https://www.blopeur.com/2020/04/08/Intel-x86-patent-never-ending.html)

~~~
jart
> Transmeta tried it and failed

Author has clearly not heard about NexGen! They implemented a RISC
architecture that code morphed x86 i586 design. They were then bought out by
AMD who shortly thereafter adopted the design for their own architecture. Then
Intel had no choice but to adopt NexGen architecture as well lool. We all use
NexGen Architecture now. The most famous microprocessor no one's heard of. I
only know because NexGen was based in Milpitas and that's where I live, so
Milpitas Architecture is like hometown pride.

As for patents, Xed is tiny (only ~4kb) and it allows us to distinguish the
which instructions belong to which microarchitectures, e.g. k8, sse3, sse4,
avx. That gives us a clear accurate picture of the intellectual property
rolloff, thereby enabling a fabless chip or emulator to simply ignore the
encumbered parts of the encoding space. The tradeoff is you can't patent troll
Intel (due to Xed being licensed Apache 2.0) and I think that's fair.

~~~
scruffyherder
Nexgen was great, the lack of a FPU at that moment in time however was fatal
at launch.

Quake was just starting to ignite the world and pentium performance at 486
prices would have done more, but no fpu... it ran NT fine enough although my
memory wants to say Microsoft detected it as a 386 so that would have cut NT 4
out of the picture.

I thought knowledge of them was more common but I guess not

------
saagarjha
As expected, macOS Big Sur refuses to run the resulting executable:

    
    
      $ ./program.com 
      -bash: ./program.com: cannot execute binary file: Exec format error
      $ sh ./program.com
      ./program.com: ./program.com: cannot execute binary file
    
    

It's quite finicky in what it will accept ;)

~~~
comex
On my Big Sur machine, `bash ./hello.com` works the first time, but then it
overwrites itself(!) with a Mach-O, so further executions have to be
`./hello.com`.

~~~
saagarjha
Yup, that matches my experience running the example (I also had to put it in
$PATH for the command -v in the header to work). I built program.com myself
and it seems to be missing the DOS header for some reason, so it just doesn't
execute at all…I'd file a bug, but I have no idea if she is interested in
supporting it or if I can provide any useful information besides "it doesn't
work".

~~~
jart
Glad to hear you're using it! You can ping me on Google Hangouts
(jtunney@gmail.com) for help. We also might be able to set up a Slack or IRC
channel to iron out these issues. I actually didn't post this thread because I
was still working on fixing the long tail of minor bugs. But now that the
project has caught everyone's attention, we might be able to fix them sooner!

~~~
saagarjha
Sure, invite sent :)

------
krackers
Can someone eli5 how this works? I sort of get that you can create one big
binary file with all the necessary file headers for each platform and the
actual x86 code being shared, but what about stuff like syscalls? The post
also lost me when it started mentioning the need for shell scripts and
emulators.

~~~
tbodt
It turns out to be impossible to create a file that is simultaneously a valid
ELF and Windows PE. The solution to this is to make a file that is
simultaneously a valid PE and shell script, and have the shell script
overwrite the start of the file with an ELF header and re-exec itself.

~~~
StavrosK
That means you can't copy the executable after executing once and have it run
on Windows, correct?

~~~
shandor
Probably the rewriting is only done on the program loaded into RAM?

~~~
yjftsjthsd-h
No, there's a discussion upthread about running on Darwin that specifically
says you have to run as `bash ./foo` first time and `./foo` thereafter because
it overwrites on disk.

------
snarfy
Back when all you had was minicom dialing a BBS, there was a chicken and egg
problem where you needed uudecode to decode any executable you downloaded. If
you did not have uudecode you were stuck. If you are unfamiliar, unencoding a
file allows you to send binary data through text transmission.

Then a clever version of a DOS .COM file was posted which implemented
uudecode, but it only used x86 instructions that were also ASCII characters.
You could copy/paste between the --cut here-- lines into a file, save it as
uudecode.com, and then get your other binaries like pkzip.

~~~
userbinator
_but it only used x86 instructions that were also ASCII characters_

That was a somewhat common approach back then. It's hard to find references to
that technique now, but here's something I did find:
[https://news.ycombinator.com/item?id=16312562](https://news.ycombinator.com/item?id=16312562)

~~~
GuB-42
Another common one is the EICAR anti-virus test file.

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

It is a com executable that prints EICAR-STANDARD-ANTIVIRUS-TEST-FILE! It
recognized by most virus scanners.

~~~
maartenh
Oh, cool! I thought this file was just prefixed with some random garbage.

Unrelated: I used this to verify that my daily scheduled full scan of my Linux
laptop works. This is required by compliance at $WORK. It reports found
viruses via the i3-nagbar.

~~~
saagarjha
Linux has antivirus software written for it? TIL.

~~~
GuB-42
ClamAV is the best known.

Usually, linux antivirus software is not designed to protect the machine
itself, instead it is more commonly used by mail and file servers to protect
windows clients.

------
notaplumber
> I believe the best chance we have of doing that, is by gluing together the
> binary interfaces that've already achieved a decades-long consensus, and
> ignoring the APIs.

Yeah, this isn't going to fly for OpenBSD, which doesn't have ABI stability,
programs are expected to use libc. Program for the API, not the ABI. The
author is clever, but misguided.

~~~
ChrisSD
I believe the claim is that there exists a stable subset:

> Bell System Five is the umbrella term we use to describe Linux, FreeBSD,
> OpenBSD, and Mac OS X which all have nearly-identical application binary
> interfaces that stood the test of time, having definitions nearly the same
> as those of AT&T back in the 1980's.

However, only Linux guarantees stability at this level so I too am very
sceptical that this will "stand the test of time". And of course this
completely excludes Windows.

~~~
FeepingCreature
Isn't Windows also known for being committed to both API and ABI stability?

~~~
mrpippy
Yes, but the stable interface is functions exported from kernel32, ntdll, etc.
Syscall numbers can and do change freely between builds.

~~~
ChrisSD
Indeed. The Win32 API (and UWP et al) is the only one that's officially
stable.

Kernel syscalls themselves are entirely unstable. Not even just the numbers
but the calling convention and everything else. Microsoft reserves the right
to add, remove or modify anything in or exposed by the NT kernel. Of course
they won't do so frivolously but syscall numbers are especially prone to
change with a new build of the kernel.

So as with MacOS, BSD, etc the stable interface is provided by userspace
libraries.

~~~
user5994461
I might not be following here. Windows kernel functions are those in
ntdll.dll. They've been stable for a very long time as far as I am aware.
Well, the 30% of them that are documented at least. It's used by drivers,
antivirus and rootkits.

C headers with the prototypes are available from the Windows Driver
Development Kit. It's not something you want to use though, the average kernel
function takes 10 arguments to support both sync and async IO.

[https://docs.microsoft.com/en-
us/windows/win32/api/winternl/...](https://docs.microsoft.com/en-
us/windows/win32/api/winternl/nf-winternl-ntcreatefile)

~~~
mkup
Symbol names and function prototypes in ntdll.dll are stable (albeit not
officially stable), but system call numbers change frequently:
[https://j00ru.vexillium.org/syscalls/nt/64/](https://j00ru.vexillium.org/syscalls/nt/64/)

------
voltagex_
>Similar to how the Super Mario Bros ROM has managed to survive all these
years without needing a GitHub issue tracker.

Well yeah, but that might be more a function of it existing before git and
github.

[https://www.mariowiki.com/List_of_Super_Mario_Bros._glitches](https://www.mariowiki.com/List_of_Super_Mario_Bros._glitches)

------
simias
It's a very cool hack and technically interesting, but I can't say that I
share the author's "serious" rationale:

>So I think it's really the best of times to be optimistic about systems
engineering. We agree more on sharing things in common than we ever have.
There are still outliers like the plans coming out of Apple and Microsoft we
hear about in the news, where they've sought to pivot PCs towards ARM.

[...]

>If a microprocessor architecture consensus finally exists, then I believe we
should be focusing on building better tools that help software developers
benefit from it

Considering ARM an outlier in a world were smartphones outnumber desktop PCs
and where the x86 stronghold is under attack from several sides seems like a
strange take to me.

Also, there's more to portability than managing to run a hello world from the
same binary on Windows and Linux. I used to use FreeBSD a lot on the desktop,
which usually involved using Linux binary compatibility to run Linux closed
source binaries that weren't available on FreeBSD. It worked generally pretty
well, but it wasn't without friction at times even though it was coded by very
smart people and between two systems that were overall very similar.

These "compatibility" applications often end up as 2nd class citizen that
don't integrate well with native applications, or at least not as easily. See
Wine for instance, managing to run Windows applications on un*x is a huge
undertaking.

>One of the reasons why I love working with a lot of these old unsexy
technologies, is that I want any software work I'm involved in to stand the
test of time with minimal toil. Similar to how the Super Mario Bros ROM has
managed to survive all these years without needing a GitHub issue tracker.

I love emulation, so I definitely understand where this is coming from, but I
don't really see what that has to do with the rest. In particular if you're
willing to go down the emulation route, why do you care about everybody
running x86? Super Mario Bros was not written to run on a Celeron. Besides CPU
emulation for something like a NES video game is only a tiny part of the
story, you also have to emulate the GPU, sound chip etc...

I feel like there's a mishmash of interesting ideas in there, but it's a bit
confusing to understand.

~~~
jart
Author here. The intention behind the post is actually very simple. I want to
be able to write stdio socket programs that run at native speed, and share
them with my friends online. I don't want to have conversations like here's
how you install steel bank common lisp and compile tensorflow and remove the
toolbar that oracle bundled in the installer. I'm also not concerned about
running software on telephones since doing so requires obtaining authorization
from Google and Apple beforehand.

Before I built Actually Portable Executable, PCs behaved de facto similar to
mobile development restrictions, where for example if you want to build for
Apple you download XCode, and if you want to build for Windows you have to
download MSVC. But it thankfully has never been a hard requirement for
creating first class native programs. It simply required the will to ignore
official tooling and encode binaries the hard way that directly talk to
canonical stock kernel abis, so that we don't need things like jenkins to
compile release binaries n times for the same microprocessor architecture.

I had enough free time to do it. I've also shared a tool that makes it easier
for everyone else to do it too. Enjoy!

~~~
simonebrunozzi
What's the deal with the uncommon font of the post title? I saw it here on HN
too and was wondering if it's just aestetics, of if there's something else.

~~~
goodcanadian
It is using (abusing?) Greek letters. I actually kind of hate that as those
letters don't necessarily sound anything like what they look like to English
speakers. It is effectively gibberish.

~~~
pmayrgundter
Oh man, missing the fun! I used to overwrite my stock system font with the
glyphs from a greek font just to practice learning Greek letters. They largely
map!

------
ocdtrekkie
Is hosting web URLs at storage.googleapis.com a thing? After finding a
persistent phishing campaign using it, I ended up restricting it from being
loaded in the web browser in my environment. (Embedded images from it, like on
blog.google, still work.)

This is the first time I've seen a legitimate website with one of these URLs.

~~~
renewiltord
To get https don't you have to put a paid load balancer in front of it? At
that point it's both more effort and costly than Netlify.

~~~
tzot
Perhaps it's not that costly (or you can circumvent costs) if you work at
Google, like Justine does IIUC.

~~~
dri_ft
She did, but no longer. The project's github README:

> Justine Tunney currently isn't on the payroll of any company. She's been
> focusing on Cosmopolitan because she wants to give back to Free Software
> which helped her be successful.

------
kokooo
This is cool but this is from the source code...

\- License is GPL2

\- If you want to be able to distribute binaries in binary only form, then
please send $1,000 to Justine Tunney jtunney@gmail.com on PayPal, for a
license lasting 1 year.

If the goal of this project is to have something similar to cross platform web
development this is the wrong way to go about it imo.

~~~
pjmlp
I imagine that Justin Tunney has bills to pay.

Long term we will be back to the shareware days and we will have the anti-GPL
task force to thank for.

~~~
saagarjha
(Justine)

------
gargalatas
So here we go for the greek alphabet: \- μ stands for m \- δ stands for th \-
τ stands for t \- ε stands for e

So I read this like: actmally pthrtable execmtable.

------
IgorPartola
This is perverse in the best way possible.

~~~
armitron
No, this is perverse in the worst way possible.

It's incompatible with modern debuggers.

It's incompatible with shared libraries.

It's limited to a feature-poor "unified" API (that might as well be seen as a
crippled VM).

It's complex in _both_ interface and implementation. The bad aspects of Unix
made even worse.

The justifications make no sense whatsoever. It wants to do future-proofing
but invents an adhoc "VM" with hardcoded OS interfaces that are meant to be
treated as private. For macOS, I doubt binaries will work in the next release
or two, nevermind 10 years.

It's a fun toy or troll, but if you're looking at this for serious work I
suggest you steer well clear.

~~~
saagarjha
> It's incompatible with modern debuggers.

Any debugger that can't debug this binary is broken and should be treated as
such.

~~~
a1369209993
That's true, but I think they meant that it fails to actively _support_
debugging the way a not-broken-by-design modern executable file format should.

------
als0
> If a microprocessor architecture consensus finally exists

I don't think that's a good goal to have. Without competing architectures
we'll enter a microprocessor dark age. Although the glory days of Alpha and
IA64 are over, plenty of that experience was used to bolster today's
instruction sets. Diversity is a good thing.

~~~
simias
I'm not sure I buy that, you can have a lot of competition on the same ISA.
After all on the desktop/server x86 has been king for a while, and on embedded
architectures ARM has all but taken over the competition. Yet there's
significant competition on both fronts.

Meanwhile attempts at creating new ISAs over the past couple of decades has
been met with relatively little success, or only in very specific niches.
Itanium being an obvious example. People talk about RISC V a lot but in
practice it's not really making a dent into the ARM market share yet.

These days competition appears to come mostly from companies reimplementing
and extending existing ISAs with better performance.

~~~
dwrodri
I would just like to add in that RISC-V is still a lot of talk because there
are still some important standards that really need closer attention before we
start mass-producing server CPUs. Specifically, the Platform-Level Interrupt
Controller[1] and the Vector Instructions[2]. The former is super-important
because we now know interrupts/traps can be used in Spectre/Meltdown style
attacks, especially if your chip has something like a DSP/iGPU, which can be
used in covert side channel attacks. The latter will be important for the same
reason that SSE/AVX is important today.

Just my opinion, but SiFive has been a huge driving force in even giving
RISC-V a shot at breaking into server space. Most other companies (Google,
Nvidia, Western Digital) have invested in RISC-V with the apparent intent of
focusing on building microcontrollers/embedded processors. AFAIK, there's only
one player who is investing in building RISC-V server-class CPUs and that's
SiFive.

Please correct me if I'm mistaken! I've been following RISC-V pretty closely
for the last year or so and there's quite a lot to catch up on.

1 = [https://github.com/riscv/riscv-v-spec](https://github.com/riscv/riscv-v-
spec) 2 = [https://github.com/riscv/riscv-plic-
spec](https://github.com/riscv/riscv-plic-spec)

------
Rebelgecko
This is incredible and also very frightening. Has anyone tried to distribute
one of these binaries in a real context?

~~~
userbinator
I think the closest to that would be
[https://en.wikipedia.org/wiki/Shar](https://en.wikipedia.org/wiki/Shar) and
I've seen ones that were both valid shell scripts and Windows batch files. Of
course, the actual polyglot part is tiny and serves only to direct execution
to continue with the appropriate platform-specific binary.

~~~
bigiain
How about most issues of PoC||GTFO?

From issue 2:

"A careful reader may have noticed that a bootable OS image was hidden in the
last issue of PoC‖GTFO,as one of the files in its dual PDF/ZIP structure (if
you haven’t, download and extract it now!). This time, though, let’s hide it
in plain sight. You will find by running ‘qemu-system-i386 -fda
pocorgtfo02.pdf’ that the PDF file you are reading is also a bootable disk
image."

------
naikrovek
I bet the name of this thing sends screen readers straight into the abyss.

"Need cred or accessibility? Nerd cred! Screw you if your eyes don't work!"

~~~
StavrosK
Or people who can read Greek. I can only imagine how Russians feel towards the
frequent misuse of their alphabet.

------
fouc
Finally, you can produce a single cross-platform executable in C.

> we've basically reconfigured the stock compiler on Linux so it outputs
> binaries that'll run on MacOS, Windows, FreeBSD, OpenBSD too. They also boot
> on bare metal

~~~
edgyquant
But it doesn't work on Linux?

~~~
ComputerGuru
It does for me. Make sure to execute via/prefix with sh, you can’t invoke it
directly even after chmod +x

------
sagebird
What's the challenges involved in making a actually portable executable that
is a compiler that can create actually portable executables. Why muck with
getting a gcc running on windows or whatever if you don't have to? If you only
mess with c once a year or so, getting compilers set up is a pain.

~~~
jart
Right now I'm solving the problem by only doing my dev work on Linux. That
works fine for me, since the output binaries run on other platforms too. But
I'd love to support more flexibility for more people! Not everyone is
accustomed to doing their coding via an SSH terminal. So the challenge is
getting more eyeballs on the Cosmo source code so we can add features and iron
out the long tail of bugs.

Earlier this year, I somehow managed to successfully compile an x86_64-linux-
gnu toolchain under MinGW. Using that, pretty much 90% of the Cosmopolitan
built fine under Windows without needing a Linux VM (which actually goes
faster than native WIN32 due to how Make+GCC assumes processes work). I've
tried and failed several times to compile GCC from source on Mac.

But I think compiling GCC is just so hard, that I'd probably rather embed the
GNU/Linux compiler binaries in the PKZIP embedded file structure of
EMULATOR.COM, since that should create a GPL boundary that's kosher per the
GPLv3 and GCC RTEv3 terms.

------
dracodoc
It's funny. In China there used to be a time when high school students like to
use rarely used Chinese characters, which are only similar to the intentional
character in shape instead of meaning.

They think that's cool. This style was called brain damaged style.
[https://zhidao.baidu.com/question/63502990](https://zhidao.baidu.com/question/63502990)

什庅bai湜焱暒妏？举些瑺鼡哋唎ふ。du 什庅湜悩残軆？举些瑺鼡哋唎ふ。 什庅湜zhi悱炷蓅？举些瑺鼡哋唎ふ。 莓兲想埝祢巳宬儰⒈种漝惯

~~~
Aachen
To be clear, "intentional" should be "intended" right? Had to read this a few
times (I'm also a non-native speaker, I wonder if that makes it easier or
harder for me to understand a text with meaning-altering typos/mistakes) but I
think it must be this.

~~~
checkyoursudo
Intentional and intended are both adjectives. They both mean intended. They
are synonyms, so they can be used mostly interchangeably. However, one or the
other may be conceptually more clear in various cases. As a native English
speaker, intentional character is understandable to me. I likely would have
written intended character, but I don't think that intentional here is clearly
incorrect.

------
angrygoat
Interesting point about the x86-64 patents expiring and the possibility of
third parties making chips for that instruction set. Is it just so big and
clunky that the energy is with ARM / RISC-V?

~~~
ekianjo
there are more recent patents involving extensions on x86_64 which are
essential for more modern processors, I believe.

~~~
sgerenser
Yes, being x64 compatible but not supporting SSE4 or AVX is basically useless.

~~~
saagarjha
Rosetta won't support this, it's far from "useless". Good programs should
detect the lack of support and fall back to earlier extensions.

~~~
sgerenser
Rosetta is a compatibility stopgap, not a whole new CPU. Apple making a new
chip with the x86/x64 instruction set and not supporting any modern SIMD
features would be pointless. I’ve seen AVX2 code that performs nearly 8x
faster than scalar code on the same CPU.

Besides, where did you hear that Rosetta wont have to at least support SSE4? I
think there are Mac apps that assume presence of these instructions since all
of Apples macs since 2008 or so has had them.

------
alganet
Oh, I love a great retrospecification work. This is awesome.

------
badrabbit
You don't always need a shebang if it is marked as executable,is this a
cosmetic conformity thing?

~~~
saagarjha
You need a shebang if you're going to execute it directly.

------
vpribish
cute title; but not searchable, machine translatable, or screen-reader
friendly.

~~~
saagarjha
Google found it in the first couple results:
[https://www.google.com/search?hl=en&q=actually%20portable%20...](https://www.google.com/search?hl=en&q=actually%20portable%20executable)

------
iamthemalto
What's the program being used to go through the machine code in the gif?

~~~
jart
The program being used is
[https://justine.storage.googleapis.com/emulator.com](https://justine.storage.googleapis.com/emulator.com)
with the -t flag passed for the tui gui. Please note that I've only tested it
on Linux and it's only intended for static executables, not shared objects.

------
Igorvelky
inadvertently revealed NSA backdoor from 1997

"

Please note that zsh has a minor backwards compatibility glitch with Thompson
Shell so try sh hello.com rather than ./hello.com.

"

------
greyhair
Is this actually portable x86 executable?

------
dwighttk
actmally pdrtable execmtable?

------
Aeolun
C programmers:

> here’s how simple it is: (two lines of arcane gcc invocation)

I just don’t see how you can call that simple.

~~~
saagarjha
I suggest you never look under the hood of the compiler frontend ;)

------
normanmatrix
This girl is a true visionary engineer

------
axegon_
People... Please stop using foreign alphabets like that! It's a nightmare for
those of us who know the alphabets. It took me a good 20 seconds to read the
title. And it's magnitudes worse when someone uses cyrillic for instance and
it's native to me.

~~~
nurettin
Foreign alphabet transliteration drama thread under the best hacking-grade
article in years. Thanks, hn.

~~~
learnstats2
Yep - if you want people to focus on what you actually wrote, don't do this. I
couldn't get past the title.

~~~
StavrosK
Same here, it's extremely annoying. Other pet peeves include "grssk" and
Beyoncé's documentary's monstrosity that I don't even care to recall.

------
sgammon
lol sick ️

------
quickthrower2
"Actually Portable Executable"

Incase anyone searches on hn.aloglia in future!

~~~
082349872349872
"Όντως φορητό εκτελέσιμο" ?

~~~
NKosmatos
IMHO a better meaning would be "Πραγματικά φορητό εκτελέσιμο", but yours is
also pretty close ;-) Having being involved with translation of software into
Greek it's the small differences that bring the meaning as close to real usage
as possible and not the transliteration that makes a great translation.

~~~
tzot
…εξακτεμάν! :D

~~~
082349872349872
يَمَن

[https://en.wikipedia.org/wiki/Mots_d%27Heures](https://en.wikipedia.org/wiki/Mots_d%27Heures)
?

------
kreas
As a person that speaks Greek, this hurts my delicate and beautiful soul.
Please don't do that again.

------
DoreenMichele
Why does the title font look pseudo Greek?

~~~
knolax
I hate it when people do that. It looks tacky and it's super annoying when
they (mis)use a script you can read.

~~~
DoreenMichele
It's especially annoying if you took two quarters of Greek like 35 years ago
and recognize it just well enough to have trouble seeing it as weird English
lettering.

~~~
alchemism
I taught myself to read Greek recently and couldn’t parse it at first either.

------
Bayart
Actmallg rdrtable ekecmatable ?

------
hattori31
Writing things like this reminds me of edgy teenager on the internet of early
2000s.

~~~
jfax
I associate it with naive teenagehood, but I don't associate it with
'edginess'.

