WB DLL file placement

[rsunde]

There is some disagreement amongst my colleagues regarding the placement of the WinBatch DLL files - both the "main" DLL and the extender DLLs on end user machines.
Some advocate for placement of the DLLs in a folder specific to the app(s) that are using them.  Others prefer placing them in C:\Windows.

Does WWW have any recommendations and/or best practices regarding DLL placement on use machines?

Thanks.

[Deana]

If you compile with the "Complete EXEs for Standalone PCs" option, the "large EXE" will include "emergency" copies of all the DLL's you included within the EXE (that's what makes it "big" or "a large EXE"). When the EXE starts up, it scouts around looking for its DLL. If it cannot locate a copy either in the current directory or anywhere along the path or in the Windows directory then it unloads the emergency copy of the DLL and places it in the same directory as the EXE. If located on a fixed hard drive, it will make the DLLs in the same directory as the EXE. If executing on removable media (floppy, zip, jaz drives), it will create the DLLs in the Windows directory.

One cute trick is to compile the setup program with the BIGexe option, and have it create the required DLLs. Subsequent EXE's can all be compiled with the small option as the DLLs then exist. For Network installations we recommend the SMALLexe with copies of the required dlls in the same directory.

You have a couple of choices in terms of where to locate the DLLs:

1. Place a copy of the DLL in some directory that is on your path (windows directory?). The exe will use that copy instead of making a new one.

OR

2. Make a directory for the specific exe and place the dll in the same directory.

Personally I prefer to compile using a small exe and place the dll in the same directory and my exe.

[rsunde]

What we do is create small EXEs and then use a software distribution tool to store them on user machines.
The "dispute" was  - where to put the required DLLs - in C:\Windows  or, for example,  C:\scripts

Some prefer to keep C:\Windows as "clean" as possible, others are less concerned.

[td]

Putting your dlls in the Windows directory can lead to dll hell.  The best approach is to treat WinBatch compiled scripts like any other program and do a proper install by placing them in their own directory with their own copies of any extender dlls and the interpreter dll. Hard drive space is cheap.

[DAG_P6]

Putting your dlls in the Windows directory can lead to dll hell.  The best approach is to treat WinBatch compiled scripts like any other program and do a proper install by placing them in their own directory with their own copies of any extender dlls and the interpreter dll. Hard drive space is cheap.

Besides that, it mixes system and user code. Overall, I agree with Tony.

Nevertheless, I have recently arrived at a compromise. Most of the scripts that I use every day go into a single directory, C:\bin, and they share a set of DLLs. The handful of scripts that have lots of satellite files usually go into dedicated directories, and look to C:\bin, by way of the PATH, for all DLLs.

I took this approach because I grew tired of maintaining a myriad copies of DLLs, and keeping all of them in sync. I can get away with keeping them in sync because I studiously avoid breaking backward compatibility, the same way that IBM used to do so.

[td]

Nevertheless, I have recently arrived at a compromise. Most of the scripts that I use every day go into a single directory, C:\bin, and they share a set of DLLs. The handful of scripts that have lots of satellite files usually go into dedicated directories, and look to C:\bin, by way of the PATH, for all DLLs.

You might want to spend some time looking into how various Windows versions search for DLLs and how that search can be altered with system settings and/or by the application itself.  It is a security issue to such an extent that WinBatch has a modified dll search order to accommodate corporate users with security concerns.   

I took this approach because I grew tired of maintaining a myriad copies of DLLs, and keeping all of them in sync. I can get away with keeping them in sync because I studiously avoid breaking backward compatibility, the same way that IBM used to do so.

If compiled scripts are treated as applications and given a proper installation,  updates should be relatively straight forward. Also based on our user's experience, the issue often isn't backward compatibility but forward compatibility.  And backward compatibility can be illusive as applications become more complex.  WinBatch has needed modification more than once because of supposedly backward compatible MSFT system dlls.

I stated my point too hurriedly and not clearly.  If you think about how WinBatch is installed, it has multiple executables sharing common dlls.   Those common dlls are all stored in a single directory under the application's top directory.  So it would be hypocritical to  advocate that a copy of each dependent dll be installed with each compiled executable.  Rather I was attempting to advocate properly installing one or more logically connected executables as a product with their own copy of dependent dlls as apposed to expecting every compiled script on the system to share the same dlls.

[galaara98]

I want to expand on this conversation with a need of my own.

is it possible to separate a Compiled "Small" Winbatch exe, from its Primary DLL "wb___44l.dll" and not have the Primary DLL in the path

example
can I have teach the exe to find the dll somehow, in the following setup

Path=standard windows stuff
exe=C:\program Files\my company\my product\zzz.exe
dlls (including primary and extenders) located in C:\program files\my company\my product\lib

the extenders work just fine there - addextender(lib\extender.dll')

but how can I get the exe to look there for the WB____.dll (or is this not possible)

===
The PURPOSE is to clean up the directory that is home to a very complicated application I wrote that uses many extenders, different bitness threads (calls to other winbatch exes), etc.  the main folders was getting cluttered, so I put all my images in a folder, all my inis in anther, and would like to put all my dlls in another.

Aaron

[Deana]

Sorry no you need some way to tell the Exe where to look. It automatically uses the dll in the same directory as the exe. if its not there then it will search the System PATH. So if you must place the dll separately then you will need to add that directory to the PATH.

[td]

Theoretically, a subkey under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths or  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths could be set to the location of WB whaterver interpreter dll for each compiled script.  This should work as long as the compiled script was started from the Windows shell because the shell prepends the registered path to the process's PATH environment at startup.  You would need to create a subkey under App Path called the compiled script's file name (file.exe) and a value under the subkey called Path which  contains your dll location. 

There are several pitfalls with this approach and I haven't tried to solve this particular problem using the technique.

[td]

Should have posted this earlier but here is the link to MSFT's App Paths documentation.

http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx