[Info-vax] openvms and xterm

[Arne Vajhøj]

On 4/26/2024 9:52 PM, David Goodwin wrote:
> 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:
>>> 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.

And why the Core/Nano editions are possible.

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

It is not particular unusual that a version 1 of a product
get released with a simple set of requirements and then usage
increase and new requirements show up - and now it makes sense
to change design in version 2.

MS own explanation is:

<quote>
WSL 2 is a major overhaul of the underlying architecture and uses 
virtualization technology and a Linux kernel to enable new features. The 
primary goals of this update are to increase file system performance and 
add full system call compatibility.
</quote>

https://learn.microsoft.com/en-us/windows/wsl/compare-versions

I have always believed the second one was the key - emulating an OS
95% or 99% or 99.9% is doable - emulating an OS 100% is difficult.

The above link elaborate a bit:

<quote>
Linux binaries use system calls to perform functions such as accessing 
files, requesting memory, creating processes, and more. Whereas WSL 1 
used a translation layer that was built by the WSL team, WSL 2 includes 
its own Linux kernel with full system call compatibility. Benefits include:

     A whole new set of apps that you can run inside of WSL, such as 
Docker and more.

     Any updates to the Linux kernel are immediately ready for use. (You 
don't have to wait for the WSL team to implement updates and add the 
changes).
</quote>

I suspect docker is a good example of something that require a real
Linux kernel.

Arne