Win32::Daemon relies upon a dll, Daemon.dll which if the installation on your development machine is correct, you should find installed in

X:/perl/site/lib/auto/win32/daemon/

or somewhere similar. I've never used 5.005, so I am unsure whether the blib paths were different back then.

Adding the contents of Win32::Daemon.pm to the top of your script would work and be trivial, but the seems little point it adding its 20k to your script to save "polluting the install", when you would need to place a 72/76 kb binary in the appropriate place in the perl directory tree anyway. In any case, the general method of using Win32::Daemon appears to be to have two scripts: The first is the deamon itself (which used Win32::Daemon) and the second is a short script to install the first (which also needs Win32::Daemon). So, all you would be doing is wasting 20k of space. Whilst it wouldn't be too hard to combine the install and service scripts into one, the next time you want to create another service script your back to square one.

The bottom line is that you are going to have to put Deamon.dll somewhere. You might get away will placing it in on a server somewhere and loading it across the network to each machine, though your going to have to play some nasty tricks with Dynaloader.pm to make that work. You might even encode the dll using mime64 or similar and tack it onto the end of your script and reconstitute it at run-time, but the chances of making this work at all, never mind reliably are pretty darn slim.

thanks to everyone for the responses. love you all :)
------------------------
<if the answer you get is not what you want> <ask a different question>

Also, it very likely is that Win32::Daemon has a bunch of XS, meaning you'd have to compile it on the target machine, anyways?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

thank you very much. Unfortunatelly Win32::Daemon seems a little more complicated in loading than CGI, and fails with: Can't locate loadable object for module Win32::Daemon in @INC (@INC contains: D:/Perl/lib D:/Perl/site/lib .) at D:/Perl /lib/DynaLoader.pm line 108 btw all that my code does is update password for some services. Chris

"loadable object" is a bad sign. It means that portions of the code are C-compiled. Ugh. You might be able to get by with PAR, so look in to that.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

One trick that I've used in the past is to modify @INC to also point to a directory I can modify (e.g. lib in my software release) and then require the module:

my $dir = Cwd::getcwd() . "/" . $0;
$dir =~ s#([/\\])[^/\\]+$#/lib#;
push(@INC,$dir);

require PrivateModule;
[download]

That way you are only affecting your own script and you can use the standard module.

I will address what seems the obvious issue to me -- you are going to be running this Perl script on all those remote machines, so something is going to be copying it out there -- Can it not also copy the modules you need?

I don't understand why you think you are limited to one script's worth of code.

Cannot pollute the remote machine perl environment as it's part of a large system. it is totally out of the question for me to do so. Chris