3 ms·
> I'm assuming you actually never used older systems - syscall/interrupt-based/call gate based is actually the "the facto standard" Actually, my code runs just
by nanolith 3y ago
> I'm assuming you actually never used older systems - syscall/interrupt-based/call gate based is actually the "the facto standard"
Actually, my code runs just fine on older versions of Unix, because it uses libc and doesn't attempt to use interrupts, call gates, or whatever hidden interfaces varying between minor releases or different hardware revisions, were available on a specific version and a specific kernel compilation.
> Case in point, the problem is with a runtime that IS NOT libc-based, and should be supported, because it is targeting a SPECIFIC OS VERSION and not a libc version.
The compiled runtime may be specific to a particular libc / *nix version, but the source code is typically agnostic. Detect what it needs and trust the compiler to fill in the details. Or, of course, you could have conditional compilation and custom code for every minor release and *nix flavor out there. Clearly, no, that's not typical.
> and the sooner we get rid of the C heritage
Ah, we get to the crux of the issue. You actually believe that it is language and not engineering process and tooling, that somehow influences safety and security.
> Your console app developed in 1999 in Windows ME should run fine on a modern Windows version...
You're describing something that's more of a bug than a feature. Windows' binary backwards compatibility has been a source of many security vulnerabilities and instances of flaky behavior caused by regressions in the emulation layer. And, yes, it's an emulation layer at this point more than it's an interface or API.
I'll skip the weird strawman about how building portable applications backed by libc is somehow an OpenBSD-ism.
Software interrupts are glacially slow. You may want to familiarize yourself with modern hardware and syscall traps. These may work similarly to a software interrupt, but they have much better performance, even when pinned to libc, libunix, or whatever other library you use instead of littering your code with explicit trap instructions.