How is Win/Dos syscalls implemented in Wine?

Peter Andersson kanelballe at
Sat Oct 26 10:36:30 CDT 2002

On Saturday 26 October 2002 14.13, Eric Pouech wrote:
> > Conclusion:
> > The ntdll is for wine apps what libc is for Linux/Unix.
> > Syscalls is made from ntdll and the native version is never
> > run.
> mostly (libc contains much more than ntdll does). A closer (yet
> incomplete) answer would be libc = ntdll + kernel32 + msvcrt
> (most of the win32 apps don't call ntdll in, they call kernel32 or
> msvcrt in)
> > You are right about the syscalls in Linux, too bad
> > theres no protection for it though. It should be, otherwise
> > there could appear wine_linux viruses.
> well, there could, as well, be pure linux viruses. and, I don't see why
> wine should be more protective than the linux kernel is.
Well for now there are not much Linux viruses around. It is possible to 
write an antivirus program (I have not heard of any yet) for Linux/Unix. And 
there are antivirus programs for Windows. But how do you check for viruses 
that directly affects the Linux/Unix environment embedded
within a Windows app? I believe running windows apps in wine should be
trusted the same way as enabling java in a web browser.

Has an int 0x80 any purpose in Windows environment?
What does it do?

> > Cant you fix this with ptrace?
> no.
> A+

Are you really sure?

Here is a cut of the Linux man side:
              Restarts the stopped child as for PTRACE_CONT,  but
              arranges  for  the  child to be stopped at the next
              entry to or exit from a system call, or after  exe-
              cution of a single instruction, respectively.  (The
              child will also, as usual, be stopped upon  receipt
              of  a  signal.)  From the parent's perspective, the
              child will appear to have been stopped  by  receipt
              of a SIGTRAP.  So, for PTRACE_SYSCALL, for example,
              the idea is to inspect the arguments to the  system
              call   at   the   first   stop,   then  do  another
              PTRACE_SYSCALL and inspect the return value of  the
              system call at the second stop.  (addr is ignored.)

Cant you use this to trap the call and kill the process before it enters
the kernel or maybe if its a 0x80 intreupt check the params for the call
and do some protective actions if the call is not supported by wine?



More information about the wine-devel mailing list