Yeah, I've had it work on an X11 server using a Ruby X11 protocol implementation instead of libX11, and it just rushed ahead and added support for a bunch of missing requests and responses. None of that is hard - it's all very well documented - but it's tedious.
replyMy terminal emulator using the same binding also started out hand-written but Claude overhauled that too recently and it knows vtxx escape codes far better than me too.
Only because the X Window System is very heavily documented, e.g., in the excellent "The Definitive Guides to the X Window System Series".
replyNo libc? It used inline assembly routines?
replyYes, something like this:
reply static inline long read(int fd, void *buf, long count) {
register long rax asm("rax") = __NR_read;
register long rdi asm("rdi") = (long)fd;
register long rsi asm("rsi") = (long)buf;
register long rdx asm("rdx") = count;
asm volatile(
"syscall"
: "+r"(rax)
: "r"(rdi), "r"(rsi), "r"(rdx)
: "rcx", "r11", "memory"
);
return rax;
}The linux kernel also has its own headers (IIRC it was something like <asm/unistd.h> and/or <sys/syscall.h>, but might depend on architecture and version) where it will provide the stub asm statements.
replyIn my memory the syscall ABI has changed a few times (i386 had int $0x80, then sysenter, then abstracting it in the vdso, then amd64 has 'syscall'), so it may be easier to let the kernel header provide the mechanism.
The Linux syscall ABI is (famously) stable; on x86* you can still call into 0x80 just fine. There might be new interfaces made available, but existing programs shouldn't break. Although, in C there could be value in abstracting over the per-platform differences like int/syscall. I've only ever done raw syscalls from assembly where portability was rather moot:)
replyIt's quite easy to get it to do syscalls directly, I even got Fable to do a simple standalone TLS implementation (in C). Not really useful since it hardcoded a set of supported algorithms etc., but it's fun to see how "simple" you can force it to go.
reply