How is Win/Dos syscalls implemented in Wine?

[Ove Kaaven]

On Fri, 25 Oct 2002, Peter Andersson wrote:

> Hi,
> Ok, I think I get it (never been much into Windoze codeing)...

Hmm. Have you been into Linux coding, then? (The concept of shared
libraries seem a little foreign to you...)

> 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?

I'm still not sure what you're talking about. Again, Win32 apps doesn't do
syscalls.

Or, let's see, what do you consider a syscall? If from your Linux program,
you call malloc(), is that a syscall? It sounds like you think it is. But
it isn't, it's a call into a shared library (libc.so)

> Is the dll mapping event, itself raised by some kind of  SIGSEGV signal?

DLLs are imported by the app, just like your Linux app imports libc.so
(and ld.so is the loader that actually loads libc.so and links your Linux
app against it at runtime).

> 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,

Since when? A syscall number isn't an interrupt vector number. Linux/i386
syscalls are always entered via int 0x80 (with eax being the syscall
number). All other ints are invalid and generate a SIGSEGV.

> wich would remove
> the users homedirectory if called, and would not raise a SIGSEGV signal.
> How would Wine stop this?

If, let's say, a windoze app really used int 0x80 to intentially
obliterate the user's system? Well, Wine wouldn't stop it.

> I know wine uses the ptrace syscall, is that really only
> for debugging purposes, or is it for catching the SIGSEGV
> signals also?

It's to support certain win32 features (that's mostly used for debugging).
Catching signals is done with sigaction().