Community Discussions and Support
Run Mercury/32 as a Windows service

[quote user="PHR"] Many thanks for your prompt reply. For me and I think for most users it is only necessary to have Mercury automatically started at boot time even when no user logs onto the server. Being myself a system developper I know the difficulties to "convert" a program to a Windows service especially when there is some interaction with the desktop. [/quote]

We have a specialized user account that logs in automatically, and thus starts Loader from the autostart section. This user account has very little user rights within the machine and the domains. Not until Mercury gets a native Windows service support will we change our approach.

<P>[quote user="PHR"] Many thanks for your prompt reply. For me and I think for most users it is only necessary to have Mercury automatically started at boot time even when no user logs onto the server. Being myself a system developper I know the difficulties to "convert" a program to a Windows service especially when there is some interaction with the desktop. [/quote]</P> <P>We have a specialized user account that logs in automatically, and thus starts Loader from the autostart section. This user account has very little user rights within the machine and the domains. Not until Mercury gets a native Windows service support will we change our approach.</P>

I would like to install Mercury/32 4.62 as a Windows 2003 service. Through standard tools as XYNTservice, Srvany or FireDaemon tools is pretty much easy but my question is the following :

what executable file has to be started MERCURY.EXE or LOADER.EXE ?

Many thanks for your help and best regards from Switzerland ...

Philippe 

 

<P>I would like to install Mercury/32 4.62 as a Windows 2003 service. Through standard tools as XYNTservice, Srvany or FireDaemon tools is pretty much easy but my question is the following :</P> <P>what executable file has to be started MERCURY.EXE or LOADER.EXE ?</P> <P>Many thanks for your help and best regards from Switzerland ...</P> <P>Philippe </P> <P mce_keep="true"> </P>

I honestly don't know for certain on this, but I'd say almost certainly MERCURY.EXE. I expect that using LOADER.EXE will create nasty little process synchronization problems and will make it very difficult to stop the service.

For what it's worth, I *am* working on native code to allow Mercury to run as a service, but it's not as straightforward as it seems, because there are certain combinations of environment (specifically Mercury and NetWare) where you run into real problems accessing network resources when you run as a service. There's also a problem in that one of Mercury's strongest features is its console (not because it's flashy or pretty, but because it reports a lot of incredibly useful information) and you're almost inevitably going to lose that console in a service environment.

Anyway, it's not that I'm unaware of the need or desirability of being able to run as a service - it's just getting the right balance of compromises to make it viable.

Cheers!

-- David --

I honestly don't know for certain on this, but I'd say almost certainly MERCURY.EXE. I expect that using LOADER.EXE will create nasty little process synchronization problems and will make it very difficult to stop the service. For what it's worth, I *am* working on native code to allow Mercury to run as a service, but it's not as straightforward as it seems, because there are certain combinations of environment (specifically Mercury and NetWare) where you run into real problems accessing network resources when you run as a service. There's also a problem in that one of Mercury's strongest features is its console (not because it's flashy or pretty, but because it reports a lot of incredibly useful information) and you're almost inevitably going to lose that console in a service environment. Anyway, it's not that I'm unaware of the need or desirability of being able to run as a service - it's just getting the right balance of compromises to make it viable. Cheers! -- David --

Many thanks for your prompt reply. For me and I think for most users it is only necessary to have Mercury automatically started at boot time even when no user logs onto the server. Being myself a system developper I know the difficulties to "convert" a program to a Windows service especially when there is some interaction with the desktop. 

Once more, many thanks for your work (and its quality ...).

Best regards,

Philippe 

 

 

<P>Many thanks for your prompt reply. For me and I think for most users it is only necessary to have Mercury automatically started at boot time even when no user logs onto the server. Being myself a system developper I know the difficulties to "convert" a program to a Windows service especially when there is some interaction with the desktop. </P> <P>Once more, many thanks for your work (and its quality ...).</P> <P>Best regards,</P> <P>Philippe </P> <P mce_keep="true"> </P> <P mce_keep="true"> </P>

I do run Mercury/32 as a service using NT Wrapper and it does work pretty well even with Netware. 

The NT Wrapper allows standard Win32 applications or scripts to be run as a Windows NT/2000/XP/2003 Service.  

Features:
    ·    Easy configuration thru a GUI and simple INI files.  
    ·    Prioritization of sub-processes.  
    ·    Custom environments.  
    ·    CPU binding  
    ·    Redirecting of Stdout/Stderr to file  
    ·    Logging to the event log and to disk.  
    ·    The capability to run multiple applications in a single NT Wrapper service instance.  
    ·    Monitoring of a service in the sys-tray.  

http://www.duodata.de/ntwrapper/

This service wrapper allows you to run the service as a specific

user and still maintain the GUI interface.  It still has a number of

problems when run with Netware but  I've not found any particular

problems when running with a standard Windows server setup.  Actually

for Netware I'm still using Mercury v1.48 for processing the mail

received via my Mercury/32 gateway server.  ;-)


That said, I'm also testing a Windows  integration setup

(mn_win.dll) with Mercury/32 and if and when this comes into general

use then the current service wrapper will need some significant work.

<p>I do run Mercury/32 as a service using NT Wrapper and it does work pretty well even with Netware.  </p><blockquote>The NT Wrapper allows standard Win32 applications or scripts to be run as a Windows NT/2000/XP/2003 Service.   Features:     ·    Easy configuration thru a GUI and simple INI files.       ·    Prioritization of sub-processes.       ·    Custom environments.       ·    CPU binding       ·    Redirecting of Stdout/Stderr to file       ·    Logging to the event log and to disk.       ·    The capability to run multiple applications in a single NT Wrapper service instance.       ·    Monitoring of a service in the sys-tray.   http://www.duodata.de/ntwrapper/ </blockquote><p>This service wrapper allows you to run the service as a specific user and still maintain the GUI interface.  It still has a number of problems when run with Netware but  I've not found any particular problems when running with a standard Windows server setup.  Actually for Netware I'm still using Mercury v1.48 for processing the mail received via my Mercury/32 gateway server.  ;-)</p><p> That said, I'm also testing a Windows  integration setup (mn_win.dll) with Mercury/32 and if and when this comes into general use then the current service wrapper will need some significant work. </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft