Greetings -
Since adding some NT 4.0 (Intel) workstations to our LAN with existing
DU 3.2G and DU4.0B Servers and Stations, I'm trying to find an elegant
solution to some incompatibilities between HummingBird Exceed running
on the NT machines and {X,DEC}windows on the DU machines.
If a user has a DXterm file named 'DXterm' and it was created via the
Options, Save Options pull-down menu item in a DECwindow, then Exceed
fails to open a window (even if they specify a
'-setup <Exceed-specific-DXterm-file>' parameter).
Exceed's attempts to open a window are fraught with copious quantities of
errors like the following and I also get numerous non-easily-killable phantom
windows - blank, AFU, and hosed:
X Error code BadGC (invalid GC parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadGC (invalid GC parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
X Error code BadDrawable (invalid Pixmap or Window parameter)
The same holds true in the vice versa situation where I delete the DXterm
file, create a DECterm via Exceed from an NT machine, then Save Options;
the DU DECwindow (even if I specify a '-setup <DU-specific-DXterm-file>'
parameter) has the same errors and phantom windows.
Work-arounds are many and none of them are very elegant. Has anybody
worked with this and found an elegant solution? The solution of not having
files named DXterm, but DXterm-DU and DXterm-exceed works for applications
which allow the '-setup' parameter, but few actually do; Plus, since users
have grown accustomed to customized {X,DEC}windows for all applications,
not having that feature is unacceptable. Creating a script (login shell)
to rlogin to which then checks the type of access and has logic to do the
"Right Thing" to then spawn off an application is a kludge at best.
A typical CDE ACTION file (*.dt on DU) has an EXEC_STRING like:
EXEC_STRING /usr/bin/X11/dxterm -ls -setup DXterm-132R -geometry 132x70+400+90 &
where the DXterm-132R file specifies colors, titles, etc...
A typical Exceed X session starter uses RLOGIN (or REXEC or RSH...) to create
an Xwindow using a command like:
/usr/bin/X11/dxterm -ls -setup DXterm-exceed -geometry 132x70+15+125 -display
host.subnet.domain:0.0 &
where the DXterm-exceed file specifies colors, titles, etc...
All of this was simply fine before we added NT4.0 and Exceed to the LAN, now
we've got a problem with users who use both DU machines and NT machines to
access their accounts via DECwindows.
Any ideas?
Summary pending responses.
Randy Hayman
haymanr_at_icefog.alaska.edu
Received on Thu Jul 10 1997 - 20:38:19 NZST