What is wrong with the PATH environment variable? He stated that he did not want to use LoadLibrary and using the PATH variable is the right way to go. It works under both Windows 9x and NT/2000.

BTW The delayed loading feature is REALLY nice for creating 9x/2000 programs that require different underlying DLLs.

Dire

Yes..the environment path is nice.. but how do I add the path in within the program??

As far as I know, The "set" command is accessed by command prompts.

Do I have to use WinExec or maybe make a dos script??

Thanks for all the answers..

..

make a batch file and call it using WinExec? that''d work, right?

If I may ask a question about WinExec...I made a playlist manager for Winamp, and when I use WinExec to run Winamp, I get the hourglass cursor and my program stops receiving messages for an irritating 2-3 seconds (still unresponsive after winamp has already loaded and gone idle). Why is that? Shouldn''t WinExec return before that?

-J

I have heard if you find a error in a dll you can fix it. by just editing the dll and distributing it. So if I were you I'd go with dlls but keep it low. It well be easier to fix errors this way after you distribute the game or maybe have a look at COM.

Edited by - ARCHIGAMER on 4/19/00 6:35:28 AM

There seem to be a lot of conflicting terms here...so I'll try to clarify the different types of libraries you can use and the situations in which you can use them. (Someone let me know if I'm wrong here.)

1) Static Library (.LIB) - Just a lib that basically gets compiled right into your program code. You cannot replace this without re-compiling your executable (obviously). However, versioning is never a problem for the end user of your executable.

2) Dynamic Library (.DLL) - This one can be loaded and unloaded dynamically, that is, at run-time. You can freely update this file, as long as the names of the functions remain the same. No static linking is required, but you must use LoadLibrary and GetProcAddress to call functions, and you must export C code.

3) Shared Library (.LIB and .DLL) - This is a mix between the first two, that inherits some properties of both. First, the project is created as a .DLL, but functions and classes may be exported. You must re-compile your executable if the .LIB file changes between builds of the .DLL file.

Static libraries are definitely the easiest for small projects where the code will only be used once. DLLs are better for maintenance, but you must be careful not to change the function names. Shared libraries are very tricky to distribute, as they must be bug-free in the release build (the build that will be distributed), or else you force the .LIB's users to re-compile every time you squash a bug in the .DLL. The only library type that does not require a header file (to use the code, that is) is the dynamic library.

Second comparison is the code size that several programs will take up on the end user's hard drive. With a static library, a copy of the library is found in each executable that uses it, so if you have 20 programs installed using your static lib, and your static lib is 350 KB, you now have approximately 7 MB being taken up by your lib. With a dynamic library, this is never a problem. The DLL is stored (typically) in the Windows or Windows\System directory, and then loaded by each program, while Windows keeps one copy of the code in memory (basically). Same thing with shared libraries, except you've got the versioning problem. So, for the last two types, with 20 programs and a DLL size of 350 KB, you use only approximately 350 KB on the end user's hard disk.

Third comparison is what you can export from the libraries. Static libraries can export classes, no problem. Dynamic libraries can only officially export C functions, but that can be easily worked-around. Shared libraries export classes just as easily as static libraries.

To do classes with a dynamic library, you use an abstract base class in the executable (the abstract class takes up almost no code because of pure virtual functions). Then, take the .h for that abstract base class and use it in the dynamic library's project, deriving your own class from it. Simply build a single C function that gets a pointer to the class from the DLL, and you can use that function from the executable to get a pointer to the class located in the DLL. Simply LoadLibrary and GetProcAddress to get the address of that C function, then call it to get the pointer to the interface. Voila! virtual functions are now the link between your executable and the code in the DLL.

Fourth comparison is updating files. With the static lib, you must update the whole executable (unless you have some sort of patching utility). With the dynamic lib, simply copy and paste the new DLL files on the old ones, and the executable will work. With shared libs, you must update the shared file, but make sure that the .LIB didn't change between builds.


- null_pointer
Sabre Multimedia


Edited by - null_pointer on 4/19/00 8:29:45 AM

quote: With a dynamic library, this is never a problem. The DLL is stored (typically) in the Windows or Windows\System directory, and then loaded by each program, while Windows keeps one copy of the code in memory (basically).

Umm? Ew! DLLs should never be put in any of the windows directories. Even things like MFC.

If you write your own DLLs, put them in the same directory as the executable, or in a subdirectory.

