Set some time aside today again to give this a shot, still get that same error message above and can't sort out why. I may just have to start over and try putting the whole thing together again in VS2022 from scratch.
The idea isn't too difficult, I've considered two approaches. Some theory below
Basically, in 'interpreter.cpp', before this on line 182:
if ( agk::GetFileExists( "bytecode.byc" ) == 1 )
A new step would be added to check for a special marker value in the EXE itself indicating the bytecode is present inside the EXE file itself. Something like (added to the pool of available AppGameKit calls or its own operation):
if ( agk::GetBytecodeMarker() == 1 )
If present, the interpreter would then load the data starting from the marker to the end of the file in exactly the same way it would read it from the '\media\bytecode.byc' file (just skipping the data contained in the interpreter file first). You can see the principle in action now by simply adding the bytecode file onto the end of the interpreter with something like (simple Tier1 example):
CreateMemblockFromFile(1,PlayerFilename$)
MemSize1=GetMemblockSize(1)
CreateMemblockFromFile(2,BytecodeFilename$)
MemSize2=GetMemblockSize(2)
CreateMemblock(3,MemSize1+MemSize2)
CopyMemblock(1,3,0,0,MemSize1)
CopyMemblock(2,3,0,MemSize1,MemSize2)
CreateFileFromMemblock(PlayerOutputFilename$,3)
DeleteMemblock(1)
DeleteMemblock(2)
DeleteMemblock(3)
Putting it together is literally that simple (could even use AGK's Tier2 calls to do the same thing internally when compiling). Attaching the bytecode data that way will still allow the EXE to run as normal (you can try it if you like), it simply now contains the bytecode data with it. Since the bytecode would no longer be in the \media folder, the default AppGameKit broadcast window will appear when the EXE is run on its own. So the interpreter/player simply needs a way to detect that the bytecode has been attached to the EXE (via some kind of marker check) and then read the data like it always does, just from the EXE instead of the separate bytecode file.
This allows the EXE to be self-contained, no need for unreliable virtual environments (that get flagged by A/V programs) while also eliminating the biggest security gap AGK/C/S has had by giving developers a way to codesign their game to keep things safe and 'locked'.
The only other possible route I can think of would be to generate a SHA512 hash after the bytecode.byc file is built, then attach that internally to the end of the interpreter EXE file, then have a check to compare the internal hash with the hash of the bytecode file at launch, then load and run as normal if they match or exit if they don't match. This binds the interpreter to only one byecode file, allowing the specialized interpreter to still be codesigned for security and not allowing anything other than the one bytecode file to run without breaking the signing/security.
The internal attachment approach might be best, but anything would be better than leaving a potentially signed player capable of running any bytecode file.
