Wednesday, November 18, 2015

x64, Dynamic Link Libraries and confusion.

Still ranting about AppV.  So all three readers plus the mysterious bot from russia that reads this, get ready for more.

Everybody knows what a dynamic link library is don't they?  They were originally designed in the good old day when memory was expensive and mutlitasking was cool.  Now Multitasking is old hat and memory is cheap, dlls are kept around because their content is useful.  They are a useful container to pile in libraries of compiled code and a whole bunch of resources your program might use.

This works great provided there is no incompatibilities between this dll and that one.  And of course, for a variety of good reasons (and some really bad ones)  this doesn't happen.  This means that although you may have a library of the same name, with the same public hooks, and a later version, you may end up with different results.  Bad.  So how do we sort this out?

In comes the .local file.  Create an empty file called blah.exe.local in a given directory and it will use the dlls it finds in the same directory as the executable first.  Then it will hunt through the system.

Other cool things you can do is create a directory called blah.exe.local and pile the dlls in there.  This has the benefit of differentiating two executables in the same directory.

So, wasn't AppV going to deliver us from dll hell by sandboxing everything?  It tried.  But fortunately this trick works inside an AppV sandbox as well.  Hooray.

And what are other solutions?

Unix as a general rule includes the version number in the file name for libraries.  This means the executable will only associate with an appropriate version.  You can have as many versions as you like in a shared directory and everyone gets what they need.

Problem solved.  The problem is solved.  We solved the problem so everything is awesome.  Problem solved...

But wait.  There's more.

Along comes x64 libraries designed to run x 64 code on x 64 chips which is back compatible with x86 (or 32 bit) code.  This might mean that there are now 4 locations that the dll might be.

  • The current working directory
  • C:\windows\System
  • C:\windows\System32
  • C:\windows\SysWOW64
Where should they go?  Just to be confusing, x86 legacy code can try to look for dlls in System32 despite the fact that this is the directory for x64 dlls.  They should use SysWOW64 as their first location to look.  They don't.  

So use your .local files wisely people as this will make life happier.  Otherwise, inside your AppV sandbox, scatter your dlls everywhere.  It is messy, but it works.  And odds are nobody will look inside to complain about it.

No comments: