Windows support: build with MinGW-w64 and OpenBLAS

[dareus66]

Adds a Windows build of the BLAS backend, so make blas works from an MSYS2 UCRT64 shell.

The delta turned out to be Linux to Windows rather than macOS to Windows: the OpenBLAS path already exists and every Accelerate include sits behind __APPLE__, so nothing had to be de-macified. The whole port is 118 lines of code across 9 files, all inside #ifdef _WIN32.

Platform shims

• iris_safetensors.c — CreateFileMapping/MapViewOfFile instead of mmap. A mapped view keeps its own references, so both handles are closed right after mapping, mirroring the POSIX code that closes the fd after mmap; the struct is unchanged. Release goes through a small iris_unmap() helper.
• iris_transformer_flux.c — GetSystemInfo instead of sysconf in get_attn_num_threads(). MinGW ships unistd.h but not sysconf, so this is a hard compile error otherwise. The other two sysconf calls sit in USE_METAL/__APPLE__ branches and never reach this build.
• terminals.c — the iTerm2 temp-file path returns -1. MinGW has no mkstemps(), and iTerm2 is never detected on Windows, so implementing one would be dead code.
• Binary-mode fopen — config, tokenizer and index files. Windows text mode translates CRLF and corrupts the sized reads that follow ftell(). On POSIX "rb" is identical to "r".

Not built on Windows

The interactive REPL (iris_cli.c, linenoise.c, embcache.c need termios); main.c prints an error and exits when interactive mode is requested. Terminal image previews compile but do not render.

Other backends

Unchanged. The only lines removed anywhere are the eight fopen mode strings and three munmap calls that now go through iris_unmap(), which on POSIX calls munmap — so macOS and Linux behaviour is identical.

Verification

Built on a Xeon W-2125 (4 cores) with OpenBLAS 0.3.34 and gcc 16.2, checked against this repository's own reference images — all well inside the threshold of 20:

Test	mean_diff	expected
64x64, 2 steps, seed 42	1.14	~3.4
512x512, 4 steps, seed 123	2.12	~1.7
img2img 256x256, seed 456	8.29	6-17

run_test.py --quick passes as is. The full suite cannot run unchanged on hardware this slow: it kills each test after 300s and the 512x512 case needs about 220s of denoising plus loading, so those three cases were run by hand.

One unrelated fix, kept in its own commit

make pngtest was broken on every platform — iris_image.c calls jpeg_load_mem()/jpeg_free(), whose implementation lives in jpeg.c, but the target only compiled png_compare.c iris_image.c, so the link failed with undefined references. It is the first commit here so it can be taken independently of the Windows work.

It still fails afterwards on its first image pair, which compares woman_with_sunglasses.png (512x512) against woman_with_sunglasses_compressed2.png (256x256). I left that alone since it is not clear which image was intended. The cat_* pair is correctly matched and passes.

🤖 Generated with Claude Code