build

SIP 1.5.0源代码

2000 version of the Platform SDK.  If you get errors while building
auth_ssl.c and gss_shim.c, it's a good bet that you don't have the
Windows 2000 Platform SDK installed and/or in your path properly.

     There is also considerable debate about how new mail is to be snarfed.
I am currently using something that seems to work with WinSMTP.  Look at
the definition of MAILFILE in imap-2000/src/osdep/nt/mailfile.h and at the
sysinbox() function in imap-2000/src/osdep/nt/env_nt.c to see what's there
now, so you have a clue about how to hack it.

     To build under Windows 95, Windows 98, and Windows NT, connect to
the imap-2000 directory and do:
	nmake -f makefile.nt
The resulting binaries will support SSL if either schannel.dll or
security.dll is installed in Windows.

     To build with MIT Kerberos support under Windows 95, Windows 98,
and Windows NT,connect to the imap-2000 directory and do:
	nmake -f makefile.nt
The resulting binaries will support SSL if either schannel.dll or
security.dll is installed in Windows.  They will also support MIT
Kerberos.  Note, however, that these binaries will only run on systems
which have the MIT Kerberos DLLs installed, and will not run on other
systems.

     For Windows 2000, connect to the imap-2000 directory and do:
	nmake -f makefile.w2k
The resulting binaries will support SSL and Microsoft kerberos.  Note,
however, that these binaries will only run under Windows 2000 and will not
run under earlier Windows systems due to DLL conflicts.

     The resulting binaries will be:
	imap-2000\mtest\mtest.exe	(testbed client)
	imap-2000\ipopd\ipop2d.exe	POP2 server
	imap-2000\ipopd\ipop3d.exe	POP3 server
	imap-2000\imapd\imapd.exe	IMAP4rev1 server

     These servers are stdio servers.  I wrote a simple network listener
for NT called inetlisn; currently it is available as:
	ftp://ftp.cac.washington.edu/mail/nt/inetlisn.tar
To build this, use "nmake" after connecting to the inetlisn directory.
inetlisn takes two arguments, the first being the port number and the second
being the binary to run to serve a connection on that port, e.g.
	c:\bin\inetlisn 143 c:\mail_daemons\imapd

     Note that NT imapd must be started as SYSTEM in order to be recognized as
being "not logged in"; otherwise it will preauth as whatever user it is
running as which is probably not what you want.  One way to have it run as
system is to have inetlisn run by an AT command, e.g. if the time now is
2:05PM, try something like:
	AT 14:06 "c:\bin\inetlisn 143 c:\mail_daemons\imapd"

     Bottom line: this is not plug-and-play on NT.  If you're not a hacker
and/or are unwilling to invest the time to do some programming, you probably
want to buy a commercial server for NT.

			     DOS/WIN16 BUILD NOTES

     If you are building a DOS client, you will need a TCP/IP stack installed
on your DOS system along with its development environment.  The currently
supported stacks are Beame & Whiteside, PC-NFS, Novell, PC/IP, Waterloo, and
Winsock.  mtest and a version of Pine called PC Pine run under DOS.

      You do not use imap-2000/Makefile under DOS, nor do you build any
components other than c-client and mtest.  Merge the contents of
imap-2000/src/c-client, imap-2000/src/charset, imap-2000/src/mtest, and
imap-2000/src/osdep/dos onto a single directory on DOS and build from that.  The
MAKE command on DOS takes an argument identifying the TCP/IP stack in use.  For
example, do:
	MAKE MAKEFILE OS=WSK   (or MAKE -F MAKEFILE OS=WSK)
to build for Winsock.  

     If you write a program for DOS/Win16, you will probably have to write a
replacement cache manager (look at mm_cache()) and otherwise disable most of
c-client's caching.  Even so, memory limitations will be an ongoing problem,
particularly with DOS, and you will have some severe performance problems.
It's a bit better on Win16, but in my opinion you are better off writing a
32-bit program and telling your Win16 customers to upgrade to Windows 95 or at
least install Win32s.

			     MACINTOSH BUILD NOTES

     If you are building a Macintosh client, you will need MacTCP installed on
your system as well as the MacTCP C includes and libraries.

     You do not use imap-2000/Makefile on the Mac, nor do you build any
