No announcement yet.

Very simple DLL question

  • Filter
  • Time
  • Show
Clear All
new posts

  • Very simple DLL question

    I just wrote my first small DLL, and it works, so far.

    But I have a question: Will Windows always find my .DLL file
    when a .DLL function is called, if it is in same directory as
    the .EXE that calls it? (Or what if it were in a different
    directory? Does that matter?)

    When I SHELL to another .EXE, I can use the PathSpec$ of the
    main .EXE, once it has been determined, in the SHELL
    command. (I'm using some code, thanx to Fred Oxenby, that he
    posted, slightly modified for getting PathSpec$) Yet I see no
    way to make sure Windows will "see" my .DLL. Is that a problem?

    I thought perhaps the precaution to take was to include a
    PathSpec$ (or $PathSpec constant) in the DECLARE for the .DLL
    function that is in the .EXE, such as:

    $PathSpec = "C:\PBDLL60\MYFILES\"


    However, I see that isn't allowed. (Compile error 429, "String
    constant expected"). Same problem, even if I use:

    $PathSpec = "C:\PBDLL60\MYFILES\MYDLL.DLL"

    So, does Windows simply look in the same directory as the .EXE
    for the .DLL file, at the time the .EXE is loaded? And if so,
    how does one call a .DLL that's NOT in the same directory?

    Dumb questions, from a raw rookie.


    [This message has been edited by Mike Jenkins (edited July 21, 2001).]

  • #2
    The safest bet is to put your DLL's in the Windows System directory.
    That's one of the default directories that Windows looks in for

    Clay C. Clear

    [email protected]


    • #3
      The best place to put your DLL is in the same directory as the EXE that calls it. That's the place that Windows looks first, so your program will load slightly faster, and there is no place that you can put a DLL that will "override" that location. For example, if you put a DLL in the Windows System directory, another copy of the DLL either 1) in the same dir as the EXE or 2) earlier in the "path" than the Windows System directory, will be found first and Windows will use that copy instead of the one in the System directory. Multiple copies of a DLL (the same file name, but different versions of the DLL) can create problems that are very difficult to troubleshoot.

      Placing DLLs in the System directory is also discouraged because it contributes to "DLL Hell". That's what happens when one program installs one version of a DLL in the System directory, then another program installs a different version and the first app stops working. (Or a completely different DLL that happens to have the same name... or lots of other nasty things that can happen.)

      On the other hand, if your DLL is used by many different programs, it makes a certain amount of sense to put it in the System directory so you don't have a dozen different copies all over your hard drive.

      Also, if I'm not mistaken, the most recent version(s) of Windows do not allow you to put DLLs in the System directory. (True?)

      -- Eric

      Perfect Sync Development Tools
      Perfect Sync Web Site
      Contact Us: mailto:[email protected][email protected]</A>

      [This message has been edited by Eric Pearson (edited July 21, 2001).]
      "Not my circus, not my monkeys."


      • #4
        Keeping the dll in the same director with the exe is, I believe,
        the recommended method. This makes maintenance and updates easy.

        My .02 cents




        • #5
          Try not ot put it in the system directory unless your program has special pathing needs (ie a console app that runs from anywhere and uses the DLL).
          No need to clutter up the system dir when it will be seen FIRST in your app, 2nd in teh system dir....

          Scott Turchin
          MCSE, MCP+I

          True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi


          • #6
            Thanks for your replies, folks! What you said makes a LOT of sense!
            I myself, run my apps straight out of the C:\PBDLL60\SAMPLES
            directory, which is in my DOS Path. So, I don't put my custom DLL's
            in the System directory. I agree with you folks, that you should
            only put the DLL's in the System directory if more than one app
            uses them, and the apps are in different directories.

            Clay C. Clear

            [email protected]



            • #7
              Just for reference, here is the search order as per the SDK:

              1. The directory from which the application loaded.
              2. The current directory.
              3. Windows 95: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
              Windows NT: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

              4.Windows NT only: The 16-bit Windows system directory. There is no Win32 function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.
              5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
              6. The directories that are listed in the PATH environment variable.

              Michael Mattias
              Tal Systems (retired)
              Port Washington WI USA
              [email protected]


              • #8
                Everything you quoted is correct, *except* it has been my experience that the winnt\system (16-bit system) is not automatically searched. I have run into some NT4 machines where it wasn't searched until I added the path to the Path environment variable. I don't know if this was non-standard behavior, but I have run across it on a couple different machines.

                Best Regards,

                Don Dickinson