> I'm just saying it shouldn't be required.
I'm still not entirely sure why you want to use instructions from the privilleged subset of your ISA instead of plain old "call fun_addr".
> And where are LoadLibraryW and GetProcAddress coming from?
They're provided by the OS. Their addresses are patched into your executable's image during the loading. It's a very ancient technology, one of the very first software technologies invented, in fact — predates FORTRAN.
> What if you had to implement those functions yourself?
What if you had to implement exec(2) yourself? As a matter of fact, why is exec even provided as a syscall? Almost all of it (except for locking the text segment IIRC) can be done in the user space, including the parsing of the program headers and relocating stuff. Which, again, I've done once and I appreciate the OS giving it to me already implemented.
> The function just happens to be identified by a stable number rather than function address.
Or you can identify it as a stable offset into a large table of function addresses; or even as a stable character string!
intptr_t fd = invoke_ffi("kernel32.dll!CreateFileW", fn, GENERIC_READ | GENERIC_WRITE, etc.);
if (fd
> it's a complete ELF object which you have to parse and resolve symbols from.
You don't have to parse it. And UEFI environment in fact does give your program's entry point a table of function pointers: you put the arguments into the registers, take an offset into this table of functions, load the address, and call it, with one instruction, "call"/"branch-and-link", and it will give you the return value in a specific register. No need to parse anything by yourself.
I personally think this kind of dependency injection is pretty neat; you can intercept your own syscalls by passing pointer a modified table down your call stack. Trapping "sysenter" instruction in the userspace is way harder.