[quaesitor-scientiam]

Summary

• Ports include/winapi/psapi.h from thirdparty-windows-amd64, where it's a pre-existing part of the base bundle (not something win32: add missing intrin.h/dbghelp.h headers so tcc can build vc/v_win.c #96/win32: add missing intrin.h/dbghelp.h headers so tcc can build vc/v_win.c (i386) #98 added). It's absent from thirdparty-windows-i386 entirely.
• Part of the investigation in thirdparty-windows-i386's tcc.exe is a much older build than amd64's, and cannot compile the current vc/v_win.c #99: this is the smaller, easy half of that issue. The larger half (this branch's tcc.exe being a much older 0.9.27 build vs. amd64's 0.9.28rc fork, which blocks a full vc/v_win.c bootstrap regardless of headers) is not addressed here and needs a separate maintainer decision.

Why this is needed

Confirmed via a real build, not assumed: compiling vc/v_win.c with this branch's own tcc.exe (using makev.bat's exact build_bootstrap_with_tcc flags) fails at v_win.c:58 on #include <psapi.h> without this file. With it added, the build gets substantially further - all the way to v_win.c:682, where it hits the unrelated _Bool/_Atomic feature gap tracked in #99.

Test plan

• Confirmed via a real i386 tcc.exe (extracted from this branch, with its libtcc.dll/lib/libgc-1.dll dependencies colocated) that adding this file resolves the psapi.h compile error and the build progresses further.
• Checked the ported file's one arch-sensitive spot (PSAPI_WORKING_SET_BLOCK's VirtualPage bitfield width) already branches correctly on _WIN64, which is unset for this branch's i386 target.
• Not a full end-to-end bootstrap verification - that's blocked by thirdparty-windows-i386's tcc.exe is a much older build than amd64's, and cannot compile the current vc/v_win.c #99, independent of this file.

🧙 Built with WOZCODE

[medvednikov]

Reviewed the complete one-file port at 31a349743258458a9b858b7dbe77a1c75af49346 against issue #99, the amd64 sibling, this branch's calling-convention definitions, and Microsoft's SDK declarations. CI status/results were not considered.

One actionable P2 is attached inline: both page-file callback typedefs omit the required i386 stdcall convention. This is an architecture-sensitive integration issue that an amd64-only check cannot detect, separate from the correctly selected VirtualPage bitfield width.

The added header is byte-identical to the amd64 file (Git blob 4b17dd6623403de60fe95bb36fb9e78b02245001). That establishes the copy's provenance, not ABI correctness on the new target. The API function declarations use WINAPI, but their callback pointer typedefs do not; Microsoft's SDK explicitly uses __stdcall for both callbacks.

Local validation: reconstructed the complete fetched header and verified its Git blob hash before testing it. Ran 32 isolated Clang 17 Windows-target probes covering original/patched declarations, i686/x86_64, PSAPI_VERSION 1/2, ANSI/Unicode, and separate layout/callback checks. All layout checks passed. The four original-header i686 callback configurations failed with incompatible function-pointer diagnostics; adding WINAPI to the two typedefs made those pass. The corresponding x86_64 controls passed unchanged.

These probes supplied minimal Windows primitive types and the A/W macro dependency; they did not compile the entire bundled Windows header tree or execute Windows callbacks. No Windows TinyCC, V bootstrap, or V tests were run locally, and direct source-download access failed DNS resolution.

Scope: this PR adds the missing include file only. It neither updates tcc.exe/libtcc.dll nor resolves the separately reported atomic-declaration failure in #99; that issue should not be treated as fully fixed by this header port.

[medvednikov]

[P2] Preserve stdcall on both page-file callback types for i386

These two typedefs default to the C calling convention, but Windows calls both PENUM_PAGE_FILE_CALLBACKA and PENUM_PAGE_FILE_CALLBACKW as __stdcall. Microsoft's SDK declares them explicitly as BOOL (__stdcall *...). This matters in the branch this PR targets: its _mingw.h retains the stdcall attribute on i386, whereas the x64 path removes it.

