vfig on 24/1/2022 at 22:05
the custom .osm i have been building for my current mission is based on Telliamed's (
https://thiefmissions.com/telliamed/) "OSM Developer's Toolkit" (osmdemo.zip) — my fork is (
https://github.com/vfig/osmdemo) on github — and built with gcc+mingw32 (from the tdmgcc32 package).
a problem that i have encountered is that from time to time, my osm would simply fail to load before any of its code gets a chance to run. most of the time it would be fine, but sometimes dromed (or thief2) would just report "failed to load 'foo.osm'" on the exact same binary that worked fine the day before. and restarting windows would generally make it work again. i have been tearing my hair out over this for the last few days, and finally understand the reason.
the .osm will work just fine when it gets loaded at its default base address, but if it was relocated (because another dll happened to occupy part of its default address space), then the OS will fail to load it, and tell dromed that it couldnt be loaded.
debugging the LoadLibrary() call shows that an access violation happens while the OS is setting up the dll's thread-local storage (tls) info. it turns out that dlls on windows—at least, those that must be compatible with windows 2000, as newdark requires—may not have static tls info if they will ever be loaded dynamically with LoadLibrary().
and although neither Telliamed's code nor mine in the osm uses tls at all, the libmingw32 library that is needed for building the dll with mingw32
does, and so is causing the problem to arise. it doesnt appear that there is any configuration option, or any way to avoid this except by not using mingw32—although perhaps building it from source would provide the option of disabling tls or using the dynamically-safe TlsAlloc() apis instead of the static tls info; i dont know, i havent looked into doing that yet.
for the moment i am choosing a base address that i think is unlikely to have any conflict, and hoping for the best. thats not really a solid answer, and it could still end up with sporadic failures for some people or even never work at all, depending on what is going on in their windows setup.
i am not happy with this as a solution, but for now it lets me carry on building what the mission needs instead of getting bogged down in awful c++ build shite. later down the line i may look into porting the code to msvc++ instead of gcc+mingw32; unfortunately doing that it is (for my osm at least) rather more painful than one might hope.
Nameless Voice on 28/1/2022 at 14:51
Ugh, this sounds really familiar. NVScript had similar issues.
It's been years and I don't remember the particulars, but I believe I ended up asking someone who was more familiar with the whole C++ build process about this, and they helped me "solve" it by converting NVScript into an MSVC project, bypassing the entire problem.
vfig on 28/1/2022 at 15:33
yes, moving over to msvc++ is my fallback plan. had a stab at converting it already, but it got messy: unfortunately for me some critical parts of my osm are in assembly, and converting that from gnu assembler to microsoft assembler style was giving me grief.
Nameless Voice on 28/1/2022 at 17:44
One tip for testing if the relocation works properly is to load the same .osm twice (e.g. copied to a different filename and loaded again.)
If you have that relocation bug, then one should fail to load every single time, as the other is using the address.
vfig on 29/1/2022 at 04:13
oh thats an excellent idea, thanks. even after moving it over to msvc++, i will still need to check that my assembly code gets fixed up properly during relocation, and that will be an easy way to test.
