Hi, Ok, I think I get it (never been much into Windoze codeing)... Windows "syscalls" is also actually done by requesting a dll mapping and calling the system_function inside processed mapped memory. Am I right so far?
Is the dll mapping event, itself raised by some kind of SIGSEGV signal?
About the DOS/Windows interrupts: Is it really sure that trusting SIGSEGV is safe? What happens for instance in this case:
EAX (ackumulator register)= (char *) "$HOME" and an instruction interupt 10h (Linux unlink syscall)? This is a fully correct Linux syscall, wich would remove the users homedirectory if called, and would not raise a SIGSEGV signal. How would Wine stop this?
I know wine uses the ptrace syscall, is that really only for debugging purposes, or is it for catching the SIGSEGV signals also?
//Peter
On Friday 25 October 2002 17.26, you wrote:
On Fri, 25 Oct 2002, Peter Andersson wrote:
Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc.
I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way.
What are Windows/NT syscalls? Win32 apps doesn't make any syscalls, they just call the system DLLs (which is just shared libraries). Wine implements those DLLs in its own way.
How does wine stop these instructions from reaching the unix kernel?
If you're talking about interrupts, the ones that DOS/Windows app may use aren't accepted by Linux, so a segmentation fault happens when an app tries to issue such an interrupt. Wine can catch that segmentation fault by installing a SIGSEGV signal handler. If you're talking about the Win32 API, then Wine just links the app to its own version of that API, so it calls into the Wine-implemented DLLs.