netnews@wnuxb.UUCP (Heiby) (04/11/85)
Unix Technical Digest Thu, 11 Apr 85 Volume 1 : Issue 42
Today's Topics:
ITC window manager available (Andrew system)
Loading object files into executing programs (2 msgs)
No SIGHUP on carrier loss (2 msgs)
----------------------------------------------------------------------
Date: 8 Apr 85 23:04:11 GMT
From: nichols@cmu-cs-h.ARPA (David Nichols)
Subject: ITC window manager available (Andrew system)
The Andrew System
Release 1 - Description
Introduction
Following discussions with IBM, it has been decided
that C-MU will distribute the Andrew system, developed
at the Information Technology Center to support the user
interface of campus applications. This is experimental
software, and is far from complete, but it has been in
use for more than a year at the ITC. The ITC expects to
continue development of this software, and may release
future versions.
The software will be distributed in source form on an
``as is'' basis, with no committment from either C-MU
or IBM to support of any kind, or to future releases.
C-MU will levy a charge of $100 to cover distribution
costs.
The software is the property of IBM, and will carry IBM
copyright. Recipients will be required to sign a
license form, which will allow use for research and
educational purposes, and will forbid re-distribution.
Licenses will be granted to Universities, and to a lim-
ited number of non-University sites. C-MU expects to be
able to ship tapes early in February 1985. To obtain a
license, contact:
Distribution Coordinator
Information Technology Center
Carnegie-Mellon University
Schenley Park
Pittsburgh PA 15213
(412)-578-6700
The Andrew system has been in normal use at the ITC for
many months on a network that now includes about 60 Sun
100U and 120 workstations and several VAXen. It con-
sists of:
1. A window manager, which runs as a user-level
process on an un-modified Sun 4.2BSD kernel and
drives either the Model 1 or Model 2 monochrome
displays, or the Model 1 color display.
2. Many client programs, including editors,
shells, clocks, performance monitors, and so on.
These communicate with the window manager using
TCP/IP stream sockets, and should run on any
4.2BSD system; they are known to run on both Suns
and VAXen.
3. A user interface toolkit, used to build many of
the clients, that may be used to construct further
clients with a compatible user interface. It im-
plements, among other objects, dynamically re-
formatted multi-font, multi-size, proportionally
spaced text, with cut-and-paste between windows.
Programs using these facilities may generate output
to be printed via either the troff or Scribe text
formatters.
4. A large collection of display fonts, including
Roman, Bold, Italic and Bold Italic in Serif, San-
Serif and Typewriter styles and sizes from 6 to 36
points. These are derived from Metafont descrip-
tions supplied with TEX, and are public-domain.
These programs are in the process of development, and
must be regarded as experimental. We would be glad to
accept any comments or suggestions for improvements
(please mail them to andrew%cmu-itc-linus@cmu-cs-
pt.arpa), but the software is supplied as-is and there
is no support of any kind.
The Window Manager
The window manager wm is a program that runs as a user-
level process on a workstation, and makes windows on
the display available as a network service. Clients
make remote procedure calls over TCP/IP stream sockets
to perform operations on windows. As supplied, wm in-
cludes drivers for the Sun 1 monochrome and color
displays, and the Sun 2 monochrome display. They use
no support from the kernel except the ability to mmap()
the display; the Sun windows support need not be con-
figured in. With the exceptions noted below, no kernel
modifications are needed. Porting wm to other displays
should be farily easy, developing the existing drivers
took 4-6 weeks each.
Two libraries are supplied to allow you to write new wm
clients. The source is in directories libwm and wm-
pascal.
The Client Programs
The client programs supplied include:
1. The edittext (sometimes called xyzzy) editor and
its associated programs (edit, edittool, and
StyleEditor).
2. Other programs built using the user interface
toolkit, such as typescript, and help.
3. preview, which displays DVI troff output.
4. h19 and telnet, based on a 24-by-80 emulator.
5. fe, the font editor.
6. clock, gvmstat, wdf, and other simple window
manager clients.
7. donz, dir, and lsh, which are experimental
icon or menu interfaces to UNIX.
Also included is TrmWM.c, a driver for Gosling's EMACS
that interfaces directly to wm. All existing Unix pro-
grams (including full screen editors such as vi) can be
run under the h19 or telnet terminal emulators.
The programs based on the toolkit typically have a print
option. This generates output for troff, but could be
changed to generate output for Scribe.
The Fonts
The fonts are public-domain and derived from Metafont.
They require some hand-tuning to cover deficiencies in
the resolution reduction process. A font editor is sup-
plied, and the ITC would be grateful if you would send
us any fonts you do tune for possible inclusion in fu-
ture distributions.
Documentation
We supply manual pages for the programs and libraries,
programmers guides for the window manager and the user
interface toolkit, and a tutorial introduction to the
system.
The documentation has been prepared with the entire ITC
system in mind. We are, at this time, releasing only a
small part of the system. You will need to ignore those
portions of the documentation dealing with parts of the
system which are not being released (such as the file
system, mail/bboards, and some printing software). This
software is still very much under development and may be
released in the future.
------------------------------
Date: 8 Apr 85 23:02:57 GMT
From: bjorn@dataio.UUCP (Bjorn Benson)
Subject: Loading object files into executing programs
Request for help:
I have a program "PROG" and a number of subroutines "SUB1", "SUB2", etc.
that are all in seperate files (PROG is an executable, SUB? are .o files).
What I would like to do is have PROG read in any of the SUB? object files
and execute them. There are three problems I see:
(1) Symbol resolution (dynamic linking)
(2) 'Text' expansion (a la sbrk(2))
(3) How to read the linked file in and know its start address
Solutions:
(1) Use ld(1) with various flags
(2) *** This is where I need help ***
(3) *** I need help here to, but I would guess a read(2)? ***
The solution does not have to be portable, but it needs to work under 4.2bsd.
I have looked at the Franz Lisp source and it seems to read object files
into the 'data' segment (via sbrk(2)) and I don't even know if they are
executable code or just data. (My problem requires executable code.)
I appreciate the time anyone takes to help me...
Thank you,
Bjorn Benson
..!uw-beaver!entropy!dataio!bjorn
------------------------------
Date: 10 Apr 85 15:36:31 GMT
From: mwherman@watcgl.UUCP (Michael W. Herman)
Subject: Loading object files into executing programs
Check net.sources from about 6 months ago. PADPowell@wateng
had posted some code he developed (twice actually). I have
an improved version of his code that I'm not ready to
distribute just yet.
On the subject of efficiency ...
I would like to know if anyone else is using Pat's code and
has attempted to speed up the dynamic loading. My quasi-
quantitative analysis shows it takes from 10-40 seconds of
elapsed time to dynamically load ~10 Kbytes of code image.
Of the total, about 2 seconds of elapsed time is needed to
invoke *ld* (regardless of whether you use *system()* or
*vfork* and *execv*). Most of the rest of time is spent in
*ld* itself. About 25% of this time is spent in the *read*
system call reading libraries (which, in my application, are
quite large (~500 Kbytes) and yes, compiled with cc -g ...).
*ld* seems to be doing a lot of optimization of the i/o
already so I don't expect to be able to speed *ld* up.
However, I expect things to speed up quite a bit when I drop
-g.
I would like to try eliminating the 2 seconds needed to
invoke *ld* by loading it into the program at "compile-time"
and calling it directly as an ordinary C function (or I
suppose I really should be dynamically loading it ;-) ).
This would involve turning the *ld* program into a function
(mostly just a name change and the problem compile-time
initialization of static variables). If anyone has done
this, plse let me know.
On the subject of *dbx* ...
At the moment a lot of my code has been compiled with -g to
leave the extra symbol table info lying around for *dbx*.
It would be nice to be able to have this information
preserved in the dynamically loaded code as well. I haven't
had any luck in trying to achieve this. Apparently, it is
the C compiler that causes this info to remain when an
executable code image is created by *ld* and *ld* is passive
in this regard (It just does the loading including the
forced loading of -lg (because it really just a .o file
masquerading as a .a library).) I've tried using *cc -A ...*
instead of *ld -A ...* to create the code image to be but
get all sorts of "multiply defined" msgs from *ld*.
Plse let me know if you have any suggestions that might help
solve this last point.
--
Michael Herman, Computer Graphics Laboratory, Department of Computer Science
University of Waterloo, Waterloo, Ontario, Canada N2L 3G1
UUCP: {allegra,ihnp4,watmath}!watcgl!mwherman
-or- {cbosgd,clyde,decvax,linus,tektronix,utcsrgv}!watmath!watcgl!mwherman
CSNET: mwherman%watcgl@waterloo.CSNET
ARPA: mwherman%watcgl%waterloo.CSNET@csnet-relay.ARPA
------------------------------
Date: 9 Apr 85 00:18:00 GMT
From: al@mot.UUCP (Al Filipski)
Subject: No SIGHUP on carrier loss
Here's the scenario: During an interactive session over a phone
line under UNIX, the user hangs up (in the telephone sense) the line.
The next person to dial in over that line (say, 10 seconds later) finds
himself connected to the abandoned session where the first user
left off. This has happened to me on VAXen under both SV and 4.1 BSD.
(I'm not sure exactly what the serial hardware was, either DZ11 or KMC11.
Also, although I didn't check it at the time, I have no reason to
believe CLOCAL was set). On one occasion I was taking a course at a
University and when I dialed up, I found myself logged in as the instructor
of the course. This is a security problem to say the least-- Especially
since the System V User's manual (Intro, p.5) recommends hanging up as
a way of terminating a session.
I looked at the code of some serial drivers, and there appears to be an
attempt to detect a loss of carrier on a tty line's modem (both at
interrupt and periodic scan) and to post a SIGHUP to that tty's family
of processes. It seems to me though, that the SIGHUP sometimes fails
to get posted.
Anybody know what causes this?
--
Alan Filipski, UNIX group, Motorola Microsystems, Tempe, AZ U.S.A
{allegra|ihnp4}!sftig!mot!al OR {seismo|ihnp4}!ut-sally!oakhill!mot!al
ucbvax!arizona!asuvax!mot!al
------------------------------
Date: 10 Apr 85 17:16:04 GMT
From: dave@lsuc.UUCP (David Sherman)
Subject: No SIGHUP on carrier loss
You have to check that your modem is configured to drop carrier detect
(CXR) when carrier is lost. Then make sure your driver picks up
a loss of CXR and sends a hangup signal to the UNIX process.
Dave Sherman, The Law Society of Upper Canada, Toronto
--
{utzoo pesnta nrcaero utcs hcr}!lsuc!dave
{allegra decvax ihnp4 linus}!utcsri!lsuc!dave
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)