Explorer Shell Host
What is it?
On Windows, explorer.exe is the shell host: the user-mode process that owns the desktop and taskbar and opens files when you double-click them. This roadmap plans a small Windows-named explorer.exe for Impossible OS that starts after the desktop is ready (or starts the installer instead in installer mode), hooks into the taskbar and desktop, opens files through ShellExecute and the Registry's file associations, and becomes the default shell with cmd.exe as the fallback. It does not replace the File Manager. Nothing is implemented yet.
How does it work?
Today. There is no explorer.exe, no shell host process and no ShellExecute. The desktop and taskbar are part of the kernel, and the only user-mode shell is cmd.exe:
boot_desktop.cinitialises the window manager (wm.c) and the desktop (desktop.c), which draws the wallpaper, taskbar, Start menu and desktop icons, and reportsDESKTOP_READY.- It opens the terminal window and starts a kernel task that loads
C:\cmd.exe(shell_loader.c,cmd.c). - It enables the scheduler and enters
compositor_run(), the loop that draws every frame and never returns (compositor.c).
flowchart LR
B[boot_desktop] --> W[wm_init + desktop_init]
W --> R[DESKTOP_READY]
R --> T[terminal_open]
T --> S[shell_loader: C:\cmd.exe]
S --> C[compositor_run loop]
That split is the main open question for this roadmap: the plan has explorer.exe own desktop and taskbar integration, while today both are kernel code driven by the compositor. The plan also places the binary at C:\Windows\explorer.exe, while the system folder everywhere else is C:\Impossible\System32.
Planned design.
- Binary and boot.
explorer.exeon the system image, started once the compositor is ready unless installer mode selects the installer. - Shell32 gate. With a strict gate enabled, boot reports an error in the log if the
shell32exportsexplorer.exeneeds are still missing. - Taskbar and desktop. Register the shell host window class and receive taskbar events.
- Open verb.
ShellExecute(..., "open", ...)looks up the file's association inHKCRand starts the right program. - Default shell. The shell is chosen by the
Shellvalue under theWinLogonRegistry key, falling back tocmd.exe.
The first milestones avoid COM, IShellWindows and web views, using shell32 stubs and USER32 window calls only.
What are its interfaces?
| Interface | Status |
|---|---|
shell_loader_func() starting C:\cmd.exe |
Shipped |
HKU\Default Shell value (C:\cmd.exe) |
Shipped Registry default, informational |
explorer.exe, shell host window class |
Planned |
ShellExecute, SHGetFolderPath and other shell32 exports |
Planned in the Win32 API surface roadmap |
WinLogon Shell value |
Planned |
How do I use it?
It cannot be used yet. The system boots straight to the kernel desktop with the Command Prompt open.
What is not implemented yet?
- Binary layout and boot
- Shell32 dependency gate
- Taskbar and desktop integration, whose window list comes from the Taskbar roadmap
- ShellExecute open-verb wiring, on File Associations
- Boot-time explorer default
How does it compare with Windows 11 and Linux?
On Windows 11, explorer.exe is the shell host and the Desktop Window Manager composites the screen; the shell is chosen by the WinLogon Shell value. On Linux the equivalent depends on the desktop environment, for example gnome-shell or plasmashell, started by the display manager. Impossible OS has no shell host process: the kernel draws the desktop and starts cmd.exe. The plan adds a Windows-named explorer.exe gated on the shell32 exports it needs.