I spent some time playing around with this sample:
http://www.codeguru.com/cpp/w-p/printing/article.php/c5893/#more but
have stumbled across some issues.
It is an old sample, based on the NT4 DDK. As such, there isn’t a
separate UI DLL.
Have I understood it correctly, that I will never see any messageboxes
shown by this sample? They all turn up in the main console session?
(which I guess isn’t the one I’m using under Vista, at least not as
long as fast user switching is enabled)
In that case, is a separate UI DLL the only way I can have any user
interaction? It seems a bit much to have a separate UI DLL just to
inform the user that he has successfully removed the port or that
“there is nothing to configure here, walk away”.
Any other known pitfalls I should be aware of before proceeding with
this old NT4 based port monitor? I’ve already modified the makefile
and sources so that I can build both amd64 and x86 versions of this
port monitor.
–
Rune
The print monitor stuff was updated in Win2000 (and back ported to NT4
SP6). So you should probably implement the new features.
Checkout the DDK! It even includes samples for print monitors.
Especially look out for:
InitializePrintMonitorUI (MONITORUI)
InitializePrintMonitor2 (MONITOR2)
It is ok to have the same DLL for both the server and UI parts. (depends
on what you export)
You might also be interested in “SplPromptUIInUsersSession” if you want
to notify the printing user of anything.
You can find information for some nasty pitfalls here:
http://www.undocprint.org/winspool/print_monitors
Btw: Did I tell you to checkout the DDK…
/Christoph
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rune Moberg
Sent: Friday, January 04, 2008 2:32 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] UI in port monitor
I spent some time playing around with this sample:
http://www.codeguru.com/cpp/w-p/printing/article.php/c5893/#mo
re but have stumbled across some issues.
It is an old sample, based on the NT4 DDK. As such, there
isn’t a separate UI DLL.
Have I understood it correctly, that I will never see any
messageboxes shown by this sample? They all turn up in the
main console session?
(which I guess isn’t the one I’m using under Vista, at least
not as long as fast user switching is enabled)
In that case, is a separate UI DLL the only way I can have
any user interaction? It seems a bit much to have a separate
UI DLL just to inform the user that he has successfully
removed the port or that “there is nothing to configure here,
walk away”.
Any other known pitfalls I should be aware of before
proceeding with this old NT4 based port monitor? I’ve already
modified the makefile and sources so that I can build both
amd64 and x86 versions of this port monitor.
–
Rune
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
On Jan 4, 2008 3:02 PM, Christoph Lindemann
wrote:
> Btw: Did I tell you to checkout the DDK…
Yes… The thing is… As the guy said on the webpage I mentioned, the
WDK sample is overkill. There’s a lot of stuff to rip out. I had hoped
that his approach was reasonably safe. All I want to do is spawn an
executable at the end of the print job (and either pipe the output or
supply a file name). I guess there is no such thing as a free lunch.
(I spent too much time getting that old sample to even build!)
I’ll check out the link you posted. Thanks very much.
–
Rune
Not sure it matters to anyone else, but I suspect you’re ignoring some scenarios in your considerations here. To wit:
When I’m printing to a print server a couple of miles away and it has your port monitor on it, where do you expect me to see or interact with the UI you intend to display?
One of the reasons the architecture and the related samples have all “that complicated BS you can just throw away” is due to things like that (and that’s one of the reasons for decoupling UI components- you can then remote them and display on the client without remoting the business end and potentially doing absurd unwanted things to the client’s machine).
Having worked in both, one of the things I like about working in the kernel and with WDM is that it’s a lot easier than printing (and I’m sure other’s opinions vary on these subjects).
On Jan 4, 2008 3:41 PM, wrote:
> Not sure it matters to anyone else, but I suspect you’re ignoring some scenarios in your considerations here. To wit:
>
> When I’m printing to a print server a couple of miles away and it has your port monitor on it, where do you expect me to see or interact with the UI you intend to display?
It is a question I’ve been keeping in mind from the beginning.
What I’m building is a bitmap printer. Eventually I’ll inject code to
spit out .tiff or .png instead, but for now I’m using an unmodified
version of the bitmap printer driver (printer\oemdll\bitmap) with my
own custom port monitor at the end.
The output is to be directed towards our application and our
application only. As such, it makes little or absolutely no sense to
install this printer driver on a print server. It will be installed
locally in parallell with our application frontend.
The next scenario involves terminal server. The users will run our
application remotely, and… Hmm, yes. Hopefully not all that
different from what I currently see with plain Windows. Terminal
Server is my first important test platform, so I will have to make
sure it works there.
–
Rune
On Jan 4, 2008 3:02 PM, Christoph Lindemann
wrote:
> Checkout the DDK! It even includes samples for print monitors.
>
> Especially look out for:
> InitializePrintMonitorUI (MONITORUI)
> InitializePrintMonitor2 (MONITOR2)
I gave it some more thought.
The MonitorUI stuff triggers when the user is adding, configuring or
deleting a port.
I need FILE: like behaviour. Actually I don’t need any UI, I need to
access HKCU belonging to the user who triggered the print job.
Unfortunately, the DDK contains source for the regular port monitor,
but it does not implement the FILE: port.
The RevertToPrinterSelf() doc entry gives me the impression that I’m
already running in the context of the user who submitted the print job
(unless I excplicitly call RevertToPrinterSelf()), but a quick test
reveals that %TEMP% points to the system temp directory, and that is
not quite what I expected if my monitor runs as me…
–
Rune
You could try dumping the thread token, to see who/if the thread is
currently impersonating.
You might need to load the registry hive of the user manually before you
can access it.
/christoph
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Rune Moberg
Sent: Tuesday, January 08, 2008 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UI in port monitor
On Jan 4, 2008 3:02 PM, Christoph Lindemann
wrote:
> > Checkout the DDK! It even includes samples for print monitors.
> >
> > Especially look out for:
> > InitializePrintMonitorUI (MONITORUI)
> > InitializePrintMonitor2 (MONITOR2)
>
> I gave it some more thought.
>
> The MonitorUI stuff triggers when the user is adding,
> configuring or deleting a port.
>
> I need FILE: like behaviour. Actually I don’t need any UI, I
> need to access HKCU belonging to the user who triggered the print job.
> Unfortunately, the DDK contains source for the regular port
> monitor, but it does not implement the FILE: port.
>
> The RevertToPrinterSelf() doc entry gives me the impression
> that I’m already running in the context of the user who
> submitted the print job (unless I excplicitly call
> RevertToPrinterSelf()), but a quick test reveals that %TEMP%
> points to the system temp directory, and that is not quite
> what I expected if my monitor runs as me…
>
> –
> Rune
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
On Jan 8, 2008 12:09 PM, Christoph Lindemann
wrote:
> You could try dumping the thread token, to see who/if the thread is
> currently impersonating.
>
> You might need to load the registry hive of the user manually before you
> can access it.
Thanks again Christoph,
Turns out it was already done for me. HKCU is good to go.
However, I’m running in a different session. (session id 0)
I tried the following to spawn a process on the current user’s desktop:
// at one point I ran amock with access masks (TOKEN_QUERY sufficient?)
if (OpenThreadToken(GetCurrentThread(), TOKEN_QUERY | TOKEN_DUPLICATE
| TOKEN_ASSIGN_PRIMARY | TOKEN_IMPERSONATE, FALSE, &hToken))
{
HANDLE hDupToken;
if (DuplicateTokenEx(hToken, TOKEN_QUERY | TOKEN_DUPLICATE |
TOKEN_ASSIGN_PRIMARY | TOKEN_IMPERSONATE, NULL, SecurityImpersonation,
TokenPrimary, &hDupToken))
{
PROCESS_INFORMATION pi;
if (CreateProcessWithTokenW(hDupToken, LOGON_WITH_PROFILE,
_T(“C:\svn\source\test.exe”), NULL, 0, NULL, NULL, NULL, &pi))
{
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
}
}
}
CreateProcessWithTokenW returns a big fat error 5 (Access denied). Do
I need to supply the window station name in the STARTUPINFO struct
(that I currently do not use)? Or did I miss a step in setting up the
token?
(ShellExecute on the same executable works, except it pops up in session 0)
–
Rune