You can always take a look how for example Windows 3.11 and earlier did it for their *.rtf file format and their “write.exe” editor / viewer / renderer (if you want to call it that way).

You have stack buffer out of bounds write. On line 52 you declare h an array of 70 unsigned ints. On line 57 you store reference to such array. Later, on line 35 you write out of bounds, one element past end of the array. The _SPR_history[i] writes to _SPR_history[70]. Created an issue: https://github.com/X64X2/sh/issues/1

ABI break when?

I know some unnamed big customers want ABI stability. But common … VS2015, VS2017, VS2019 and VS2022 all compatible with each other if used with new enough linker? They all are sharing pre-defined macro _MSC_VER 19xx and VC++ toolset version number 14.xx. That is too much of holding back progress on performance and correctness fronts. Eight years is enough.

Customers need to learn that they cannot rely on ABI stability of STL provided classes, cos guess what: The Holy Standard doesn’t specify any. Toolchain vendors do. This also applies to MFC/ATL/whatnot distributed as part of Visual Studio. Remember the GCC copy-on-write string ABI problem? We already have technology to help migrate between ABI versions: one is called COM, other is pimpl, other is version number as first member of struct or first function parameter. I bet there are many more out there.

https://twitter.com/visualc/status/1688976075584376845

Think of advanced features of WinRAR not being accessible without valid licence key. Ehm, WinRAR distributes the same binary for both licensed and unlicensed users, unlocking the features with license key or with a crack (equivalent of NOPing the if). What if instead WinRAR distributed different binary for each licensed user, advanced features encrypted by per-user key. Crack or keygen would need to use some particular user’s binary with theirs license. Easily trackable. Or crack would need need to be applied once and then distribute the un-encrypted features / code.

Think of password protected access to something, anything. Instead of checking if(password == some_constant){...} or if(hash(password) == precomputed_hash){...} you encrypt that something. The first variant has disadvantage that some_constant is stored inside your binary, thus password visible to anybody. The second variant … the same, hash of the password is stored inside the binary and could be brute-forced or rainbow-tabled. Both variants have the disadvantage, that there is a run-time check refusing access to some data, but those data are available in the binary anyway. Just open the program in debugger or in hex editor and NOP the if out. With my approach the data is unreadable without the correct password. The app could not be convinced / persuaded to provide the data in any way without the password.