DMWIN(1) SysV DMWIN(1)
NAME
dmwin - create a DM transcript/input pad pair and execute a program in it
SYNOPSIS
dmwin [[ switches program-name [ program-arguments ... ]]
DESCRIPTION
The dmwin command creates a DM transcript/input pad pair and runs the
specified program in it. It is intended to be used while you are running
the Apollo shared X server, you are typing to an xterm(1), and you want
to start a program that is going to try to "take over" the existing
window pad as is common in the Apollo environment (Interleaf's -w option,
/com/dspst, and many graphics programs behave this way). The tip-off
that you should be using dmwin is receiving an error message similar to
"attempted operation is illegal on this stream (stream manager/IOS)" when
you try to start a program from an xterm(1).
dmwin exists to bridge a fundamental difference between the Apollo DM pad
calls system of creating windows and the X window system (see
"EXPLANATION" below).
If the first argument is present, it is either a switch or the name of
the program to be run inside the wrapper. Any further arguments are
passed as arguments to this program.
Permissable switches include the "-r" switch to specify rawmode, and the
"-f filename" switch to specify the name of a file to be used for
standard input.
IMPORTANT NOTE: Unless a "-f filename" switch is used, standard input is
automatically asumed to be from "/dev/tty". This is done so that users
may execute dmwin fromm a script with an "&" at the end of the command
line to run it as a background process. It was found that when dmwin was
executed in this manner, standard input was assumed to be from /dev/null,
which caused problems when a call was executed in the newly created DM
pad. Since it is expected that the priority of dmwin users will want to
execute dmwin from an X window manager starrtup file as a background
process, it seemed more appropriate to require the switch only when the
dmwin user requires redirection of standard input. Hence, the "-f
filename" switch.
The SHELL environment variable is used to identify the particular shell
which is to be used. If this variable is not defined, the /com/sh shell
is used.
You can also use dmwin from an xterm to run programs such as /com/mail
and /com/dsee that need a DM pad for full-screen operation, rather than
suffering them in line-by-line "teletype" mode in the xterm window.
If you use dmwin in a DM pad, it looks at the current standard input and
output streams. If they are both DM pads already, is just invokes the
given program with the given arguments. If either is not a DM pad, it
creates a new DM transcript/input pad pair (using the DM's system for
default size and position), and runs the given program with the resulting
streams as its standard ones. It uses the SHELL environment variable to
determine what type of shell to run in the DM pad.
If you do not want to remember to type "dmwin" you can set up command
scripts or aliases to make invocation of commonly-used Apollo commands
look "Just Like Real Aegis" regardless of which type of window you are
typing in.
Since Apollo graphics programs (pad calls included) cannot execute
remotely over a network the way that X clients can, dmwin does not work
if the xterm you are typing to is on a remote machine-- the graphics
program will try to execute on the remote machine. The xterm must be on
the local server.
EXAMPLE
prompt% dmwin ops -w &
EXPLANATION
In the Apollo environment, programs wishing to create and manipulate
windows do so with pad calls. Practically all pad calls take an IOS
(Input/Output Stream) stream ID as an input argument. This stream is
assumed to be connected to an Apollo DM pad, and the pad call will fail
if it is not. This stream is used as the channel over which to send a
request to the DM to do something, such as to resize the window in which
the pad appears. Furthermore, these streams are used in the
initialization calls of the varius Apollo graphics packages, if they are
to work within an Apollo window.
Most Apollo native window/graphics programs "inherit" the DM transcript
session which they ASSUME they were run from. This means that the
programs do not try to create new windows and streams with pad calls, but
instead use a standard stream (typically ios_$stdout) to operate on. The
user's view in this case is that the transcript window is cleared of
text, and the graphics session starts up in the same area. Examples of
such programs are /com/dspst and Interleaf (if you give the '-w' option).
These programs depend on the assumption that the standard output stream
is in fact connected to a DM pad.
X does not have this stream/pad idea. In X, applications always create
their own windows, which have window ID's, not stream ID's; they then can
manipulate the window via Xlib calls; and when the program exits, its
windows are deleted. Terminal sessions are not a special case as they
are in the DM; instead, there is a particular kind of application called
a terminal emulator, which acts very much like the Apollo VT100 emulator.
The xterm program is the prime example of this. Such a program does X
calls to create a window and draw text in it, and it also forks a shell
whose standard streams are connected to pseudo-tty's controlled by it.
So the shell and the programs it runs have standard streams connected to
a pty, not a DM pad.
This fundamental difference in approach comes to a head when you are
sitting in an xterm and you try to run a program that wants to inherit
the xterm's non-existent DM pad stream IDs. Hence the error message:
"attempted operation illegal on this stream (stream manager/IOS)."
dmwin is thus a "wrapper" function that, when run from an xterm creates a
new DM transcript window, hooks up the standard streams to it, and then
invokes the desired program.
Programs that do not make assumpsions about their standard input/output
stream (those that borrow the display or those that run themselves in a
new window by using a pad_$CREATE_WINDOW call) will work when invoked
from an xterm(1) without needing dmwin.
dmwin is written in Pascal. The source is in /domain_examples/X11/dmwin
COPYRIGHT
Copyright 1988, 1989, Apollo Computer, Inc.
See X(1) for a full statement of rights and permissions.
AUTHOR
Dave Gorgen, Apollo Computer, Inc.