Move zeroed globals to data? and use MAX_PATH

[RatinCN]

Summary

This PR contains two small size-oriented commits:

1. Move zeroed globals to data?

   • Moves zero-initialized global storage from .DATA into MASM .DATA?.
   • This keeps initialized data out of the physical image while preserving the same zeroed runtime state.
   • It targets buffers and handles such as CmdFile, TitleBuf, find/replace buffers, status buffer, and zero-default flags.

2. Use MAX_PATH for file path buffer

   • Removes the custom 128-byte path/title limits now that the relevant storage lives in .DATA?.
   • Uses MAX_PATH directly for CmdFile, TitleBuf, command-line parsing, and Open/Save dialog path sizes.
   • This builds on the first commit: increasing these buffers no longer adds initialized file bytes.

Size impact

Measured with the same local build environment for each revision:

Revision	Object size	Normal linked exe	Crinkler exe
Baseline (44b7f2f)	14,939 bytes	11,264 bytes	2,794 bytes
After .DATA? (32789fa)	14,315 bytes	10,752 bytes	2,779 bytes
Final (2ece43d)	14,315 bytes	10,752 bytes	2,777 bytes

Net effect vs baseline:

Metric	Delta
Object size	-624 bytes
Normal linked exe	-512 bytes
Crinkler exe	-17 bytes

Validation

• Built with build.user.bat
• Final Crinkler output: trpad.exe = 2,777 bytes

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2ece43d112

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reserve space for the title suffix

With CmdFile now accepting MAX_PATH-1 characters, TitleBuf being only MAX_PATH bytes is not enough for valid paths whose final component is near the NTFS/Win32 component limit. For example, opening C:\ plus a 245+ character filename fits in CmdFile, but BuildTitle copies that basename and then appends " - TinyRetroPad" without bounds, overwriting the following globals (BytesRead, fDirty, etc.). Either cap the copied basename or make the title buffer include room for the suffix.

Useful? React with 👍 / 👎.

[RatinCN]

Thanks, this is a fair observation, but I think it is outside the intended scope of this PR.

This PR does not add new title-building behavior; BuildTitle already copied the basename into TitleBuf and appended the fixed " - TinyRetroPad" suffix without bounds. The only behavioral change here is that the path-related storage was moved into .DATA?, which lets CmdFile and TitleBuf grow from the previous 128-byte buffers to MAX_PATH without increasing initialized data size.

So this PR actually increases the available title/path buffer space compared with the existing code. Handling pathological filename lengths more rigorously would mean adding bounds checks or reserving extra suffix space, both of which are separate correctness/robustness work and would add code or storage beyond the size-reduction goal of this PR.

Given the size-first goal of TinyRetroPad, I would prefer to keep this PR limited to the storage-layout and buffer-size change rather than add new title truncation logic here.