Originally posted by Weasel
View Post
E.g since each library can be linked with any of the gazillion libc:s that exist in Windows (4 installed in Windows per default and then each version of VS introduces 4 new ones since VS7) and memory is allocated by libc they have a context switching facility in Windows so that when your function calls a DLL, Windows switches to the libc that this DLL is linked to.
So far so good, but let us now use something a little bit more complex, say that the shared library allocates memory (say for a url_encode() function or whatever) and you free that from your application, well then you have now freed memory that your libc never allocated and now you have made a complete mess of your applications free-memory tables. Which is why all libraries originating on Windows have a mylibrary_free() function so that Windows can do that little context switching bit.
Then we can go a little more advanced, let's say that the library implements some form of callback functionality, say like cURL for receiveing HTTP data or libexpat for decoding XML data. You call whatever function in the shared library that initiates the transfer or file decoding and Windows switches context, however when the library calls back to your code Windows does not switch context so any memory or object that you allocate in the callbacks in your own code is now allocated with the libc that the DLL happened to be linked with. So if that version or type of libc differs from the one you use then you again mess up your free-memory lists if you ever try to free that memory/object.
Originally posted by Weasel
View Post
And it also removes the problem on Windows where you can have a new version of libXX globally in system32 but since you have an old unpatched version in the same folder where your application is this old version is loaded instead.
Now there are benefits and drawbacks to each solution, it's just that Windows and Linux works in two completely different ways here.
Comment