xwindow@mcrsys.UUCP (XWindow Install) (04/24/89)
This is my first post(age?) but I'm making up for lost time.
This is in responce to a few queries about porting X to SYS V boxes,
as well as to ask: Has anyone else been foolish enough to do this?
The following doc describes my port of X11R3 to Microport SYSV.3/386 3.0e.
No flames about choice of Vendor, that's the way the cookie crumbles.
I'm posting it to try and make someone else's life easier, I hope it will.
I was off the net for about 6 months, living in the DOS community, and
I'm curious if anyone else ported X11 onto a 386PC, and whether a 'public-
domain' posting has been make. I am considering posting my solution,
pending permission from Rick, and no death threats from corporate attorneys.
Tony Becker
uunet!mcrsys!tony
-----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 -
------CUT HERE------
/Tony Becker
/MCRSYS
/Aptos Ca.
/uunet!mcrsys!tony
/______________________________________________________________________________