windows-NT

	           Concurrent Versions System (CVS)
		    ported to Microsoft Windows NT

Check the ../INSTALL file for information on the most recent version
of CVS which has been known to be tested with NT and/or Win95.

This port implements the full set of CVS commands, both local and
client.  It does not provide a CVS server for NT.  Multiple users can
access a common CVS repository, if they can mount the repository,
either directly or via a networked file system.

We don't distribute a .ZIP source distribution partly because, as far
as I can tell, PKZIP insists on munging long file names, which would
confuse the makefile for Visual C++.

To compile, use Microsoft Visual C++ on the file cvsnt.mak in the
distribution's top directory.  At least with the tar port I'm using,
the sources get extracted without carriage returns and you must add
carriage returns to the end of every line in cvsnt.mak.  It doesn't
seem to be necessary to add them to any other file.  This makefile was
generated with Visual C++ 5.x.  With Visual C++ 6.x you can also try
cvsnt.dsw.  For Visual C++ 2.x you probably are in the position of
digging through old versions of CVS for a cvsnt.mak and then updating
it.  Feel free to let us know about problems of this sort as with
other bug reports.

If you end up regenerating the MSVC makefiles and submitting a patch back to
us, please be careful.  MSVC appears to be trying to write absolute paths into
the diff/libdiff.mak file and a relative path to a file in the local MSVC
install in cvsnt.dep (this last only with MSVC 6.x).

Send bug reports to bug-cvs@nongnu.org.

As of May 1996, this port passed all of the tests in src/sanity.sh,
save the one that deals with reserved all-upper-case tags (BASE and
HEAD), due to a limitation in the NT command shell.  sanity.sh
provides pretty minimal feature coverage, but still gives me some
confidence it isn't totally broken.  The tests were run by defining
KLUDGE_FOR_WNT_TESTSUITE (see src/main.c).

To operate in client mode with old versions of CVS (1.9 and older),
you will need GNU patch.  To do compressed transfers with old versions
of CVS (1.8 and older), you also need gzip.  Note that you do NOT need
an rsh client if you are using the :server: access method (which uses
the internal rsh client), except perhaps for debugging.

To operate in local mode, you should need nothing other than CVS (that
is, you no longer need RCS, diff, &c, in order to run CVS).

One useful site may be the Congruent ports of various packages to
Windows NT, binary and source:

	ftp://microlib.cc.utexas.edu/microlib/nt/gnu/

In particular, microlib seems to have versions of GNU tar and gzip
which support long file names, which you will need to unpack the CVS
source distribution.

The Cygwin project is a port of various GNU tools for NT, providing
bash as the shell and gcc as the compiler.  Basically, you don't want
the stuff in this directory for CVS running under Cygwin; you want
the same stuff as for unix (../configure, Makefile.in, &c).  For
Cygwin information see

	http://www.cygwin.com/

Morten Hindsholm's port of CVS 1.4A2 to Windows NT may be useful if
you're modifying CVS itself:

	ftp://ftp.digex.net/pub/access/schueman/cvs/cvsnt14b.zip

Here are some other things which may be of interest for unix junkies:

	http://www.halcyon.com/gvr/vim/       (VI clone)
	ftp://wuarchive.wustl.edu/systems/ibmpc/gnuish/less177.zip

If you want to browse/edit the sources using Visual C++, we recommend
setting tab stops to 8 spaces, since that is what the CVS sources
expect.  The tab stop setting is in the "Editor" or "Tabs" section of
the "Options..."  dialog which is in the "Tools..." menu.

The following harmless warnings are known:

- regex.c: 103 warnings, mostly signed/unsigned comparison conflicts.
  I am not going to *touch* this code. :-) I got my fill of it when I was
  hacking GNU Emacs.

.\lib\getdate.c(760) : warning C4013: 'getdate_yyparse' undefined; assuming extern returning int
.\lib\getdate.c(1612) : warning C4102: 'yyerrlab' : unreferenced label
.\lib\getdate.c(1612) : warning C4102: 'yynewstate' : unreferenced label

Oct 1998 update: there are more now.  I've gotten lax about removing
the warnings lately :-( -kingdon.

CODING STANDARDS for Windows

For general coding standards, see ../HACKING.

In my opinion win32 is the right API to write to.  Microsoft seems to
be better about compatibility across versions than unix vendors (on a
good day, anyway)--the Visual C++ package I bought has not only win32
but also win16 too (that is, they also include Visual C++ 1.x).  As
far as I know there is only one win32 (not counting win32s or win32c
or whatever), not multiple versions.

ANSI C is also good.  As far as I know these calls work fairly well on
NT.

What one should avoid like the plague on NT (IMHO) is POSIX calls such
as stat().  These tend to be very poorly supported, and tend to break
from version to version or vendor to vendor (the latter being
particularly an issue on OS/2, with IBM, Watcom, and EMX all having
_very_ different C libraries).