OS/2 eZine - http://www.os2ezine.com
Spacer
16 December 2001
 
Robert Basler is the president of Aurora Systems, Inc. and a dedicated OS/2 user since he tired of rebooting Windows 3.1 twenty times a day.

If you have a comment about the content of this article, please feel free to vent in the OS/2 eZine discussion forums.

There is also a Printer Friendly version of this page.

Spacer
Previous Article
Home
Next Article


OS/2 Netlabs.  Open source software for OS/2.


A Cool OS/2 Feature: LIBPATHSTRICT

One of the new features being heavily promoted for Windows XP is the ability to load different versions of the same DLL into memory at the same time. Well little would you expect, but IBM has quietly added this feature to OS/2.

Operating systems use DLL's to save memory by sharing code between applications so up until recently, only a single instance of a DLL with any given name could be loaded at one time. The reason behind this new feature is to allow you to avoid "DLL-hell" where two programs require different versions of a DLL in order to operate. This isn't supposed to happen, DLL developers are supposed to make sure that new versions of DLL's are backwards compatible, but sometimes mistakes happen. It might even be the case that two programmers writing two different applications accidentally pick the same name for a DLL that is part of their program and is not meant to be used by other programs. However it happens, DLL versioning and name collisions are a big problem for operating systems which use shared libraries or DLL's.

To load a different version of a DLL into memory for a specific OS/2 program when one version of the DLL is already loaded, there are a couple of simple steps to follow. You might want to create an OS/2 .CMD file to automate this.

  1. Type the following SET statement in your OS/2 Window. Note that this does not work if you just add the SET statement to CONFIG.SYS:

    SET LIBPATHSTRICT=T

  2. Add a BEGINLIBPATH statement like below to add the directory containing the specific DLL you want the program to use to the beginning of your LIBPATH.

    SET BEGINLIBPATH=C:\MYAPP\DLLS

    Don't rely on having "." in your libpath, that doesn't guarantee the DLL will be loaded from the current directory. Use BEGINLIBPATH. Oh, and you can't use "." in BEGINLIBPATH either.

  3. Run your application. It will load the required DLL from C:\MYAPP\DLLS even if another DLL with the same name has been loaded by another process.

When you are done with LIBPATHSTRICT, you can go back to regular LIBPATH processing by typing:

SET LIBPATHSTRICT=F

Note that using SETLOCAL and ENDLOCAL seems to have no effect on LIBPATHSTRICT. If you want it off after your application ends, you have to set it back to F yourself.

This feature is included in FP15, eComStation Preview 1, and MCP (any kernel after September 1, 2000.) Thanks to Rich Walsh, William L. Hartzell and others for looking into the workings of LIBPATHSTRICT and passing on the details. You can read the complete discussion here. If you're a programmer, you can take advantage of this feature through DosSetExtLIBPATH('T', LIBPATHSTRICT).

Previous Article
Home
Next Article

Copyright (C) 2001. All Rights Reserved.