3 ms·
We don't use SYSCALL on Windows. We link KERNEL32 and friends. It adds bloat to our binaries (for instance, hello world could be 4kb rather than 16kb if we didn
by jart 4y ago
We don't use SYSCALL on Windows. We link KERNEL32 and friends. It adds bloat to our binaries (for instance, hello world could be 4kb rather than 16kb if we didn't need DLLs) but Microsoft leaves us with little other option, since it'd require just as much bloat to use Xed to wrangle the syscall ordinals out of NTDLL. Our policy is to stick with stable supported interfaces whenever possible. Since XNU's SYSCALL interface is allowed, and it's nearly identical to those of Linux and BSDs, it'd be tragic to not use something that fits so perfectly hand in glove with the rest of our system call support. Look here, all we need to support a XNU system call is 16-bits of a word. https://github.com/jart/cosmopolitan/blob/2.1/libc/sysv/syscalls.sh https://github.com/jart/cosmopolitan/blob/2.1/libc/sysv/sysc...
- lgg 4y agoThe macOS syscall interface policy is the same as Windows. In practice it has had less churn then then NTDLL which may make it feel more practical, but it is only more "allowed" in the sense that it is technically feasible, not that it is guaranteed to be stable or supported.
- brynet 4y ago> Our policy is to stick with stable supported interfaces whenever possible Except you're not doing that consistently though. On OpenBSD, mincore(2) was removed 3 years ago, and it's UNIMPL syscall 78 was eventually recycled by a different system call: mquery(2), which your library calls expecting mincore and passes bogus arguments to. I would be very surprised if there aren't more serious mistakes lurking in your library, in fact I know there are. https://github.com/openbsd/src/commit/54e4f6b9a1dc183e1dc7c4a722c2646aa309246a https://github.com/openbsd/src/commit/54e4f6b9a1dc183e1dc7c4... https://github.com/openbsd/src/commit/1d60349d0b961891264d426ffe1c0ced24b2374c https://github.com/openbsd/src/commit/1d60349d0b961891264d42...
- anamexis 4y agoFrom the OP chart, it looks like mincore is indeed not supported on OpenBSD, so what's the issue?
- brynet 4y agoThey updated the chart since I posted, from what I can tell the issue remains in the sources published. https://web.archive.org/web/20220921050525/https://justine.lol/cosmopolitan/functions.html https://web.archive.org/web/20220921050525/https://justine.l...
- deleted 4y ago[deleted]
- Dwedit 4y agoYou can actually get Hello World down to 1.5K in MSVC with the right compiler switches. First the code to say hello: const char \*const str = "Hello World!\n"; HANDLE standardOutput = GetStdHandle(STD_OUTPUT_HANDLE); WriteFile(standardOutput, str, strlen(str), NULL, NULL); Then the compiler switches: /merge:.rdata=.text cuts out an entire section 0.5K /nocoffgrpinfo cuts out about 256 bytes from your .text section /emittoolversioninfo:no is supposed to omit the RICH header, but doesn't seem to work anymore. /stub:stub.bin will let you replace the default DOS EXE stub with something smaller. Using a 64 byte file will get the EXE header and PE header to fit in the first 512 bytes (when combined with merging the .rdata and .text sections) Set "Entry Point" to main. This completely bypasses the C standard library and CRT, none of that gets initialized or called. Then you end up with an EXE containing 3 sections: The EXE header (512 bytes), the .text section (512 bytes, but only 141 bytes actually used in there), and the .idata section (512 bytes, for importing DLLs, only 41 bytes actually used)