X windows for the UNIXpc

Dave Glowacki dglo at kronos.ADS.COM
Tue Jun 6 11:27:55 AEST 1989


Here's the article from comp.windows.x on porting X to a non-networked,
System V machine.  From the sound of this, all we need to do is get a
halfway decent replacement for /etc/lddrv/wind and we'll have X on the 3b1.

-------Cut Here-----



					      MMMMCCCCRRRRSSSSYYYYSSSS CCCCoooonnnnssssuuuullllttttiiiinnnngggg,,,, AAAAppppttttoooossss CCCCaaaa....



       subject:	Port of	X11R3 To Microport    date: April 24, 1989
		SYSV.3/386 3.0e	EGA
					      from: Becker. AE
						    uunet!mcrsys!tony



			    _P_R_O_G_R_A_M_M_E_R_'_S__N_O_T_E_S



       1.  _P_u_r_p_o_s_e

	    The	purpose	of this	document is to describe	the  module
       changes/additions  of  the X11R3	Core software, Server Code,
       SYSV library additions, and Device Driver additions, as they
       pertain to porting said code.


       2.  _S_c_o_p_e

	    The	scope of this  document	 is  the  overall  software
       design  of  the	additions,  and	 not  to  actual X11R3 Core
       release.


       3.  _P_r_e_c_e_d_e_n_c_e

	    This document supersedes any previous documents of	the
       same name based on the Date, and	Time printed below.

       ____________________________________________________________
      |			     REVISION LEVELS			  |
      |_________________|___________________________________________|
      |	   Revision    |		   Reason		  |
      |_________________|___________________________________________|
      |	     1.0       |     Initial Release - April 23rd, 1989	  |
      |_________________|___________________________________________|

       Revision	Control	System
       $Header:	port.mm,v 1.2 89/04/24 00:53:57	xwindow	Exp $
       $Log:   port.mm,v $
       Revision	1.2  89/04/24  00:53:57	 xwindow
       cleaned up to release to	uunet

       Revision	1.1  89/04/23  16:54:37	 xwindow
       Initial revision






       Revision	1.0						  1



		      SYSV.3/386 EGA X Windows Port



       _P_r_e_f_a_c_e

	    I would like to take this time out to thank	 MIT,  DEC,
       and  the	 others	 for  releasing	X into the public domain. I
       have tried to convince a	number of  people  to  start  using
       UNIX  as	 a  software developement envirionment,	with little
       success.	Personaly, as a	designer, I  need  the	underly-ing
       power  of  the operating	system (UNIX vs	DOS), and its tools
       (CC/MAKE/CRONTAB/JOBCONTROL/EMACS) vs ..., and, to  a  major
       extent, I'm a purist, and I don't care about the	cost.

	    Like any programmer, I require the computer	 to  do	 my
       job. I have a 20Mhz 386 SYSV.3 worth about $8K. If I upgrade
       every two years,	it works out to	about 10%  of  Salary/Fees.
       If  someone  is paying me to work for them this doesn't seem
       like a lot of money to spend on capital equipment.   I  have
       worked  at  a company who prided	themselves on only spending
       $2K per programmer, but you only	got about 4  hours  of	cpu
       time  a day. When schedules started to slip, they hired more
       programmers, of course.

	    It has been	beaten into me that the	guy who	 makes	the
       desision	 usually  doesn't  know	 anything  about  operating
       systems,	or tools, but just likes to see	something like	ico
       running	on  the	 screen.   It is extreemly expensive (time-
       wise) to	train these people in computer productivity.

	    Additionally, there	is a large population of  computer-
       unfriendly  people out there that need a	simple front-end to
       protect themselves from what the	computer can do. Once  that
       population  is trained on a multi-tasking, multi-user, icon-
       driven window envirionment, that	will  run,  WITH  IDENTICAL
       USER  INTERACTION,  on his computer at his home,	office,	and
       at his next/past	place of work, ... THEN	this  industry	can
       start   developing  languages,  and  tools,  as	apposed	 to
       spending	money re-training  these  people  everytime  a	new
       OS/Program  comes  out.	 It is to this giant leap towards a
       common developement/work	platform that I	would like to thank
       MIT & Co.

       Stepping	down off my soap-box now...
       Tony.











       2					       Revision	1.0



		      SYSV.3/386 EGA X Windows Port



       _I_n_t_r_o_d_u_c_t_i_o_n

	    I get involved in graphics about once every	two  years,
       or so just to see whats happening. So, when X11R2 came out I
       started playing with it to see what I could do with  it.	 It
       became quite clear that I didn't	know near as much as my	ego
       thought I did about windowing  envirionments,  client/server
       applications, or	SYSV. In the middle of hacking apart X11R2,
       X11R3 was announced, so I took the opportunity to dive  into
       X11R2,  knowing	I  would  throw	 it away, and just see what
       would happen when I experimented	with the code. This allowed
       me to make some desisions about how to go and develope X11R3
       when I got it.

	    What I decided to do, was to assume	SYSV.4	would  move
       towards	NFS,  and  sockets.   With  this  in  mind, and	the
       assumption that most server clients were	being developed	 on
       SUN's,  and  other 4.2/4.3 systems, as apposed to my SYSV, I
       have tried to make my SYSV.3 box	look like a 4.3bsd  system.
       Thus,  whenever possible, I changed my system, as apposed to
       X11R3 code, by adding libraries,	or device drivers.

	    The	implications of	these assumptions are as follows:
	  - X11R3 ports	easily,	since it has SYSV hooks	in it. (the
	    only thing I can't change about my system.)
	  - X11R4 should also port easily, since I  have  not  made
	    any	drastic	changes	to X11R3.
	  - When SYSV.4	comes out I should be able to reduce my	lib
	    code, and remove some of my	device drivers.
	  - The	majority of the	changes	are in libraries and device
	    drivers,  written  (thus  owned)  and most importantly,
	    maintained by me,  so  they	 won't	be  different  next
	    release.
	  - X programs coming off the net should compile unchanged.



















       Revision	1.0						  3



		      SYSV.3/386 EGA X Windows Port



       4.  _I_n_s_t_a_l_l_a_t_i_o_n__O_f__C_o_r_e__R_e_l_e_a_s_e

	    Go and read	the Introduction. No skipping right to	the
       easy  part.  DO NOT install this	code on	any system that	you
       can't afford to have down for  two  days.  This	means  your
       company's  main file server.  While I didn't trash my system
       during the port,	 that  doesn't	mean  you  won't.  And,	 of
       course, back your system	up before installing any code.

	    I've made a	rash assumption	that you have the code.	 It
       can  be	obtained  from	your local archive site	(cheap), or
       down-loaded from	the net	 (expensive).	If  you're  reading
       this,  go  to the person	in charge of your uunet	access,	and
       ask him.	Failing	that, call:

		      UUNET Communications Services
			 3110 Fairview Park Drive
			       PO Box 2324
			  Falls	Church,	VA 22042
			      (703)-876-5050

	    It will cost you $35 to sign up, and/or  $200  for	the
       archive tapes.

	    The	Core release is	about 15Mb of source. Compiled,	 It
       takes up	about 35Mb, (without profiling)	so you'll need that
       space. If you don't have	a post-script laser printer, delete
       all  the	 *.PS,	and *.PS.Z files in the	hardcopy directory,
       you can't read them anyway. Start saving	to buy the printer.

	    Hunt  down	all  the  *.man	 files	 in   the   various
       directories,  format  and  print	 them.	Look in	the './doc'
       subdirectories for *.doc	files, and print  them.	  Now  read
       them.

       4.1  _I_m_a_k_e__I_n_s_t_a_l_l

	    The	first thing to do is to	go  to	the  './util/imake'
       directory  and  get  imake  to  compile	and run. Imake is a
       wonderful tool that takes  a  simple  'Imakefile'  file	and
       converts	 it  to	 a Makefile by parsing it and adding macros
       that you	tell it.  Documentation	 is  provided,	and  sample
       SYSV,	and    site-specific	files	are   provided	 in
       './util/imake.includes'.	 If your C compiler doesn't compile
       with  a	default	symbol,	add one	in imake.c.  Mine does,	but
       it's '-DUNIX', so I added '-DMCRSYS'. You'll  see  the  code
       from  other people. Edit	the Makefile to	you hearts content.
       It's NOT	generated by Imake.  You may  have  to	delete	the
       bandaid	compiler  stuff	 from  a  few of the Imakefiles.  I
       assume that this	was for	the supplied C pre-processor, but I
       don't know.


       4					       Revision	1.0



		      SYSV.3/386 EGA X Windows Port



       4.2  _M_a_k_e_d_e_p_e_n_d__I_n_s_t_a_l_l

	    This is where  I  started  to  run	into  problems.	 In
       'main.c'	 I  added,  with  a  conditional compile on '#ifdef
       MCRSYS',	an additional directive	to ignore, called  'ident',
       which  occurs  in  most	of my system header files.  Also in
       'main.c', for SYSV,  add	 your  conditional  to	the  'mips'
       signal code, and	to the chmod code at the end of	the file.

	    In 'include.c' there is code  to  check  for  a  linked
       file.  My file system isn't that	smart. I put a kludge in to
       check to	see how	many times  the	 file  is  linked,  but	 it
       doesn't	know  which  file is the original.  Additionally, I
       have 'stat(2)' not  'lstat(2)',	so  that  is  conditionally
       compiled.

	    Edit the Makefile by hand to get Imake to  compile	the
       first  time.  You'll  have  to add your conditional into	the
       makefile. Watch out to see that you add your  stuff  to	the
       last  occurance of a define like	'CFLAGS', it may occur more
       then  once,  the	 first	being  a  default.  You	 may   have
       unresolved  externals  like  'rename'. Make yourself a site-
       specific	library	(you are going to add to it), and add these
       subroutines. For	Microport users, rename() is simply:

       int rename(oldfile, newfile)
       char *oldfile, *newfile;
       {
       link(oldfile,newfile);
       return(unlink(oldfile));
       }

	    Now, go back and add the name of your site-specific	lib
       to 'SYSLAST_LIBRARIES' in your imake template/macro file.

       4.3  _C_h_e_c_k_f_n__I_n_s_t_a_l_l

	    Check  function  ('./util/checkfn/checkfn.c')  has	the
       same  stat  problem  as	the  include.c	file above. You	are
       required	to have	check function compile because it's one	 of
       the   dependants	  of   X11,   while   './util/patch',	and
       './util/compress' are not.

       4.4  _H_e_a_d_e_r__F_i_l_e_s

	    By now, you've tried to 'make World', and the make	has
       failed because:
	  - It can't find a header file.
	  - It includes	it twice, causing typedefs to fail.
	  - It can't find a definition,	and has	NO  IDEA  where	 to
	    look.


       Revision	1.0						  5



		      SYSV.3/386 EGA X Windows Port



	    To the former, you have three options:
	  - Go through all the	code,  and  make  your	own  header
	    files,  and	 then try and figure out the typedefs. This
	    is	the  wrong  way	 and,  of  course,  I  speak   from
	    experience.
	  - Go buy a TCP/IP, or	socket package from somebody.  This
	    will  cost	you  about $500-$1000. This didn't make	any
	    sense to me	since I	had no intension of  networking	 my
	    one, and only system.
	  - The	Header files are public	domain from the	 net.  This
	    is the prefered method.

	    To the second, go edit all your systems header files to
       have:

       #ifndef __STDIO.H__
       #define __STDIO.H__

	    At the beginning, and:

       #endif

	    At the end,	just like all the X11 header files.

	    To the third, its SYSV dependant, or site specific.	Try
       to  stick  to changing './X11/Xos.h', or	'./lib/X/Xlibos.h'.
       They seem to be included	everywhere. Things that	 will  need
       to  be  changed	are  the including of headers 'time.h',	and
       'sys/time.h', 'types.h',	and any	misc  headers  that  define
       site specific things like file control, path length, etc.

	    However you	aquire the header files, put  them  all	 in
       one  place  like	 '/usr/include/netinet',  and  link them to
       where ever they are really  required.  This  allows  you	 to
       maintain	 them  from one	known point, and separate them from
       your own	system headers.

       4.5  _F_o_n_t_s

	    In the './fonts' directory,	check  the  bit/byte  order
       defines	for  correct  order. The Core release is capable of
       compiling fonts,	and other glyphs for for different machines
       so  that	 you  can  run	the  server on one machine, and	the
       client programs on another.

	    For	Microport users, you must include  'dirent.h',	and
       define  'direct'	as 'dirent' in 'mkfontdir.c'.  This took me
       some time to figure out.	 Including 'dir.h',  as	 one  would
       assume,	solved	about  80%  of	the  problem,  but I wasn't
       looking to find two different directory structures.



       6					       Revision	1.0



		      SYSV.3/386 EGA X Windows Port



       4.6  _Y_o_u_r__C__C_o_m_p_i_l_e_r

	    By now, you've got Imake and Makedepend  to	 work,	and
       most  of	 the files compile.  Your compiler won't handle	the
       number of defines  in  './X11/keysymdef.h',  so	you  change
       compilers,  and	the  new one (after 25 minutes of cpu time)
       kernel panics on	'cfbbitblt.c'. You're about  3	weeks  into
       your  four week schedule, you haven't got the server to load
       yet, and	you're getting tired of	your (ex)friends saying	 'I
       could  have done	it in...'.  Just keep putting more sugar in
       their coffee.

	    I can't really help	you with your compiler.	I  switched
       from  the  supplied 'cc'	to the Green Hills 'gcc'. I haven't
       tried the public	domain gnu C compiler.	I can tell you that
       if  your	 compiler  won't  handle  the  includes,  or  macro
       expansions you're in for	a long uphill battle.

       4.7  _T_h_e__S_e_r_v_e_r

	    As supplied, the X11 Core release  comes  with  support
       for  SUN's,  Apollo's,  HP's,  etc.  There  is documentation
       supplied	on how to port for one of the supplied solutions in
       './doc/server'.	      You	 have	     to	       edit
       './server/include/servermd.h'  and  tell	 it   your   bitmap
       word/byte  order,  and  bit/byte	order, with the	conditional
       you defined above.

	    I tried porting from the SUN solution first, and  found
       that  between  all  the	SUN code, X11, and SYSV	stuff I	was
       dealing with too	many unknowns. I through out that code,	and
       went  with  the DEC qvss	sample server solution,	which comes
       with more doc, and is only three	simple files.

	    What you have to do	with these files is:
	  - set	your screen to a bitmapped graphics mode, and  pass
	    a pointer to the start of the screen to the	server.
	  - tell the server how	it can	check  when  the  user	has
	    input, either mouse, or keyboard.
	  - tell the server how	to process the input into its form,
	    when it occurs.

	    It should be noted that my solution	is  for	 an  IBM/PC
       EGA  card. The X11 server assumes (incorrectly in this case)
       that it is writing to a linear bitmap.  That is,	for a  mono
       (2  color)  server  a  byte represents 8	consecutive pixels.
       For  a  color  (16  color)  server  a  byte   represents	  2
       consecutive pixels, each	nibble being one pixel.

	    The	EGA card is set	up as four 64K planes, in the  same
       address space, and uses I/O to enable/disable the planes	for


       Revision	1.0						  7



		      SYSV.3/386 EGA X Windows Port



       pixel read/writes. The mono  should  work  with	the  planes
       globally	 enabled,  but	doesn't,  and the color	server will
       never work, as is.

	    The	VGA card is set	up to  handle  the  server  mapping
       correctly  to  a	 point.	  Mode 13 extensions allow 256/256K
       colors by mapping each byte to a	pixel.	Unfortunately,	The
       VGA  address  space  is	limited	 to the	EGA's 64K(128K), or
       about 320x200(320x400) resolution.

	    For	 an  exceptable	 800x600  mode,	  an   intermediate
       refresher  is  required for both	mono and color solutions. I
       chose 800x600 as	both my	mono, and color	resolution  because
       most EGA/VGA cards now support it as an extended	resolution.
       If you're a manufacturer	looking	 to  port  the	code  to  a
       hardware	platform, you will probably end	up tied	to specific
       EGA/VGA cards like the DOS/Merge	products until 800x600 is a
       standard.


       5.  _S_o_c_k_e_t_s

	    If you have	to write any socket code go  buy  'Computer
       Networks'  by Tanenbaum.	 You won't regret it. For those	who
       have to write emulation libraries here's	a quick	primer:

       int socket(soc_addr,soc_type,soc_opt)
       int soc_addr,soc_type,soc_opt;
       {
       /* ie: socket(AF_UNIX, SOCK_STREAM,0); */
       /* returns -1 for Can't open a new socket error,
	  0-N (a fildes) for allocated type */
       /* note that both ends open this	connection */
       /* ie; the server and client both make 'socket' calls */
       /* to open the connection */
	       return(fd);
       }
















       8					       Revision	1.0



		      SYSV.3/386 EGA X Windows Port



       int bind(soc_fd,unix_soc,name_len)
       int soc_fd,name_len;
       struct sockaddr *unix_soc;
       {
       /* attach the number (soc_fd) to	the struct unix_soc */
       /* and especially the file unix_soc.name	*/
       /* what this does is to mark a generic socket */
       /* connection as	a main link */
       /* unix_soc.name="/tmp/.X11-unix/X0", the main display */
       /* you'll have to open the file 'unix_soc.name' because */
       /* all the clients */
       /* need to find it, so they can connect to it */
	       return(0);
       }

       int listen(soc_fd, listen_req)
       int soc_fd, listen_req;
       {
       /* mark bound file as listening,	ie looking for connect requests	*/
       /* once the 'socket' is 'bound',	you set	it to listen for connects */
	       return(0);
       }

       int setsockopt(soc_id,soc_opt_mask,soc_opt,soc_opt_ptr,soc_opt_len)
       int soc_id,soc_opt_mask,soc_opt,soc_opt_ptr,soc_opt_len;
       {
	       return(0);
       }

       int connect(soc_fd,unix_soc,soc_addr_len)
       int soc_fd,soc_addr_len;
       struct sockaddr *unix_soc;
       {
       /* connect soc_fd to soc_addr, as apposed to binding */
       /* a client program will	open a socket, look for	a bound	file, */
       /* and send a connect request to	it */
       /* select() will	find the connect request */
	       return( 0 );
       }

       int BytesReadable(fd,int_ptr)
       int fd, *int_ptr;
       {
       /* return in int_ptr the	number of bytes	for the	socket 'fd' */
	       return(0);
       }







       Revision	1.0						  9



		      SYSV.3/386 EGA X Windows Port



       int select(num_sockets, rd_mask,	wr_mask, ex_mask, wait_timer_ptr)
       int num_sockets;
       long rd_mask[], wr_mask[], ex_mask[];
       struct timeval *wait_timer_ptr;
       {
       /* this is the nasti-est	piece of socket	code */
       /* given	read, write, and execute bit masks, check the given */
       /* sockets for activity,	time-out if requested */
       /* see poll(2) */
	       return(num_found);
       }

       int accept(soc_fd,soc_addr,soc_addr_len)
       int soc_fd, *soc_addr_len;
       struct sockaddr *soc_addr;
       {
       /* check	soc_fd (a bound-listener) for activity */
       /* return a new fd, a person to talk to */
		       return(fd);
	       else
		       return(-1);
       }


       6.  _P_s_u_e_d_o__T_e_r_m_i_n_a_l__S_u_p_p_o_r_t

	    Xterm talks	to your	shell via psuedo  terminals.  These
       are  really  fancy pipes	that look like terminals on one	end
       (/dev/ttyq0)  and   pipes   on	the   other   (/dev/ptyq0).
       Internally,  tty	 writes	 get  buffered	for  pty reads,	and
       vice-versa. The only nasty about	this code is  that  opening
       the pty must set	up u_ttyp, and u_ttyd in the user structure
       of the calling task, in order for the open of '/dev/tty'	 to
       work.  This  is	System V terminal code,	developed via trial
       and error, as apposed to	having any documentation.


       7.  _C_l_i_e_n_t__P_r_o_g_r_a_m_s

	    Once you have got the server  to  compile,	the  client
       programs	 should	compile	with no	changes. Most of the system
       dependant stuff will be found,  and  fixed  in  getting	the
       server  to  compile & run. Assuming that	your solution, like
       mine, was to make a  library  of	 missing  subroutines,	and
       change Imake to your system, the	client programs	should just
       compile and run.

	    The	 reason	 for  this  is	that   this   code   is	  a
       client/server  relation-ship.   This  means  that the server
       talks to	your system, and the client program  talks  to	the
       server.


       10					       Revision	1.0



		      SYSV.3/386 EGA X Windows Port



       8.  _C_o_n_c_l_u_s_i_o_n

	    These are the files	I have changed to get X11 to run on
       this system:

















































       Revision	1.0						 11



		      SYSV.3/386 EGA X Windows Port



	./X11/RCS/Xutil.h,v
	./X11/RCS/Xos.h,v
	./lib/Xaw/RCS/Load.c,v
	./lib/Xt/RCS/Imakefile,v
	./lib/X/RCS/Xlibos.h,v
	./server/ddx/cfb/cfbmskbits.h,v
	./server/ddx/cfb/cfbbitblt.c,v
	./server/ddx/mcrsys/RCS/Imakefile,v
	./server/ddx/mcrsys/RCS/mcrsysInit.c,v
	./server/ddx/mcrsys/RCS/mcrsys_io.c,v
	./server/ddx/mcrsys/RCS/mcrsys_kbd.c,v
	./server/ddx/mcrsys/RCS/keynames.h,v
	./server/include/RCS/servermd.h,v
	./server/os/4.2bsd/RCS/connection.c,v
	./server/os/4.2bsd/RCS/osinit.c,v
	./server/os/4.2bsd/RCS/access.c,v
	./server/os/4.2bsd/RCS/WaitFor.c,v
	./server/os/4.2bsd/RCS/io.c,v
	./server/RCS/Imakefile,v
	./fonts/mkfontdir/RCS/mkfontdir.c,v
	./fonts/bdftosnf/RCS/bdftosnf.h,v
	./clients/xterm/RCS/Imakefile,v
	./clients/xterm/RCS/main.c,v
	./clients/xterm/RCS/Tekproc.c,v
	./clients/xterm/RCS/charproc.c,v
	./clients/xmh/RCS/Imakefile,v
	./clients/xmh/RCS/command.c,v
	./clients/uwm/RCS/Menu.c,v
	./clients/xedit/RCS/Imakefile,v
	./clients/xinit/RCS/xinit.c,v
	./clients/x10tox11/RCS/resource.h,v
	./clients/xclipboard/RCS/Imakefile,v
	./clients/xman/RCS/Imakefile,v
	./clients/xman/RCS/man.h,v
	./clients/xman/RCS/man.c,v
	./clients/xdm/RCS/Imakefile,v
	./util/imake/RCS/Makefile,v
	./util/imake/RCS/ccflags.c,v
	./util/imake/RCS/imake.c,v
	./util/imake.includes/RCS/Imake.tmpl,v
	./util/makedepend/RCS/include.c,v
	./util/makedepend/RCS/main.c,v
	./util/makedepend/RCS/Imakefile,v
	./util/checkfn/RCS/checkfn.c,v
	./demos/xeyes/RCS/Imakefile,v
	./RCS/Imakefile,v
	./RCS/port.mm,v

	    With    the	   exception	of     the     files	 in
       './server/ddx/mcrsys',  no files	have any more then 10 lines
       of change in them.  'xinit'  files  were	 changed  to  debug


       12					       Revision	1.0



		      SYSV.3/386 EGA X Windows Port



       sockets,	 and 'xterm' files were	changed	to debug my psuedo-
       terminal	code.

	    As far as 'Porting'	to SYSV, the code has defines in it
       already.	 The  hardest part is trying to	make your SYSV look
       like their SYSV.	In my case Microport's SYSV.3 took a little
       more work then planned.














































       Revision	1.0						 13







MCRSYS Consulting, Aptos Ca.	 Cover Sheet for Technical Memorandum
_____________________________________________________________________
The information	contained herein is  for  the  use  of	employees  of
MCRSYS	Consulting,  Aptos  Ca.	  and is not for publication (see GEI
13.9-3)
_____________________________________________________________________


Title: Port of X11R3 To	Microport	     Date: April 24, 1989
       SYSV.3/386 3.0e EGA
					     TM:
Other Keywords:

Author(s)	    Location	Extension    Charging Case:
Becker.	AE	    uunet!mcrsys!tony	     Filing Case:









































_____________________________________________________________________
Pages Text: 13	 Other:	0	 Total:	13

No. Figures: 0	 No. Tables: 0	 No. Refs.: 0
_____________________________________________________________________
E-1932-U(3-76)SEE REVERSE SIDE FOR DISTRIBUTION	LIST









				 CONTENTS


       1.  Purpose.............................................	  1

       2.  Scope...............................................	  1

       3.  Precedence..........................................	  1
	   Preface.............................................	  2
	   Introduction........................................	  3

       4.  Installation	Of Core	Release........................	  4
	   4.1	Imake Install..................................	  4
	   4.2	Makedepend Install.............................	  5
	   4.3	Checkfn	Install................................	  5
	   4.4	Header Files...................................	  5
	   4.5	Fonts..........................................	  6
	   4.6	Your C Compiler................................	  7
	   4.7	The Server.....................................	  7

       5.  Sockets.............................................	  8

       6.  Psuedo Terminal Support.............................	 10

       7.  Client Programs.....................................	 10

       8.  Conclusion..........................................	 11



























				  - i -
-- 
Dave Glowacki          dglo at ads.com          Advanced Decision Systems



More information about the Unix-pc.general mailing list