Improve build scripts and lower Crinkler runtime memory

[mandel99]

Summary

• make build.bat auto-detect ml, link, and the newest installed Windows SDK x86 library path
• add build-tiny.bat so the Crinkler build stays available without making it the default build path
• reuse a few existing strings/constants in trpad.asm to shave bytes without changing visible UI text
• set the tiny Crinkler build to /TRANSFORM:CALLS /HASHSIZE:32 as a smaller-RAM compromise than Crinkler 3.0's large default hash table

Background

While testing this project locally with Crinkler 3.0a, one trpad.exe instance built with the compressed path was using far more memory than expected. The main cause turned out to be Crinkler's runtime decompressor settings rather than TinyRetroPad's editor logic.

Crinkler's manual states that /HASHSIZE controls the amount of memory the decompressor may use, and that this memory remains allocated for the lifetime of the program. In practice, that runtime cost was very noticeable on this project.

What this PR changes

build.bat

• switches the default build to a normal ml + link.exe path
• auto-detects ml.exe, link.exe, and the newest installed Windows SDK x86 lib directory
• keeps the project buildable without hardcoding one specific SDK version

This default build is the low-RAM build path.

build-tiny.bat

• keeps the Crinkler path separate and explicit
• uses /TINYIMPORT /TRANSFORM:CALLS /HASHSIZE:32

trpad.asm

• removes a few duplicate strings/constants and reuses existing offsets instead
• replaces the explicit "open" ShellExecute verb with NULL
• uses the built-in static class atom instead of carrying a separate "STATIC" string

These are conservative byte-saving changes that keep visible UI text the same.

Measured results

Local measurements on my machine:

Original repository build

• size: 2794 B
• runtime memory with the compressed path was very high in testing

Earlier Crinkler-tuned build using Crinkler's large default hash table

• size: 2708 B
• runtime memory was extremely high
• representative measurement: about 517 MB working set, 588 MB private memory, 777 MB virtual memory

Build proposed in this PR (/HASHSIZE:32)

• size: 2731 B
• representative measurement: about 47.5 MB working set, 118.8 MB private memory, 265.7 MB virtual memory

So this PR keeps the tiny build smaller than the original repository build while dramatically reducing the worst runtime memory behavior seen with the default Crinkler settings.

Additional investigation: TINYHEADER

I also tested Crinkler /TINYHEADER as an alternative.

Relevant manual note:

• TINYHEADER uses repeated linear searches instead of hashing
• /HASHSIZE and /HASHTRIES are ignored when /TINYHEADER is enabled

Measured TinyRetroPad result with TINYHEADER + TINYIMPORT:

• size: 2787 B
• representative measurement: about 4.9 MB working set, 85.3 MB private memory, 96.9 MB virtual memory

That means TINYHEADER is a real alternative if runtime memory is prioritized more than compressed size. However, for this project it was still larger than the /HASHSIZE:32 tiny build:

• TINYHEADER: 2787 B
• this PR's tiny build: 2731 B

So this PR keeps /HASHSIZE:32 because it stays below the original 2794 B build size while avoiding the huge memory overhead of Crinkler's larger default hash table.

Tradeoff summary

• original repo build: 2794 B
• Crinkler with large default hash table: smallest of the tested variants, but very large runtime memory usage
• TINYHEADER: much better runtime memory, but larger output than /HASHSIZE:32
• this PR (/HASHSIZE:32): smaller than original repo build and a more reasonable runtime compromise

Verification

• ran build.bat
• ran build-tiny.bat
• measured representative runtime memory for the tested Crinkler variants