[Info-vax] openvms and xterm

[Lawrence D'Oliveiro]

On Sat, 27 Apr 2024 13:52:06 +1200, David Goodwin wrote:

> In article <v0hdf0$3v35b$3 at dont-email.me>, ldo at nz.invalid says...
>> 
>> So it?s quite clear: no more “new features and functionality”. And
>> when was the last time you saw a “critical bug fix” for WSL1, by the
>> way?
> 
> What makes you say they aren't fixing critical bugs?

You were the one who claimed it was “still supported”, not me. It is up to 
you to prove that point, if you can.

>> [NT] has the GUI inextricably entwined into it. 
> 
> The GUI actually lives in the Win32 Environment Subsystem.

But it is not modular and replaceable, like on Linux. It took them a long 
time even to offer anything resembling a “headless” setup, and that only 
for Windows Server. So it’s only a choice between Microsoft’s GUI, or no 
GUI at all. There are no APIs to make anything else work.

>> It doesn’t have a
>> virtual filesystem layer--most filesystem features seem to be
>> specifically tied into NTFS. 
> 
> I'm not sure what you mean by filesystem features being tied into
> NTFS ...

Mount points as an alternative to drive letters--only work with NTFS. I 
think also system booting only works with NTFS.

>> It doesn?t have pluggable security
>> modules. Does it even have loadable modules at all?
> 
> It does have pluggable security modules. These are managed by the Local 
> Security Authority Subsystem Service. Kerberos, SSL and NTLM modules
> are provided out of the box ...

Those are all for network security, not local security. I’m talking about 
things like SELinux and AppArmor. And containers.

> You can also completely replace the login screen if you like by 
> reimplementing the GINA interface ...

How wonderful. So they (partially) reinvented GUI login display managers 
that *nix systems have had since the 1990s. Have they figured out how to 
add that little menu that offers you a choice of GUI environment to run, 
as well?

>> And its “personality” system seems a lot more unwieldy and clumsy than
>> Linux’s pluggable “binfmt” system.
> 
> It also goes beyond what binfmt does.

Does it indeed? Weren’t you making apologies about its limitations, due to 
its being 30 years old, elsewhere?

>> Note that “32-bit”: it was never designed to make a transition
>> to 64-bit easy. 
> 
> I ported C-Kermit for Windows in about a day IIRC.

Not sure why that’s relevant.

>> Also note that “portable” nonsense--that was another
>> abject failure.
> 
> Windows NT has been publicly released for: MIPS R4000, x86, Alpha, 
> PowerPC, Itanium, x86-64, ARM, ARM64
> 
> It has been ported to, but not released on: i860XR, MIPS R3000,
> Clipper, PA-RISC, 64bit Alpha. And work was started on a SPARC port it
> doesn't appear to have got far.
> 
> Not seeing the failure here. 

All those ports are gone. All the non-x86 ones, except the ARM one, which 
continues to struggle.

>> As for “next-generation” ... drive letters, that?s all I need to say.
> 
> Drive letters are a feature of the Win32 environment subsystem - the 
> Win32 namespace. This is implemented on top of the NT namespace which
> is provided by the Object Manager.

Which is somehow specifically tied into NTFS. Try this: create and mount a 
FAT volume, mount it somewhere other than a drive letter, create a 
directory within it, and mount some other non-NTFS volume on that 
directory.

The Linux VFS layer doesn’t care: it all works. No drive letters, no 
special dependency on one particular filesystem.

>> WSL1 certainly is [a failure]. Else there would not have been WSL2,
>> would there?
> 
> WSLv2 mostly improves ...

“Compatibility”. Go on, say it: WSL1 could not offer good enough 
compatibility with Linux.

> Perhaps if general linux binary compatibility for desktop PCs was 
> the initial goal WSLv1 would have been designed differently.

How on earth do you design a “personality” that does not properly support 
the APIs being emulated? What exactly is it supposed to run, if not 
“binaries” from the platform being emulated?