Because most applications do not access the printer hardware directly
and instead use the Windows API to perform printer-related tasks, the
easiest way to determine programmatically if an application has
printer support is to check the applications import table for
printer-related API calls. The most obvious function to check for is
StartDoc, which is required for basic printing. StartDoc is exported
by gdi32.dll as StartDocA for standard applications and as StartDocW
for unicode applications.
Because many applications store their printer-related code in separate
DLLs you will need to write your own dependency walker in order to
locate all of the imports for a given application.
Writing a dependency walker is a fairly straightforward task. In
short, you examine the import tables of the application in question
and determine what other processes are linked. You then examine the
import tables of all of the processes you discovered in the first
import table. You do this recursively until you have discovered the
dependencies of all of the processes, or you have reached whatever
recursion depth you feel comfortable quitting at.
Parsing an executable's import table is a bit tricky, but fortunately
there are a fair number of source code examples available. The MSDN
provides a very thorough, easy to read example named YAHU that
supports practically every executable format you are likely to ever
encounter. (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarwbgen/html/msdn_exeform.asp)
The only limitation with this method is that you may occasionally get
"false positives" from a few types of applications. For example,
applications that embed Internet Explorer as a control will appear to
be able to print, because obviously Internet Explorer can. Truth be
told, functionally there is no reason why these applications could not
print; they simply do not present the option to the user. I am not
sure that there is a way to separate out these applications
programmatically with *any* method as, again, technically speaking
these apps could print if they really wanted to.
If you would like to manually review the import tables for the
applications you are thinking of processing programmatically to see if
this method will work for you, you can do so with a free application
by Steve Miller named Dependency Walker.
(http://www.dependencywalker.com/)
I hope this answers your question. If you need any further information
or specific details, do not hesitate to ask.
Good luck with your project!
Spot
"StartDoc", MSDN Library
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_95sz.asp
Extending Apihijack
http://www.codeguru.com/mfc/comments/28299.shtml
Wingdi.h
Microsoft VisualStudio Windows Header File
"YAHU, or Yet Another Header Utility", MSDN Library
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnarwbgen/html/msdn_exeform.asp
Dependency Walker
http://www.dependencywalker.com/
Search Strategy:
StartDoc import
://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=StartDoc+import
executable header utility import address source code
://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&q=executable+header+utility+import+address+source+code |
,
0 Comments
)