[quote user="Rolf Lindby"]You could declare the daemon function the way you describe, but if it's actually never going to be called you could presumably leave it out.

I haven't used Visual Studio 2010 to compile a daemon so I can't comment on that part.

/Rolf[/quote]

Thanks, Rolf.  I read "In its simplest form, a Daemon is a simple 32-bit Windows DLL that
exports a single function, called "daemon"." and figured it must be there.  So I put it there.  It's working fine.

First I'll point out that in Visual Studio 2010, daemon.h's definition of "PARSE_MIME" conflicts with a definition of "PARSE_MIME" in urlmon.h (which you apparently get by including windows.h).

Does a resident daemon require a special alias (as described in daemon.txt) or is the daemon.ini entry sufficient?

A daemon need only export daemon() (as declared in daemon.h) ... right?

I don't want me daemon to provide any services to Mercury, so I wonder if this function will be sufficient:

Thanks!

 - Vince

Here is what the Mercury Daemon Developer Guide says about resident daemons:

This type of Daemon is loaded by Mercury at startup and remains resident until Mercury terminates. In its simplest form, it performs the same type of processing as a Single Instance Daemon, but is never unloaded. As with Single Instance Daemons, an alias can be associated with the Daemon’s path, which will result in the Daemon being invoked whenever a message is sent to that address, but the Daemon is not required to provide this type of servicing. Resident Daemons can start their own threads and can perform whatever processing  they wish in real time – indeed, a Resident Daemon need not ever interact with Mercury directly again after it is loaded, nor does it ever need to process a mail message if that is not its purpose.
Resident Daemons are installed via a Mercury configuration file called DAEMON.INI , which is located in the same directory as MERCURY.EXE – the format of this file is covered in a later section. Any Resident Daemon can, if it wishes, instruct Mercury to add an option to its Configuration menu, which, when invoked, will result in the Daemon’s own configuration dialog code being called. Resident Daemons can also create Mercury Console windows (much the same as the ones created by protocol modules such as MercuryS and MercuryE) if they wish.

You could declare the daemon function the way you describe, but if it's actually never going to be called you could presumably leave it out.

I haven't used Visual Studio 2010 to compile a daemon so I can't comment on that part.

/Rolf