Chapter 6: Developing Phase: Migrating the User Interface

This chapter describes how to migrate from a UNIX user interface (UI) to a Microsoft® Windows® user interface. As a majority of UNIX graphical interfaces are built on X Windows and Motif, once you know about the support available on Windows for X Windows and the differences between the UNIX user interface and the corresponding Windows UI, you can follow the steps required to migrate the user interface of X Windows, Motif, and POSIX applications to the Windows UI.

On This Page

X Windows Support on Windows Services for UNIX 3.5 X Windows Support on Windows Services for UNIX 3.5
Migrating Character-based User Interfaces Migrating Character-based User Interfaces
Porting OpenGL, Motif, and Xview Applications Porting OpenGL, Motif, and Xview Applications

X Windows Support on Windows Services for UNIX 3.5

The X Windows system is a portable, network-transparent Windows system that runs on many different computers. Any X Windows system consists of two distinct parts:  the X server and one or more X clients. The server controls the display directly and is responsible for all input and output (I/O) through the keyboard, mouse, or display. The clients do not access the screen directly. Instead, they communicate with the server, which handles all I/O requests. It is the clients that do the "real" computing, such as running applications. Each client communicates with the server, causing the server to open one or more windows to handle the I/O requests for that client.

Windows Services for UNIX 3.5 includes many X Windows-based client programs that you can start from within Microsoft Interix. These programs, which include xterm, xlsfonts, and xrdb, are compiled using X11R5 and X11R6 libraries to run with the corresponding servers. Some of these programs are provided for only one version of the X Windows system, but most programs compiled for use on X11R5 servers are capable of running with X11R6 servers as well.

However, Windows Services for UNIX 3.5 does not include an X Windows-based server. You must first install and start an X Windows server program before using any X Windows-based client applications. In addition, you must have an X11 server running either locally or on a remote system before you can run any of the Interix X Windows-based clients on your computer. You must also set the DISPLAY variable in Interix as the name of the computer on which you want the X client output to be displayed. This would be either localhost:0.0 if you have a local X11 server running, or the remote-system name, where an X server is running. When a shell is started with Interix, the environment variable DISPLAY is set to localhost:0.0 by default.

Windows Services for UNIX 3.5 also supports the xhost tool, which is used to add and delete host names to the list allowed to make connections to the X server. The usage syntax of xhost is xhost [[+-]name...], where name is the host name to be added to the list allowed to make connection to the X server. The xhost + command grants access to everyone, while the xhost – command restricts access to only those on the list. More details on the xhost program can be found in the Help manual of Windows Services for UNIX 3.5.

The display of X client applications depends upon how you have configured your X11 server and which window manager you are running. Most X11 servers running under Windows have the following two display modes:

  • Single-window mode. One application window, the X root window, is open. All X clients exist in this window. You must use a window manager, such as twm(1X11R6). The twm window manager is one of the X Windows clients included with Interix. It can be run from the command line.

  • Multiple-window mode. Each X client application is opened in its own window. Individual windows are controlled by the Microsoft Windows window manager or an X Windows window manager.

Most X servers that run with Windows have a default X Windows window manager in the multiple-window mode. Hence, you do not need to necessarily start an X Windows manager to run a client except when you need to use the manager with settings that are different from the default.

By default, Interix also sets up your PATH to include the directory /usr/X11R6/bin, which is the location of the X11R6 client binaries. The XAPPLRESDIR environment variable, which is used by X clients to locate their resources, is set up for you as well.

X Windows Programs Supported by Interix

Table 6.1 lists the X Windows programs that are supported by Interix.

Table 6.1. X Windows Programs in Interix

X Windows Program

Description

Xman*

This tool is a manual page browser.

Xedit*

This tool opens a simple text editor for X Windows.

Xbiff*

This program displays a little image of a mailbox. When there is no mail, the flag on the mailbox is down. When mail arrives, the flag goes up and the mailbox makes a sound.

Xcalc*

This tool is a scientific calculator desktop accessory that can emulate a TI-30 or an HP-10C.