A correctly declared WINAPI callback is therefore incompatible with the new pointer types. Conversely, writing an ordinary C callback to match these typedefs gives Windows the wrong stack-cleanup convention and can unbalance the stack on return. Applying WINAPI to EnumPageFilesA/W themselves does not fix the callback's separate ABI. The omission is inherited from the amd64 source, but becomes significant in this i386 port.

Please change both declarations to typedef WINBOOL (WINAPI *PENUM_PAGE_FILE_CALLBACKA/W)(...) (or use the equivalent CALLBACK/__stdcall) and add an i386 compile check assigning and passing real stdcall callbacks for both variants.

I reproduced the type mismatch with isolated Clang 17 probes using the exact fetched header and Windows primitive-type stubs: i686 rejects both callback assignments/calls, x86_64 accepts them, and adding WINAPI fixes i686. This is a compiler-level ABI check, not a claimed Windows runtime reproduction or a failure of the bootstrap's bare include.

SDK reference: https://github.com/microsoft/win32metadata/blob/main/generation/WinSDK/RecompiledIdlHeaders/um/Psapi.h#L572-L574
Calling-convention reference: https://learn.microsoft.com/en-us/cpp/cpp/stdcall

[quaesitor-scientiam]

Good catch - fixed in 03caf75, added WINAPI to both PENUM_PAGE_FILE_CALLBACKW/A. Confirmed with a real i386 tcc.exe that the fix compiles and the build reaches exactly as far as before (the unrelated #99 _Bool wall at v_win.c:682) - no regression from the change.

Worth noting for the record: this exact mismatch exists verbatim in amd64's own copy of the file too (same blob content before this fix), just invisible there since amd64 has one calling convention. Not touching that here since it's a different branch, but flagging in case it's worth a matching fix there independent of this PR.

[medvednikov]

Re-reviewed fix commit 03caf7519a36284081481fd9b2601e64566ba895 against the previously reviewed 31a349743258458a9b858b7dbe77a1c75af49346, while following up on #99. CI status/results were excluded.

The previous P2 about the i386 page-file callback calling convention is addressed. No new actionable correctness issue found in this two-line fix.

Both PENUM_PAGE_FILE_CALLBACKW and PENUM_PAGE_FILE_CALLBACKA now put WINAPI on the callback pointer itself. This fixes the separate callback convention, rather than merely relying on WINAPI on the consuming EnumPageFilesW/A declarations. Parameter types, return types, and the A/W and PSAPI-version mappings are unchanged.

Independent local validation: ran 16 isolated Clang 17 Windows-target syntax probes using transcriptions of the changed typedefs and consuming declarations with minimal Windows primitive types. The matrix covered original/fixed declarations, i686/x86_64, ANSI/Unicode, and PSAPI_VERSION 1/2. Each probe checked both explicit A/W callback types, direct callback arguments, and the generic A/W alias. All eight fixed-declaration configurations passed; reverting the two additions caused all four i686 controls to fail their type-compatibility assertions and callback assignments/calls, while the four x86_64 controls still passed.

These are isolated declaration/ABI checks, not compilation of the entire bundled Windows header tree or execution of Windows callbacks. I did not run either Windows TCC binary, a V bootstrap, or V tests. This environment has no Windows interpreter or V compiler, and the attempted direct source download failed DNS resolution.

This closes the callback finding only. The native-toolchain and bootstrap-snapshot work discussed in #99 remains separate from this header-only PR.

[quaesitor-scientiam]

Thanks for the thorough re-verification - 16 more isolated probes with a clean pass/fail split exactly where expected (i686 controls fail without the fix, x86_64 unaffected either way) is a solid close on this.

Agreed on scope: this PR stays header-only. The toolchain/snapshot work is tracked separately in #99, where I've since run the separated _Bool/_Atomic probes you asked for (confirms _Bool itself is fine, _Atomic is the actual unsupported construct) and posted a working local proof of a native i386 tcc.exe from the same modern source - though as you noted there, that's a proof, not a published fix, and the deeper blocker (vc/v_win.c never being generated for a 32-bit target, plus makev.bat's hardcoded V_C_FILE) means real end-to-end i386 bootstrapping is still open.