It has been a while since I have done any serious service work, so I
checked with my friend who knows a lot in this area.
Here are his notes:
***** Snip
Here it goes in a fairly short version.
a) Services generally run in a different window station than the
interactive desktop and therefore cannot produce any GUI that is visible
or accept any input (like keyboard, mouse, etc.). If a service needs
some interaction then you can configure it to run in the interactive
window station (WinSta0), but you MUST be aware of some problems with
doing that. Some of them are as follows:
a1. The global atom table in WinSta0 gets re-initialized when users log
off and back on. This causes all sorts of problems for services that
rely on this information staying stable. An example is using named
pipes. If you use named pipes and the global atom table gets
re-initialized you will die a horrible death!
a2. If you run in WinSta0 you will only have Local System permissions
because you cannot specify the user account to run the service under.
This is great on the local machine, but you get NULL permissions when
dealing with remote machines.
a3. I know there are a lot more, but I haven’t worked on a service in a
while and just can’t think of the other issues.
This doesn’t mean that your service should not be designed this way. It
just means that you should keep all of this in mind and only put GUI in
your service if the service will work with these limitations.
BTW: You can still pop up message boxes from services running in
non-interactive window stations by or’ing the MB_SERVICE_NOTIFICATION
flag with your MB_OK (or whatever other flags you specify).
b) Microsoft has fixed the show stoppers for using MFC in your
services. However, I would highly recommend installing at least SP3 of
Visual Studio. Prior to that you would get all kind of exceptions being
thrown when they would dereference your CWinApp object (which you don’t
have!). Unhandled exceptions are really bad in services because you
never see them and can never dismiss them.
Here are some additional tips that might make your life easier (since
you are already familiar with SoftIce). If you are writing a C or C++
service, put ALL of you code in a separate DLL and the only code you
would put in the service exe would be the interface functions to the
SCM. Have them do nothing more than calling into the DLL to do the
work. This makes debugging the service much easier because it doesn’t
start as a standard process. Instead it is started by the SCM, which
means that you can’t run it directly from the debugger. By putting the
main code in a DLL you can load the DLL into SoftIce (using IcePack if
you need to test it at boot time) and then set your breakpoints and tell
the SCM to start the service. You will thank me later for this one!!!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Tuesday, July 29, 2003 11:54 AM
To: Windows System Software Developers Interest List
Subject: [ntdev] RE: ShellExecute from a Windows ser vice
And for God’s sake, do not use MFC in the service!
Why not? CString and such can be used in service without any problems,
so is
MFC’s COM/OA support (which is long ago superceded with ATL).
I only remember that there were problems in the service (and in any code
starting with main() and not WinMain) with MFC’s resource access stuff.
I mean
the resources in the binary’s .rsrc sections like string tables.
To bypass it, I used some hack to call some MFC stuff explicitly which
is
usually called implicitly, and for now, I do not remember what it was -
AfxSetResourceHandle or something like.
Max
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com