Well, while I agree with the general sentiment, this is technically not quite right. In i386 protected mode, you cannot jump directly to code with a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be done through a "gate" (typically an interrupt). Passing through such a privilege-transition gate also implies switching to a similarly-privileged stack (before the return address is pushed), so you cannot push your own return address onto the kernel's privileged stack. And you probably can't even get the address of the kernel interrupt handler (the IDT can be protected from being read). This doesn't make Wine any more secure though, of course...
I wasn't talking about jumping directly into the kernel I was referring to the trusted/untrusted DLL part. the int 80h instruction was in trusted code. I was trying to show that "trusting" DLLs (or code pages) to allow/disallow syscalls could be rather easily circumvented and was offering no protection ("trusted" int 80h insn in trusted code could be used easily by untrusted code)
A+