Re: [TUHS] First Unix-like OSes not derived from AT&T code?

[ron minnich <rminnich@gmail.com>]

Someone mentioned the weird message format on AIX. IBM, in many
things, was out there ahead of everyone. One of those areas was in
"the message catalog", sample doc here:
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SA380673/$file/ieam600_v2r3.pdf

For every message there was a short identifier that was the message
catalog id, the one that sticks in my mind from years as an operator
is IEA013I, which is not in that doc ... IEA013E is, however.

This was useful for internationalization. IOW, IBM got it i8n well
ahead of a lot of us, in the 19[67]0s or so? The message catalog did
not change; the allegedly human readable message was in the local
language, if that applied.

Which comes to a prank we pulled on a friend. One evening in 1977, we
replaced all shell messages with IBM message catalog style messages,
and then set that as their login shell.

As you might guess, they were *not* amused ;-)


On Mon, May 2, 2022 at 7:16 AM Miod Vallat <miod@online.fr> wrote:
>
> > The RT 4.3 port was called AOS (for the, "Academic Operating System"). It
> > was mostly Tahoe with NFS and came with most of the sources, but some bits
> > were distributed only as object code: I believe some of the MM bits?
> > Perhaps the MMU code? I vaguely recall this being one of the things people
> > had a hard time with when trying to port Reno and 4.4 to the RT.
>
> What was delivered as binary was the Advanced Floating-Point Accelerator
> microcode.
>
> At the end of the AOS work circa 1996, most of the kernel was 4.4,
> except for the network stack which was 4.3-Reno, and the VM system which
> was still 4.3 (hence no mmap).
>
> > The port was fairly faithful; the C compiler was a bit strange "High C" or
> > "Hi C", bit GCC was available after a while, but had some bug and could not
> > compile the kernel.
>
> The compiler was Metaware High C. GCC could not be used to compile the
> kernel sources unchanged, because one of the locore->trap.c paths was
> relying upon the stack layout used by the compiler. With that fixed, gcc
> could be used to build a working kernel.
>
> Miod