wxmaxima-cli.cpp File Reference

A console-subsystem front end for the GUI-subsystem wxmaxima.exe. More...

#include <windows.h>
#include <cstdio>
#include <cwchar>
#include <string>

Include dependency graph for wxmaxima-cli.cpp:

Functions
int	main ()

Detailed Description

A console-subsystem front end for the GUI-subsystem wxmaxima.exe.

On Windows an executable's subsystem is a bit in its PE header, fixed at link time: a binary is either GUI-subsystem or console-subsystem, never both. wxmaxima.exe has to be GUI-subsystem (a console-subsystem GUI app pops up a console window next to every worksheet), and that has two consequences for anything run from a command prompt:

• it starts with no stdio wired up at all, which is what RedirectStdioToParent() in main.cpp exists to paper over, and
• cmd.exe does not wait for a GUI-subsystem process. It returns to the prompt immediately, so even output that does reach the console lands after the next prompt has already been printed.

The second one no amount of code inside wxmaxima.exe can fix. So this: a tiny console-subsystem launcher that starts wxmaxima.exe with our own standard handles, waits for it, and passes its exit code back. Because this* process is console-subsystem, cmd.exe waits for it, and –version, –help and –batch behave the way a command-line tool is expected to.

Deliberately plain Win32 + CRT, with no wxWidgets and none of wxMaxima's own code linked in: it needs neither, and staying dependency-free keeps it a few tens of kilobytes that link statically without dragging a second copy of a statically-linked wxWidgets along. If this ever grows into a genuinely headless CLI that evaluates worksheets, share the core through a CMake OBJECT library (the pattern wxmTestApp/wxmFuzzApp already use) rather than a DLL – a DLL would duplicate statically-linked wxWidgets' global state (the wxModule registry, the wxApp instance, the art provider table) across the boundary.