components other than c-client and mtest.  Merge the contents of
imap-2000/src/c-client, imap-2000/src/charset, imap-2000/src/mtest, and
imap-2000/src/osdep/mac onto a single directory on the Mac and build from that.
mtext.sit.hqx is a THINK C project file and cute icon for building mtest,
encoded with Binhex and StuffIt.

     THINK C is a truly wretched product which help make me understand why
Macintosh has lost most of its market share.  Not only does it do cretinous
things such as barf about a cast in front of an lvalue, it also limits the size
of code *or* data in a single file to 32K!  So much for having large character
set tables.  Symantec says that "MacOS requires it, break up your files into
smaller pieces" yet somehow gcc under MachTen contrives to compile C programs
without subjecting the programmer to this idiocy.

     As a result of this, I found myself obliged to comment out the #includes
of the East Asian character sets in utf8.c in order to get it to build.  It's
also necessary to break up some of the files, at least mail.c and imap4r1.c.
Maybe you don't have to do this in CodeWarrior or whatever the new compiler is
called, but I've pretty much given up on Macintosh.

     If you use precompiled headers, you may get some compilation errors since
some Apple symbols need to be redefined in order to get it to build under all
versions of MacOS.  Try turning off the precompiled headers (so it will
re-read the .h files) and see if it builds any better.

     If you use a Mac C compiler with 2-byte ints (such as THINK C's normal
mode) you will need to fix some bugs in the MacTCP C includes and libraries to
prevent it from generating bad code, since those MacTCP files violate Apple's
standards of always using explicit shorts or longs, never ints.  You could
avoid this if you set 4-byte ints in THINK C; however, the ANSI and UNIX
libraries in THINK C use 2-byte ints so you will also need to build 4-byte int
versions of these.  c-client itself is 2-byte int or 4-byte int clean; it can
be used in either mode.

     The most important bug in the MacTCP files that you need to fix is in the
file AddressXlation.h, you need to change the definition of the rtnCode member
of the hostInfo structure to be long instead of int.  There are several other
changes you need to make if you decide to compile dnr.c under THINK C instead
of using the Apple-supplied object file; see me for details if you decide to
undertake such an effort.  This is fixed in newer versions from Apple.

			     TOPS-20 BUILD NOTES

     I have provided a c-client port for TOPS-20 systems, but you're on your
own in terms of a nice TOPS-20 like main program.  Maybe someday some nice
person will try porting Pine to TOPS-20.  I recently built mtest on TOPS-20
(thank you, XKL!!), so the sources are known to compile with the ANSI C
version of KCC.

     You do not use imap-2000/Makefile under TOPS-20, nor do you build any
components other than c-client and mtest.  Merge the contents of
imap-2000/src/c-client, imap-2000/src/charset, imap-2000/src/mtest, and
imap-2000/src/osdep/tops-20 onto a single directory on TOPS-20 and build from
that.  The command:
	DO BUILD.CTL
will build the sources.  If you don't have MIC, then SUBMIT BUILD.CTL and let
BATCON execute it.

     KCC loves to give lots of diagnostics about unused parameters.  That's
perfectly alright; just ignore them.

			       VMS BUILD NOTES

      You do not use imap-2000/Makefile under VMS, nor do you build any
components other than c-client and mtest.  Merge the contents of
imap-2000/src/c-client, imap-2000/src/charset, imap-2000/src/mtest, and
imap-2000/src/osdep/vms onto a single directory on VMS and build from that.  The
command to build it is:
	@BUILD MULTINET
or	@BUILD NETLIB
If you just do @BUILD it will build with dummy TCP code, and since only TCP
based drivers are provided here this isn't too useful.

     If you aren't on the Pacific coast of the US or Canada, you probably will
need to change the wired-in timezone in the BUILD.COM file.  Apparently, the
wonderful VMS system that DEC loves so much doesn't maintain any concept of
time zone; the VMS C compiler returns a null pointer from gmtime()!

     Otherwise you're pretty much on your own here.

		      AMIGA BUILD AND INSTALLATION NOTES

     See the UNIX build notes.  I can't tell you much more than that, since
the Amiga code was contributed.


			       WCE BUILD NOTES

     I build using Visual C++ 6.0 with the WCE extensions.  The current code
has SH3 wired in for the compiler building.

     To build under NT, connect to the imap-2000 directory and do:
	nmake -f makefile.wce

     The only binary produced is a cclient.lib file.  I haven't gotten as far
as building mtest on WCE, mainly because I don't have a stdlib library.


			       OS2 BUILD NOTES

     The OS2 port is incomplete.  There are no plans to continue work on it.