So the only detail that is open for interpretation is whether the first thread of the process is treated specially.
Yup – and IMHO it's not a good idea to extrapolate usermode public API documentation to unspecified OS internals. There's a lot of reasons (a very big one being the OS implemented mainly in C) that it will probably keep on working forever, but it's dangerous to make assumptions. Especially when you don't gain much from it.
Also, as you state yourself:
In any case, the best you can assume is that RET exits the thread, not the process. It only happens to end the process when there are no other threads - another implicit (and potentially unsafe) assumption.
And these can be created for a myriad of reasons, including but not limited to printer drivers and endpoint security software.
But that's mostly an issue with how documentation is written - it may not give a strong argument for exiting the main thread with RET, but in my opinion it is an argument for improving the documentation.
Amen.
I do believe some leeway should be given, not requiring every bit of OS internal to be documented, otherwise things would be set in stone and very hard to improve (I'm not sure I agree with e.g. the Linux approach of keeping the ABI 99.9% stable), and it's also fair to target documentation and assumptions of a mass-market OS at the C level. But the entrypoint guarantees and assumptions ought to be more clearly specified.
(There's also a bit of pedantry of whether we can even call the
AddressOfEntryPoint the canon entrypoint, DLLs and TLS callbacks and whatnot
)
Index
> Windows > Is there a list of syscall?
- carpe noctem
