It is beyond the scope of this document to even give an introduction about the correct installation of the TCP/IP networking system. You must do this yourself or seek assistance elsewhere. It is only possible to say here that a PC working well in a TCP/IP based LAN network will also work with XFree86/OS2 (when all other prerequisites are matched as well).
With IAK, there is a special configuration necessary, unless you want to use XFree86/OS2 only during a hot link to your Internet provider, the so called ``localhost'' or ``loopback'' configuration. This is a local network interface which ``loops'' back to the same host. The following settings are necessary for this:
\tcpip\etc\hostswith the following content:
If you don't have such a tcpstart.cmd file (Warp 4 calls this file
ifconfig lo 127.0.0.1 up
\MPTN\BIN\MPTSTART.CMD), create one, and add a line like the following to your config.sys file:
CALL=C:\OS2\CMD.EXE /Q /C C:\tcpip\bin\tcpstart.cmd >NUL: (implying that your bootdrive is C:).
localhostas described in the last section.
[C:\] ping localhost
You don't need this ``loopback'' interface if your PC is connected to a LAN (either directly or through SLIP/PPP).
In case of a SLIP/PPP line, you have to establish this connection BEFORE you start XFree86. See the next section for more details.
Note that the ability to use host names, for instance in the After you have added the required settings and setup a working network,
variable, correlates with the existance of a name resolver. If you don't
have a LAN-based DNS server available, you have to add the relevant hostnames
HOSTS/ file. The TCP/IP configuration dialogue in your system configuration folder allows you to edit this file.
checkinstall.cmd script coming with XFree86/OS2 gives some advice
on the configuration as well.
If you have problems to get this or other basic networking things running,
seek assistance in the FAQ, the xf86os2 mailing list
or the mailing list archive.
10.1. Dynamic IP ConsiderationsGenerally, the whole stuff works best, if your machine has a fixed IP address.
The localhost address, and also fixed (non-routable) local addresses
(10.x.x.x, 192.168.x.x, 172.16.x.x-172.31.x.x) work fine. A problem occurs
on both sides of such an X connection if there are dynamic IP addresses
involved, for instance in case of a PPP line to an ISP. Unfortunately, the
XFree86/OS2 net community hasn't come up with a set of helpful scripts yet
(which I would integrate), so there are here only some hints what the problem
really is: The X server listens for X protocol packets on some defined host/port socket. It gets the information about the socket from either the
command line or the resolved hostname (which it gets from the
or the DNS server). Here the
HOSTNAME variable comes into play. Once the
server is running, a change in the IP/HOSTNAME configuration won't be
recognized any more. Thus, the general approach for X over a dynamic IP line
is: build the connection to the ISP first, then start the server. The
relevant script that is responsible for starting the server is the startx.cmd
script which executes (indirectly) the \XFree86\lib\X11\xinit\xinitrc.cmd
script. You have to modify these scripts in order to set the
DISPLAY variables correctly and start the server with the right IP address.
The X server log shows, right to the beginning, at which IP address it is
listening, for debug purposes.
10.1.1. Configuring X for Your Hardware
xf86config program to create a standard configuration file
Y:\XFree86\lib\X11\XF86Config from a windowed
or full screen OS/2 text session:
After you have added the required settings and setup a working network,
xf86config program will ask a number of questions. You will need
the information obtained from the SuperProbe program here. The program should
be self explanatory; if you have problems to understand something though, seek
assistance in the newsgroups.
It is possible, but strongly discouraged for the non-expert, to edit the
XF86Config file with a text editor. In a few situations as described in
the FAQ, however, this might even be mandatory. This file is not a hacker's area,
such as the Win95 registry, but it has in common with it that you can
easily cause damage.
For details about the
XF86Config file format, refer to the
XF86Config(4/5) manual page.
If you know the configuration process from Linux or other XFree86 platform, you will encounter a few differences:
for a MouseSystems compatible mouse, for instance.
DEVICE=D:\OS2\BOOT\PCLOGIC.SYS SERIAL=COM1 DEVICE=D:\OS2\BOOT\MOUSE.SYS TYPE=PCLOGIC$
xf86configprogram. If you encounter incorrect settings, please send a mail to
XFree86@XFree86.orgdescribing in detail what is wrong. Even with XKB, you have the option to replace some key settings with a xmodmap file. See the man page for xmodmap for details (or use some available xmodmap file from Linux - they are the same).
In most cases, an existing
XF86Config file for the same XFree86 version
from Linux or another platform may be used without changes. There are two
prominent exceptions: some S3 805 based VLB cards put their video memory
in odd locations, and there seems to be an unresolvable PM driver
inconsistency with Matrox cards.
For S3 VLB cards, the X server can search for this memory by experimentally mapping and unmapping possible memory regions. However, in XFree86/OS2, the OS may run out of memory tiles during this process. If this happens, you must find out the location of the memory yourself and add it as an option
to the section "Device" of your XF86Config file.
For Matrox cards, the X server may fail to detect the PCI ID of the card correctly, as the PM driver and Matrox BIOS may have reprogrammed the card's PCI configuration in a non-standard way. The server will then fall into a VGA compatible mode at 320x200 resolution. To prevent this, add a
to the section "ServerFlags" of your XF86Config file.
Once you've set up a XF86Config file, you can fine tune the video
modes with the
xvidtune utility. Note this is an X11 program which
has to be executed in a local xterm window of a running X server, not in
a PM window.
16mb of memory is a recommended minimum for running the network software, X and the presentation manager in parallel. The server, window manager and an xterm take about 4-6 Mb of memory themselves. X will start up on a system with 8MB or less, but the performance will severely suffer from heavy disk swapping. Your mileage may vary, though, so some people might consider this still tolerable.
Some more on resource requirements: With the arrival of complex desktops like WindowMaker, KDE, Gnome, Enlightment, etc. which add a lot of graphical features, resource requirements grow. The X server will cache used fonts and resource settings internally, and depending on the number of windows (backing- store) it may require much more memory and swapspace than the mentioned few MBs. Also take into consideration that X runs in parallel to PM which also takes its share. My own system, albeit meanwhile rather outdated, is a PII-233 with 128MB, however, it is a development system. 64 MB are meanwhile standard, and okay for the purpose, and my laptop runs Aurora with XFree86 in 32MB, as well.
The easiest way for new users to start X windows is to type:
in a PM CMD window. People have reported problems when starting this in a fullscreen session or through a remote telnet session, so don't try it.
To get out of X windows, type: ``
exit'' in the console xterm.
You can customize your X by creating
.twmrc files in the directory that the
variable points to. These files are described in the xinit and startx
By default, the systemwide
xinitrc file (in
installs the rather simplistic
twm window manager. You can find better
window managers on the ported software page at
Do you really want to rebuild XFree86/OS2 from source? Read the file OS2.Notes on details to recompile XFree86/OS2 from scratch.
The easiest way to build a new client (X application) is to use
xmkmf if an
Imakefile is included in the sources. Type
xmkmf -a'' to create the Makefiles, check the configuration if
necessary and type ``
xmake'' is a wrapper for the
GNU make program which defeats the improper SHELL setting typically found
in a Makefile generated from an Imakefile. Also see the XFree86/OS2 FAQ
for more hints about porting X clients.
Many thanks to:
$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/OS2.sgml,v 18.104.22.168 1999/12/20 12:55:51 hohndel Exp $ $XConsortium: OS2.sgml /main/4 1996/03/11 10:46:06 kaleb $