[Info-vax] openvms and xterm

[David Goodwin]

In article <v0hdf0$3v35b$3 at dont-email.me>, ldo at nz.invalid says...
> 
> On Fri, 26 Apr 2024 19:53:31 +1200, David Goodwin wrote:
> 
> > In article <v0fel2$3grqf$1 at dont-email.me>, ldo at nz.invalid says...
> >> 
> >> On Fri, 26 Apr 2024 17:05:21 +1200, David Goodwin wrote:
> >> 
> >> > WSLv1 exists and it does work surprisingly well.
> >> 
> >> But never quite good enough. And it is now abandoned.
> > 
> > Its still there and still works. And importantly its still supported.
> 
> You know how they like to use marketing-speak to avoid coming out and
> saying something is EOL?
> 
> From
> <https://devblogs.microsoft.com/commandline/the-windows-subsystem-for-linux-in-the-microsoft-store-is-now-generally-available-on-windows-10-and-11/>:
> 
>     Additionally, the in-Windows version of WSL will still receive
>     critical bug fixes, but the Store version of WSL is where new
>     features and functionality will be added.
> 
> 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? I'm sure if you 
report a security issue in WSLv1 they'll fix it same as any other 
windows component.

> >> You tell me: are two monolithic kernels better than one?
> > 
> > NT isn't generally considered to have a monolithic kernel.
> 
> It has the GUI inextricably entwined into it. 

The GUI actually lives in the Win32 Environment Subsystem. Until NT 4.0 
it was all implemented entirely in userspace. For performance reasons 
window management and a few other bits were moved into a kernel driver 
service (win32k.sys) in NT 4.0. This driver is loaded by the Win32 
Environment Subsystem (csrss.exe) when its loaded.

So the kernel itself knows nothing about GUIs and until the Session 
Manager Subsystem launches the Win32 Environment Subsystem, Windows NT 
is an entirely text-mode operating system. This is why on-boot 
filesystem checks aren't graphical: the check disk tool is implemented 
using the Native API and run before the Win32 subsystem has started 
meaning there is no GUI for it to use. 

> It doesn?t have a
> virtual filesystem layer--most filesystem features seem to be
> specifically tied into NTFS. 

Microsoft has shipped a bunch of filesystem drivers including the well 
known ntfs, fastfat, cdfs and in the past hpfs. Various 3rd parties have 
shipped drivers too. Here is a btrfs filesystem driver for Windows: 
https://github.com/maharmstone/btrfs

I'm not sure what you mean by filesystem features being tied into NTFS, 
or what features you imagine NTFS is missing that would limit what other 
filesystem drivers could provide.

> 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 along side local accounts. If you want you can 
write your own authentication packages too - the details are all on 
MSDN.

You can also completely replace the login screen if you like by 
reimplementing the GINA interface - this is what the Novell NetWare 
client did.

> And its ?personality? system seems a lot more unwieldy and clumsy than
> Linux?s pluggable ?binfmt? system.

Given you don't appear to know anything about it I'm not sure how you're 
able to say it seems more unwieldy or clumsy. It also goes beyond what 
binfmt does.

> > Windows NT started life as a next-generation portable high-end 32-bit
> > OS/2 implementation known as NT-OS/2.
> 
> I know. 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. Most of the code that 
needed changing was stuff that deviated from the recommended way of 
building Windows applications. The transition in this case was quite 
easy.

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

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

Wikipedia has a whole bunch of pages describing its architecture which 
may be of interest:
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT

> > If converting the entire userspace personality from one OS to another in
> > a year without any significant architectural changes doesn't validate
> > the design I don't know what would.
> 
> Has anybody demonstrated OS/2 software actually running under NT? Just
> curious.

Presentation Manager for NT: 
https://virtuallyfun.com/2021/05/19/presentation-manager-for-windows-nt/

Though I think the OS/2 subsystem was primarily there for running server 
software in the early days of NT. Until the release of NT 3.1, all of 
microsofts server software (SQL Server, LAN Manager, etc) ran on OS/2 
which meant that Microsoft was still shipping OS/2 1.3 after they'd cut 
their ties with IBM.

Additionally it only ever supported OS/2 1.x applications. While 
Microsoft was involved in the early work on the 32bit OS/2 2.0, they had 
no involvement with the final released product so NT never supported 
IBMs 32bit OS/2 API.

> > I'm also not sure why you think WSL is a failure.
> 
> WSL1 certainly is. Else there would not have been WSL2, would there?

WSLv2 mostly improves filesystem performance and gives you support for 
linux kernel modules. The downside is accessing files outside of the 
linux filesystem requires using the 9P protocol and the same is true for 
accessing linux files from Windows.

WSLv1 runs on top of the regular Windows filesystem storing all its 
files in NTFS so there is no performance penalty for accessing stuff 
outside the "linux area" beyond the general filesystem performance 
penalty WSLv1 itself imposes.

I believe the original design goal for WSLv1 was actually for running 
Android apps on Windows 10 Mobile. A more limited variety of 
applications on hardware that would not necessarily be appropriate for 
running a hypervisor and linux kernel. This code was later repurposed as 
WSLv1. Perhaps if general linux binary compatibility for desktop PCs was 
the initial goal WSLv1 would have been designed differently.