[Info-vax] openvms and xterm

[David Goodwin]

[This followup was posted to comp.os.vms and a copy was sent to the 
cited author.]

In article <v0kbcs$q4lf$4 at dont-email.me>, ldo at nz.invalid says...
> 
> 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.

Microsoft says its still supported. I don't see any reason to claim or 
believe otherwise without proof.

> >> [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.

There are APIs to make something else work - the same APIs the Win32 
Environment Subsystem uses. The main roadblock is almost certainly the 
fact the GUI that ships with the system is good enough and modifying it 
is far easier than starting from scratch.

Just like there is nothing stopping the default shell from being 
replaced. People have certainly done that in the past but for most 
people the default one is good enough so the alternatives never get any 
real traction.

> >> 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.

This is primarily because NTFS is the only filesystem that ships with 
windows that has the required features. You *used* to be able to install 
and run windows NT from FAT and HPFS volumes up until I guess Win2k or 
Windows XP. HPFS was removed because it was obsolete, and booting from 
FAT was probably removed due to lack of support for ACLs and general 
reliability.

Mounted folders are implemented using reparse points - the same feature 
used for hard links, symbolic links, junctions and other such things. I 
think these are stored as extended attributes or similar which are not 
supported by FAT.

> >> 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.

I don't see anything in the documentation that says those security 
modules can't be used for local authentication. And the Local Security 
Authority handles all local security - its in the name. Its what 
enforces security policy and generates access tokens that describe the 
security context a process or thread is running in. As far as I can see 
most of what SELinux adds has been in Windows NT since version 3.1. 

I don't know if current windows has a general equivalent to AppArmor 
though - I suspect not.

> > 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?

Really grasping at straws here.

They could put that menu there. *YOU* could put that menu there. But why 
would you bother? Whats going to be in that menu? Why would people want 
to choose a different shell each time they login? Whats the use case 
here to make increasing the UIs complexity worthwhile?

And I don't see how this has anything to do with Xdm.

> >> 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?

No, I was not. And I think I've described NTs architecture more than 
enough at this point for you to know that binfmt is not the same concept 
as NTs Environment Subsystems.

> >> 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.

You were implying the transition from 32bit to 64bit is not easy. From 
my experience this is not the case. I suspect you are just making 
assumptions here.

> >> 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.

Yes, because all of those platforms are gone.
Intel i860XR: Gone, was a bad architecture. Support never released.
MIPS R3000: Obsolete by the time NT 3.1 came out. Support never 
released.
MIPS R4000: Compatible workstations never became widespread enough so 
Microsoft eventually ended support.
PowerPC: IBM pulled the plug.
Alpha: Compaq pulled the plug.
Alpha, 64bit: Compaq pulled the plug
Itanium: HP and Intel gave up on it
Clipper: Intergraph stopped making new Clipper CPUs and so stopped 
porting NT to Clipper
SPARC: This port was being done by Integraph. Probably stopped early on 
as Intergraph gave up on SPARC and moved to x86
PA-RISC: This port was being done by HP. HP decided not to release 
compatible hardware or the port for whatever reasons. Perhaps they 
thought Itanium being due any day now made the effort not worthwhile.

Most of the ports were discontinued because the companies that made the 
hardware stopped making the hardware or stopped providing support for 
running Windows on it. Just like how Linux drops support for CPU 
architectures when they're obsolete and no one is interested in 
maintaining support anymore.

The fact that it has been ported to so many architectures clearly 
demonstrates that it is fairly portable. The fact that those ports were 
not maintained indefinitely does not change this.

> >> 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.

It would seem it isn't necessarily tied to NTFS but rather requires 
certain filesystem features FAT doesn't have. You can't use fat32 as the 
root filesystem on linux for similar reasons.
 
> 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.

Not good enough for what? I used it for ages with no problems. Just 
because WSLv2 provides better compatibility does not imply that the 
compatibility of WSLv1 was not good enough for all possible use cases.

> > 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?

Silly question and you already know the answer. It the same reason why 
Windows 95, 98 and ME only implemented a subset of the Win32 API: There 
are a lot of APIs that are rarely used and most applications will run 
fine without them. Its not perfectly compatibility but its good enough.

If you wish to continue trying to find ways to prove that Windows NT is 
somehow a bad operating system you should probably read up a bit on it 
rather than just guessing or assuming. And remember that Windows NT is 
an entirely different OS from Windows 95/98/ME. Just because Windows 95 
could not do something does not mean current current windows can not do 
it.

And you don't actually have to try and prove other operating systems are 
somehow inferior because you prefer Linux. Other operating systems can 
be good and that's OK. There are things Linux does better, and there are 
things that Windows NT does better. This is to be expected as they have 
different designs and different design goals. Being different does not 
imply bad or inferior. Differences are good - it makes things 
interesting.