Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re: Re: Re: (tye)Re: Running Perl code from a Windows service

by John M. Dlugosz (Monsignor)
on Sep 19, 2001 at 10:28 UTC ( #113271=note: print w/replies, xml ) Need Help??

in reply to Re: Re: (tye)Re: Running Perl code from a Windows service
in thread Running Perl code from a Windows service

A service should not need to access the desktop. It can, BTW, throw up a message box for an error and it will be visible to any desktop that's current. There's a special flag in MessageBox for this.

But the service will normally work behind the scenes. Another program, running as a normal program in the current interactive user's account, can interact with the user and communicate with the service. That's the model MS describes.

  • Comment on Re: Re: Re: (tye)Re: Running Perl code from a Windows service

Replies are listed 'Best First'.
Re: Re: Re: Re: (tye)Re: Running Perl code from a Windows service
by $code or die (Deacon) on Sep 19, 2001 at 21:12 UTC
    You are probably right, I haven't tried MessageBox in a service.

    I am slightly confused about the model you describe. Are you saying that the service should spawn a process in the context of the current logged on user so the user can interact with it? I am not disagreeing with you here, just seeking clarification. It sounds complicated - what happens when the user logs off? Do you kill the process and spawn a new one with the new logged on user?

    Personally, I agree that a service shouldn't need access to the desktop. All the services I have written have been completely in the background, and if I've needed to interact with it, I use a client with sockets or something. But your model sounds a bit confusing. Unless we're talking about the same thing. What do you mean by "Another program, running as a normal program "

    Simon Flack ($code or die)
    $,=reverse'"ro_';s,$,\$,;s,$,lc ref sub{},e;$,
    =~y'_"' ';eval"die";print $_,lc substr$@,0,3;
      The ability of the MessageBox is specific to the MessageBox. Other windows can't do that in any documented manner.

      No, the service doesn't spawn a process. The user runs the process, if/when desired. For example, in the Startup group is something that adds a tray icon, or a control panel applet or MMC snap-in interacts with the service once you run it.

      See "Design a Windows NT Service to Exploit Special Operating System Facilities" by Jeffrey Richter. I just did a search in MSDN to find something on this subject. I've seen it described many times. Jeff says,

      The second thing you need to know when writing a service is that it should have absolutely no user interface. Most services will be running on a Windows NT Server machine locked away in a closet somewhere. If your service presents any user interface elements like message boxes, it's unlikely that a user will be in front of the machine to see the message box and dismiss it. Since you shouldn't have a user interface, it doesn't matter whether you choose to implement your service as a GUI application (with WinMain as its entry point) or as a console application (with main as its entry point).
      From the October 1997 issue of Microsoft Systems Journal. —John

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://113271]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2018-06-24 02:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.