How to Write a Windows Service (native)

[Mike C#]

Anyone know of any good articles on how to write a windows service in native
(unmanaged) VC++? Also, how to use IPC in the service to communicate with a
front-end GUI application would be helpful... Thanks!

 

[Carl Daniel [VC++ MVP]]

Anyone know of any good articles on how to write a windows service in
native (unmanaged) VC++? Also, how to use IPC in the service to
communicate with a front-end GUI application would be helpful... Thanks!

I'd start with the Windows SDK samples.

For IPC with the front-end GUI, I'd probably use COM (have the service
register an object in the running objects table - note that I haven't tried
that, but that's where I'd start out).

-cd

 

[Mike C#]

I'd start with the Windows SDK samples.

I'm going through them now, but was sort of hoping there might be some good
tutorials to better explain what I'm looking at out there

For IPC with the front-end GUI, I'd probably use COM (have the service
register an object in the running objects table - note that I haven't
tried that, but that's where I'd start out).

I was afraid you might say that I really wanted to avoid COM if
possible, but it looks like I might be stuck like Chuck on this one...
Thanks!

 

[Steve Alpert]

Anyone know of any good articles on how to write a windows service in native
(unmanaged) VC++? Also, how to use IPC in the service to communicate with a
front-end GUI application would be helpful... Thanks!

ATL is pretty good at doing most of the heavy lifting for a windows service.

/steveA

 

[William DePalo [MVP VC++]]

Anyone know of any good articles on how to write a windows service in
native (unmanaged) VC++? Also, how to use IPC in the service to
communicate with a front-end GUI application would be helpful... Thanks!

I agree with Carl. You'll find a barebones service in the

Samples\winbase\Service

directory of the Platform SDL installation.

Just by the way, it demonstrates using named pipes to communicate from
client to server. I like that option because it is simple, reasonably fast,
securable, impersonable and message rather than stream oriented.

RPC is a nice option as well, but there are more moving parts.

If you need to be able to scale, this (non-service) sample shows how to
perform overlapped I/O operations on a pipe:

http://windowssdk.msdn.microsoft.com/en-us/library/ms690564(VS.80).aspx

and this one shows to create a thread to handle each client:

http://windowssdk.msdn.microsoft.com/en-us/library/aa365588(VS.80).aspx

Regards,
Will

 

[Bruno van Dooren [MVP VC++]]

I'd start with the Windows SDK samples.

I'm going through them now, but was sort of hoping there might be some
good tutorials to better explain what I'm looking at out there

The SDK sample is pretty simple and should get you started for simple
services (1 service per process).
COM for the front end is possible, but another option would be to use named
pipes for example.

If your service has to communicate with clients on remote computers, plain
old TCP sockets are a good solution as well.
I have done that for a customer who needed a windows service on the windows
machine and a unix app on an old HP workstation.
If that sort of compatibility is needed, TCP sockets are basically your only
option.

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"

 

[Mike C#]

I agree with Carl. You'll find a barebones service in the

Samples\winbase\Service

directory of the Platform SDL installation.

Just by the way, it demonstrates using named pipes to communicate from
client to server. I like that option because it is simple, reasonably
fast, securable, impersonable and message rather than stream oriented.

Thanks for the info. After a little more investigation it looks like it
might not even be that easy It looks like they want the front end for
this service to be a web page. I'm thinking the path of least resistance
will be to have the service just write to an XML file and use AJAX to
dynamically update the page with the contents of the XML file. Anyone else
done anything like this (use a web browser as a front end for a web
service?) As always any hints, tips or suggestions are appreciated!

Thanks

 

[William DePalo [MVP VC++]]

Thanks for the info.

You are welcome.

After a little more investigation it looks like it might not even be that
easy

Ah, the real world can be so ugly.

It looks like they want the front end for this service to be a web page.
I'm thinking the path of least resistance will be to have the service just
write to an XML file and use AJAX to dynamically update the page with the
contents of the XML file. Anyone else done anything like this (use a web
browser as a front end for a web service?) As always any hints, tips or
suggestions are appreciated!

On a project that was started while .Net was still in beta I did something
similar. I built an ISAPI extension which fielded requests from the browser.
It took the request, mapped it into a datagram and sent it through a pipe to
a service which knew nothing of either HTTP or HTML.

It was _very_ fast but a _lot_ of work. Except in an environment where
scalability is of prime importance that's not likely to be a good choice
these days.

These days, you are much likely to see something done with ASP.NET. This
page has a link to a quick start on web services

http://samples.gotdotnet.com/quickstart/aspplus/doc/

and this one has an interesting video on what they call a "zero code DAL":

http://www.codeplex.com/Wiki/View.aspx?ProjectName=actionpack

(If like me, you've never run across that buzz phrase before it is a web
based, data access layer which requires no code. Or so they say <g>.)

Regards,
Will

 

[Mike C#]

On a project that was started while .Net was still in beta I did something
similar. I built an ISAPI extension which fielded requests from the
browser. It took the request, mapped it into a datagram and sent it
through a pipe to a service which knew nothing of either HTTP or HTML.

That sounds interesting, but I'm on a tight deadline and don't have too much
time to experiment with building server extensions, etc.

It was _very_ fast but a _lot_ of work. Except in an environment where
scalability is of prime importance that's not likely to be a good choice
these days.

Scalability isn't important to this app, since it will be running on a small
local network with only a few users at a time will be using it.

These days, you are much likely to see something done with ASP.NET. This
page has a link to a quick start on web services

Ahh if .NET were an option this would all already be done Unfortunately
..NET is not an option at this time

http://samples.gotdotnet.com/quickstart/aspplus/doc/

and this one has an interesting video on what they call a "zero code DAL":

http://www.codeplex.com/Wiki/View.aspx?ProjectName=actionpack

(If like me, you've never run across that buzz phrase before it is a web
based, data access layer which requires no code. Or so they say <g>.)

I'll check into it. Thanks!