is on what is already owned and usually readily available, and most likely coincides with the system actually in use, IMHO.
1. When confronted with a DLL file problem, a copy of some Microsoft media may already be owned from which the file can be extracted, "Definition and Explanation of a .DLL file (Q87934)".
2. To determine whether the file is a Microsoft issue, access the "DLL Help Database", enter the file name -- including extension in the space provided, and then press Enter (correct spelling and punctuation is recommended). If a list is rendered, simply determine from what media is shown and that you currently have and extract a copy, "How to Extract Original Compressed Windows Files (Q129605)".
3. If the file cannot be determined from that site and you know your system requires it, it's usually advantageous to simple uninstall and reinstall the applicable program for which the file belongs. Search the "Google_Group" Web site for resources or ascertain from the vendor who released the program whether there was any mention of having to furnish a particular ".DLL" file from some other site before theirs work correctly.
4. By default and to enhance performance, Win98 will only look in the \Window\System directory for certain system DLLs if the applicable x.DLL name is listed in the following registry key regardless of whether the file is in fact present in the parent folder of the program being used and to correct this anomaly, either copy the applicable x.DLL file to the parent directory or remove the x.DLL name from the registry key that enables Windows to look elsewhere, [Q193067]:
a. The above scenario does not apply to executables filenames. The article [Q125410] explains that when you type only the program's executable, Win9x/ME searches the current folder, and then the folders on the path statement (Autoexec.bat file) for the executable's possible location. If the file is not found, you receive the following error message:
bad command or filename
b. The method that an app uses to search for other component files (such as DLLs) depends on the individual app and how the app references those DLLs. There are basically two methods to "bind" a DLL to an executable and many application use a combination of both methods:
? With compile-time binding, the references to any external modules (AKA "dependencies") are encoded into the executable file's header, and those modules are loaded either when the executable itself is loaded or when it calls a function that is located in one of those modules.
? With run-time binding, the application loads other modules explicitly, as it needs them.