How is Win/Dos syscalls implemented in Wine?
kanelballe at softhome.net
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?
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