Shoes 3.2 has met the future and the future is kicking my ass. I can see many reasons why the despised binject failed on a mingw stub and the winject (c) version. And the winject.rb – but I fixed that.
The exerb (pure Ruby) based winject.rb can create/inject string resources into the MinGW compiled stub.c -> shoes-stub.exe. It creates string table resources, but you have reference them with an id#, not a “string” lookup. So (per my previous post) “SHOES_FILE_NAME” is now
Winject::EXE::SHOES_APP_NAMEy in Ruby and
#define SHOES_APP_NAME 50 (from stub32.h) for C. The stub shoes-stub.exe will not look up by string name, it will use the number (50). That could be an annoyance
to future maintainers. Was it too hard to get exerb to create named string resources? Yes it was. It can create a StringTable for each injected String and that took major cowboy head scratching.
And now we meet the Windows Unicode monster. When MingW compiles a STRING_TABLE it produces a UTF16 bastard. Yeah, that might be controllable with some sort of #define but exerb doesn’t know about that (or handle it well). As it turns out, stub.c is not really unicode aware. Just enough syntactic sugar cover-ups to compile with MSVC 6 and MinGW.
I needed to fix stub.c to deal with the download site issue (it should be from a loaded resource, not a compiled constant). Bite the Windows Unicode bullet. I’d be lieing if I said that was going well. For now, I’m going to convert all UTF-16 resource strings to UTF-8 in stub.c with a
char * shoes_str_load(HINSTANCE inst, UINT resnum).
It’s going to take some time.