|distributed.net Faq-O-Matic : the Client software : Automatically starting the client at boot time : Windows (32bit)|
32bit Windows clients are capable of running as 'services', which start when the machine starts, and don't shut down until the machine does. (ie, they survive logouts). The -install option configures the system to launch the
client as a service the next time the machine is booted.
Although services on Win9x and WinNT are dramatically different in terms of implementation, dnetc attempts to make the behavior between the two environments approximately equal.
Note that the (WinNT) client cannot run with "Allow service to interact
with desktop" enabled. This is because when the client starts, it does not
know whether it was started as a service or not (it does not depend on the
-svcrun switch). If it tried to initialize itself as a service, and wasn't
actually started as a service (from 'net start' or whatever), it would take
ages to start. So, since, under normal circumstances, the shell isn't
active/visible when the service starts, it uses this condition as an
indication of whether it should try to initialize itself as a service or not.
In order to reduce its footprint and other overhead, the client runs with an
implicit -quiet when started as service, so, even if it did not use the
check-for-shell described above, you wouldn't see anything.
|The distributed.net client will fail to start as a service if the directory is marked for encryption. This limitation applies not specifically to the distributed.net client, but to any service or process that is running from a different logon context than the user the file is encrypted to. Encrypted directories and files can only be accessed by the user who created them, and services generally are started from within the "LocalSystem" user context.
Explicitly unencrypting each of the individual files within the directory is not sufficient, since new files created in that directory by the client will inherit the encryption from the parent directory.
Configuring the service to login as me (instead of as LocalSystem) seemed to fix it, but the safer approach is to keep the distributed.net client in an unencrypted directory, where no parent directory is encrypted either.
This limitation will also be apparent if you ever try to encrypt your Windows directory itself, or the base "Documents and Settings" directory (that contains the profile directories for multiple users, not just yourself), or the root directory of a hard drive that contains things that multiple users or the system itself needs to access. Generally speaking, only sensitive documents should be encrypted, and not application directories, or entire hard drives.
|Older clients (<=.463) running as a WinNT service had a problem detecting modem connections. This is no longer an issue (it continues to be one for perproxy though), and to ensure that newer clients update their dependancy tables, you will need to re-"-install" the client.
Although not specific to NT service, be sure that the interface name that you've told the client to monitor is the correct interface name of your modem connection. However, typing the interface name incorrectly will prevent the client from detecting your modem connection when running as an NT Service or as an interactive process.
|For at least Vista 'gold', running 'dnetc.exe -install' (the install service command) as administrator appears to be necessary to successfully install dnetc as a system service. Probably the easiest way to do this would be to select 'Run this program as administrator' under 'Privilege Level' in the 'Compatibility' tab in 'dnetc Properties' (a right click on the file) first. Once 'dnetc.exe -install' is run, it should be OK to un-set this option, unless you want to do other stuff that requires administrator access, like 'dnetc.exe -svcstart' and some such.
© Copyright distributed.net 1997-2013 - All rights reserved