Windows will search for DLLs by doing this:
-Is it in the current directory?
-Is it in the windows directories (windows, windows\system, windows\system32?
-Is it somewhere else in the path?

The current directory might not be the same place as the executable - this can happen if you set up a shortcut, and don''t fill in the "start in" field.

Putting dlls in the windows directories, or modifying the DOS path, is against the rules (even if you''re allowed to do it). It can cause so many horrible, evil problems that to suggest doing so makes me feel ill.

If you want to put DLLs somewhere, create a registry entry which says where such things are . This is the same for a single product as it is for multiple products using shared dlls.

On a slightly less nasty point, null_pointer - .lib and .dll files are shared libraries - a shared library isn''t some special form of a .lib or .dll.

Shared library is just a term used to describe the fact that .libs and .dlls provide ways to share your code/resource libraries.

TheTwistedOne
http://www.angrycake.com

Hi all.

NullPointer

quote: Fourth comparison is updating files. With the static lib, you must update the whole executable (unless you have some sort of patching utility). With the dynamic lib, simply copy and paste the new DLL files on the old ones, and the executable will work. With shared libs, you must update the shared file, but make sure that the .LIB didn''t change between builds.

Well, while developing a DLL I made a Test.exe which simply calls a function In that DLL called "SelfTest", so I did not have to go back and forth testing the DLL, which was statically linked to the exe (or in NullPointer''s terminology "LIB/DLL"). So with DLLs you never have to recompile the executables using them.

TwistedOne, just a correction for your post, Windows also searches the directory from which the application was started (which, as you correctly stated, may be diferent than he current directory).

I also agree with the person who recomended not to put files in windows directories or change system settings like the path, but a good idea would be to create a directory, put DLLs there, then put your applicatinos in separate subdirectories inside this directory, then open the DLLs with "..\TheDLL.dll". (But as with the registry technique, you will not be able to statically link, as Windows does not search in the parent directory, that''s why I said it is good to specify a particular path for the DLLs.)

Plase correct me if I am wrong,
Topgoro

"So with DLLs you never have to recompile the executables using them."

If the DLL is statically linked, then you will only have to recompile it IF the exports change. Try changing the parameters or the name of the exported function in your testDll, or adding new ones. You will have recompile the client exe since the DLLs .lib file would have changed.

If the DLL is loaded at runtime, then you dont ever have to recompile the client.

Umm? Ew! DLLs should never be put in any of the windows directories. Even things like MFC.

You're quite mad, you know that? Looking in WinNT/System32, I find 10MB of readily identifiable MFC DLLs.

Given the great number of MFC based applications, that would be potentially an extra 10MB per application if they stored their MFC DLLs in the same directory. It's more than likely you'll have numerous applications, too (Visual C++, WordPad, Word, almost any C++ GUI application, regardless of author...).

Putting dlls in the windows directories, or modifying the DOS path, is against the rules (even if you're allowed to do it).

No, it's not. You are supposed to put DLLs in the %SystemRoot%/System(32) directory if they are shared by more than one application. If only one uses it, then put it either with your application, or with Windows.

If it's shared, then you are supposed to place it in a location on the path...and the system directory is a guaranteed location. Otherwise you are taking up space on an end users hard drive for no valid reason.

However, I agree in that changing the system path is a bit of a faux pas; don't do it unless you have very good reason to do so, such as a development need (Java, CORBA, Delphi, etc.). Games do not qualify as a "very good reason".

It can cause so many horrible, evil problems that to suggest doing so makes me feel ill.

No, it wont. The mere presence of a file is inconsequential. DirectX and OpenGL are in the system directory, and there aren't any problems with those (the only problems are at the driver and application levels, not the library level).

If you're concerned about the versioning aspect of shared libraries, do what MFC does, and include the versioning info in the filename itself (this is akin to COM versioning).

All in all, I suggest everyone pick up a book on getting your applications certified for Windows (i.e., logo certification). It details the requirements of all applications that are released for Windows (not a strict rule, only one that you follow if you want to put the official "Windows Compatible" logo on your product).

P.S. - Delay loading rocks! =)

-------------------
Revolver, aka Brian Smith
MIS Programmer Analyst
brian.smith@realpage.com
RealPage >> www.realpage.com

My views aren't even mine, much less my employers. =)

Edited by - revolver on 4/19/00 11:27:17 AM