[AWS] AWS as a service on a Win2000 server

[David Marceau]

anders.wirzenius@wartsila.com wrote:
> 
> > -----Original Message-----
> > From: David Marceau [mailto:davidmarceau@sympatico.ca] wrote:
> > The weird thing about nt services is that if you create a dll
> > with too much housekeeping at the load time, the dll will not
> > return immediately and as a result your dll will give the
> > appearance that it failed to load and you end up with an hour
> > glass Icon.
> >
> > nt service success trick #1
> > ----------------------------
> > Don't do any initialization at load time.  Have some timer
> > actually initialize your application after 5 seconds.  That
> > will give windows the chance to behave properly and return
> > success for DLL_INIT...  In fact the ideal is that you just
> > return success in the DLL_INIT part right away. There should
> > be about three lines.
> > 1)load dll but don't do any init.
> > 2)set a timer with a callback that in 5 seconds it will init
> > and start aws
> > 3)return success.
> >
> 
> I havenĄ¨t created any dll files, I just have an .exe file.
> I tried to put a delay 60.0 at the beginning of the main procedure (runme) and then continue with declaring
> WS   : AWS.Server.HTTP:
> 
> procedure Runme is
> 
>    use Ada;
> begin
>    --
>    --  Delay program so that Windows is able to start the program as a service.
>    --
>    delay 60.0;
> 
>    declare
>       WS   : AWS.Server.HTTP;
>    begin
>    --
>    --  Text_IO.Put_Line ("AWS " & AWS.Version);
>    --  Open databases
>    HD.Database_OCI.SD.Open_SD_read;
> ...
> but that caused the service start attempt to only struggle a few seconds more and then issue the error message.
> 
> Do you mean I have to put the runme in a separate package and write a main program?
> Like:
> with separate_package;
> procedure main is
> begin
>    delay 5.0
This won't work because the delay 5.0 here is happening after ada_init is
called.
No housekeeping can go on because the nt service start needs to load the dll in
memory and just return success.
Then the win32 callback from the timer you set in the dll_init gets called after
a few seconds to do the real ada_init.

Here is what I think it could look like...this is pseudocode so don't try to
compile this:
function DllMain (hInst    : HINSTANCE;
                     Reason   : ULONG;
                     Reserved : LPVOID) return BOOL is
   begin

      --  take the action for which we are called
      case Reason is

         --  a new process (_not_ thread) is attaching itself
         --  initialize the Ada runtime library for it
         when DLL_PROCESS_ATTACH =>
            --This was here --AdaInit;  --this takes too long for the nt-service
stuff.
	    call the nt service stuff and call the win32 settimer callback function
here.
            return True_BOOL;

         --  a process is unloading the dll
         --  finalize the Ada runtine library for it
         when DLL_PROCESS_DETACH =>
            AdaFinal;
            return True_BOOL;

         --  in all other cases we simply return 'True'
         when others =>
            return True_BOOL;

      end case;

   end DllMain;

win32 settimer callback function
begin
	Ada_Init;
end

It doesn't matter if your program is an exe or a dll since it's the order of the
things that needs to be respected.
It's also having your program behave properly with respect to permitting the
Windows Messages to breathe through the 
PeekMessage/ProcessMessage stuff.  In old windows 3.1 this was absolutely
necessary for collaborative tasking to work.
>From what I can see there is some residue still in windows nt/win32 regarding
this issue especially around nt services.  Remark a winmain and dllmain is in
fact the same thing with a different entry point name.  The only difference is
what messages the dll handles.  Notice the when others clause up there.  That's
all the other windows messages flying around in a sense.  I don't want to get
into the nitty gritty details but at least it does provide some perspective I
hope.  Another recommendation to recommend windows stuff: Read up on
winmain/dllmain/peekmessage/processmessage/breath.

Cheers.