[Info-vax] Decwindows Motif V1.1 kit

[johnwallace4 at yahoo.co.uk]

On Wednesday, 29 May 2019 08:35:36 UTC+1, Paul Hardy  wrote:
> Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> > On 2019-05-28 21:58:27 +0000, Paul Hardy said:
> > 
> >> The problem with more recent DECWindows such as CDE is that it 
> >> allocates colours at both top and bottom of the hardware colour table,
> > 
> > I'm going to infer that the code has dependencies on specific 
> > documented or possibly on undocumented behaviors of old and buggy 
> > DECwindows code, or of the particular graphics hardware involved.
> 
> It’s not very unusual for the period when the code was written, and the
> limited capabilities of the graphics devices of the time.  It’s allocating
> colours in the hardware colour table, such that switching off bits in the
> colour lookup table allows the manipulation of visual overlay of two or
> more datasets.
> > 
> > Switch to hardware with more planes, or debug the code.   Also have a 
> > look at the previous discussions of DirectColor and TrueColor, and what 
> > is supported with your particular graphics controller.
> 
> As I said, this is a software archaeology project, trying to archive a
> piece of digital mapping history for posterity. As such I’m trying not to
> touch the original code, but allow it to be seen in emulation on modern
> hardware.
> 
> > Old DECwindows has a lot of problems, and you're going to end up 
> > chasing those in addition to chasing whatever problems might arise in 
> > the particular app code involved here.
> > 
> The app works fine now when logged on as System, so I could stop there.
> However it would be more realistic to be able to run as an unprivileged
> user, which was always the case. I’ll continue to investigate as a
> background task. 
> 
> 
> -- 
> Paul at the paulhardy.net domain

There's a bit of a hint already if the app works OK when logged
on as SYSTEM, but fails when using the intended (non-priv'd,
in some sense?) account.

As you mentioned, process exit status in accounting records is 
a good place to start looking.

If nothing obvious appears courtesy of exit status, and if
you have the capability to set up this system so that file 
access failures and similar are recorded in the audit log, 
you might want to try that and see if anything is revealed.

Along similar lines, you may also want to make sure that 
OPCOM is logging potentially relevant stuff, even if you 
wouldn't normally do so.

Account-specific resource limits (ie 'quotas') might also be
worth a look - checking the UAF's account limits (on the 
failing account) vs the usage values recorded in the 
accounting records for the failing process.

If you're feeling brave you could even change the UAF entry
for the failing account, a few items at a time, to make it
look more like an account that works (e.g. SYSTEM). Not 
just privileges and quotas, but also working directories
and such.

Given where you appear to be based, and where you historically 
worked, there may still be local(ish) VMS resources available 
to help, especially if remote interactive access to your 
system is realistic (for looking at logfiles etc rather than 
looking at DECwindows displays... mind you if one were to point
a modern smart phone at the workstation screen... nooo, too 
confusing, although probably rather cheaper than an IPKVMbox 
with video-in/RGB capability from someone like Raritan...). 

Wasn't Roy Omond somewhere near your part of the world for a 
long while?

Best of luck anyway.