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...
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!
> 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.
> 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 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).
> 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"
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.
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.
If you look at the functionality provided there, it includes ability to compile generated code. This is implemented using those command-line compilers.
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!
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.)
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.
> 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.
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?
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
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!
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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!
> 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...
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.
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'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.
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.
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.
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.
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.
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)
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.
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 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.
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
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.
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.
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.
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.
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'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.
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).
Things that are subversive, clever, mind bending, tongue in cheek ... tend to get criticized around these parts for not being simple, plain, and literal.
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.
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.
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.
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.
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.
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.
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 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].
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.
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. ;)
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.
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 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.
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...