Xeyes*

This tool is a follow-the-mouse X Windows demo that watches what you do and reports to the Boss.

xterm

This tool is a terminal emulator for X Windows.

xclock

This program displays the time in analog or digital form. The time is continuously updated at a frequency that may be specified by the user.

oclock

This program displays the current time on an analog display.

twm

This is a window manager for X Windows. It provides title bars, shaped windows, several forms of icon management, user-defined macro functions, click-to-type and pointer-driven keyboard focus, and user-specified key and pointer button bindings.

Note All X Windows programs marked with * are supported by X Windows System 11 Release 5 (X11R5). Therefore, to run such clients as xman, you need to add /usr/X11R5/bin to your PATH or give /usr/X11R5/bin/xman as the command.

Additional X Windows programs, such as rxvt,  are available for downloading at
https://www.interopsystems.com/tools/warehouse.htm.

Building X Windows Applications

The Interix Software Development Kit (SDK) contains X11R5 and X11R6 libraries, header files, and various other tools specifically designed for building X Windows applications.

Many of the tools provided as part of the Interix SDK (cpp, imake(1X11R5), xmkmf(1X11R5), mkdirhier(1X11R5), and makedepend(1X11R5)) are necessary to build X11 software packages provided by third parties.

When you are building an application, you must include the appropriate X11 header directory as part of the object compilation as follows:

CFLAGS = -O -I/usr/X11R5/include

or

CFLAGS = -O -I/usr/X11R6/include

You must also include the libraries and place them after the object files as follows:

XLIBS = -lXaw -lXmu -lXt -lXext -lX11

For the X11 versions of functions to be linked, include general purpose libraries after the X11 libraries:

XLIBS = -lXaw -lXmu -lXt -lXext -lX11

You must include the -L directive (library location) before the object file:

XLIBDIR = -L/usr/X11R5/lib

or

XLIBDIR = -L/usr/X11R6/lib

Some applications use the xrdb(1X11R6) tool to create the application default files. When you build these applications, you must set your display and start the X11 server before you start the build process.

Many X Windows applications come with Imakefiles. You can create a makefile from an Imakefile using either xmkmf(1X11R5) or imake.

If you use xmkmf to build an application from an Imakefile, you will see the following output:

mv Makefile Makefile.bak
imake -DUseInstalled -I/usr/X11R6/lib/X11/config

You can use imake directly, but you might need to pass appropriate -D and -I options. You can type the previous command as an imake command:

imake -DUseInstalled -I/usr/X11R5/lib/X11/config

or

imake -DUseInstalled -I/usr/X11R6/lib/X11/config

After building the makefile, you can build the application with make.

Note To install the shared X11 libraries, during installation, install the GNU SDK component.

Migrating Character-based User Interfaces

Not all UNIX interfaces are graphical. Character-based interfaces were the original mainstay of UNIX computing long before the graphical workstation was developed. The following two options are available for character-based interfaces:

  • Migration to the Interix environment can take place with minimal change.

  • Replacement of the character-based interface with the graphical interface (Windows-based or HTML).

A preliminary port to Portable Operating System Interface (POSIX) using POSIX terminal I/O ensures a smooth migration to Interix.

POSIX Terminal I/O

The POSIX termios structure and a new set of access calls replace the two traditional terminal hardware interfaces, namely termio structures in System V and stty structures in Berkley Software Development (BSD).

The POSIX input/output (I/O) model is very similar to the System V model. The following two modes exist in the POSIX I/O:

  • Canonical mode. Canonical input is line-based, like BSD cooked mode.

  • Noncanonical mode. Noncanonical input is character-based, like BSD raw or cbreak mode.

The Interix subsystem includes a true, noncanonical mode, with support for cc_c[VMIN] and cc_c[VTIME]. The termios structure is defined in Termios.h, as shown in the following listing:

struct termios {
tcflag_t c_iflag; /* input mode */
tcflag_t c_oflag; /* output mode */
tcflag_t c_cflag; /* control mode */
tcflag_t c_lflag; /* local mode */
speed_t c_ispeed; /* input speed */
speed_t c_ospeed; /* output speed */
cc_t c_cc[NCCS]; /* control characters */
};

