Announcement

Collapse
No announcement yet.

Very simple DLL question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Don Dickinson
    replied
    Michael,
    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.basicguru.com

    Leave a comment:


  • Michael Mattias
    replied
    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.
    MCM

    Leave a comment:


  • Clay Clear
    replied
    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]

    http://www.v3space.com/a/a39/202/

    Leave a comment:


  • Scott Turchin
    replied
    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

    Leave a comment:


  • Bruce Singleton
    replied
    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

    Bruce



    ------------------

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • Clay Clear
    replied
    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
    DLL's.




    ------------------
    Clay C. Clear

    [email protected]

    http://www.v3space.com/a/a39/202/

    Leave a comment:


  • Guest's Avatar
    Guest started a topic Very simple DLL question

    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\"

    DECLARE FUNCTION GetMyData LIB $PathSpec & "MYDLL.DLL" _
    ALIAS "GetMyData" (BYVAL x AS LONG) AS LONG

    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).]
Working...
X