The Win32 subsystem

AnotherOS runs native Windows 32-bit .exe files as first-class, crash-isolated Fasadas applications.

This is a native subsystem, modelled on Windows NT's own architecture. It is not Wine, and it is not an emulator.

The model: WOW64 on a 64-bit kernel

A Win32 .exe is 32-bit machine code and the kernel is x86_64. The subsystem bridges that the way Windows' own WOW64 layer does.

• The executable's 32-bit code runs in the CPU's compatibility mode — a ring-3 32-bit code segment.
• When it needs an operating-system service it transitions in the same process to 64-bit code, by a far jump to the 64-bit ring-3 code segment. This is the classic WOW64 "heaven's gate".
• The 64-bit half is the per-process Win32 host that implements kernel32, user32, gdi32, ddraw and dsound. It is ordinary AnotherOS C, and it reaches the real system — the filesystem, threads, the display protocol, Garsas audio — through normal syscalls.

It draws onto the native compositor. No X server is involved.

Because both ring-3 selectors already exist in the CPU's descriptor table at user privilege, the 32-to-64 transition needs no kernel code at all: it is a user-mode far jump within one address space. And because the host is 64-bit C, the subsystem needs no 32-bit C toolchain — only a handful of hand-written 32-bit thunk instructions, which the 64-bit loader emits at runtime.

Crash isolation

Each .exe is one AnotherOS process and one ordinary compositor client. A Win32 application crashing kills exactly that process — never the compositor, never the system.

Everything session-global that must survive an application crash — the window station, clipboard, atom table, registry and handle namespace — lives in a separate supervised server, exactly as NT's own does.

Running one

There is nothing to type. A .exe is executable:

./hello.exe

No wine, no shim, no loader on the command line. ps and top report the process under the executable's own name, not the loader's.

The kernel recognises an i386 PE image and hands it to the native Win32 loader, which maps the image at its base address, generates the 32-bit import thunks and enters the program. Detection is deliberately conservative, so anything that is not really a Win32 executable falls through to a truthful "not executable" error rather than being half-loaded.

What works today

The kernel can enter and execute 32-bit compatibility-mode user code, and a trivial .exe runs as a native process from a plain execve.

Faults reach a userland handler correctly. A synchronous CPU fault delivers a correct faulting address to a signal handler, so a handler can read the address, read and modify the interrupted program counter, step past the fault and resume. That is the recovery move every JIT, every garbage collector and Windows' structured exception handling all depend on, and without it none of them can be supported at all.

A system-wide crash reporter symbolises any process that dies from a fault: the kernel queues a crash record, and a supervised reporter resolves the faulting address against the binary's symbols and walks the stack for a backtrace. This is not Win32-specific — the Win32 personality adds NT detail to the same report.

Graphics and input for Win32 programs are covered on the DirectX and OpenGL page.

Turning it off

The subsystem can be disabled, in which case a .exe is simply not an executable file and reports so.