How to statically identify sys files on which an application depends?
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?
windows-xp drivers
asked Dec 7 at 10:16
fractor
1215
add a comment |
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?
windows-xp drivers
asked Dec 7 at 10:16
fractor
1215
add a comment |
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?
windows-xp drivers
asked Dec 7 at 10:16
fractor
1215
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?
windows-xp drivers
windows-xp drivers
asked Dec 7 at 10:16
fractor
1215
asked Dec 7 at 10:16
fractor
1215
edited Dec 7 at 11:17
asked Dec 7 at 10:16
fractor
1215
asked Dec 7 at 10:16
fractor
1215
asked Dec 7 at 10:16
fractor
1215
1215
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Dec 7 at 11:09
harrymc
253k12259562
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 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 at 11:24
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1381595%2fhow-to-statically-identify-sys-files-on-which-an-application-depends%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Dec 7 at 11:09
harrymc
253k12259562
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 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 at 11:24
add a comment |
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.
answered Dec 7 at 11:09
harrymc
253k12259562
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 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 at 11:24
add a comment |
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.
answered Dec 7 at 11:09
harrymc
253k12259562
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.
answered Dec 7 at 11:09
harrymc
253k12259562
answered Dec 7 at 11:09
harrymc
253k12259562
answered Dec 7 at 11:09
harrymc
253k12259562
answered Dec 7 at 11:09
harrymc
253k12259562
253k12259562
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 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 at 11:24
add a comment |
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 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 at 11:24
1
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 at 11:16
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 at 11:16
1
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 at 11:24
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 at 11:24
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1381595%2fhow-to-statically-identify-sys-files-on-which-an-application-depends%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
