NT Service, WinSock

NT Service, WinSock

[Peter Hend�n]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

I am doing an overhaul of a Windows NT service. It is
currently done in C++. I now have a (very tight) time
window to convince the powers that be to let me rewrite
this in Ada (I did the original C++ implementation). What
I would like some help with is how to implement an NT
service (the service module handler stuff) - sample/boilerplate
code would be enormously appreciated as I'm serioulsy
pressed for time. Also: what sockets bindings exist, and
what are their merits?

Regards,
Peter Hend�n

Re: NT Service, WinSock

[Ted Dennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]

In article <8t8u9l$4ru$1@zingo.tninet.se>,
  "Peter Hend�n" <phenden@tdab.com> wrote:
> I am doing an overhaul of a Windows NT service. It is
> currently done in C++. I now have a (very tight) time
> window to convince the powers that be to let me rewrite
> this in Ada (I did the original C++ implementation). What
> I would like some help with is how to implement an NT
> service (the service module handler stuff) - sample/boilerplate

Hmmm. There's a nice little discussion of that on the MDSN disk that
should have come with your C++ compiler: "Design a Windows NT Serice..."
in Periodicals 1997. It looks pretty simple. You just need to create a
ServiceMain and Handler routine (with the proper parameter profiles of
course) for each service in your program. If your executable is listed
in the registry as containing a service, the OS calls your main
procedure at startup to perform initialization. As part of that
initialization your main procedure builds a LPSERVICE_TABLE_ENTRY array
containing the name and ServiceMain address for each service in the
executable. You then pass that to StartServiceCtrlDispatcher (You have
to do this within 2 minutes, or the OS will kill your process).

The OS then creates a thread for each ServiceMain (and they all call
their respective ServiceMain's). ServiceMain's should probably implement
a "loop forever" or start a task or something. If you return from
ServiceMain, NT assumes your service stopped, and removes it from the
list of running services.

Similarly, each ServiceMain needs to call RegisterServiceCtrlHandler
with the address of its Handler routine. The Handler routine will get
called (from within the context of the main thread) whenever the OS or
user wants to change the status (eg: start or stop) of your service.

There's also a SetServiceStatus that you need to call to tell Windows
what types of control message you a prepared to handle.

There's actually a large amount of discussion in there about how you
need to communicate between the Handler routine in the main thread and
your ServiceMain's thread. Apparently its enough of a pain that a lot of
folks take the sloppy way out (killing the thread, which can cause
resource leaks if the SCM restarts it before the process exits). I think
there's a place where Ada's task synchronization support really could
help out. However, I'm not sure how your Ada compiler would handle calls
to protected type routines from different threads that weren't created
as Ada tasks.

I know I wrote a lot above. But it really doesn't look too complicated
at all; at least not for someone who has managed to figure out COM, or X
or Windows GUI programming.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: NT Service, WinSock

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

In article <8t9lbu$ml1$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> writes:
> In article <8t8u9l$4ru$1@zingo.tninet.se>,
>   "Peter Hend�n" <phenden@tdab.com> wrote:
>> I am doing an overhaul of a Windows NT service. It is
>> currently done in C++. I now have a (very tight) time
>> window to convince the powers that be to let me rewrite
>> this in Ada (I did the original C++ implementation). What
>> I would like some help with is how to implement an NT
>> service (the service module handler stuff) - sample/boilerplate
> 
> Hmmm. There's a nice little discussion of that on the MDSN disk that
> should have come with your C++ compiler: "Design a Windows NT Serice..."
> in Periodicals 1997. It looks pretty simple. You just need to create a
> ServiceMain and Handler routine (with the proper parameter profiles of
> course) for each service in your program. If your executable is listed
> in the registry as containing a service, the OS calls your main
> procedure at startup to perform initialization. As part of that
> initialization your main procedure builds a LPSERVICE_TABLE_ENTRY array
> containing the name and ServiceMain address for each service in the
> executable. You then pass that to StartServiceCtrlDispatcher (You have
> to do this within 2 minutes, or the OS will kill your process).

Wasn't this the area with a problem letting the Ada RTL know about
threads created by the Microsoft OS code ?

Re: NT Service, WinSock

[Ted Dennison]

Larry Kilgallen wrote:

> Wasn't this the area with a problem letting the Ada RTL know about
> threads created by the Microsoft OS code ?

I'd expect there to be. Ada tasks may be implemented *using* threads, but that doesn't
mean that's all there is to one. Anything that involves tasking semantics (eg: protected
types, rendezvous) is probably going to require an actual Ada task. Thus you shouldn't
count on them working with an OS-created thread.

