[Info-vax] openvms and xterm

[Lawrence D'Oliveiro]

On Sun, 28 Apr 2024 17:03:19 +1200, David Goodwin wrote:

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

Nope, all you’ve done is continue to insist that Microsoft’s PR weasel 
words still mean something, contrary to past experience.

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

That is absolutely laughable to claim it is “good enough”, given the long-
standing complaints about the inflexibility of the Windows GUI.

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

Like I said, in Linux these are not “features” specific to the filesystem, 
they are implemented in the VFS layer. So they are able to work across 
different filesystems--even ones from the Windows world, where Windows 
itself is unable to support those features.

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

Why do you need on-disk attributes to store information about mount 
points?

>> Those are all for network security, not local security. I?m talking
>> about things like SELinux and AppArmor. And containers.
> 
> As far as I can see most of what SELinux adds has been in Windows NT
> since version 3.1.

You realize SELinux was created by the NSA? It offers military-strength 
role-based mandatory access control.

Maybe Windows has something equivalent to one of the simpler LSMs, like 
maybe AppArmor. Not SELinux.

>> 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?
> 
> They could put that menu there.

Nobody could, apart from Microsoft. The GUI is not easily replaceable, 
remember.

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

Ah, first you were claiming these “go beyond” binfmt, now you are trying 
to backpedal by saying they are somehow not comparable at all?

Want to change your story yet again?

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

No, I was looking for some relevance to the 32-bit-to-64-bit transition, 
and your story had nothing about that.

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

No, ARM and POWER and MIPS are all still very much here and continuing to 
be made and sold. And like I said, even with the massive popularity of 
ARM, Microsoft still can’t get Windows running properly on it.

> The fact that [Windows NT] has been ported to so many architectures
> clearly demonstrates that it is fairly portable.

The fact that every single one of those ports ran in into trouble clearly 
demonstrates that that “portability” was more of a PR claim than 
practical.

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

Like I said, on Linux this has nothing to do with filesystem-specific 
features. It is all handled within the VFS layer.

>> “Compatibility”. Go on, say it: WSL1 could not offer good enough
>> compatibility with Linux.
> 
> Not good enough for what?

Not good enough to do the things Linux users/developers expect from their 
systems as a matter of course.

Not good enough to pass for Linux.