The NTP 4 distribution runs as service on Windows Vista, Windows NT 4.0, Windows 2000, Windows XP, Windows .NET Server 2003. It will NOT run on Windows 95, 98, ME, etc. The binaries work on multi-processor systems. This port has not been tested on the Alpha platform. This release now uses OpenSSL for authentication. IPv6 is not implemented yet for Win32 platforms. A ready-to-run install distribution is available from Meinberg at http://www.meinberg.de/english/sw/ntp.htm.
Users should note that the stock Windows client sends requests as mode-1 packets, which can have unintended consequences and create a security risk. The client should send requests as mode-3 (client) packets, which conform to the protocol specification. The issues and resolution are described in Microsoft KB 875424. A less desirable alternative that avoids changing registry keys is to use the --with-wintime option when building the executable.
With this release ntp-keygen is supported. See the ntp keygen documentation for details on how to use ntp-keygen.
ntpd can now use the generated keys in the same way as on Unix platforms. Please refer to the Authentication Options for details on how to use these.
NOTE: ntpd and ntp-keygen both use OpenSSL which requires a random character file called .rnd by default. Both of these programs will automatically generate this file if they are not found. The programs will look for an environmental variable called RANDFILE and use that for the name of the random character file if the variable exists. If it does not exist it will look for an environmental variable called HOME and use that directory to search for a file called .rnd in that directory. Finally, if neither RANDFILE nor HOME exists it will look in C:\ for a .rnd file. In each case it will search for and create the file if the environmental variable exists or in the C:\ directory if it doesn't.
Note that ntpd normally runs as a service so that the only way that it will have either RANDFILE or HOME defined is if it is a System environmental variable or if the service is run under a specific account name and that account has one of those variables defined. Otherwise it will use the file c:\.rnd. This was done so that OpenSSL will work normally on Win32 systems. This obviates the need to ship the OpenSSL.exe file and explain how to generate the .rnd file. A future version may change this behavior.
Refer to Compiling Requirements and Instructions for how to compile the program.
Reference clock support under Windows NT is tricky because the IO functions are so much different. Some of the clock types have been built into the ntpd executable and should work but have not been tested by the ntp project. If you have a clock that runs on Win32 and the driver is there but not implemented on Win32 you will have make the required configuration changes in config.h and then build ntpd from source and test it. The following reference clock is known to work and is supported by Windows NT: Type 1 Undisciplined Local Clock (LOCAL)
All NTP functions are supported with some constraints. See the TODO list below. Note that the ntptrace executable is not supported and you should use the PERL script version instead.
Greg Brackley has implemented a fantastic interpolation scheme that improves the precision of the NTP clock using a realtime thread (is that poetic or what!) which captures a tick count from the 8253 counter after each OS tick. The count is used to interpolate the time between operating system ticks.
On a typical 200+ MHz system NTP achieves a precision of about 5 microseconds and synchronizes the clock to +/-500 microseconds using the Trimble Palisade as UTC reference. This allows distributed applications to use the 10 milliseconds ticks available to them with high confidence.
Recent InstallShield based executable versions of NTP for Windows NT (intel) are available from:
These tasks are in no particular order of priority.
The default NTP configuration file path is %SystemRoot%\system32\drivers\etc\. (%SystemRoot% is an environmental variable that can be determined by typing "set" at the "Command Prompt" or from the "System" icon in the "Control Panel").
Refer to your system environment and create your ntp.conf file in the directory corresponding to your system installation. The older <WINDIR>\ntp.conf is still supported but you will get a log entry reporting that the first file wasn't found.
The instsrv program in the instsrv subdirectory of the distribution can be used to install 'ntpd' as a service and start automatically at boot time. Instsrv is automatically compiled with the rest of the distribution if you followed the steps above.
You can change the start mode (automatic/manual) and other startup parameters corresponding to the NTP service in the "Services" dialog box if you wish.
You can also use instsrv to delete the NTP service by entering: >"instsrv.exe remove"
Unlike the Unix environment, there is no clean way to run 'ntpdate' and reset the clock before starting 'ntpd' at boot time. NTP will step the clock up to 1000 seconds by default. While there is no reason that the system clock should be that much off during bootup if ntpd was running before, you may wish to override this default and/or pass other command line directives.
Use the registry editor to edit the value for the ntpd executable under LocalMachine\System\CurrentControlSet\Services\NTP.
Add the -g option to the ImagePath key, behind "%INSTALLDIR>\ntpd.exe". This will force NTP to accept large time errors (including 1.1.1980 00:00)
Send questions and bug reports to NTP Bug Reporting Procedures.
by Danny Mayer (mayer@ntp.org>)
This latest release of NTP constitutes a major upgrade to its ability to build and run on Windows platforms and should now build and run cleanly. More importantly it is now able to support all authentication in the same way as Unix boxes. This does require the usage of OpenSSL which is now a prerequisite for build on Windows. ntp-keygen is now supported and builds on Win32 platforms.
by Sven Dietrich (sven_dietrich@trimble.com)
pSignificant Changes:
by Sven Dietrich (sven_dietrich@trimble.com)
ignificant Changes:
This version compiled under WINNT with Visual C 6.0 by Greg Brackley and Sven Dietrich. Significant changes:
This version corrects problems with building the XNTPversion 3.5-86 distribution under Windows NT. The following files were modified:
In order to build the entire Windows NT distribution you need to modify the file scripts\wininstall\build.bat with the installation directory of the InstallShield software. Then, simply type "bldrel" for non-debug or "blddbg" for debug executables.
Greg Schueman, schueman@acm.org>
This set of changes fixes all known bugs, and it includes
several major enhancements. Many changes have been made both to the build environment as well as the code. There is no longer an ntp.mak file, instead there is a buildntall.bat file that will build the entire release in one shot. The batch file requires Perl. Perl is easily available from the NT Resource Kit or on the Net.
The multiple interface support was adapted from Larry Kahn's work on the BIND NT port. I have not been able to test it, adequately as I only have NT servers with one network interfaces on which to test.
Enhancements:
Bug fixes
See below for more detail
Note: SIGINT is not supported for any Win32 application including; Windows NT and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems generate a new thread to specifically handle that interrupt. This can cause a single-thread application such as UNIX, to become multithreaded, resulting in unexpected behavior.
Possible enhancements and things left to do:
This NTPv3 distribution includes a sample configuration file and the project makefiles for WindowsNT 3.5 platform using Microsoft Visual C++ 2.0 compiler. Also included is a small routine to install the NTP daemon as a "service" on a WindowsNT box. Besides xntpd, the utilities that have been ported are ntpdate and xntpdc. The port to WindowsNT 3.5 has been tested using a Bancomm TimeServe2000 GPS receiver clock that acts as a stratum 1 NTP server with no authentication (it has not been tested with any refclock drivers compiled in).
Following are the known flaws in this port
by Sven_Dietrich@Trimble.COM