Eliminate FreeLibrary/dlclose

[a1batross]

dlclose and FreeLibrary functions do not guarantee that the library was really unloaded.

It may lead to crashes, especially with global variables, when these don't get reinitialized to default value. Simplest example is pm_shared_initialized global in HLSDK code. If it somehow was marked as NODELETE, it will instantly crash the engine.

glibc and windows tries to unload the library but for example musl do not implement that at all. Also in Android NDK 25 release notes there is an bug mentioned where using dlclose can lead to crashes on some Android versions. NODELETE flag or eliminating dlclose is the only fix.

Some mods also are not intended to be reloaded all the time, like Metamod. I also get easy crashes with halflife-unified-sdk.

We already switched to execv() call for changing game because of dlclose/FreeLibrary being unreliable.

Here is the list of some troublesome parts that needs to be fixed as soon as possible:

• [ ] RefAPIs GetHumanReadable call. I guess we cannot collect renderers descriptions this way, loading the library, calling the export and unloading.
• [ ] pfnCheckGameDll menu call. It's used for menu to detect if there is a usable server library, or we can only connect to multiplayer games.
• [ ] settings.scr cvars collect. Engine uses that to generate listenserver.cfg
• [ ] Engine still can unload server library. I believe we don't need this in general, goldsrc never unloads it.

[a1batross]

cc @nekonomicon @SNMetamorph @mittorn

[SNMetamorph]

Yea I agree that this should be done.

[nekonomicon]

IDK why need to unload libraries, It's just waste of time.

[a1batross]

@nekonomicon glad to see you again! :)

I like loading libraries dynamicly, it makes sense for plugin architecture.

But unloading is unnecessary. We can only restart the engine.

Though guys from RTX branch @zgdump @0x4E69676874466F78 would not agree, since they implemented hot renderer swap.

[vklachkov]

Eh, I really wanted to switch renders... But I still haven't figured out why after a couple of ref switches everything explodes in random places of the engine

[a1batross]

@zgdump well, I doubt we can do anything with runtime that doesn't cleanup or even do anything at all after dlclose() and FreeLibrary().

Crashes and bugs just unavoidable with them.

[vklachkov]

@a1batross I understand, cut the ends! If i'm really want to do some bad things, I will make a ref_proxy with... [ton bad jokes about booms]

[a1batross]

@zgdump well, in theory, with carefully crafted code that doesn't have unneeded exports (because they can get shared, that's why we compile with -fvisibility=hidden by default) we can run multiple renderers simultaneously with some kind of RefAPI proxy.