Re: How to avoid DLL hell?

[Nick Gammon <nick@...>]

On 26/11/2010, at 7:24 PM, GrayFace wrote:

> Maybe something like this can be used to create a fake 5.1 dll that would redirect calls to 5.2 dll:  http://www.codeproject.com/KB/DLL/CreateYourProxyDLLs.aspx
> 
> Though, it's far too early to switch to 5.2 in any real projects.
> 

The module that expected to be talking to Lua 5.1 but actually got Lua 5.2 would fail on things like setfenv not existing any more. Plus, the internal structure of the Lua state has almost certainly changed. As for switching, I'm trying to anticipate problems before everything gets too ingrained for anyone to want to change.


On 26/11/2010, at 8:22 PM, Axel Kittenberger wrote:
>> 
> 
> I agree, additionally naming all dll binaries after the LUA version
> only isnt solving anything. First if i would put a version number
> there, it would be the version of the luasocket library, not the lua
> it was linked against. Since maybe you want something to have in
> luasocket 2.0.2 only or there might be incompatibilities with
> luasocket 2.0.0 etc.  

Well the DLLs like luasocket don't currently have their own version number in them so why introduce that now? My suggestion was to have the version of Lua required (the major version, like 5.1, 5.2, 5.3 etc).

The thing is, minor changes to (say) luasocket, luacom etc. are probably fixing bugs or introducing minor functionality. Like, the difference between Lua 5.1.3 and Lua 5.1.4. So you don't care about that too much.

However because of the internal changes to Lua, and the fact that Lua states are shared between modules, means Lua simply *won't run* unless you get the correct DLL linked in dynamically at runtime.

Think of it like the way many sites distribute cross-platform stuff (like Python for example). You might get:

python_installer.exe  --> Windows
python_installer.dmg  --> Mac OS/X
python_installer.tgz  --> Linux

Here the different file names indicate the operating system compatibility. Now you probably don't have them all downloaded onto one PC, but you might if you were making a disk to take from client to client, or maintaing a file mirror.

I'm not particularly keen on ugly version numbers everywhere, but I'm also not keen on the support nightmare of random crashes caused by by mismatched DLLs. By the way, fairly recently, Windows has introduced a \Windows\WinSxS (Side by Side) directory, into which are lots of cryptically-named directories (eg. x86_Microsoft.VC80.ATL_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_cbb27474). Inside those are copies of the DLLs required by various applications, where a particular version number is needed). The DLLs themselves aren't renamed, their parent directory (somehow) is used to match the DLL to the DLL that wants it. 

If Microsoft themselves are doing this, it seems to indicate they realise they have created a DLL monster and are trying to retro-fit some sort of fix. It also tends to suggest that just "packaging it all together" or "write a better installer" isn't going to work. After all, if anyone can do that sort of stuff (ie. writing installers), surely Microsoft's programmers could - after all they understand their own operating system.