Since the service facility creates an OS thread for each service's ServiceMain routine, it
stands to reason that it may not be safe to perform a rendezvous or protected type call
from within ServiceMain. However, I'd think you should be able to declare an (Ada) task in
ServiceMain, which can do all those things. It would mean using another OS thread, but it
may be worth it.

The other option would be to just use Windows thread communications calls to communicate
between the handler procedure (in the main task) and ServiceMain. That's what a C
programmer is forced to do anyway.

I've gotten interested enough in this to play with it a bit on my home system "in my
copious free time". If I come up with anything interesting, I'll report back.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: NT Service, WinSock

[Ted Dennison]

In article <39F8DEBD.82CA66C4@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> I've gotten interested enough in this to play with it a bit on my home
> system "in my copious free time". If I come up with anything
> interesting, I'll report back.

I now have a nice little thick binding built for NT services that seems
to be working. Its a generic that you simply instantiate with your
handler routines. It takes care of all the details of registering the
service and its handlers with NT.

It appears to work nicely. The only real glitch I've seen is that some
test code of mine, in trying to write to a file in a handler, causes an
exception to get raised (and handled) in the ServiceMain routine, which
should be in a completely different thread!

Other than that, with Gnat Text_IO to files works fine. "delay" works
fine. I haven't tried any other tasking or protected type primitives
yet. I'm having trouble creating processes with CreateProcess, but
that's probably an unrelated bug.

Right now I'm using this as part of a mini-project to create a SETI@Home
controller service (something I've wanted for a while), which I plan to
release as free software if I can get it working well enough. If anyone
is interested in the NT service binding itself, let me know.

Would someone familiar with CLAW care to comment on how/if it handles NT
services? I'm interested in what other thick bindings have done.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: NT Service, WinSock

[Randy Brukardt]

Ted Dennison wrote in message <8tk5bf$lgh$1@nnrp1.deja.com>...

>Would someone familiar with CLAW care to comment on how/if it handles
NT
>services? I'm interested in what other thick bindings have done.

Sure. Claw doesn't have a services package. I don't think anyone has
ever asked for one. We do have a thin binding to the services APIs for
Janus/Ada; I needed that to control our E-Mail server. (That binding is
included with the compiler).

As far as the threading issues go, that pretty much is outside of the
scope of Claw. Our goal is to use mechanisms that will work on any Ada
95 compiler. Certainly issues with threading and Ada tasks differ
widely; we've had lots of problems with differences in handling the task
that manages windows.

I probably would have written a package something like yours, but I
discovered a program called "srvany.exe" on one of the Microsoft CD's.
It allows any console program to be run as a service. For my
applications (to be used only by me), that is sufficient, so I've just
been using it with Ada console applications.

                    Randy Brukardt
                    R.R. Software, Inc.

Re: NT Service, WinSock

[Ted Dennison]

Randy Brukardt wrote:

> I probably would have written a package something like yours, but I
> discovered a program called "srvany.exe" on one of the Microsoft CD's.
> It allows any console program to be run as a service. For my
> applications (to be used only by me), that is sufficient, so I've just
> been using it with Ada console applications.

I've heard of it, and I agree with your assessment. I discounted it for my
puposes for a couple of reasons

If I remember correctly it doesn't come on the standard NT OS disk. I think
its on a system adminsitration pack of some sort. Let's do a help
search.....Its on "The Windows NT Resource Kit", whatever that is. It looks
like you can download it for free, if you can find it in their labryinthian
site. Any facility that uses it would require the user to do this, as its
license certianly doesn't allow me to distribute copies.  That's an OK
solution for personal use if you happen to already have it laying around.

There are also some other various freeware or shareware programs that do
almost the same thing as srvany. But they all seem to have some extra
limitation that srvany doesn't have. Also, a custom service could do things
like restart the process when it dies (something that happens to seti every
now and then when it can't connect to turn in work units).

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591