To help with the migration of applications off of legacy operating systems (e.g. XP) I need to identify driver (sys) files on which an application relies in order to run. This needs to be done by inspecting an existing system with the application installed, without running the installer and without running the application.

Although not a perfect solution, an attempt has been made to identify out-of-box drivers (drivers added since installation of the operating system) since this will narrow the number of sys files to be considered. DISM API can return the Inbox status of a driver, but this requires Windows 7 and above.

So far a reliable solution has proved evasive on XP. It's possible that querying of NTFS timestamp metadata (e.g. Changed) will help identify sys files that have been added to the file system since the operating was installed. Even if successful, this only narrows the field of enquiry, it doesn't actually identify drivers on which an application depends.

I've asked a similar question here.

So, how to statically identify sys files on which an application depends?


This is a misconception: No program is "dependent" on .sys files or on drivers. It is only dependent on the operating-system, and the operating system uses whatever modules seem appropriate.

For example, if your program wants to print, it does not depend on the printer driver on the computer where it was developed. On another computer, with another operating system or another printer, another driver will be used.

On your other post, you were counseled to use the Dependency Walker, which will tell you which DLLs a program calls. On the target computer, you will need to assure yourself that some version of these DLLs is available.

Some DLLs, such as kernel32.dll are an integral part of Windows and will exist on any Windows version.

Other DLLs, pertaining for example to the .Net Framework or the C/C++ Runtime, may or may not be installed on the target computer, and you might also need the right version to be installed.

While .Net Framework is backward compatible, meaning that a higher version will work for a program compiled with a lower version, the C/C++ Runtime needs the exact version, so you may need to distribute the DLLs with your product.

There is a term created for this : DLL Hell, which is entirely appropriate. As a developer, you will need to test your distributed software on as many environments as possible to minimize this hell. But be assured that sooner or later you will encounter it.

  • 1
    By "depends" I didn't mean in the sense that Dependency Walker or other static analysis tools can discover e.g. by analysing import tables. I meant depends in the sense for an application to actually work. A license driver might be required for example. I actually feel I know the answer but was interested to find if anyone had an angle I hadn't thought of. I've edited the question slightly. – fractor Dec 7 '18 at 11:16
  • 1
    Been there, done that. If your program has pre-requisites, then they need to be installed, but this is done on a case-by-case basis. In some cases, Dependency Walker will tell you which DLLs are to be bundled with your product. In other cases, the pre-requisite product must be installed separately and might need a license, although many such distinguish between development and runtime licenses where the later are often free. If you are looking for a product that will do the grunt work for you, there is none. The subject is too vast to be centrally organized. – harrymc Dec 7 '18 at 11:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.