The Interix SDK extends the POSIX.1 set of flags for c_iflag to include IMAXBEL and VBELTIME. For c_cc, VMIN and VTIME do not have the same values as VEOF and VEOL. However, for a portable application, a developer should take into consideration that VMIN and VTIME can be identical to VEOF and VEOL on a POSIX.1 system.

Table 6.2 lists the 12 new functions that replace the terminal I/O ioctl() calls, which include ioctl(fd, TIOCSETP, buf) and ioctl(fd, TIOCGETP, buf) or stty() and gtty(). They were changed because the data type of the final argument, for terminal I/O ioctl() calls, depends on an action that makes type checking impossible.

Table 6.2. Functions That Replace the Terminal I/O ioctl() Calls

Function

Description

int tcgetattr (int fd, struct termios *t)

Fetches attributes (termios structure).

int tcsetattr (int fd, int action, const struct termios *t)

Sets attributes (termios structure).

speed_t cfgetispeed (const struct termios *t)

Gets input speed.

speed_t cfgetospeed (const struct termios *t)

Gets output speed.

int cfsetispeed (struct termios *t, speed_t speed)

Sets input speed.

int cfsetospeed (struct termios *t, speed_t speed)

Sets output speed.

int tcdrain (int fd)

Waits for all output to be transmitted.

int tcflow (int fd, int action)

Suspends transmit or receive.

int tcflush (int fd, int queue_selector)

Flushes pending I/O.

int tcsendbreak (int fd, int len)

Sends BREAK character.

pid_t tcgetpgrp (int fd)

Gets foreground process group identifier (ID).

int tcsetpgrp (int fd, pid_t pgrp_id)

Sets foreground process group ID.

For the window size, use the TIOCGWINSZ command for ioctl() with the winsize structure, which are both supported.

Porting Curses and Terminal Routines to Interix

The Interix SDK libraries include libcurses, a port of the ncurses package, and libtermcap, the termcap routines. The Interix SDK also supports pseudoterminals. Porting such applications to Interix should be straightforward, but note the following:

  • The curses routines make use of the terminfo database, stored in /usr/share/terminfo. This location is different from the location used in traditional systems. To link with the terminfo routines, link with the curses library.

  • Interix supports both the BSD /dev/ptynn and the System V /dev/ptmx methods for opening the master side of a pseudoterminal. The System V method is slightly faster because the search for an available master device is handled by the subsystem. Currently, the Interix subsystem supports 265 ptys named /dev/ pty[p–zA–E][0–9a–f] on the master side. The corresponding subordinate side names are /dev/tty[p–zA–E][0–9a–f].

  • When using /dev/ptmx, the subordinate (slave) tty name can be obtained with ptsname(). BSD-based ioctl() calls can be used with the pty master side.

  • Provided that it is a session leader, a process without a controlling tty acquires a controlling terminal on the first open() call to a tty, unless NOCTTY is specified in the open() call.

Older, character-based terminal applications placed the cursor on the physical display screen based on the capabilities of the terminal. These capabilities were typically stored in the /etc/termcap file.

Note The mouse-interfacing features found in the ncurses source are not enabled for Interix. Interix does not support System V STREAMS.

Porting OpenGL, Motif, and Xview Applications

The Interop Systems Web site provides a product with Motif 2.2.2 development environment for the Interix technology in Windows Services for UNIX 3.5, with static libraries (and documentation). The OpenGL Development Kit version 1.3 with libraries and APIs for Windows Services for UNIX 3.5 is also included in the Interop Systems Web site.

Note Additional information is available at  https://www.interopsystems.com/Motif-OpenGL.htm.

The Xview toolkit is a toolkit for developing X11 programs and includes an X11 window manager for OpenLook behavior.

Note Additional information on downloading the Xview toolkit is available at https://www.interopsystems.com/tools/warehouse.htm.

Download

Get the UNIX Custom Application Migration Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions