published on Jan 15 2026

Because Windows 11 is Bad, I’ve been playing with Wine lately. Mostly trying out various windows-exclusive softwares that I really like, in order to see how they would work on Linux. But also, doing some surface level exploration of how Wine works. It led me to the following fun experiment that I want to share...

Syscalls and Wine

Let’s talk about syscalls. You probably know what they are. If you don’t, you should read the relevant section of the assembly tutorial on this blog! But, in short, syscalls are services that the operating system can perform for the applications. Things like opening/reading/writing files, allocating memory, etc. are all done via syscalls at the end of the day.

In the post linked above, I had explained that there is an important difference between how applications use the `syscall` instruction on Windows vs. Linux: on Linux, application code is expected to use the syscall instruction directly, whereas on Windows, applications are not expected to use syscall directly. They’re supposed to call WinAPI functions, which handle direct communication with the OS kernel behind the scenes.

This last bit is crucial for Wine. Roughly speaking, Wine "just" has to load the windows portable executable file, make everything in the process address space look like Windows and provide its own set of "system libraries" containing the implementations of the WinAPI functions (all of this is already _a lot_ easier said than done, and i’m still skipping a lot of detail).

The code of the Windows program executing under Wine runs like that of any other normal process - there’s no "virtualization" of any kind, nothing’s really "emulated" other than the set of functionality provided by WinAPI. From the Linux kernel point of view, that Windows program is just another process.

Unfortunately, not every Windows program follows the rules. You see, Windows syscall conventions are not exactly secret. Microsoft just makes no guarantees about those conventions remaining stable (since you’re not supposed to rely on them!), though in practice a lot of them are stable. Because of that, some programs will just use syscall directly - usually for performance reasons.

Such programs are a huge problem for Wine. If you execute the syscall instruction under Linux while using the Windows conventions, nothing good will happen - most likely the process will just crash. There are potential ways to get around this problem but none of them are easy - as far as I’m aware there is no 100% working solution at the time of this writing.

The Unholy Wine-Drunk Chimera

A nagging thought wormed its way into my head: yeah, making direct Windows syscalls under Wine will fail. But what about making direct syscalls using Linux conventions? That should work, right? Linux syscalls from a Windows program? I really see no reason why it would fail.

It’s a stupid stupid idea. Literally nobody needs or wants this. There’s zero practical utility because no program written to be executed on Windows contains raw Linux syscalls. But I just had to see if it was possible. So, I broke out my trusty friend Flat Assembler:

section '.text' code readable executable
start:
; Win64 calling convention appeasement - align stack.
sub	rsp,8*5

; Call the MessageBox WinAPI function to show we're really running under
; Wine.
xor r9, r9
lea	r8,[msg_win]
lea	rdx,[msg_win]
xor	rcx,rcx
call	[MessageBoxA]

; Execute a Linux syscall
mov rax, 1 ; Syscall no 1 - "write to file"
mov rdi, 1 ; File handle for stdout
mov rsi, msg_lnx ; byte buffer to write to the file
mov rdx, [msg_lnx_len] ; buffer length
syscall

; Exit cleanly.
xor rax,rax
call [ExitProcess]

; Import table stuff (not interesting, included for posterity).
section '.idata' import data readable writeable

dd 0,0,0,RVA kernel_name,RVA kernel_table
dd 0,0,0,RVA user_name,RVA user_table
dd 0,0,0,0,0

kernel_table:
ExitProcess dq RVA _ExitProcess
dq 0
user_table:
MessageBoxA dq RVA _MessageBoxA
dq 0

kernel_name db 'KERNEL32.DLL',0
user_name db 'USER32.DLL',0

_ExitProcess dw 0
db 'ExitProcess',0
_MessageBoxA dw 0
db 'MessageBoxA',0

And wouldn't you know it? It totally worked\!

![](https://gpfault.net/assets/post-img/drunk-exe.gif)

For fun, I also tried using fork and execve to launch a linux program\. Launching the new program works, though it seems to crash the original process:

format PE64 NX GUI

entry start

section ‘.data’ readable writeable msg_win db “Hello from Windows!”,0 binary_path db “/usr/bin/mousepad”,0 envvar0 db “DISPLAY=:1.0”,0 envvar1 db “XAUTHORITY=/home/nicebyte/.Xauthority”,0 envvars dq envvar0, envvar1, 0 argv dq binary_path, 0

section ‘.text’ code readable executable start: ; Win64 calling convention appeasement - align stack. sub rsp,8*5

; Call the MessageBox WinAPI function xor r9, r9 lea r8,[msg_win] lea rdx,[msg_win] xor rcx,rcx call [MessageBoxA]

; Linux syscalls mov rax, 0x39; fork syscall

cmp rax, 0 jnz exit

mov rax, 0x3b ; execve mov rdi, binary_path ; ELF executable file name mov rsi, argv mov rdx, envvars; environment vars syscall

exit: ret

; ..import table stuff skipped…

So yeah, you can make linux syscalls from windows programs, as long as they're running under Wine\. Totally useless, but the fact that such a frankenstein monster of a program could exist is funny to me\.

---

*Like this post? [Follow](https://bsky.app/profile/nicebyte.bsky.social) me on bluesky for more\!*