The pdfcraft-print unit-test executable imported windows.data.pdf.dll and
prntvpt.dll at load time (the windows crate binds them with raw-dylib), so
on a Windows installation without them it could not start, and the tests
of the missing-DLL guard never ran there. crates/print/build.rs now passes
/DELAYLOAD for both and delayimp.lib on MSVC, as the applications' build
scripts do. Link arguments from a build script reach only this package's
own executables, so dependents are unaffected.
dumpbin /imports: before, both DLLs under "the following imports"; after,
under "the following delay load imports". A copy of each test binary with
prntvpt.dll renamed to a DLL that doesn't exist: the old one exits with
0xC0000135 (STATUS_DLL_NOT_FOUND) before main, the new one starts and runs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Pq7HyCfwzyRXj4VfQAVVdv
pdfcraft.exe and pdfcraft-cli.exe imported windows.data.pdf.dll and
prntvpt.dll at load time (through craft-print's printing), so a trimmed
Windows installation without them refused to start the program at all.
The executables now delay-load the two DLLs, and the spool adapters
check that they exist before calling in: without them the printer list
is empty and a print job fails with a message pointing to Save as PDF.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pdfcraft-cli.exe had no VERSIONINFO, so Explorer's Details tab,
(Get-Item pdfcraft-cli.exe).VersionInfo and inventory tools showed no
version or publisher for it. A build.rs like the app's embeds one with
winresource (already a build dependency of pdfcraft): the same product
name and copyright, its own description and file names, and the package
version. PDFCRAFT_REQUIRE_WINRES=1, which the Windows packaging already
sets, makes a missing resource compiler an error; otherwise it's a
warning, and other targets are unaffected.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>