[Info-vax] openvms and xterm

[David Goodwin]

In article <v16nsc$1gbho$2 at dont-email.me>, ldo at nz.invalid says...
> 
> 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.

Can you point to some recent examples where Microsoft has ended support 
earlier than they claimed they would? Or failed to patch critical 
vulnerabilities for products that were still in support?

I can remember them *extending* the support period for old products on 
occasion. And they have on occasion provided patches for particularly 
serious issues in products that were out of support. 

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

I've no doubt some people don't like the Windows GUI. Some people don't 
like the Mac GUI either. Clearly not enough people have big enough 
issues to bother doing something about it though. 

The only part you can't really "easily" replace (AFAIK) is the window 
manager. I've never really desired a different window manager on Windows 
so don't care it can't be replaced - on Linux I've almost always just 
gone with whatever the default is too.

There are alternative shells but they've never been popular I guess 
because most people think the default one is fine.

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

Why does Unix need a text file to store information about mount points? 
Because that's how it was designed. Windows NT and Unix are different 
operating systems and so do some things differently. This is ok.

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

The login screen is a DLL. You can replace it. Novell *did* replace it. 
You can put whatever buttons you like on your replacement login screen. 
Novell *did* put whatever buttons they liked on their login screen. This 
is why it is a DLL and why Microsoft published the specifications for 
the DLL - so that people could replace it if needed.

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

Binfmt handles executable formats - it alone can't make Linux look like 
Windows. It is not the same concept as Windows NTs Environment 
Subsystems which are responsible for providing most of the userspace 
environmnet.

If you take away binfmt, Linux still looks and works like Linux. If you 
take away CSRSS, Windows NT is practically some other operating system. 

I'm not really sure how much clearer I can make this. I think you are 
being more than a little disingenous here.

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

Been a long time since I've seen PowerPC or MIPS PCs on store shelves...

The PowerPC port ended when IBM stopped including ARC-compatible 
firmware on new machines. The MIPS port ended when you could no longer 
buy MIPS workstations with ARC firmware. Compatible hardware was 
discontinued so the ports were discontinued.

Microsoft could have taken on supporting these platforms with whatever 
random firmware they have like Linux does. But Microsoft is selling a 
product here - if the number of sales to people who want to run Windows 
rather than AIX on their brand new RS/6000 doesn't cover the costs its 
not worth doing.

That doesn't mean it can't be done or that Windows NT isn't portable. It 
just means it doesn't make business sense to do it. 

Same goes for ARM - Windows runs on ARM devices built to run Windows. 
For business reasons Microsoft doesn't spend money porting Windows to 
any random ARM device thats designed and sold for some other purpose.

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

None of them ran into technical problems. The ports exist and they work. 
I have PowerPC and Alpha hardware here running Windows NT and it works 
just fine. Only reason I don't have a MIPS is because they're extremely 
rare. The operating system itself is indistinguishable from the regular 
x86 version and all the included utilities work just the same. The 
operating system is portable and its a bit absurd to try and claim 
otherwise.

But the level of vendor support does make a difference. IBM put in only 
minimal effort and abandoned it quickly. Few machines were sold and so 
hardware and software vendors rarely built drivers and software for 
PowerPC.

DEC put far more effort in and it shows. A lot more software and drivers 
built for Alpha, plus their binary translation software (FX!32) works 
very well for running regular x86 binaries. Its really a shame Compaq 
killed the Win2k effort as Win2k RC2 works quite nicely on Alpha.

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

Would be interested to see Linux using fat32 as the root filesystem. 
Last I checked it wasn't possible due to missing features in that 
filesystem.

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

What in your experience was it not good enough for? I ran WSLv1 for 
quite a while and don't remember having any issues with it.

> Not good enough to pass for Linux.

Based on your extensive experience with WSLv1 I assume?

I'm still not entirely sure what the point of this discussion is. Is 
there some point you're trying to make here or are we just trying to 
find the differences between two operating systems?