>> Check out the online service tutorials - they nearly all use a timer
>> to log the diskspace every 5 mins etc etc.
>
> Then they are all doing the wrong thing.
Yes and teaching us bad coding.
> I am assuming that you are using TTimer, which is a message-based timer.
> The WM_TIMER message is posted to the message queue of the thread that
> creates the TTimer instance. TService is instantiated in the main thread,
> so the TTimer would be running off of the main thread message queue.
> TService creates a thread internally for its work. That means that the
> TTimer is running in a different thread than the TService is running. If
> the TTimer accesses members of the TService, then you have a race
> condition
> unless you protect access to all of the members with a mutex, semaphore,
> or
> critical section. You also have race condition due to the main thread and
> TService worker thread accessing the TTimer during startup and shutdown.
Went straight over my head but I'll take your word for it ;)
> You can't do that with a service. You have to start the service with the
> SCM first, and then attach the debugger to the service manually using the
> debugger's "Attach to Process" feature. Once the debugger is attached to
> the service's process, press F9 to continue execution and you can then
> debug
> the code normally like any other project.
>
> The only tricky part is when you need to debug the service's startup code.
> For that, you need to increase the service's WaitHint property (I
> generally
> use 30-45 seconds) and then put a Sleep() at the very beginning of the
> TService's OnStart event hander for the duration of the WaitHint. While
> the
> service is sleeping, the WaitHint property told the SCM not to expect a
> quick startup, so it won't error when the service takes awhile to start.
> This way, this gives you enough time to switch over to the IDE and attach
> the debugger before the sleeping finishes. For example:
>
> procedure TService1.ServiceCreate(Sender: TObject);
> begin
> {$IFDEF DEBUG}
> WaitHint := 30000;
> {$ENDIF}
> end;
>
> procedure TService1.ServiceStart(Sender: TService; var Started:
> Boolean);
> begin
> {$IFDEF DEBUG}
> Sleep(WaitHint-100);
> ReportStatus; // so the SCM waits another WaitHint interval
> {$ENDIF}
>
> // Your normal startup code here. Put a breakpoint somewhere
> // so that the debugger has a place to stop after the sleeping
> finishes
> end;
Now that was VERY useful. I can see you put effort into helping me here -
Many thanks!!!
>> wanna come round my place and take a look?
>
> I doubt that would work, considering that you are on the other side of the
> globe from me.
Dude, chill. It was a joke ;) Btw, how do you know where I am? :~
> For a single executable file to do that reliably, it would hae to separate
> the service and non-service logics, and then decide at runtime which one
> to
> invoke at startup. A service executable can have a separate GUI
> implemented
> that runs in a separate process. I tend to do that in my own services to
> provide setup UIs in the same file as the service that is being
> configured.
> At runtime, command-line "/service" and "/setup" paramaters are used so
> the
> executable knows which mode to run in.
I found it easier to set the form.visible := false; ;)
>> I kinda find it easier to use TIdTCPClient/Server these days but
>> then that has its pitfalls...
>
> Those work well in services as well.
Hooray I done something right!!!
>
>> And under the System account they can.
>
> Not if there are GUI resources attached to the service, they can't. Not
> very well, anyway.
Thats just it, it does - very well!
>> Talker.exe (which I told you about previously) can speak
>> with no user logged on at all.
>
> That has no relavance to what I've been talking about.
It does, see below!
>
>> But Talker.exe has worked faultlessly for over 6 months - almost
>> 7!!! - Until now!
>
> That doesn't require a GUI to do its work, though. You said yourself
> that
> Talker is using DirectX to do its speaking. DirectX doesn't require a
> user
> to be logged in to function.
I didn't explain this well did I. Talker.exe is a GUI application/service.
It has a main form included so that you can input connection details and
text to send to the other Talker.exe over a network. It also allows you to
preview the text before you send it to the remote Talker.exe - Thus it has a
UI.
>> The "Build with runtime packages" box is NOT checked.
>
> Did you also uncheck the "Use Dynamic RTL" option? If not, then the
> executables will be dependant on external DLLs for memory management.
> Perhaps you are getting corrupted memory due to an incompatibilty between
> the D6 VCL and the D2005 memory manager?
This sounds interesting and possibly the key to my problem.
Where can I find "Use Dynamic RTL option" in the D6 IDE? - I seen it
previously but now I can't seem to locate it!
Sounds like a possible cure though!
> DirectSS has nothing to do with MSAgent. They are separate and
> independant
> technologies.
Strange! - Would not work until i also installed Agent for some reason! -
never simple in my world :*(
>> I know you mean well but I've got first hand experience using it.
>
> And I have first-hand experience writing services without the use of
> third-party wrappers. And I know the pitfalls that services can have at
> the
> OS and VCL levels.
Lol, I know but I'll take my chances until I can learn enough to understand
high-level programming ;)
> That does not change what I said. An invisible form still allocates and
> binds to resources that can disappear behind the form's back during a user
> logout, and when the user logs back in the form will be corrupted because
> its resources are invalid.
Which is why it runs under the system account.... - system does not log out!
> Only an Interactive service can access the System Tray to place icons.
> Which means the service won't work properly when no Interative user is
> logged in. That is another thing that is best moved into a non-service
> application that runs while the user is logged in. The service itself
> should not be trying to display tray icons at all.
Ok, point taken on that - I'll write a TCP interface..
>> Not had that happen yet to be honest. Maybe there are some
>> differences with XP & NT?
>
> Nope. This effects all versions from NT up to and including Server 2003
Ok
>
>> Either way it runs under the system account so effectively, the
>> user never logs off but is always logged on. That makes sense?
>
> You do know how dangerous it is to running your services under the SYSTEM
> account, don't you?
Lol Nope!
>It is not that difficult for malicious software to
> cause a fault in another process, such as a service, and gain permissions
> to
> the machine.
Ah, but then someone would need to know my service is a)installed and b) how
it works before they can exploit this potential vulnerability. Seeing as I
don't release my work (Personal licence) I don't see anyone learning of any
vulnerability anytime soon..
> It is generally best practice to create a new user account
> with the minimal permissions needed and then run the service under that
> account instead.
I'll look into that!
