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...
It is actually pretty useful. If you’re given a locked down machine (for example in your company), you can write code in notepad, compile it with csc.exe and run it. As it is generated on the local machine, you may get to be able to execute it. (I tried this once when I was super bored at an intership, and a hello world program compiled and ran.)
On Windows, though, there's C# compiler out of the box on every OS since Vista. And C# has a bunch of rarely-used syntax for things like raw pointers, that can work on more or less the same level as C, and even look pretty similar. It might be possible to do something with that.
Huh, I never knew this. For anyone else who didn't know, it's in the C:\Windows\Microsoft.NET\Framework64\ folders, it's the CSC.exe file included with each version of the .NET framework.
Edit: Good grief, there's even vbc.exe, which is a command line Visual Basic 2012 compiler. Also JSC.exe for Jscript, aspnet_compiler.exe for ASP and MSBuild. Kinda embarrassed that I didn't know this.
It’s been my go to toolset for ages. It’s the #1 reason to learn c# as it’s everywhere.
Also if we are talking exploit vectors, uuencode is great for people that let you have a clipboard. Get uudecode in c#, and paste in your arbitrary binaries and you’ll be in business In no time!
If you look at the functionality provided there, it includes ability to compile generated code. This is implemented using those command-line compilers.
> I believe that scripts without a shebang line cannot be executed by execve.
This was once true on old systems, but current ones (including Linux) have native support for scripts starting with #!. See fs/binfmt_script.c in Linux, which has existed for several decades.
Downloaded unsigned executables will not run by default on macOS and the error dialog provides no affordance to override this. You just have to know that if you option-click and select "Open", which is always identical to double-clicking except in this special case, you get a different dialog that allows you to override the block.
I think that counts as a workaround and no longer works on Apple Silicon. But I haven't verified this myself. Would be interesting to hear from someone who knows.
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!
> The printf statement in the header will overwrite the first 64-bytes of the executable
This is cool but also a problem for subsequent sharing of the executable. I thought about doing this as well but decided against having the file mutate into a version that wouldn't work on other systems.
Again, super cool project! I love this kind of thing.
> The printf statement in the header will overwrite the first 64-bytes of the executable, the first time it's invoked
Is this a problem for anti-virus/other security measures? My understanding is, executables that manipulate themselves is something any security software will look for.
Though perhaps the answer is "don't rely upon security software to police your system; do it yourself"
> 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.
What's the issue specifically? I've never had a good Autotools experience (granted, I wouldn't reach for Bazel or CMake either--the whole build tool ecosystem is in desperate need of innovation IMO and probably the nicest things are Nix or Guix).
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.
> 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.
Every single one of those programs you listed is FOSS licensed.
Autotools was originally developed as a compatibility layer to compile code on proprietary UNIXes.
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`.
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".
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!
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.
>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.
Wow, what a link. I submitted it just now as a separate HN post using your phrasing:
> 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?
The TL;DR seems to be that if you restrict yourself to implementing an ISA from 20 years ago, your chip can indeed be patent free, but that isn't going to run modern software - maybe not even modern x86 32-bit software!
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.
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
Even if the patent on the instruction set expired, that's only half the battle (if that). When you licence ARM you're getting both the instruction set design AND the implementation.
AFAIK Apple mostly only licenses the ISA and then runs a completely custom implementation, so in this case that's not relevant.
I think the sibling comment is more accurate: while the core of the ISA might effectively be public domain soon, there are plenty of extensions in common use that aren't. If you implement a custom x86 design without those a lot of software won't be able to run or it will run with significantly worse performance.
The assumption I'd made was that they'd left the actual core mostly alone. They've gone a lot further than everyone else in what they've put around it though, e.g. large caches and other accelerators.
I'd be interested in being pointed to any references as to what they've actually done, not that much information is likely to be public domain.
My source is "I know somebody who knows somebody who works in Apple's hardware design team" so take it with a grain of salt but it seems that their core is almost entirely custom, or at least customized to the point where it's effectively a different core.
And it makes sense for them to do it too, they clearly have the money and people to pull it off and it gives them a big competitive advantage. It's not for nothing that they push for ARM on the desktop as well, this way they'd have a tighter control on their ecosystem than they've had for decades (maybe ever), both soft- and hardware.
So ISAs are patentable? Even if you reimplement them from scratch, it's covered? Can anyone ELI5 that in the light of the Oracle vs Google "APIs are not copyrightable" battle? Seems like an ISA (sans implementation) is comparable to an API, so is the difference patents versus copyright? Are APIs patentable?
I haven't investigated it in detail personally, but my understanding is that Intel has or had troll patents on the obvious (and therefore not legitimately patentable) way to go about implementing various x86 features. So if you reimplement it from scratch, the way you naturally go about implementing it will just happen to match 'Intel's' supposed 'inventions' which they have patents on. (Eg, I think they had a patent on register renaming at one point.)
I think neither the basic idea of register renaming nor solutions to do it in a way that speeds up the processor (conceptually, each register reference has to go through a logical register-physical register lookup) are so obvious that they are guaranteed to be unworthy of patenting.
If Intel had a patent on this, it must have been on some (possibly tiny) variation, though, as IBM had register renaming in hardware in 1967 (See https://en.wikipedia.org/wiki/Tomasulo_algorithm) and the POWER1 had it in 1990.
Yes. So, if you want to reimplement a CPU from 1999, you will probably be fine without any kind of license. If you want to add features or use new methods, however, you may run into infringement issues.
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.
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.
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.
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.
Since COM files are basically just raw binary code without headers or metadata, it should be easy to adapt the technique to make valid english language COM files.
There's also this compiler (with accompanying paper/video), that compiles C89 to x86 with the output executable restricted even further, to only printable ASCII bytes: http://tom7.org/abc/
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.
I use this laptop for $WORK and web browsing, and my warez times are behind me now that the software I want to run is typically open source, and the content I consume can be bought.
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.
I ran into that conundrum just recently with emulating old MacOS for gaming purposes. Software on abandonware sites is distributed as images for a proprietary program. :thonk:
Great memories you brought back. Minicom times were so simple, the BBS sysop dialed upr2.clu.net for us so we had a nice UUCP connection and got our mails pushed out.
I had to undergo the same chicken egg situation with uudecode
> 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.
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.
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.
Go tried to break the rules and call macOS syscalls directly (like they do on Linux, because Go is a massively NIH language so they don't use libc where they can get away with it) and it bit them hard when an OS update broke all Go apps.
If Apple broke every Go program, then that's on Apple. Why are people blaming the victim? Go didn't do anything wrong.
Apple came back in the late nineties, in part, because they copied and pasted the magic numbers from the Bell System Five codebase, e.g. 1 for exit(), etc. Capitalizing on UNIX popularity helped Apple succeed. So they shouldn't treat Bell Labs technologies like it's their own implementation detail.
For example, Microsoft has the right to break NTDLL because they invented it, and never intended for it to be used directly by app developers. Windows was designed from its beginning to have dynamic system interfaces too. In the UNIX community, DSOs have always been extremely controversial, since they raise legal questions compared to SYSCALL and INT trapping, and they violate the ability of a program to assume complete control of the full virtual address space.
If Apple devs are reading, then please, we love your products, but we don't love DSOs. Please grant us the freedom to choose. Please keep SYSCALL stable. It'd also be great if you didn't add special-cased code to XNU that blocks open source Actually Portable Executables, like you did with UPX. Email me (the author) your feedback instead. I'll do anything to help, short of adopting a second WIN32 linkage model.
Are you familiar with Apple's concept of "private API"? Apple considers the list of exported symbols from a dynamic library to not be a boundary (in fact, they have a linker that ignores that and links against a predefined list of symbols regardless of what a binary exports), much less the kernel syscall interface. In fact, Apple silicon requires that your program is loaded by dyld as far as I can tell.
While I wan't around in the nineties, I'm curious how syscall numbering helped Apple's success. I'm sure System-V ABI when they switched to 64-bit Intel was probably a nice bonus, but system call numbers?
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.
ntdll is a userspace library, not a part of the kernel. So when you call ntdll functions you aren't calling into the kernel (although most ntdll functions will do so on your behalf).
And ntdll itself is technically unstable[0], though I'll grant you that there are many functions that are unlikely to break. There's no guarantee though.
There are different rules for drivers. Which is also why it's common and normal for a driver written for an older version of Windows to not work on a new version, but it's rare (and considered a bug) for userspace software.
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/
NTDLL is only stable if Microsoft likes what you're doing. For example, Microsoft culture is super biased against fork() or any creative use of virtual memory. There was, for decades, a sort of a hush hush fork() workaround in NTDLL that people thought was stable. Then some Sunnyvale startup called Crossmeta built a product to capitalize on it, Microsoft rolled out a security update, and poof it's gone. They ignored all the documented warnings saying "if you use NTDLL be sure to have fallback!" So think twice before messing with Redmond.
Doubtful. There have long been software that abuses syscalls and other kernel level features to implement Sony rootkits and other DRM. Ironically those that implement game copy protection would be annoyed if syscalls were stabilized because the whole reason they use unstable syscalls is to obfuscate what they're doing and make the program extremely sensitive to tampering.
Do you have a source for that? The closest I could find suggests otherwise, but admittedly I haven't yet found a more relevant document on policy:
> No compatibility for API and ABI is guaranteed from one to the next major release, though an effort is made to make the upgrade process and source code changes as untroubled as possible.
It’s pretty obvious from the fact that people are routinely running jails with old userspace (eg 11.0) under newer kernels (eg 13.0). It doesn’t always work for management interfaces (so eg an old route(8) binary might be broken), but is guaranteed to work for normal user programs.
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.
> I couldn't resist the temptation of making it a reality, since it means that high-performance native code can be almost as pain-free as web apps.
> Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil.
My understanding was that people are using web-apps and electron precisely to provide cross-platform GUIs. I feel like this is really missing the forest for the mountains...
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!
> I'm also not concerned about running software on telephones since doing so requires obtaining authorization from Google
That's not actually true. Fortnite has an APK download many users download straight from the internet and run on their Android phones for example. There's no requirement to run Google authorized software as long as you are willing to check a checkbox in the phone settings.
I hope I didn't come off as too negative, I think it's a really cool hack.
I guess the people I could see myself sharing binaries with are either too clueless to use the command line or savvy enough that installing a compiler/interpreter is not an issue.
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.
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.
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!
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.
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.
- 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.
Author here. I'm sorry you feel that way. If you'd rather it be licensed ISC/MIT/BSD/etc. then please encourage your favorite member of FAANG or some other huge company to acquire Actually Portable Executable and then make it freely available under those terms, for the sake of benevolence and commitment to serving public interest. I come included.
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.
> 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.
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.
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.
Microarchitectures are the new architectures. The game these days is all about finding a way to make your code go fast on the latest and greatest AVX thing, while still maintaining compatibility for old machines via CPUID. Getting those 10x speedups (sometimes 50x w/ things like crc32 pclmul) is much more fun than caring about things like s390x (i.e. doing IBM's work for them), SH (i.e. folks emulating Sega Saturn on FPGAs for fun), MIPS (hacked home routers), etc.
I think the closest to that would be 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.
"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."
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
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.
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.
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.
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.
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.
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?
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.
I'm not sure exactly what debugger is used, but gdb dashboard can be set up in a similar way.
It's just stepping through instructions and viewing the registers and some memory regions.
The program being used is 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.
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.
Oh yes, the Cyclopean usernames of titan blocks and sky-flung monoliths, all dripping with green ooze and sinister with latent horror. Definitely not screen-reader friendly.
I have at least one visually impaired Twitter follower (there may be more that I'm unaware of). This is why I don't do clever things with Unicode characters or post those text-picture memes and always type in alt text for my images. I'd like to think that I would be sensitive enough to do so without having him in my followers list, but I suspect that if I'm honest with myself, I probably wouldn't so I'm thankful for his presence to remind me to keep things accessible.
No that's a reversed-R which happens to look identical like a Cyrillic letter. I don't think that's a problem any more than getting confused and trying to pronounce a circle in a logo as an "o". In contrast, the text here is trying to look Greek but doing it poorly.
Not really confusing when you assume the intention is to look clever - the more different the letterform you find while it still being recognisable as the one you are replacing, the more exaggerated your effect is without further reducing readability.
(Yes, I know this isn't "just to try look clever", ala 1337-speak, and is trying to make a relevant reference to the cross audience understanding the is relevant to a cross platform executable, but the point still stands about choosing less similar but still similar enough glyphs)
Which, I would argue, says at least as much about the HN crowd as it does about whoever posted the article under this specific title.
EDIT: more specifically .. it's rather ironic how judgmental (and honestly: pretty darn pretentiously) so many here instantly get, yet how there is this implied assumption that the collective wisdom and judgement of this community is above criticism itself, somehow. It might say far more about HN, that nobody appears to be discussing the article's content itself, than it says about the (mis)use of alphabets.
I can read Cyrillic fluently, and a bit of Greek too, yet I'm not in the least bit upset about this pun. If this does upset anyone, maybe it's time for some seriously self-reflection for those people, about what they decide to get upset about and what not.
It's probably more virtue signalling than actually being upset. Complaining is a way for the complainer to show off they know the actual pronunciations.
FWIW, it's not annoying or upsetting to me. However, I took Russian years ago. The only thing I remember is the alphabet and some random words. I also live in a country where the language is not my native one. So, when I saw this in a language I may be able to pronounce like a 3 year old, my immediate response was to think "oh, let's see if I can guess what this says" into "wait what..." into "wtaf" into "oh, that's dumb." I skipped that article this morning because while I wasn't upset or annoyed, I was disappointed. I was disappointed that a skill I once worked very hard for was wasted. Since it was also at the top of the page, I felt like it was abused in this community. In fact, I attributed the title for the only reason it was on the front page. When I just clicked to see what the comments were, I was pleasantly surprised to find I was not the only one disappointed with the alphabets chosen for this title.
The stupid game was getting too cute with the title, in a way that essentially invited a backfire. Arguably, it's still better than many titles from the newsrooms, but newsrooms reached the bottom long ago and decided to open a deep mine.
Thus, the stupid game led to a stupid prize, where major thread (in fact, one that felt like drowning any other discussion) was about the title technicalities, but not about content.
If you (i.e. anyone) really wants to be helpful about things like this, email us at hn@ycombinator.com. Downweighting off-topic subthreads that get upvoted to the top is one of the best interventions we can do for discussion quality. We do that whenever we see them, but we don't see them all.
There are a couple of users who email us regularly when they see things like that. This is one of the highest-leverage contributions anybody can make to HN, so we'd certainly appreciate hearing from more such users. Actually I only found out about this subthread because of such an email.
Supercilious complaints, on the other hand, just make the thread even worse. Please don't do that. The thing where some HN commenters use HN to posture over the rest of HN is tedious, and in poor taste. Let's just work together to make it better, to the extent possible.
IMO this is not in the same category as people complaining about a website requiring Javascript or using the wrong font. It's an unreadable title for screenreaders. And unlike Javascript or CSS styling or trackers, needing a screenreader is not a personal choice, or a limitation that people can turn on and off.
I think it's fair to point out when a good article makes itself inaccessible due to a trivially correctable problem.
I'm not even saying that the author can't make the joke they're trying to make, but even a small title change like "αcτµαlly pδrταblε εxεcµταblε (actually portable executable)" would basically solve the entire problem without sacrificing any of the meaning behind what the author wants to convey with their misuse of Unicode.
It is a good article, which is why the pointless pushback over accessibility is so frustrating. There would be no engineering effort or large compromise required to make the title of the submission readable. It wouldn't suddenly make the article bad, or not worth reading. It feels like it's being exclusionary just for the sake of being exclusionary.
OPs compaints fall into the accessibility bucket. The site makes itself less accessible since some people (greek alphabet users) have trouble consuming the content.
I could ready #1 immediately and thought "hey, I can actually read faux-cyrillic a lot better that I thought" and then I realized that you used a semi-proper transliteration.
You need to see when me and my friends start chatting in English written in Cyrillic. It's epic and utterly frustrating for the first hours, then becomes like native ;)
One of the other things that bugs the hell out of me is when in the late 90's during the boom of irc, here in Bulgaria everyone was writing in Bulgarian with latin script. And to make matters worse:
4 = ch
6 = sh
And some people keep on doing it. I can understand it when you have to switch between scripts every 2 seconds but most commonly that isn't the case and you are either having a conversation with someone or leaving it for later when you have time or when you feel like it...
Йес, съмтаймс уи ду дис то каунтър шльокавица ин партикюлър.
Edit: for the non initiates. It's this written in Cyrillic: "Yes, sometimes we do this to counter shlyokavitsa in particular"
Shlyokavitsa is the name of the forementioned style of writing Bulgarian with latin letters. The original meaning of the word is "low quality, self-made alcohol", possibly even poisonous because of methanol
I'm really pleased to hear this, because I've kept scratch notes in english text written in the greek alphabet for decades, and every so often I wondered if it was more readable than I expected if someone who read greek happened to glance at it :) (It's not secrets - more like a habit of stream-of-consciousness writing while listening to someone talk, that would probably look bizarre).
I guess I'm not as l33t as I thought I was, because I couldn't read that without having to figure out what each number was supposed to be individually.
I'm not sure what precluded me from reading that, but I don't think not knowing numbers would have helped me figure out that portable is p0274813 without context clues. Might need a more readily parseable example there.
It's horrible to some of us that don't know the foreign alphabet too. While I had no problem reading the title it still makes my eyes bleed and my brain hurt to see it. ;)
I personally think its kind of creative, and looks cool. Though the author might like to be aware of the discontent it causes certain individuals. This is mean but it comes accross as though you are just wanting to show off you knowledge of a different alphabet...a complainbrag. Seems unlikely you'd take the effort to bother but thats my perception.
One might argue that "context" is a valid discriminator for that, but your point certainly has validity too. They are just two different arguments. The argument of arrogance in claiming an absolute right from wrong, and the argument that context can make one interpretation more correct because it relates to the meaning and not just the description of something.
Yeah apparently the converter I used used a Cyrillic character, the actual "LATIN LETTER SMALL CAPITAL F" is ꜰ. Also apparently there's a "LATIN LETTER SMALL CAPITAL *" for every letter except X[0][1].
Things that are subversive, clever, mind bending, tongue in cheek ... tend to get criticized around these parts for not being simple, plain, and literal.
It's not even that, why does this headline deserve to stick out from others on the HN front page? What's the next step, make your title bold or twenty lines long for an unfair click advantage?
> 𝐀𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐩𝐨𝐫𝐭𝐚𝐛𝐥𝐞 𝐞𝐱𝐞𝐜𝐮𝐭𝐚𝐛𝐥𝐞
I'd rather see submissions stand out for their content.
I guess for HN OP should have refactored the title to be "Actually Portable Executable" but I thought the whole point of the title was that it's something we can interpret that has been "written in something else" which is fitting given what the article discusses? It's a direct copy/paste from the source and I don't think OP was trying to stand out in any unfair way.
I'm not blaming the HN submitter, but you can also see how bloggers can easily abuse this if whatever unicode characters they put in their title are allowed in the HN submission on the grounds of "it's a direct copy/paste".
FWIW, the title stands out, but at least for me it's not working in the favor of the article. Unless it was for the content ("actually portable executable"), I would actually stay away from articles with such strange fonts.
People have of course been pulling such tricks for years. We don't allow it generally, and in fact are pretty strict about that. But all such rules have exceptions.
The quality of this post is so high that it doesn't feel right to override any aspect of what the author created, including quirks like the title. There may be a superficial similarity to garden-variety title pimping, but as someone who bathes in spam every day I can tell you how rarely such gimmicks come attached to first-class feats of hacking prowess. Respect for content requires looking closely enough to detect truly unusual cases, pick them out of the mud, and give them a special place.
Another principle applies here too: it's good for readers to have to work a little (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...). If a title like that appears at #1 on HN, there are two possibilities: (1) this is dreck that somehow managed to evade all of the standard moderation; or (2) something's happening here and you don't know what it is. Actually, either possibility is rather interesting, and it's not hard for any HN reader to do the bit of work to figure it out. Even if it takes 20 seconds.
I've learned some degree of Russian (and certainly enough to roughly read Greek) and even that's enough for me to have to take a few passes to parse it as English.
The only boundary this transcends is readability and is ironically not portable at all.
It's a bad thing to do for attention, like hacker elite speak using numbers would be, but is that why the author did that? Did you read the article? It's about a file that can be read by all Unix, Windows, and MacOS. Part of how that happens is one OS mistakes some other text for executable code while the other OS doesn't.
Therefore the title of the article written in multiple language letters and somewhat readable in one language despite that is a good introduction.
I would argue you could write an informative title, and reserve the problematic text for the article text, where you can explain why you are doing that. Just like the comment you were responding to I can't imagine screen reader users are super stoked by how "appropriate" this title is
To that note, would it be possible to change the title of the submission to "Actually Portable Executable"?
It would help people focus more on the content of the article, make the submission more accessible for non-English & blind readers, and feel less spammy and exploitative, all at the same time.
I doubt the author of this article or the submitter wants this to be the top thing people are discussing about their article anyway. And that is the title -- if you go to the library source code[0], its graphical banner is using the normal English letters. The unicode weirdness here is only being used typographically, the author isn't claiming that their title should be pronounced differently or something.
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.
> I started a project which called Cosmopolitan which implements the αcτµαlly pδrταblε εxεcµταblε format. I chose the name because I like the idea of having the freedom to write software without restrictions that transcends traditional boundaries.
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.
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...
> C compiler is installed
It's a great idea but that part is a big ask for any Windows user who doesn't develop desktop applications.
True. I'm imagining this as useful mostly for build scripts or other developer tools. To the extent that it's useful at all.
It is actually pretty useful. If you’re given a locked down machine (for example in your company), you can write code in notepad, compile it with csc.exe and run it. As it is generated on the local machine, you may get to be able to execute it. (I tried this once when I was super bored at an intership, and a hello world program compiled and ran.)
On Windows, though, there's C# compiler out of the box on every OS since Vista. And C# has a bunch of rarely-used syntax for things like raw pointers, that can work on more or less the same level as C, and even look pretty similar. It might be possible to do something with that.
Huh, I never knew this. For anyone else who didn't know, it's in the C:\Windows\Microsoft.NET\Framework64\ folders, it's the CSC.exe file included with each version of the .NET framework.
Edit: Good grief, there's even vbc.exe, which is a command line Visual Basic 2012 compiler. Also JSC.exe for Jscript, aspnet_compiler.exe for ASP and MSBuild. Kinda embarrassed that I didn't know this.
It’s been my go to toolset for ages. It’s the #1 reason to learn c# as it’s everywhere.
Also if we are talking exploit vectors, uuencode is great for people that let you have a clipboard. Get uudecode in c#, and paste in your arbitrary binaries and you’ll be in business In no time!
In case you're wondering why - it's because every version of Windows since Vista comes with .NET Framework, and .NET Framework has this API:
https://docs.microsoft.com/en-us/dotnet/api/system.codedom
If you look at the functionality provided there, it includes ability to compile generated code. This is implemented using those command-line compilers.
> I believe that scripts without a shebang line cannot be executed by execve.
This was once true on old systems, but current ones (including Linux) have native support for scripts starting with #!. See fs/binfmt_script.c in Linux, which has existed for several decades.
I'm talking about scripts without the shebang (#!) line.
I'm sorry, I completely misread that.
There were once systems where scripts with the shebang line would get run by the shell rather than the kernel, hence my confusion.
Yes, that is the aforementioned shebang line.
> the workaround to run unsigned executables
Was there ever a workaround for this? I thought you just ran them…
Downloaded unsigned executables will not run by default on macOS and the error dialog provides no affordance to override this. You just have to know that if you option-click and select "Open", which is always identical to double-clicking except in this special case, you get a different dialog that allows you to override the block.
You've always been able to run those without any warnings from the command line.
I think that counts as a workaround and no longer works on Apple Silicon. But I haven't verified this myself. Would be interesting to hear from someone who knows.
Edit: Here are the details. Looks like it's true that it simply won't run totally unsigned ARM code. But self-signing is allowed. For now. https://lapcatsoftware.com/articles/unsigned.html
Right, Apple silicon has different rules.
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!
> The printf statement in the header will overwrite the first 64-bytes of the executable
This is cool but also a problem for subsequent sharing of the executable. I thought about doing this as well but decided against having the file mutate into a version that wouldn't work on other systems.
Again, super cool project! I love this kind of thing.
> The printf statement in the header will overwrite the first 64-bytes of the executable, the first time it's invoked
Is this a problem for anti-virus/other security measures? My understanding is, executables that manipulate themselves is something any security software will look for.
Though perhaps the answer is "don't rely upon security software to police your system; do it yourself"
Generally executables like to rewrite themselves while in RAM; rewriting on disk is rarer (since you leave behind the changes you made).
> 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.
What's the issue specifically? I've never had a good Autotools experience (granted, I wouldn't reach for Bazel or CMake either--the whole build tool ecosystem is in desperate need of innovation IMO and probably the nicest things are Nix or Guix).
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.
Just google for "notelemetry.obj"
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.
> 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.
Every single one of those programs you listed is FOSS licensed.
Autotools was originally developed as a compatibility layer to compile code on proprietary UNIXes.
As expected, macOS Big Sur refuses to run the resulting executable:
It's quite finicky in what it will accept ;)
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`.
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".
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!
Sure, invite sent :)
The source code equivalent of this is a polyglot program:
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...
Edit: also, Yusuke Endoh is a master at this art form
https://github.com/mame/quine-relay
and has even written a book about it
http://uguu.org/words/2015_10_01.html
which I would still love to have available in English!
+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
A quine that prints itself as scrolling text in an AVI file: 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
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
>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.
Wow, what a link. I submitted it just now as a separate HN post using your phrasing:
https://news.ycombinator.com/item?id=24257630
Classical examples of chimera/polyglots are:
PoC||GTFO International Journal of Proof-of-Concept or ... https://www.alchemistowl.org/pocorgtfo/
Corkami: https://github.com/corkami
> 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?
https://www.blopeur.com/2020/04/08/Intel-x86-patent-never-en...
The TL;DR seems to be that if you restrict yourself to implementing an ISA from 20 years ago, your chip can indeed be patent free, but that isn't going to run modern software - maybe not even modern x86 32-bit software!
I thought windows runs on anything which supports extensions up to sse2, which is what amd64 includes.
https://docs.microsoft.com/en-us/windows-hardware/design/min...
Devices that run Windows 10 for desktop editions require a 1 GHz or faster processor or SoC that meets the following requirements:
* Compatible with the x86* or x64 instruction set.
* Supports PAE, NX and SSE2.
* Supports CMPXCHG16b, LAHF/SAHF, and PrefetchW for 64-bit OS installation
Mmmh, so it seems one would be stuck on win 8.0 (for 64bit) with an original implementation of amd64. Could probably still run a lot of new software.
Or run 32-bit Windows 10 instead.
The PAE and NX requirements can be disabled in the bootloader.
> 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.
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
XED is an Intel project, the X86 Encoder Decoder, for those who don't know.
https://intelxed.github.io/
2026. Six years to go.
Even if the patent on the instruction set expired, that's only half the battle (if that). When you licence ARM you're getting both the instruction set design AND the implementation.
AFAIK Apple mostly only licenses the ISA and then runs a completely custom implementation, so in this case that's not relevant.
I think the sibling comment is more accurate: while the core of the ISA might effectively be public domain soon, there are plenty of extensions in common use that aren't. If you implement a custom x86 design without those a lot of software won't be able to run or it will run with significantly worse performance.
The assumption I'd made was that they'd left the actual core mostly alone. They've gone a lot further than everyone else in what they've put around it though, e.g. large caches and other accelerators.
I'd be interested in being pointed to any references as to what they've actually done, not that much information is likely to be public domain.
My source is "I know somebody who knows somebody who works in Apple's hardware design team" so take it with a grain of salt but it seems that their core is almost entirely custom, or at least customized to the point where it's effectively a different core.
And it makes sense for them to do it too, they clearly have the money and people to pull it off and it gives them a big competitive advantage. It's not for nothing that they push for ARM on the desktop as well, this way they'd have a tighter control on their ecosystem than they've had for decades (maybe ever), both soft- and hardware.
So ISAs are patentable? Even if you reimplement them from scratch, it's covered? Can anyone ELI5 that in the light of the Oracle vs Google "APIs are not copyrightable" battle? Seems like an ISA (sans implementation) is comparable to an API, so is the difference patents versus copyright? Are APIs patentable?
I haven't investigated it in detail personally, but my understanding is that Intel has or had troll patents on the obvious (and therefore not legitimately patentable) way to go about implementing various x86 features. So if you reimplement it from scratch, the way you naturally go about implementing it will just happen to match 'Intel's' supposed 'inventions' which they have patents on. (Eg, I think they had a patent on register renaming at one point.)
I think neither the basic idea of register renaming nor solutions to do it in a way that speeds up the processor (conceptually, each register reference has to go through a logical register-physical register lookup) are so obvious that they are guaranteed to be unworthy of patenting.
If Intel had a patent on this, it must have been on some (possibly tiny) variation, though, as IBM had register renaming in hardware in 1967 (See https://en.wikipedia.org/wiki/Tomasulo_algorithm) and the POWER1 had it in 1990.
> Or are all the extensions patented as well
Yes. So, if you want to reimplement a CPU from 1999, you will probably be fine without any kind of license. If you want to add features or use new methods, however, you may run into infringement issues.
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.
He talks about it a bit as the "magic numbers". You can see the big table: https://github.com/jart/cosmopolitan/blob/c91b3c50068224929c...
I guess there's also syscall emulation stubs for Windows but since he only supports "stdio and sockets" maybe not.
The author is a "she": https://en.wikipedia.org/wiki/Justine_Tunney
"Tunney has described Occupy Wall Street as a far-left movement.[13] Her former comrades have described her as a technocratic fascist.[14]"
Wow, although I'm not familiar with her, this wiki article seems a bit melodramatic
How on earth has that article met the "notability" threshold?
Well she owns/owned the Occupy Wallstreet twitter account.
I remember this person, she was on Gavin McInnes podcast quite a while ago. Here is the interview:
https://www.dailymotion.com/video/x2ke4nq
Listening to her talk, she seems a pretty standard run of the mill Libertarian with a blend of technocrat.
Reading that page, and this HN article, reminds me of a classic phrase: "There is a fine line between genius and insanity."
>technocratic fascist
>zealous googler
At this rate GPL2 will stand for Google Public License.
You can read more in the libc source. The readme gives an overview.
https://github.com/jart/cosmopolitan/tree/master/libc
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.
Ah thank you. And I presume the qemu part is optional, used only when the target platform is non x86?
That means you can't copy the executable after executing once and have it run on Windows, correct?
Probably the rewriting is only done on the program loaded into RAM?
Hmm, possibly, though that wouldn't really make sense, why not just execute itself at that point?
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.
>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
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.
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
This is still quite useful when working on constrained shellcode, specifically the kind of shellcode you'd enter through a text input field.
You can even do one better, you can construct shellcode out of valid english sentences.
http://www.cs.jhu.edu/~sam/ccs243-mason.pdf
Since COM files are basically just raw binary code without headers or metadata, it should be easy to adapt the technique to make valid english language COM files.
There's also this compiler (with accompanying paper/video), that compiles C89 to x86 with the output executable restricted even further, to only printable ASCII bytes: http://tom7.org/abc/
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.
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.
Cool. How many viruses has it picked up?
(Presumably ClamAV?)
Yes, used ClamAV.
None besides this example file.
I use this laptop for $WORK and web browsing, and my warez times are behind me now that the software I want to run is typically open source, and the content I consume can be bought.
Linux has antivirus software written for it? TIL.
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.
I remember that. Then in the early 90's it was .sit and .hqx on a Mac.
Not forgetting NNTP Usenet binaries and the evolution from UUEncoded files to YEnc-oded files.
Truly magical days.
I ran into that conundrum just recently with emulating old MacOS for gaming purposes. Software on abandonware sites is distributed as images for a proprietary program. :thonk:
Great memories you brought back. Minicom times were so simple, the BBS sysop dialed upr2.clu.net for us so we had a nice UUCP connection and got our mails pushed out.
I had to undergo the same chicken egg situation with uudecode
Hmm, I might have used that, or at least something very similar. Don't know exactly why, but then, it was a while ago...
> 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.
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.
Isn't Windows also known for being committed to both API and ABI stability?
Yes, but the stable interface is functions exported from kernel32, ntdll, etc. Syscall numbers can and do change freely between builds.
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.
Go tried to break the rules and call macOS syscalls directly (like they do on Linux, because Go is a massively NIH language so they don't use libc where they can get away with it) and it bit them hard when an OS update broke all Go apps.
If Apple broke every Go program, then that's on Apple. Why are people blaming the victim? Go didn't do anything wrong.
Apple came back in the late nineties, in part, because they copied and pasted the magic numbers from the Bell System Five codebase, e.g. 1 for exit(), etc. Capitalizing on UNIX popularity helped Apple succeed. So they shouldn't treat Bell Labs technologies like it's their own implementation detail.
For example, Microsoft has the right to break NTDLL because they invented it, and never intended for it to be used directly by app developers. Windows was designed from its beginning to have dynamic system interfaces too. In the UNIX community, DSOs have always been extremely controversial, since they raise legal questions compared to SYSCALL and INT trapping, and they violate the ability of a program to assume complete control of the full virtual address space.
If Apple devs are reading, then please, we love your products, but we don't love DSOs. Please grant us the freedom to choose. Please keep SYSCALL stable. It'd also be great if you didn't add special-cased code to XNU that blocks open source Actually Portable Executables, like you did with UPX. Email me (the author) your feedback instead. I'll do anything to help, short of adopting a second WIN32 linkage model.
Are you familiar with Apple's concept of "private API"? Apple considers the list of exported symbols from a dynamic library to not be a boundary (in fact, they have a linker that ignores that and links against a predefined list of symbols regardless of what a binary exports), much less the kernel syscall interface. In fact, Apple silicon requires that your program is loaded by dyld as far as I can tell.
While I wan't around in the nineties, I'm curious how syscall numbering helped Apple's success. I'm sure System-V ABI when they switched to 64-bit Intel was probably a nice bonus, but system call numbers?
Live at head goes both ways it seems
> and UWP et al
That remains to be seen in ~10 years at least :-P
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/...
ntdll is a userspace library, not a part of the kernel. So when you call ntdll functions you aren't calling into the kernel (although most ntdll functions will do so on your behalf).
And ntdll itself is technically unstable[0], though I'll grant you that there are many functions that are unlikely to break. There's no guarantee though.
[0]: https://docs.microsoft.com/en-us/windows/win32/devnotes/call...
There are different rules for drivers. Which is also why it's common and normal for a driver written for an older version of Windows to not work on a new version, but it's rare (and considered a bug) for userspace software.
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/
NTDLL is only stable if Microsoft likes what you're doing. For example, Microsoft culture is super biased against fork() or any creative use of virtual memory. There was, for decades, a sort of a hush hush fork() workaround in NTDLL that people thought was stable. Then some Sunnyvale startup called Crossmeta built a product to capitalize on it, Microsoft rolled out a security update, and poof it's gone. They ignored all the documented warnings saying "if you use NTDLL be sure to have fallback!" So think twice before messing with Redmond.
Might this change now that things like game copy protections are implementing syscalls manually?
Doubtful. There have long been software that abuses syscalls and other kernel level features to implement Sony rootkits and other DRM. Ironically those that implement game copy protection would be annoyed if syscalls were stabilized because the whole reason they use unstable syscalls is to obfuscate what they're doing and make the program extremely sensitive to tampering.
FreeBSD guarantees syscall ABI stability too.
Do you have a source for that? The closest I could find suggests otherwise, but admittedly I haven't yet found a more relevant document on policy:
> No compatibility for API and ABI is guaranteed from one to the next major release, though an effort is made to make the upgrade process and source code changes as untroubled as possible.
https://wiki.freebsd.org/VendorInformation
It’s pretty obvious from the fact that people are routinely running jails with old userspace (eg 11.0) under newer kernels (eg 13.0). It doesn’t always work for management interfaces (so eg an old route(8) binary might be broken), but is guaranteed to work for normal user programs.
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.
Not to mention this one:
> I couldn't resist the temptation of making it a reality, since it means that high-performance native code can be almost as pain-free as web apps.
> Please note this is intended for people who don't care about desktop GUIs, and just want stdio and sockets without devops toil.
My understanding was that people are using web-apps and electron precisely to provide cross-platform GUIs. I feel like this is really missing the forest for the mountains...
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!
I wish more people had this mentality. Thanks for taking the time to share, both the content of the post, and posting here about your rationale.
> I'm also not concerned about running software on telephones since doing so requires obtaining authorization from Google
That's not actually true. Fortnite has an APK download many users download straight from the internet and run on their Android phones for example. There's no requirement to run Google authorized software as long as you are willing to check a checkbox in the phone settings.
I hope I didn't come off as too negative, I think it's a really cool hack.
I guess the people I could see myself sharing binaries with are either too clueless to use the command line or savvy enough that installing a compiler/interpreter is not an issue.
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.
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.
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!
The serious solution is to use Python, JVM or whatever interpreter is available on the device and use that to load/create the correct executable.
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.
Haha yeah, I have the same question... normally Google Buckets are hosted under storage.googleapis.com/[your bucket] not under a subdomain...
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.
Perhaps it's not that costly (or you can circumvent costs) if you work at Google, like Justine does IIUC.
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.
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.
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.
(Justine)
Author here. I'm sorry you feel that way. If you'd rather it be licensed ISC/MIT/BSD/etc. then please encourage your favorite member of FAANG or some other huge company to acquire Actually Portable Executable and then make it freely available under those terms, for the sake of benevolence and commitment to serving public interest. I come included.
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.
This is perverse in the best way possible.
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.
> It's incompatible with modern debuggers.
Any debugger that can't debug this binary is broken and should be treated as such.
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.
> 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.
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.
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 2 = https://github.com/riscv/riscv-plic-spec
Microarchitectures are the new architectures. The game these days is all about finding a way to make your code go fast on the latest and greatest AVX thing, while still maintaining compatibility for old machines via CPUID. Getting those 10x speedups (sometimes 50x w/ things like crc32 pclmul) is much more fun than caring about things like s390x (i.e. doing IBM's work for them), SH (i.e. folks emulating Sega Saturn on FPGAs for fun), MIPS (hacked home routers), etc.
This is incredible and also very frightening. Has anyone tried to distribute one of these binaries in a real context?
I think the closest to that would be 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.
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."
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!"
Or people who can read Greek. I can only imagine how Russians feel towards the frequent misuse of their alphabet.
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
But it doesn't work on Linux?
It does for me. Make sure to execute via/prefix with sh, you can’t invoke it directly even after chmod +x
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.
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.
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
什庅bai湜焱暒妏？举些瑺鼡哋唎ふ。du 什庅湜悩残軆？举些瑺鼡哋唎ふ。 什庅湜zhi悱炷蓅？举些瑺鼡哋唎ふ。 莓兲想埝祢巳宬儰⒈种漝惯
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.
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.
30und5 c1053 70 13375p34k.
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?
there are more recent patents involving extensions on x86_64 which are essential for more modern processors, I believe.
Yes, being x64 compatible but not supporting SSE4 or AVX is basically useless.
Rosetta won't support this, it's far from "useless". Good programs should detect the lack of support and fall back to earlier extensions.
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.
Oh, I love a great retrospecification work. This is awesome.
You don't always need a shebang if it is marked as executable,is this a cosmetic conformity thing?
You need a shebang if you're going to execute it directly.
cute title; but not searchable, machine translatable, or screen-reader friendly.
Google found it in the first couple results: https://www.google.com/search?hl=en&q=actually%20portable%20...
What's the program being used to go through the machine code in the gif?
I'm not sure exactly what debugger is used, but gdb dashboard can be set up in a similar way. It's just stepping through instructions and viewing the registers and some memory regions.
https://github.com/cyrus-and/gdb-dashboard
Though any debugger should be able to give the same information (including just plain gdb).
The program being used is 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.
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.
"
Is this actually portable x86 executable?
actmally pdrtable execmtable?
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.
I suggest you never look under the hood of the compiler frontend ;)
This girl is a true visionary engineer
Actmallg rdrtable ekecmatable ?
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.
not to mention people using screen readers...
This is a massive issue on Twitter when people use "vanity" display names as well.
It's the Cyclopean, non-Euclidean display names that really grind my gears.
Oh yes, the Cyclopean usernames of titan blocks and sky-flung monoliths, all dripping with green ooze and sinister with latent horror. Definitely not screen-reader friendly.
The ones that bother me more are all the mathematical characters, horribly abused.
I have at least one visually impaired Twitter follower (there may be more that I'm unaware of). This is why I don't do clever things with Unicode characters or post those text-picture memes and always type in alt text for my images. I'd like to think that I would be sensitive enough to do so without having him in my followers list, but I suspect that if I'm honest with myself, I probably wouldn't so I'm thankful for his presence to remind me to keep things accessible.
https://ux.stackexchange.com/questions/118149/can-screen-rea...
Agreed. It’s not even a particularly good example of the style, given υ could have been used instead of μ, ο instead of δ.
And use lambda and pi.
"actmally rdrtable execmtable" that's more or less how it reads to someone who knows the Greek alphabet :-D
(I might be partially wrong because I've studied Greek many years ago and my memory is not good)
It's somehow worse than "toys ya us".
Or Nee (Nine Inch Nails: NIИ)
Whoa... that means Trent Reznor is a Knight who says Nee!
Or Stack Overflow's "We are less than three people who code."
This comment is the top Google result for "stack overflow we are less than three people who code". It's not clear to me what you mean.
I think it refers to this[1] page with the header "We <3 people who code" where <3 is supposed to be a heart.
(Probably people from the "post-emoji generation" can't recognise <3 as well as us old people ahah)
[1] https://pics.onsizzle.com/stack-overflow-where-dev-x-https-s...
No that's a reversed-R which happens to look identical like a Cyrillic letter. I don't think that's a problem any more than getting confused and trying to pronounce a circle in a logo as an "o". In contrast, the text here is trying to look Greek but doing it poorly.
That Cyrillic letter happens to be pronounced "ya".
another offence is using sigma (∑) as a stylized "E" or uppercase lambda (Λ) as "A" (see NASA logo).
Γορ μεμορι ις στιλλ γκουτ
LOL some high-end Anglo-Greek right there :-D thanks
Shouldn’t it be ‘γκουvт’?
actmally r-thee-ta-blae execm-ta-blae
Really confusing that they use mu when upsilon is available...
Not really confusing when you assume the intention is to look clever - the more different the letterform you find while it still being recognisable as the one you are replacing, the more exaggerated your effect is without further reducing readability.
(Yes, I know this isn't "just to try look clever", ala 1337-speak, and is trying to make a relevant reference to the cross audience understanding the is relevant to a cross platform executable, but the point still stands about choosing less similar but still similar enough glyphs)
That's an English p, not a Greek ρ.
you are right, I assumed it was a rho but on closer inspection it's a lowercase p
Foreign alphabet transliteration drama thread under the best hacking-grade article in years. Thanks, hn.
Yep - if you want people to focus on what you actually wrote, don't do this. I couldn't get past the title.
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.
The most HN comment ever.
Play stupid games, win stupid prizes.
Please explain your reasoning for this.
Not GP, but I'll take a crack at this.
The stupid game would be making your article title not an immediately obvious summary of your article.
The stupid prize would be this HN thread now that is only discussing the title, instead of the actual article.
Which, I would argue, says at least as much about the HN crowd as it does about whoever posted the article under this specific title.
EDIT: more specifically .. it's rather ironic how judgmental (and honestly: pretty darn pretentiously) so many here instantly get, yet how there is this implied assumption that the collective wisdom and judgement of this community is above criticism itself, somehow. It might say far more about HN, that nobody appears to be discussing the article's content itself, than it says about the (mis)use of alphabets.
I can read Cyrillic fluently, and a bit of Greek too, yet I'm not in the least bit upset about this pun. If this does upset anyone, maybe it's time for some seriously self-reflection for those people, about what they decide to get upset about and what not.
It's probably more virtue signalling than actually being upset. Complaining is a way for the complainer to show off they know the actual pronunciations.
Anti-virtue anti-signalling.
FWIW, it's not annoying or upsetting to me. However, I took Russian years ago. The only thing I remember is the alphabet and some random words. I also live in a country where the language is not my native one. So, when I saw this in a language I may be able to pronounce like a 3 year old, my immediate response was to think "oh, let's see if I can guess what this says" into "wait what..." into "wtaf" into "oh, that's dumb." I skipped that article this morning because while I wasn't upset or annoyed, I was disappointed. I was disappointed that a skill I once worked very hard for was wasted. Since it was also at the top of the page, I felt like it was abused in this community. In fact, I attributed the title for the only reason it was on the front page. When I just clicked to see what the comments were, I was pleasantly surprised to find I was not the only one disappointed with the alphabets chosen for this title.
The stupid game was getting too cute with the title, in a way that essentially invited a backfire. Arguably, it's still better than many titles from the newsrooms, but newsrooms reached the bottom long ago and decided to open a deep mine.
Thus, the stupid game led to a stupid prize, where major thread (in fact, one that felt like drowning any other discussion) was about the title technicalities, but not about content.
Because it is not transliteration, at least in any correct sense of the word.
If you (i.e. anyone) really wants to be helpful about things like this, email us at hn@ycombinator.com. Downweighting off-topic subthreads that get upvoted to the top is one of the best interventions we can do for discussion quality. We do that whenever we see them, but we don't see them all.
There are a couple of users who email us regularly when they see things like that. This is one of the highest-leverage contributions anybody can make to HN, so we'd certainly appreciate hearing from more such users. Actually I only found out about this subthread because of such an email.
Supercilious complaints, on the other hand, just make the thread even worse. Please don't do that. The thing where some HN commenters use HN to posture over the rest of HN is tedious, and in poor taste. Let's just work together to make it better, to the extent possible.
Appreciate the gesture. That might work. Took no pleasure in that comment, but truth had to be said.
IMO this is not in the same category as people complaining about a website requiring Javascript or using the wrong font. It's an unreadable title for screenreaders. And unlike Javascript or CSS styling or trackers, needing a screenreader is not a personal choice, or a limitation that people can turn on and off.
I think it's fair to point out when a good article makes itself inaccessible due to a trivially correctable problem.
I'm not even saying that the author can't make the joke they're trying to make, but even a small title change like "αcτµαlly pδrταblε εxεcµταblε (actually portable executable)" would basically solve the entire problem without sacrificing any of the meaning behind what the author wants to convey with their misuse of Unicode.
It is a good article, which is why the pointless pushback over accessibility is so frustrating. There would be no engineering effort or large compromise required to make the title of the submission readable. It wouldn't suddenly make the article bad, or not worth reading. It feels like it's being exclusionary just for the sake of being exclusionary.
It's not great for accessibility neither.
OPs compaints fall into the accessibility bucket. The site makes itself less accessible since some people (greek alphabet users) have trouble consuming the content.
Not to mention it is terrible for searching.
Thanks a lot! It annoys me extremely every time I have to read such mess.
1) актуалли портабле екзекутабле
2) αcτµαlly pδrταblε εxεcµταblε
What is easier to comprehend?
3) Actually Portable Executable
There's a better option.
APE audio might come a knocking though and I'm not you sure you want to make them angry. You won't like them when they're angry...
https://en.wikipedia.org/wiki/Application_Enhancer might too, if Apple hadn't restricted Input Manager plugins ;)
My screenreader can pronounce Greek. Which means the first is far easier to comprehend.
My contribution to your #1
астиа11у рогтаЬ1е ехеситаЬ1е
No, please no.
I could ready #1 immediately and thought "hey, I can actually read faux-cyrillic a lot better that I thought" and then I realized that you used a semi-proper transliteration.
Case in point I guess.
The 1) is simply transliteration of English into Russian/Cyrillic and it does look weird to me but it is easier to read than 2).
(Russian is my native language)
You need to see when me and my friends start chatting in English written in Cyrillic. It's epic and utterly frustrating for the first hours, then becomes like native ;)
One of the other things that bugs the hell out of me is when in the late 90's during the boom of irc, here in Bulgaria everyone was writing in Bulgarian with latin script. And to make matters worse:
4 = ch
6 = sh
And some people keep on doing it. I can understand it when you have to switch between scripts every 2 seconds but most commonly that isn't the case and you are either having a conversation with someone or leaving it for later when you have time or when you feel like it...
Йес, съмтаймс уи ду дис то каунтър шльокавица ин партикюлър.
Edit: for the non initiates. It's this written in Cyrillic: "Yes, sometimes we do this to counter shlyokavitsa in particular"
Shlyokavitsa is the name of the forementioned style of writing Bulgarian with latin letters. The original meaning of the word is "low quality, self-made alcohol", possibly even poisonous because of methanol
I'm really pleased to hear this, because I've kept scratch notes in english text written in the greek alphabet for decades, and every so often I wondered if it was more readable than I expected if someone who read greek happened to glance at it :) (It's not secrets - more like a habit of stream-of-consciousness writing while listening to someone talk, that would probably look bizarre).
It's cringe, but I don't find it hard to read, anymore than knowning numbers precludes me from reading "4c7u411y p0274813 3x3cu74813".
I guess I'm not as l33t as I thought I was, because I couldn't read that without having to figure out what each number was supposed to be individually.
I'm not sure what precluded me from reading that, but I don't think not knowing numbers would have helped me figure out that portable is p0274813 without context clues. Might need a more readily parseable example there.
Fwiw, it’s significantly easier to read on the actual site than on Hacker News. Something about the font.
HN’s title should probably be changed.
It's horrible to some of us that don't know the foreign alphabet too. While I had no problem reading the title it still makes my eyes bleed and my brain hurt to see it. ;)
I personally think its kind of creative, and looks cool. Though the author might like to be aware of the discontent it causes certain individuals. This is mean but it comes accross as though you are just wanting to show off you knowledge of a different alphabet...a complainbrag. Seems unlikely you'd take the effort to bother but thats my perception.
> This is mean but it comes accross as though you are just wanting to show off you knowledge of a different alphabet
There are people whose native languages are in those alphabets.
Quick: How would you pronounce СССР?
Hint: It would be completely wrong, because it's not English.
bold of you to assume the existence of an objective right or wrong mapping from characters to sounds
One might argue that "context" is a valid discriminator for that, but your point certainly has validity too. They are just two different arguments. The argument of arrogance in claiming an absolute right from wrong, and the argument that context can make one interpretation more correct because it relates to the meaning and not just the description of something.
That is actually one of my hinderances in learning Russian, because I keep reading the identical Cyrillic letters as English.
Ι ⅼіκе іτ аɴԁ аⅼѡауѕ геϲоⅿⅿеɴԁ τо реорⅼе τо τаκе ⅿоге аԁⅴаɴτаɡе оғ ⋃ɴіϲоԁе.
Tʜᴇʀᴇ ᴀʀᴇ ᴀʟʀᴇᴀᴅʏ ᴅᴇᴅɪᴄᴀᴛᴇᴅ ᴄʜᴀʀᴀᴄᴛᴇʀs ғᴏʀ sᴍᴀʟʟ ᴄᴀᴘs
‘ғ‘ looks slightly weird though.
Yeah apparently the converter I used used a Cyrillic character, the actual "LATIN LETTER SMALL CAPITAL F" is ꜰ. Also apparently there's a "LATIN LETTER SMALL CAPITAL *" for every letter except X[0][1].
[0] https://unicode-table.com/en/search/?q=small+capital [1] https://en.wikipedia.org/wiki/Small_caps#Unicode
Не ми харесба.
Also a nightmare for screen reader users, who can't read the title at all and need to click the article.
¯\_(ツ)_/¯
For me, it always takes some time to see it as face and still hard to understand what emotion this face presents.
shrug
Never mind the fact that it's just super pretentious
I hear your pain.
I wish this wasn’t the top voted comment.
Things that are subversive, clever, mind bending, tongue in cheek ... tend to get criticized around these parts for not being simple, plain, and literal.
It's not even that, why does this headline deserve to stick out from others on the HN front page? What's the next step, make your title bold or twenty lines long for an unfair click advantage?
> 𝐀𝐜𝐭𝐮𝐚𝐥𝐥𝐲 𝐩𝐨𝐫𝐭𝐚𝐛𝐥𝐞 𝐞𝐱𝐞𝐜𝐮𝐭𝐚𝐛𝐥𝐞
I'd rather see submissions stand out for their content.
I guess for HN OP should have refactored the title to be "Actually Portable Executable" but I thought the whole point of the title was that it's something we can interpret that has been "written in something else" which is fitting given what the article discusses? It's a direct copy/paste from the source and I don't think OP was trying to stand out in any unfair way.
I'm not blaming the HN submitter, but you can also see how bloggers can easily abuse this if whatever unicode characters they put in their title are allowed in the HN submission on the grounds of "it's a direct copy/paste".
FWIW, the title stands out, but at least for me it's not working in the favor of the article. Unless it was for the content ("actually portable executable"), I would actually stay away from articles with such strange fonts.
> What's the next step, make your title bold or twenty lines long for an unfair click advantage?
Hm. Not a bad idea.
Files away as an Unethical LifeHack
You can expect a bold, Cyrillic, ZALGO!͇̺̫̞̤͇̼͋̆̂-fied post about my next paper shortly.
People have of course been pulling such tricks for years. We don't allow it generally, and in fact are pretty strict about that. But all such rules have exceptions.
The quality of this post is so high that it doesn't feel right to override any aspect of what the author created, including quirks like the title. There may be a superficial similarity to garden-variety title pimping, but as someone who bathes in spam every day I can tell you how rarely such gimmicks come attached to first-class feats of hacking prowess. Respect for content requires looking closely enough to detect truly unusual cases, pick them out of the mud, and give them a special place.
Another principle applies here too: it's good for readers to have to work a little (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...). If a title like that appears at #1 on HN, there are two possibilities: (1) this is dreck that somehow managed to evade all of the standard moderation; or (2) something's happening here and you don't know what it is. Actually, either possibility is rather interesting, and it's not hard for any HN reader to do the bit of work to figure it out. Even if it takes 20 seconds.
I've learned some degree of Russian (and certainly enough to roughly read Greek) and even that's enough for me to have to take a few passes to parse it as English.
The only boundary this transcends is readability and is ironically not portable at all.
edit for readability:
тхе онлу боундары тхис трансцендс ис реадабилиты анд ис ироницаллы нот портабле ат алл.
И вхолехеартедлы агрее.
https://ux.stackexchange.com/questions/118149/can-screen-rea...
It's a bad thing to do for attention, like hacker elite speak using numbers would be, but is that why the author did that? Did you read the article? It's about a file that can be read by all Unix, Windows, and MacOS. Part of how that happens is one OS mistakes some other text for executable code while the other OS doesn't.
Therefore the title of the article written in multiple language letters and somewhat readable in one language despite that is a good introduction.
I would argue you could write an informative title, and reserve the problematic text for the article text, where you can explain why you are doing that. Just like the comment you were responding to I can't imagine screen reader users are super stoked by how "appropriate" this title is
Really? You didn't find it clever enough to muster a little smile?
The things that bother some people.
To that note, would it be possible to change the title of the submission to "Actually Portable Executable"?
It would help people focus more on the content of the article, make the submission more accessible for non-English & blind readers, and feel less spammy and exploitative, all at the same time.
I doubt the author of this article or the submitter wants this to be the top thing people are discussing about their article anyway. And that is the title -- if you go to the library source code[0], its graphical banner is using the normal English letters. The unicode weirdness here is only being used typographically, the author isn't claiming that their title should be pronounced differently or something.
[0]: https://raw.githubusercontent.com/jart/cosmopolitan/46750430...
Bsuthuncs has a lot to answer for.
It's also not accessible whatsoever to screen readers.
lol sick ️
"Actually Portable Executable"
Incase anyone searches on hn.aloglia in future!
"Όντως φορητό εκτελέσιμο" ?
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.
…εξακτεμάν! :D
يَمَن
https://en.wikipedia.org/wiki/Mots_d%27Heures ?
... or uses a screenreader.
As a person that speaks Greek, this hurts my delicate and beautiful soul. Please don't do that again.
Why does the title font look pseudo Greek?
Because that's the name of the post/"format"...
> I started a project which called Cosmopolitan which implements the αcτµαlly pδrταblε εxεcµταblε format. I chose the name because I like the idea of having the freedom to write software without restrictions that transcends traditional boundaries.
I hate it when people do that. It looks tacky and it's super annoying when they (mis)use a script you can read.
"My Big Fat GRSSK Wedding" was a big offender there.
It also plays havoc with screen readers! I feel sorry for any blind people scrolling down the home page at the moment.
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.
I taught myself to read Greek recently and couldn’t parse it at first either.
aCtmaLLg rdRtaBLe exeCmtaBLe
Yeah.
My eyesight is terrible and my recollection of Greek is lousy, but I was going "Aren't those Ms?? Isn't that a D?"
Thank you for that.
Writing things like this reminds me of edgy teenager on the internet of early 2000s.
I associate it with naive teenagehood, but I don't associate it with 'edginess'.