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. _______________________________________________ wine-users mailing list wine-users@winehq.com http://www.winehq.com/mailman/listinfo/wine-users
