Remove files not present in 4.1.1a import.

3 files changed, 0 insertions, 501 deletions

diff --git a/contrib/ntp/html/hints/winnt b/contrib/ntp/html/hints/winnt
deleted file mode 100644
index 6fd7c84..0000000
--- a/contrib/ntp/html/hints/winnt
+++ /dev/null
@@ -1,207 +0,0 @@
--------------
-INTRODUCTION:
--------------
-Last revision 27 July 1999 	Version 4.0.95.
-
-This version compiles under WINNT with Visual C 6.0.
-
-Greg Brackley and Sven Dietrich 
-
-Significant changes:
--Visual Studio v6.0 support
--Winsock 2.0 support
--Use of I/O completion ports for sockets and comm port I/O
--Removed the use of multimedia timers (from ntpd, others need removing)
--Use of waitable timers (with user mode APC) and performance counters to fake getting a better time
--Trimble Palisade NTP Reference Clock support
--General cleanup, prototyping of functions
--Moved receiver buffer code to a separate module (removed unused members from the recvbuff struct)
--Moved io signal code to a separate module
-
-Compiling Instructions:
-1. Requires Perl to be installed, and the Perl environment variable to be set correctly
-2. Open the .\ports\winnt\ntp.dsw
-3. Batch build of all debug projects compile
-
-
-Last revision:  20-Oct-1996
-
-This version corrects problems with building the XNTP 
-version 3.5-86 distribution under Windows NT.
-
-The following files were modified:
-	blddbg.bat
-	bldrel.bat
-	include\ntp_machine.h
-	xntpd\ntp_unixclock.c
-	xntpd\ntp_refclock.c
-	scripts\wininstall\build.bat
-	scripts\wininstall\setup.rul
-	scripts\wininstall\readme.nt
-	scripts\wininstall\distrib\ntpog.wri
-	html\hints\winnt (this file)
-
-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>
-
-
-Last revision:  07-May-1996
-
-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:
-*	Event Logging now works correctly.
-*	Version numbers now work (requires Perl during build)
-*	Support for multiple network interface cards (untested)
-*	NTP.CONF now default, but supports ntp.ini if not found
-*	Installation procedure automated.
-*	All paths now allow environment variables such as %windir%
-
-Bug fixes:
-*	INSTSRV replaced, works correctly
-*	Cleaned up many warnings
-*	Corrected use of an uninitialized variable in XNTPD
-*	Fixed ntpdate -b option
-*	Fixed ntpdate to accept names as well as IP addresses
-        (Winsock WSAStartup was called after a gethostbyname())
-*	Fixed problem with "longjmp" in xntpdc/ntpdc.c that 
-        caused a software exception on doing a Control-C in xntpdc.
-	A Cntrl-C now terminates the program. 
-
-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:
-*	Reference clock drivers for NT (at least Local Clock support)
-*	Control Panel Applet
-*	InstallShield based installation, like NT BIND has
-*	Integration with NT Performance Monitor
-*	SNMP integration
-*	Fully test multiple interface support
-
-
-Known problems:
-*       bug in ntptrace - if no Stratum 1 servers are available,
-                such as on an IntraNet, the application crashes.
-
-
-
-
-Last revision:  12-Apr-1995
-
-
-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 strata 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:
-1) currently, I do not know of a way in NT to get information about multiple
-   network interface cards. The current port uses just one socket bound to
-   INADDR_ANY address. Therefore when dealing with a multihomed NT time server,
-   clients should point to the default address on the server (otherwise the
-   reply is not guaranteed to come from the same interface to which the 
-   request was sent). Working with Microsoft to get this resolved.
-2) There is some problem with "longjmp" in xntpdc/ntpdc.c that causes a 
-   software exception on doing a Control-C in xntpdc. Be patient!
-3) The error messages logged by xntpd currently contain only the numerical
-   error code. Corresponding error message string has to be looked up in
-   "Books Online" on Visual C++ 2.0 under the topic "Numerical List of Error
-   Codes".
-
-
-----------------------------------------------------
-MAKING XNTPD FOR WindowsNT 3.5 using Visual C++ 2.0:
-----------------------------------------------------
-
-Separate projects are needed for xntpd, ntpdate, xntpdc, and the library
-containing routines used by them.
-
-1) First build the static library composed of routines in the lib
-   subdirectory of the distribution. Load the project by opening the 
-   corresponding makefile libntp.mak (in the lib subdirectory of the 
-   distribution) by choosing the Open option in the File menu. This should
-   display a list of files contained in this project. Then choose the 
-   "Rebuild All" option from the Project menu in order to compile the
-   routines into a library. The libntp.lib static library is created in
-   the lib/WinDebug directory
-
-   You can now choose to build xntpd, ntpdate, and xntpdc in any order.
-
-2) To build xntpd, load the project by opening the corresponding makefile
-   xntpd.mak (in the xntpd subdirectory of the distribution), and rebuild
-   all files. The xntpd.exe executable is created in the xntpd/WinDebug
-   directory.
-
-3) repeat the above step for ntpdate and xntpdc
-
-
--------------------------------------------------
-INSTALLING XNTPD AS A SERVICE UNDER WindowsNT 3.5
--------------------------------------------------
-
-At this point you need to install 'xntpd' as a service. First modify the
-sample configuration file conf/config.winnt35 in the distribution to
-suit your needs. Then install it as "%SystemRoot%\NTP.INI" (%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",
-NTP.INI is the suggested name for the "ntp.conf" file in Windows environment).
-The instsrv.c program in the util subdirectory of the distribution can 
-be used to install 'xntpd' as a service and start automatically at boot 
-time. Compile instsrv.c, and enter form the command prompt 
-      "instsrv.exe NetWorkTimeProtocol <pathname_for_xntd.exe>"
-Clicking on the "Services" icon in the "Control Panel" ("Main" group
-in the "Program Manager") will display the list of currently installed
-services in a dialog box. The NetworkTimeProtocol service should show
-up in this list. Select it in the list and hit the "Start" button in
-the dialog box. The NTP service should start. View the event log by
-clicking on the "Event Viewer" icon in the "Administrative Tools" group
-of the "Program Manager", there should be several successful startup
-messages from NTP. NTP will keep running and restart automatically when
-the machine is rebooted.
-
-You can change the start mode (automatic/manual) and other startup 
-parameters correponding to the NTP service (eg. location of conf file)
-also in the "Services" dialog box if you wish.
-
-There is no clean way to run 'ntpdate' before starting 'xntpd' at boot
-time, unlike the Unix environment. 'xntpd' will step the clock upto
-a 1000 seconds. While there is no reason that the system clock should
-be that much off during bootup if 'xntpd' was running before bootup,
-you may want to increase the CLOCK_WAYTOOBIG parameter in include/ntp.h
-from 1000 to, say, MAXINT.
-
-You can also use instsrv.c to delete the NTP service
-	"instsrv.exe NetworkTimeProtocol remove"
-
-
-Viraj Bais
-<vbais@mailman1.intel.com>
diff --git a/contrib/ntp/html/vxworks.htm b/contrib/ntp/html/vxworks.htm
deleted file mode 100644
index b6fae80..0000000
--- a/contrib/ntp/html/vxworks.htm
+++ /dev/null
@@ -1,153 +0,0 @@
-<HTML>
-<HEAD>
-   <TITLE>vxWorks Port of NTP</TITLE>
-</HEAD>
-<BODY LINK="#00008B" VLINK="#8B0000">
-
-<H1>VxWorks port of NTP </H1>
-
-<P>Creating a port for vxWorks posed some problems. This port may help
-as a starting point for similar ports to real-time OS's and other embeddable
-kernels, particularly where main() is not allowed, and where the configure
-scripts need to be altered. </P>
-
-<H1><B>Configuration issues</B></H1>
-
-<P>I decided to do as little invasive surgery as possible on the NTP code,
-so I brought the vxWorks header tree in line with the standard unix tree.
-The following changes were needed, as a side effect these changes will
-allow for easy porting of other autoconfigure enabled code. </P>
-
-<P>Where I have 386 you will need to put in your target type. The vxWorks
-tree entry point is /usr/wind. If these are the same for your system, you
-should be able to cut and paste the changes. </P>
-
-<P><BLINK>WARNING: Check you are not overwriting files, before entering
-the following: there should be no conflict, but check first... </BLINK></P>
-
-<P>export CC=&quot;cc386 -nostdlib -m486 -DCPU=I80486 -I/usr/wind/target/h&quot;
-<BR>
-export RANLIB=ranlib386 <BR>
-export AR=ar386 <BR>
-export VX_KERNEL=/usr/wind/target/config/ims_std_bsp/vxWorks <BR>
-cd /usr/wind/target/sys <BR>
-ln -s ../signal.h <BR>
-ln -s ../time.h <BR>
-ln -s socket.h sockio.h <BR>
-ln -s ../selectLib.h select.h <BR>
-ln -s ../timers.h <BR>
-touch file.h param.h resource.h utsname.h var.h ../netdb.h ../a.out.h ../termios.h
-<BR>
-echo &quot; ******ADD #include \&quot;sys/times.h\&quot; to sys/time.h
-&quot; </P>
-
-<P>The configure script must be changed in the following way to get the
-linking tests to work, once in the correct directory issue the following
-commands: <BR>
-sed -e 's%main.*()%vxmain()%' configure &gt; configure.vxnew <BR>
-mv configure.vxnew configure <BR>
-chmod 755 configure </P>
-<P>The new version 4 of NTP requires some maths functions so it links in the
-maths library (-lm) in the ntpd <a href="../ntpd/Makefile.am">Makefile.am</a>
-change the line "ntpd_LDADD = $(LDADD) -lm" by removing the "-lm".<BR>
-You are now ready to compile</P>
-
-
-<P><BR>
-The <A HREF="../configure.in">configure.in </A>file needed to be altered
-to allow for a host-target configuration to take place. </P>
-
-<UL>
-<LI>The define SYS_VXWORKS was added to the compilation flags. </LI>
-
-<LI>Little endianess is set if the target is of type iX86. </LI>
-
-<LI>The size of char, integer, long values are all set. If Wind River ever
-changes these values they will need to be updated. </LI>
-
-<LI>clock_settime() is defined to be used for setting the clock. </LI>
-
-<LI>The Linking flags have -r added to allow for relinking into the vxWorks
-kernel </LI>
-</UL>
-
-<P>Unfortunately I have had to make use of the <A HREF="../include/ntp_machine.h">ntp_machine.h
-</A>file to add in the checks that would have been checked at linking stage
-by autoconf, a better method should be devised. </P>
-
-<UL>
-<LI>There is now a NO_MAIN_ALLOWED define that simulates command line args,
-this allows the use of the normal startup sysntax. </LI>
-
-<LI>POSIX timers have been added. </LI>
-
-<LI>Structures normally found in netdb.h have been added with, the corresponding
-code is in <A HREF="../libntp/machines.c">machines.c </A>. Where possible
-the defines for these have been kept non-vxWorks specific.</LI>
-</UL>
-
-<P>Unfortunately there are still quite a few SYS_VXWORKS type defines in
-the source, but I have eliminated as many as possible. You have the choice
-of using the usrtime.a library avaliable from the vxworks archives or forgoing
-adjtime() and using the clock_[get|set]time().The <A HREF="../include/ntp_machine.h">ntp_machine.h
-</A>file clearly marks how to do this. </P>
-
-<H1><B>Compilation issues</B> </H1>
-
-<P>You will need autoconf and automake ... available free from the gnu
-archives worldwide. </P>
-
-<P>The variable arch is the target architecture (e.g. i486) </P>
-
-<P>mkdir A.vxworks (or whatever....) <BR>
-cd A.vxworks <BR>
-../configure --target=arch-wrs-vxworks [any other options] <BR>
-make </P>
-
-<P>Options I normally use are the --disable-all-clocks --enable-LOCAL-CLOCK flags.
-The program should proceed to compile without problem. The daemon ntpd,
-ntpdate, ntptrace, ntpdc, ntpq programs and of course the libraries are
-all fully ported. The other utilities are not, but they should be easy
-to port. </P>
-
-<H1>Running the software </H1>
-
-<P>Load in the various files, call them in the normal vxWorks function
-type manner. Here are some examples. Refer to the man pages for further
-information. </P>
-
-<P>ld &lt; ntpdate/ntpdate <BR>
-ld &lt; ntpd/ntpd <BR>
-ld &lt; ntptrace/ntptrace <BR>
-ld &lt; ntpq/ntpq <BR>
-ld &lt; ntpdc/ntpdc <BR>
-ntpdate (&quot;-b&quot;, &quot;192.168.0.245&quot;) <BR>
-sp(ntpd, &quot;-c&quot;, &quot;/export/home/casey/ntp/ntp.conf&quot;)
-<BR>
-ntpdc(&quot;-c&quot;, &quot;monlist&quot;, &quot;192.168.0.244&quot;)
-<BR>
-ntpq(&quot;-c&quot;, &quot;peers&quot;, &quot;192.168.0.244&quot;) <BR>
-ntptrace(&quot;192.168.0.244&quot;) <BR>
-</P>
-
-<H1>Bugs and such </H1>
-
-<P>Should you happen across any bugs, please let me know, or better yet
-fix them and submit a patch. Remember to make you patch general for Vxworks,
-not just for your particular architecture.
-<A HREF="http://www.ccii.co.za">CCII Systems
-(Pty) Ltd</A>, my ex employers, sponsored the time to this port.
-Please let me know how it goes, I would be most interested in offsets
-and configurations. </P>
-
-<P><BR>
-</P>
-
-<P>Casey Crellin</A> <BR>
-<A HREF="mailto:casey@csc.co.za">casey@csc.co.za</A> </P>
-
-<P><BR>
-</P>
-
-</BODY>
-</HTML>
diff --git a/contrib/ntp/html/y2k.htm b/contrib/ntp/html/y2k.htm
deleted file mode 100644
index 3609ee3..0000000
--- a/contrib/ntp/html/y2k.htm
+++ /dev/null
@@ -1,141 +0,0 @@
-<html><head<title>
-Network Time Protocol Year 2000 Conformance Statement
-</title></head><body><h3>
-Network Time Protocol Year 2000 Conformance Statement
-</h3>
-
-<img align=left src=pic/alice15.gif>
-from <i>Alice's Adventures in Wonderland</i>, by Lewis Carroll,
-illustrations by Sir John Tenniel
-
-<p>The Mad Hatter and the March Hare are discussing whether the Teapot
-serial number should have two or four digits.
-
-<br clear=left><hr>
-
-<h4>Introduction</h4>
-
-By the year 2000, the Network Time Protocol (NTP) will have been in
-use for over two decades and remain the longest running, continuously
-operating application protocol in the Internet. There is some concern,
-especially in government and financial institutions, that NTP might
-cause Internet applications to misbehave in terrible ways on the epoch
-of the next century. This document presents an analysis of the various
-hazards that might result in incorrect time values upon this epoch. It
-concludes that incorrect time values due to the NTP timescale, protocol
-design and reference implementation are highly unlikely. However, it is
-possible that external reference time sources used by NTP could
-misbehave and cause NTP servers to distribute incorrect time values to
-significant portions of the Internet. Note that, while this document
-addresses the issues specifically with respect to Unix systems, the
-issues are equally applicable to Windows and VMS systems.
-
-<h4>The NTP Timescale</h4>
-
-It will be helpful in understanding the issues raised in this document
-to consider the concept of a universal timescale. The conventional civil
-timescale used in most parts of the world is based on Universal
-Coordinated Time (UTC sic), formerly known as Greenwich Mean Time (GMT).
-UTC is based on International Atomic Time (TAI sic), which is derived
-from hundreds of cesium clocks in the national standards laboratories of
-many countries. Deviations of UTC from TAI are implemented in the form
-of leap seconds, which occur on average every eighteen months. For
-almost every computer application today, UTC represents the universal
-timescale extending into the indefinite past and indefinite future. We
-know of course that the UTC timescale did not exist prior to 1972, the
-Gregorian calendar did not exist prior to 1582, the Julian calendar did
-not exist prior to 54 BC and we cannot predict exactly when the next
-leap second will occur. Nevertheless, most folks would prefer that, even
-if we can't get future seconds numbering right beyond the next leap
-second, at least we can get the days numbering right until the end of
-reason.
-
-<p>The universal timescale can be implemented using a binary counter of
-indefinite width and with the unit seconds bit placed somewhere in the
-middle. The counter is synchronized to UTC such that it runs at the same
-rate and the units increment coincides with the UTC seconds tick. The
-NTP timescale is constructed from 64 bits of this counter, of which 32
-bits number the seconds and 32 bits represent the fraction. With this
-design, the counter runs in 136-year cycles, called eras, the latest of
-which began with a counter value of zero at 0h 1 January 1900. The
-design assumption is that further low order bits, if required, are
-provided by local interpolation, while further high order bits, when
-required, are provided by external means. The important point to be made
-here is that the high order bits must ultimately be provided by
-astronomers and disseminated to the population by international means.
-Ultimately, should a need exist to align a particular NTP era to the
-current calendar, the operating system in which NTP is embedded must
-provide the necessary high order bits, most conveniently from the file
-system or flash memory.
-
-<h4>The Year 2000 Era</h4>
-
-With respect to the year 2000 issue, the most important thing to observe
-about the NTP timescale is that it knows nothing about days, years or
-centuries, only the seconds since the beginning of the latest era, the
-current one of which began on 1 January 1900. On 1 January 1970 when
-Unix life began, the NTP timescale showed 2,208,988,800 and on 1 January
-1972 when UTC life began, it showed 2,272,060,800. On the last second of
-year 1999, the NTP timescale will show 3,155,672,599 and one second
-later on the first second of the next century will show 3,155,672,600.
-Other than this observation, the NTP timescale has no knowledge of or
-provision for any of these eclectic seconds.
-
-<p>The NTP timescale is almost never used directly by system or
-application programs. The generic Unix kernel keeps time in seconds and
-microseconds (or nanoseconds) to provide both time of day and interval
-timer functions. In order to synchronize the Unix clock, NTP must
-convert to and from its representation and Unix representation. Unix
-kernels implement the time of day function using two 32-bit counters,
-one representing the seconds since Unix life began and the other the
-microseconds or nanoseconds of the second. In principle, the seconds
-counter will wrap around in 136-year eras, the next of which will begin
-in 2106. How the particular Unix semantics interprets the counter values
-is of concern, but is beyond the scope of discussion here.
-
-<p>While incorrect time values due to the NTP timescale and protocol
-design or reference implementation upon the epoch of the next century
-are highly unlikely, hazards remain due to incorrect software external
-to NTP. These hazards include the Unix kernel and library routines which
-convert Unix time to and from conventional civil time in seconds,
-minutes, hours, days and years. Although NTP uses these routines to
-format monitoring data displays, they are not used to read or set the
-NTP clock. They may in fact cause problems with certain application
-programs, but this is not an issue which concerns NTP correctness.
-
-<p>While it is extremely unlikely that NTP will produce incorrect time
-values upon the epoch, it is possible that some external source to which
-NTP synchronizes may produce a discontinuity which could then induce a
-NTP discontinuity. The NTP primary (stratum 1) time servers, which are
-the ultimate time references for the entire NTP population, obtain time
-from various sources, including radio and satellite receivers and
-telephone modems. Not all sources provide year information and not all
-of these provide time in four-digit form. In point of fact, the NTP
-reference implementation does not use the year information, even if
-available. Instead, the year information is provided from the file
-system, which itself depends on the Unix clock.
-
-<p>The NTP protocol specification requires the apparent NTP time derived
-from external servers to be compared to the file system time before the
-clock is set. If the discrepancy is over 1000 seconds, an error alarm is
-raised requiring manual intervention. This makes it very unlikely that
-even a clique of seriously corrupted NTP servers will result in
-incorrect time values. In the case of embedded computers with no file
-system, the design assumption is that the current era be established
-from flash memory or a clock chip previously set by manual means.
-
-<p>It is essential that any clock synchronization protocol, including
-NTP, include provisions for multiple-server redundancy and multiple-
-route diversity. Past experience has demonstrated the wisdom of this
-approach, which protects clients against hardware and software faults,
-as well as incorrectly operating reference sources and sometimes even
-buggy software. For the most reliable service, we recommend multiple
-reference sources for primary servers, including a backup radio or
-satellite receiver or telephone modem. We also recommend that primary
-servers run NTP with other primary servers to provide additional
-redundancy and mutual backup should the reference sources themselves
-fail or operate incorrectly.
-
-<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
-href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
-</address></a></body></html>