Problem
The kwxApp_* application lifecycle functions (kwxApp_Initialize, kwxApp_MainLoop, kwxApp_Shutdown, etc.) currently live only in �xamples/CApp/ and are not part of the kwxFFI library itself.
This causes a fatal issue for language bindings: when a language binding (e.g., kwxFortran) compiles its own copy of kwxApp.cpp into a static library, and that static library links against wxWidgets static libs (wxbase, wxcore), the result is two separate copies of wxWidgets — one in kwxFFI.dll and one in the consuming executable.
The kwxApp_Initialize() call sets wxTheApp in the executable's copy of wxWidgets, but wxFrame_Create() and all other kwxFFI functions live in kwxFFI.dll which has its own copy where wxTheApp is still null. This causes a null pointer crash on the first WM_ACTIVATEAPP message (line 3109 of wxWidgets \src/msw/window.cpp):
\\cpp
case WM_ACTIVATEAPP:
wxTheApp->SetActive(wParam != 0, FindFocus()); // wxTheApp is null in DLL's copy
break;
\\
Requested Fix
Move the kwxApp_* functions into the kwxFFI library itself so they are exported alongside all other wxFFI functions. This ensures:
- Only ONE copy of wxWidgets exists (inside kwxFFI.dll)
- wxTheApp is set in the same module that processes window messages
- Language bindings don't need to link wxWidgets directly — they only link kwxFFI
The key functions needed as exports:
- \kwxApp_Initialize\
- \kwxApp_MainLoop\
- \kwxApp_ExitMainLoop\
- \kwxApp_Shutdown\
- \kwxApp_SetAppName\ / \kwxApp_GetAppName\
- \kwxApp_SetTopWindow\ / \kwxApp_GetTopWindow\
- \kwxApp_SetExitOnFrameDelete\
- \kwxApp_InitAllImageHandlers\
- \kwxApp_IsTerminating\
Impact
All language bindings (Fortran, Rust, Go, Julia, Perl, LuaJIT) will hit this same issue. None of them can safely compile their own \kwxApp.cpp\ because it creates duplicate wxWidgets state.
Discovered In
kwxFortran-dev, Phase 2 (Core Windows). The minimal example builds and links successfully but crashes immediately on launch due to null \wxTheApp\ inside kwxFFI.dll.
Problem
The kwxApp_* application lifecycle functions (kwxApp_Initialize, kwxApp_MainLoop, kwxApp_Shutdown, etc.) currently live only in �xamples/CApp/ and are not part of the kwxFFI library itself.
This causes a fatal issue for language bindings: when a language binding (e.g., kwxFortran) compiles its own copy of kwxApp.cpp into a static library, and that static library links against wxWidgets static libs (wxbase, wxcore), the result is two separate copies of wxWidgets — one in kwxFFI.dll and one in the consuming executable.
The kwxApp_Initialize() call sets wxTheApp in the executable's copy of wxWidgets, but wxFrame_Create() and all other kwxFFI functions live in kwxFFI.dll which has its own copy where wxTheApp is still null. This causes a null pointer crash on the first WM_ACTIVATEAPP message (line 3109 of wxWidgets \src/msw/window.cpp):
\\cpp
case WM_ACTIVATEAPP:
wxTheApp->SetActive(wParam != 0, FindFocus()); // wxTheApp is null in DLL's copy
break;
\\
Requested Fix
Move the kwxApp_* functions into the kwxFFI library itself so they are exported alongside all other wxFFI functions. This ensures:
The key functions needed as exports:
Impact
All language bindings (Fortran, Rust, Go, Julia, Perl, LuaJIT) will hit this same issue. None of them can safely compile their own \kwxApp.cpp\ because it creates duplicate wxWidgets state.
Discovered In
kwxFortran-dev, Phase 2 (Core Windows). The minimal example builds and links successfully but crashes immediately on launch due to null \wxTheApp\ inside kwxFFI.dll.