On 1/1/2024 11:12 AM, Dan Cross wrote:
> In article <umujck$282li$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
>>> On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
>>>> It stands for Linux, but that does not mean that they are trying to move
>>>> the general Windows user to a Linux experience.
>>>
>>> That seems inevitable, though. At some point it is going to become a
>>> mandatory part of any Windows install. I’m not saying it was Microsoft’s
>>> conscious intention when they introduced it, but it will become the path
>>> of least resistance.
>>
>> MS could roll it out to every Windows user tomorrow if they
>> wanted to.
>>
>> But why on earth would they want to do that??
>
> To pave a way for MSFT to jetison Windows in favor of Linux.
>
> Maintaining an OS like Windows is expensive and requires a
> steady stream of talent. There is more talent working on that
> kind of thing outside of Microsoft than inside, just not on
> Windows: most of the work is happening around Linux. Being able
> to leverage that investment would be a strategic win.

It cost money to maintain Windows, but it also generates revenue.

A lot of revenue. MS sell Windows licenses in the magnitude of
20 B$ per year.

Becoming just another Linux distro vendor would loose
most of that revenue.

Does not make any business sense.

>> For servers the preference is real ESXi/Hyper-V/KVM not WSL.
>>
>> For desktop/laptop the vast majorities of users has no interest
>> in Linux at all. Windows are facing serious challenges, but not
>>from (traditional) Linux. Windows usage is dropping because
>> people are switching to Android/iOS phones/tablets.
>>
>> People are switching from a GUI centric OS (Windows) to
>> GUI only OS (Android & iOS) for casual use. Expecting them
>> to use WSL command line utilities is a non-starter.
>
> This conflates two things: WSL as a path for moving to Linux
> as the kernel substrate for Microsoft's OS offerings, and using
> WSL as an end user.
>
> The latter is likely never going to happen outside of developer
> communities. The former could well happen; WSL gives MSFT a
> low-cost way to dip their toe into the waters and explore
> interoperability between the traditional Windows API and Linux.

If MS wanted to switch to Linux kernel then Win32 API for Linux
would be very interesting.

But WSL does not provide anything for that.

WSL 1 provided the opposite direction - Linux API on Windows kernel.

WSL 2 is just a VM with a very smart/transparent integration.

Arne

In article <umuq8b$28tuo$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/1/2024 11:12 AM, Dan Cross wrote:
>> In article <umujck$282li$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
>>>> On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
>>>>> It stands for Linux, but that does not mean that they are trying to move
>>>>> the general Windows user to a Linux experience.
>>>>
>>>> That seems inevitable, though. At some point it is going to become a
>>>> mandatory part of any Windows install. I’m not saying it was Microsoft’s
>>>> conscious intention when they introduced it, but it will become the path
>>>> of least resistance.
>>>
>>> MS could roll it out to every Windows user tomorrow if they
>>> wanted to.
>>>
>>> But why on earth would they want to do that??
>>
>> To pave a way for MSFT to jetison Windows in favor of Linux.
>>
>> Maintaining an OS like Windows is expensive and requires a
>> steady stream of talent. There is more talent working on that
>> kind of thing outside of Microsoft than inside, just not on
>> Windows: most of the work is happening around Linux. Being able
>> to leverage that investment would be a strategic win.
>
>It cost money to maintain Windows, but it also generates revenue.
>
>A lot of revenue. MS sell Windows licenses in the magnitude of
>20 B$ per year.
>
>Becoming just another Linux distro vendor would loose
>most of that revenue.
>
>Does not make any business sense.

....right now.

The windows market share is, as you yourself mentioned earlier
in this thread, continuing to shrink.

People at Microsoft aren't stupid. They can see the long-term
direction themselves.

>>> For servers the preference is real ESXi/Hyper-V/KVM not WSL.
>>>
>>> For desktop/laptop the vast majorities of users has no interest
>>> in Linux at all. Windows are facing serious challenges, but not
>>>from (traditional) Linux. Windows usage is dropping because
>>> people are switching to Android/iOS phones/tablets.
>>>
>>> People are switching from a GUI centric OS (Windows) to
>>> GUI only OS (Android & iOS) for casual use. Expecting them
>>> to use WSL command line utilities is a non-starter.
>>
>> This conflates two things: WSL as a path for moving to Linux
>> as the kernel substrate for Microsoft's OS offerings, and using
>> WSL as an end user.
>>
>> The latter is likely never going to happen outside of developer
>> communities. The former could well happen; WSL gives MSFT a
>> low-cost way to dip their toe into the waters and explore
>> interoperability between the traditional Windows API and Linux.
>
>If MS wanted to switch to Linux kernel then Win32 API for Linux
>would be very interesting.
>
>But WSL does not provide anything for that.
>
>WSL 1 provided the opposite direction - Linux API on Windows kernel.

....and integration at the file level.

>WSL 2 is just a VM with a very smart/transparent integration.

As I said, it's a way for them to dip their toe in the water and
explore compatibility. It's obviously not the end state.

- Dan C.

On 12/31/2023 9:52 PM, Arne Vajhøj wrote:
> On 12/31/2023 9:40 PM, Lawrence D'Oliveiro wrote:
>> On Sun, 31 Dec 2023 21:36:33 -0500, Arne Vajhøj wrote:
>>> On 12/31/2023 9:05 PM, Lawrence D'Oliveiro wrote:
>>>> On Sun, 31 Dec 2023 19:38:00 -0500, Arne Vajhøj wrote:
>>>>> On 12/31/2023 4:50 PM, Lawrence D'Oliveiro wrote:
>>>>>> Along with those 8-bit-era single-letter drive names, for some
>>>>>> reason.
>>>>>>
>>>>>> Microsoft: “26 drive letters ought to be enough for anybody!”
>>>>>
>>>>> You can mount disks without using drive letters with NTFS.
>>>>
>>>> As I recall from reading docs, that doesn’t work with network shares or
>>>> hot-pluggable storage. Or this thing called “storage spaces”.
>>>
>>> You don't need it for a network share - those can just be accessed
>>> directly via UNC.
>>
>> So how do you select from available UNC shares in an application’s file
>> picker?
>>
>>> (it is said that one can make a symlink to UNC if one want to)
>>
>> Windows symlinks have their own share of problems.
>
> If one is a Windows user that:
> * need more than 26 drives
> * need to use a file picker to choose network drives
> * don't like to create symlinks
> then one has a problem.
>
> But my guess is that you can invite everyone in the world matching
> that criteria to coffee in your dining room.

Even if your dining room is a phone booth ...

Does such even exist anymore?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/1/2024 11:52 AM, Dan Cross wrote:
> In article <umuq8b$28tuo$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/1/2024 11:12 AM, Dan Cross wrote:
>>> In article <umujck$282li$1@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
>>>>> On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
>>>>>> It stands for Linux, but that does not mean that they are trying to move
>>>>>> the general Windows user to a Linux experience.
>>>>>
>>>>> That seems inevitable, though. At some point it is going to become a
>>>>> mandatory part of any Windows install. I’m not saying it was Microsoft’s
>>>>> conscious intention when they introduced it, but it will become the path
>>>>> of least resistance.
>>>>
>>>> MS could roll it out to every Windows user tomorrow if they
>>>> wanted to.
>>>>
>>>> But why on earth would they want to do that??
>>>
>>> To pave a way for MSFT to jetison Windows in favor of Linux.
>>>
>>> Maintaining an OS like Windows is expensive and requires a
>>> steady stream of talent. There is more talent working on that
>>> kind of thing outside of Microsoft than inside, just not on
>>> Windows: most of the work is happening around Linux. Being able
>>> to leverage that investment would be a strategic win.
>>
>> It cost money to maintain Windows, but it also generates revenue.
>>
>> A lot of revenue. MS sell Windows licenses in the magnitude of
>> 20 B$ per year.
>>
>> Becoming just another Linux distro vendor would loose
>> most of that revenue.
>>
>> Does not make any business sense.
>
> ...right now.
>
> The windows market share is, as you yourself mentioned earlier
> in this thread, continuing to shrink.
>
> People at Microsoft aren't stupid. They can see the long-term
> direction themselves.

Windows desktop market share is not shrinking much. The
problem for MS is that the desktop market itself is shrinking - a
lot of casual users are switching to phones and tablets. Most
still have a PC, but because it is not used so much then they
are kept way longer than they used to. So PC sales is dropping
and Windows sales is dropping.

If MS want to continue the big presence in the consumer segment,
then they need to address it. Somehow they need to get into
the phone and tablet market. This is why the MS CEO recently
said that he regretted killing Windows Phone.

Creating a Linux desktop distro is not going to help with this
problem, because it is not what the customers are looking for.

>>>> For desktop/laptop the vast majorities of users has no interest
>>>> in Linux at all. Windows are facing serious challenges, but not
>>>> from (traditional) Linux. Windows usage is dropping because
>>>> people are switching to Android/iOS phones/tablets.
>>>>
>>>> People are switching from a GUI centric OS (Windows) to
>>>> GUI only OS (Android & iOS) for casual use. Expecting them
>>>> to use WSL command line utilities is a non-starter.
>>>
>>> This conflates two things: WSL as a path for moving to Linux
>>> as the kernel substrate for Microsoft's OS offerings, and using
>>> WSL as an end user.
>>>
>>> The latter is likely never going to happen outside of developer
>>> communities. The former could well happen; WSL gives MSFT a
>>> low-cost way to dip their toe into the waters and explore
>>> interoperability between the traditional Windows API and Linux.
>>
>> If MS wanted to switch to Linux kernel then Win32 API for Linux
>> would be very interesting.
>>
>> But WSL does not provide anything for that.
>>
>> WSL 1 provided the opposite direction - Linux API on Windows kernel.
>
> ...and integration at the file level.
>
>> WSL 2 is just a VM with a very smart/transparent integration.
>
> As I said, it's a way for them to dip their toe in the water and
> explore compatibility. It's obviously not the end state.

"dip their toe in the water" and "explore compatibility" ????

It does not do anything for running Windows applications on a Linux
system.

Arne

In article <umv3ll$2adef$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/1/2024 11:52 AM, Dan Cross wrote:
>> [snip]
>> ...right now.
>>
>> The windows market share is, as you yourself mentioned earlier
>> in this thread, continuing to shrink.
>>
>> People at Microsoft aren't stupid. They can see the long-term
>> direction themselves.
>
>Windows desktop market share is not shrinking much. The
>problem for MS is that the desktop market itself is shrinking - a
>lot of casual users are switching to phones and tablets. Most
>still have a PC, but because it is not used so much then they
>are kept way longer than they used to. So PC sales is dropping
>and Windows sales is dropping.
>
>If MS want to continue the big presence in the consumer segment,
>then they need to address it. Somehow they need to get into
>the phone and tablet market. This is why the MS CEO recently
>said that he regretted killing Windows Phone.
>
>Creating a Linux desktop distro is not going to help with this
>problem, because it is not what the customers are looking for.

You seem to conflate, "using the Linux kernel" with "creating
a Linux desktop distro."

>>>>> For desktop/laptop the vast majorities of users has no interest
>>>>> in Linux at all. Windows are facing serious challenges, but not
>>>>> from (traditional) Linux. Windows usage is dropping because
>>>>> people are switching to Android/iOS phones/tablets.
>>>>>
>>>>> People are switching from a GUI centric OS (Windows) to
>>>>> GUI only OS (Android & iOS) for casual use. Expecting them
>>>>> to use WSL command line utilities is a non-starter.
>>>>
>>>> This conflates two things: WSL as a path for moving to Linux
>>>> as the kernel substrate for Microsoft's OS offerings, and using
>>>> WSL as an end user.
>>>>
>>>> The latter is likely never going to happen outside of developer
>>>> communities. The former could well happen; WSL gives MSFT a
>>>> low-cost way to dip their toe into the waters and explore
>>>> interoperability between the traditional Windows API and Linux.
>>>
>>> If MS wanted to switch to Linux kernel then Win32 API for Linux
>>> would be very interesting.
>>>
>>> But WSL does not provide anything for that.
>>>
>>> WSL 1 provided the opposite direction - Linux API on Windows kernel.
>>
>> ...and integration at the file level.
>>
>>> WSL 2 is just a VM with a very smart/transparent integration.
>>
>> As I said, it's a way for them to dip their toe in the water and
>> explore compatibility. It's obviously not the end state.
>
>"dip their toe in the water" and "explore compatibility" ????
>
>It does not do anything for running Windows applications on a Linux
>system.

Bluntly, you're long on opinion, but based on this and many
other answers in this newsgroup and others, I really don't think
you have a good handle on how any of the underlying technologies
actually work. If you did, perhaps you wouldn't be so quick to
dismiss how a kernel compatibility layer that implements a
kernel ABI (e.g., WSL1) could be leveraged to gain insight into
how two kernel interfaces could be made to work simultaneously,
or how virtualization across a kernel boundary with shared
services (e.g., WSL2) could be similarly leveraged.

- Dan C.

On Mon, 1 Jan 2024 12:25:44 +0000, Chris Townley wrote:

> If I wanted to create something in Linux, I would not use WSL, I would
> use a proper distribution, either under a VM or on the various physical
> linux devices I have

Certainly, and so would I. But WSL is the path by which the Windows
installed base will get there from here.

On Mon, 1 Jan 2024 09:48:53 -0500, Arne Vajhøj wrote:

> On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
>
>> On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
>>
>>> It stands for Linux, but that does not mean that they are trying to
>>> move the general Windows user to a Linux experience.
>>
>> That seems inevitable, though. At some point it is going to become a
>> mandatory part of any Windows install. I’m not saying it was
>> Microsoft’s conscious intention when they introduced it, but it will
>> become the path of least resistance.
>
> But why on earth would they want to do that??

Because Windows is becoming increasingly complex and expensive for
Microsoft to maintain, and the profits from doing so are shrinking. Every
Windows user has been noticing how Microsoft is cutting corners on its QA
lately, with the deteriorating quality of its updates and patches.

So it will naturally take decisions (in its typical short-sighted fashion)
to reduce that support burden. The obvious, easy one is to rely more and
more on that Linux kernel for core stuff.

Exhibit A, what I consider to be the first step on this path:
<https://www.theregister.com/2023/12/14/windows_ai_studio_preview/>.

On 1/1/2024 3:15 PM, Dan Cross wrote:
> In article <umv3ll$2adef$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/1/2024 11:52 AM, Dan Cross wrote:
>>> [snip]
>>> ...right now.
>>>
>>> The windows market share is, as you yourself mentioned earlier
>>> in this thread, continuing to shrink.
>>>
>>> People at Microsoft aren't stupid. They can see the long-term
>>> direction themselves.
>>
>> Windows desktop market share is not shrinking much. The
>> problem for MS is that the desktop market itself is shrinking - a
>> lot of casual users are switching to phones and tablets. Most
>> still have a PC, but because it is not used so much then they
>> are kept way longer than they used to. So PC sales is dropping
>> and Windows sales is dropping.
>>
>> If MS want to continue the big presence in the consumer segment,
>> then they need to address it. Somehow they need to get into
>> the phone and tablet market. This is why the MS CEO recently
>> said that he regretted killing Windows Phone.
>>
>> Creating a Linux desktop distro is not going to help with this
>> problem, because it is not what the customers are looking for.
>
> You seem to conflate, "using the Linux kernel" with "creating
> a Linux desktop distro."

(if they want to reduce cost significantly, then that would
be what they would need to do)

But no matter what they do to their desktop OS, then it does not
solve the problem of people moving from desktop OS
to phones and tablets.

>>>>>> For desktop/laptop the vast majorities of users has no interest
>>>>>> in Linux at all. Windows are facing serious challenges, but not
>>>>>> from (traditional) Linux. Windows usage is dropping because
>>>>>> people are switching to Android/iOS phones/tablets.
>>>>>>
>>>>>> People are switching from a GUI centric OS (Windows) to
>>>>>> GUI only OS (Android & iOS) for casual use. Expecting them
>>>>>> to use WSL command line utilities is a non-starter.
>>>>>
>>>>> This conflates two things: WSL as a path for moving to Linux
>>>>> as the kernel substrate for Microsoft's OS offerings, and using
>>>>> WSL as an end user.
>>>>>
>>>>> The latter is likely never going to happen outside of developer
>>>>> communities. The former could well happen; WSL gives MSFT a
>>>>> low-cost way to dip their toe into the waters and explore
>>>>> interoperability between the traditional Windows API and Linux.
>>>>
>>>> If MS wanted to switch to Linux kernel then Win32 API for Linux
>>>> would be very interesting.
>>>>
>>>> But WSL does not provide anything for that.
>>>>
>>>> WSL 1 provided the opposite direction - Linux API on Windows kernel.
>>>
>>> ...and integration at the file level.
>>>
>>>> WSL 2 is just a VM with a very smart/transparent integration.
>>>
>>> As I said, it's a way for them to dip their toe in the water and
>>> explore compatibility. It's obviously not the end state.
>>
>> "dip their toe in the water" and "explore compatibility" ????
>>
>> It does not do anything for running Windows applications on a Linux
>> system.
>
> Bluntly, you're long on opinion, but based on this and many
> other answers in this newsgroup and others, I really don't think
> you have a good handle on how any of the underlying technologies
> actually work. If you did, perhaps you wouldn't be so quick to
> dismiss how a kernel compatibility layer that implements a
> kernel ABI (e.g., WSL1) could be leveraged to gain insight into
> how two kernel interfaces could be made to work simultaneously,
> or how virtualization across a kernel boundary with shared
> services (e.g., WSL2) could be similarly leveraged.

I do find it difficult to see why running Linux apps
on Windows help with running Windows apps on Linux.

And they have known about both concepts for a long
time. WSL1 concept goes back to 90's - Win32 API on
top of NT kernel and Win9x kernel. WSL2 concept goes
back to late 00's - XP mode in Windows 7.

Arne

on Windows 7

On 1/1/2024 4:57 PM, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 09:48:53 -0500, Arne Vajhøj wrote:
>> On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
>>> On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
>>>> It stands for Linux, but that does not mean that they are trying to
>>>> move the general Windows user to a Linux experience.
>>>
>>> That seems inevitable, though. At some point it is going to become a
>>> mandatory part of any Windows install. I’m not saying it was
>>> Microsoft’s conscious intention when they introduced it, but it will
>>> become the path of least resistance.
>>
>> But why on earth would they want to do that??
>
> Because Windows is becoming increasingly complex and expensive for
> Microsoft to maintain,

That problem is something almost all software has. Code bases grow over
time.

> and the profits from doing so are shrinking. Every
> Windows user has been noticing how Microsoft is cutting corners on its QA
> lately, with the deteriorating quality of its updates and patches.

That is a hypothesis but the numbers does not support it.

Windows sale = 20 B$/year.

10000 engineers @ 200 K$/year = 2 B$

It does not seem plausible that maintenance cost of Windows
is a real problem for MS.

(and if Windows development are actual done in India instead of
Seattle the cost would be way less)

> So it will naturally take decisions (in its typical short-sighted fashion)
> to reduce that support burden. The obvious, easy one is to rely more and
> more on that Linux kernel for core stuff.

I can't see that.

If they create another Linux desktop distro, then sale would plummmet.
There are no money in Linux desktop distros.

The compatibility API solution would not reduce maintenance significant.

From:

COM + .NET
Win32
NT kernel

to:

COM + .NET
Win32
Linux kernel

MS would still need to maintain all the high level stuff where most
of the work are done.

> Exhibit A, what I consider to be the first step on this path:
> <https://www.theregister.com/2023/12/14/windows_ai_studio_preview/>.

That is a developer tool not a general user tool. So it is not an
indication of WSL being more than development.

Arne

On 2023-12-31 2:43 a.m., John Dallman wrote:
> Good work. You might want to explain why StreamCR is provided: I doubt it
> is because of traditional Mac format, because VMS predates Mac by several
> years. Was it used by older DEC OSes?

According to a couple of search hits, the Apple II used CR line ending
before the Mac did.

You could save space on those 360K 5¼ floppy disks by eliminating the LF
on every line in a text file. ;-)

Here's one reference:

"... and Classic MacOS inherited the CR line ending convention from
ProDOS on the Apple II (and presumably SOS on the Apple ///, which was
the genesis of ProDOS.)"

https://stardot.org.uk/forums/viewtopic.php?p=381225&sid=5b7d6dac7407c615aaad1c711fa3fda9#p381225

That would be somewhere after 1980 (Apple /// SOS).

On Mon, 2024-01-01 at 09:55 -0500, Arne Vajhøj wrote:
> You sort of get both with WSL.

No, WSL is terrible! Use WSL2 instead.
--
Tactical Nuclear Kittens

On Sun, 2023-12-31 at 19:38 -0500, Arne Vajhøj wrote:
> You can mount disks without using drive letters with NTFS.
>
> It is just that nobody use it.

Before I was made redundant last month I used UNC mounts a lot with the
ex-employer's business application to share data between workstations.
--
Tactical Nuclear Kittens

On Mon, 2024-01-01 at 02:40 +0000, Lawrence D'Oliveiro wrote:
> So how do you select from available UNC shares in an application’s
> file picker?

We don't let the users do that, we know it's too easy to mess up.
--
Tactical Nuclear Kittens

On Mon, 2024-01-01 at 12:48 -0500, Dave Froble wrote:
> Even  if your dining room is a phone booth ...

Well, if a Police box worked well for a Time Lord ...
--
Tactical Nuclear Kittens

On 1/2/2024 6:10 AM, Single Stage to Orbit wrote:
> On Mon, 2024-01-01 at 09:55 -0500, Arne Vajhøj wrote:
>> You sort of get both with WSL.
>
> No, WSL is terrible! Use WSL2 instead.

I guess I was not being precise enough.

I generally use the term WSL to cover both WSL1 and WSL2.

And here I was actually talking about WSL2 per the
"You get a VM with ...".

Arne

Single Stage to Orbit wrote:

> Arne Vajhøj wrote:
>
>> You sort of get both with WSL.
>
> No, WSL is terrible! Use WSL2 instead.

Performance-wise sure, but there is a certain technical elegance to the
WSL1 mechanism.

On 1/2/2024 7:46 AM, Andy Burns wrote:
> Single Stage to Orbit wrote:
>> Arne Vajhøj wrote:
>>> You sort of get both with WSL.
>>
>> No, WSL is terrible! Use WSL2 instead.
>
> Performance-wise sure, but there is a certain technical elegance to the
> WSL1 mechanism.

Was the problem with WSL1 performance?

I always thought that the problem was compatibility
(that 99.9% compatibility was not god enough).

Arne

On 2023-12-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
> So I took:
> * what everybody knows about RMS
> * relative file and direct access fixed length file examples
> I recently posted
> * the index-sequential file examples I have used numerous times before
> * some file read and file creation test code I did a few years ago
> and baked it into:
>
> https://www.vajhoej.dk/arne/articles/rms.html
>

Some feedback:

About your VFC comments: what does Fortran carriage control use on VMS ?
You say there is no use for VFC, but then you go on to say Fortran uses
VFC for carriage control.

You may wish to make explicit what the maximum record size is with RMS.

Do you want to discuss the history of ISAM files with their different
prolog versions ?

You may wish to make it clear that RMS is a part of VMS in that it is
within VMS itself and not just some user-mode library linked in to each
user program.

You may wish to make the byte ordering explicit by giving offsets to
each field. IOW, make it clear that the control data is at the start
of each record and that fields are in little-endian and not big-endian
format. This matters because different operating systems have both
different documentation and endian conventions.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-12-31, John Dallman <jgd@cix.co.uk> wrote:
> In article <umqcjd$1er1l$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj)
> wrote:
>
>> https://www.vajhoej.dk/arne/articles/rms.html
>
> Good work. You might want to explain why StreamCR is provided: I doubt it
> is because of traditional Mac format, because VMS predates Mac by several
> years. Was it used by older DEC OSes?
>
> John

Second-system effect ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
> And remember, it?s NTFS-specific. Windows lacks the equivalent of a fully
> general VFS layer, for some totally unfathomable reason.

So does VMS. Unfortunately.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/2/2024 8:39 AM, Simon Clubley wrote:
> On 2023-12-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> So I took:
>> * what everybody knows about RMS
>> * relative file and direct access fixed length file examples
>> I recently posted
>> * the index-sequential file examples I have used numerous times before
>> * some file read and file creation test code I did a few years ago
>> and baked it into:
>>
>> https://www.vajhoej.dk/arne/articles/rms.html
>
> Some feedback:

Thanks. Apperciated.

> About your VFC comments: what does Fortran carriage control use on VMS ?
> You say there is no use for VFC, but then you go on to say Fortran uses
> VFC for carriage control.

DCL use record format VFC with carriage control PRN .

Fortran default use record format VAR with carriage control FTN.

I hope that is what I communicate:

<quote>
Nobody seems to see a purpose with VFC record format. But DCL create
files in VFC record format, so it is used.
....
Fortran carriage control use the first column in file for control. A
space ' ' in first column means ordinary new line. A one '1' in first
column means new page. This is a very old Fortran convention. And
usually it is only files generated by Fortran programs that use Fortran
carriage control, but VMS and RMS support sit.

Print carriage control use the content of the control information for
VFC files to manage output.
</quote>

(but I just noted that I can't count to 3)

> You may wish to make explicit what the maximum record size is with RMS.

Yes. That is important. It may not have been a severe limitation
in 1977, but it sure is today.

And I would need to mention Fortran segmented files.

> Do you want to discuss the history of ISAM files with their different
> prolog versions ?

I want to but I can't.

:-)

I don't have the knowledge.

> You may wish to make it clear that RMS is a part of VMS in that it is
> within VMS itself and not just some user-mode library linked in to each
> user program.

I should probably mention EXEC mode

> You may wish to make the byte ordering explicit by giving offsets to
> each field. IOW, make it clear that the control data is at the start
> of each record and that fields are in little-endian and not big-endian
> format. This matters because different operating systems have both
> different documentation and endian conventions.

Yes.

Not as big a problem today as 25 years ago. But still relevant.

Arne

In article <umvlnj$2cmas$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/1/2024 3:15 PM, Dan Cross wrote:
>> In article <umv3ll$2adef$1@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/1/2024 11:52 AM, Dan Cross wrote:
>>>> [snip]
>>>> ...right now.
>>>>
>>>> The windows market share is, as you yourself mentioned earlier
>>>> in this thread, continuing to shrink.
>>>>
>>>> People at Microsoft aren't stupid. They can see the long-term
>>>> direction themselves.
>>>
>>> Windows desktop market share is not shrinking much. The
>>> problem for MS is that the desktop market itself is shrinking - a
>>> lot of casual users are switching to phones and tablets. Most
>>> still have a PC, but because it is not used so much then they
>>> are kept way longer than they used to. So PC sales is dropping
>>> and Windows sales is dropping.
>>>
>>> If MS want to continue the big presence in the consumer segment,
>>> then they need to address it. Somehow they need to get into
>>> the phone and tablet market. This is why the MS CEO recently
>>> said that he regretted killing Windows Phone.
>>>
>>> Creating a Linux desktop distro is not going to help with this
>>> problem, because it is not what the customers are looking for.
>>
>> You seem to conflate, "using the Linux kernel" with "creating
>> a Linux desktop distro."
>
>(if they want to reduce cost significantly, then that would
>be what they would need to do)

Nope. Again, you're conflating replacing the Windows
kernel with a producing "desktop Linux distro."

>But no matter what they do to their desktop OS, then it does not
>solve the problem of people moving from desktop OS
>to phones and tablets.

Indeed. So as their market share continues to shrink,
support costs will continue to be significant. Moreover,
Windows revenue is not growing as fast as other parts of
their business, and as applications move to the cloud,
there is less incentive for users to run Windows.

>>>>>>> For desktop/laptop the vast majorities of users has no interest
>>>>>>> in Linux at all. Windows are facing serious challenges, but not
>>>>>>> from (traditional) Linux. Windows usage is dropping because
>>>>>>> people are switching to Android/iOS phones/tablets.
>>>>>>>
>>>>>>> People are switching from a GUI centric OS (Windows) to
>>>>>>> GUI only OS (Android & iOS) for casual use. Expecting them
>>>>>>> to use WSL command line utilities is a non-starter.
>>>>>>
>>>>>> This conflates two things: WSL as a path for moving to Linux
>>>>>> as the kernel substrate for Microsoft's OS offerings, and using
>>>>>> WSL as an end user.
>>>>>>
>>>>>> The latter is likely never going to happen outside of developer
>>>>>> communities. The former could well happen; WSL gives MSFT a
>>>>>> low-cost way to dip their toe into the waters and explore
>>>>>> interoperability between the traditional Windows API and Linux.
>>>>>
>>>>> If MS wanted to switch to Linux kernel then Win32 API for Linux
>>>>> would be very interesting.
>>>>>
>>>>> But WSL does not provide anything for that.
>>>>>
>>>>> WSL 1 provided the opposite direction - Linux API on Windows kernel.
>>>>
>>>> ...and integration at the file level.
>>>>
>>>>> WSL 2 is just a VM with a very smart/transparent integration.
>>>>
>>>> As I said, it's a way for them to dip their toe in the water and
>>>> explore compatibility. It's obviously not the end state.
>>>
>>> "dip their toe in the water" and "explore compatibility" ????
>>>
>>> It does not do anything for running Windows applications on a Linux
>>> system.
>>
>> Bluntly, you're long on opinion, but based on this and many
>> other answers in this newsgroup and others, I really don't think
>> you have a good handle on how any of the underlying technologies
>> actually work. If you did, perhaps you wouldn't be so quick to
>> dismiss how a kernel compatibility layer that implements a
>> kernel ABI (e.g., WSL1) could be leveraged to gain insight into
>> how two kernel interfaces could be made to work simultaneously,
>> or how virtualization across a kernel boundary with shared
>> services (e.g., WSL2) could be similarly leveraged.
>
>I do find it difficult to see why running Linux apps
>on Windows help with running Windows apps on Linux.

Yes, you do, but it's not that complex. If you have to provide
compatibility for one system interface in terms of another, you
must necessarily understand what can be shared and how to share
it. Implementing the Linux system interface inside of the
Windows kernel (as one does with WSL1) gives MSFT engineers
insight into how to bridge between the two; if you do so in one
direction, you've necessarily learned a lot about how to do it
in the other direction. I'm sure in doing so, Microsoft also
took lessons from e.g. gVisor etc.

Of course, the issue of system interface fidelity is a big one,
which is why WSL2 simply boots the Linux kernel in a VM. But
if you do that, then conceptually you have two kernels running
in an orchestrated way on a single machine, and now you can
start to vary the interface between them and which takes
primacy. This allows you to transition from one to the other
in a principled way, while maintaining compatibility.

Note that the Windows API is, by design, opaque to application
programs: programs like with a DLL that interfaces with the
kernel as opposed to publishing how to do this directly (as
under Linux). This gives MSFT a lot of room in how they
implement their system while maintaining backwards compatibility
with application programs. There's nothing magical about the
Windows kernel that would preclude them providing the same
interface on a different kernel entirely, and there's lots of
prior art (e.g., plan 9 ports, Rosetta and the Mac and A/UX
on the Mac, even within Windows, etc).

I do not expect you to understand this.

>And they have known about both concepts for a long
>time. WSL1 concept goes back to 90's - Win32 API on
>top of NT kernel and Win9x kernel.

Not really, but the basic concept of emulating a system
interface on another system goes much further back than
that; e.g., PA1050 on TOPS-20, or the DTSS environment on
Multics.

- Dan C.

In article <umvmsf$2cq5r$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/1/2024 4:57 PM, Lawrence D'Oliveiro wrote:
>> On Mon, 1 Jan 2024 09:48:53 -0500, Arne Vajhøj wrote:
>>> On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
>>>> On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
>>>>> It stands for Linux, but that does not mean that they are trying to
>>>>> move the general Windows user to a Linux experience.
>>>>
>>>> That seems inevitable, though. At some point it is going to become a
>>>> mandatory part of any Windows install. I’m not saying it was
>>>> Microsoft’s conscious intention when they introduced it, but it will
>>>> become the path of least resistance.
>>>
>>> But why on earth would they want to do that??
>>
>> Because Windows is becoming increasingly complex and expensive for
>> Microsoft to maintain,
>
>That problem is something almost all software has. Code bases grow over
>time.
>
>> and the profits from doing so are shrinking. Every
>> Windows user has been noticing how Microsoft is cutting corners on its QA
>> lately, with the deteriorating quality of its updates and patches.
>
>That is a hypothesis but the numbers does not support it.
>
>Windows sale = 20 B$/year.
>
>10000 engineers @ 200 K$/year = 2 B$
>
>It does not seem plausible that maintenance cost of Windows
>is a real problem for MS.

....right now. But no one is talking about Right Now. People
are talking about 5 or 10 years down the road.

>(and if Windows development are actual done in India instead of
>Seattle the cost would be way less)
>
>> So it will naturally take decisions (in its typical short-sighted fashion)
>> to reduce that support burden. The obvious, easy one is to rely more and
>> more on that Linux kernel for core stuff.
>
>I can't see that.
>
>If they create another Linux desktop distro, then sale would plummmet.
>There are no money in Linux desktop distros.

You keep talking about "Linux desktop distros", but that's your
failure of vision, not the rest of the world's.

>The compatibility API solution would not reduce maintenance significant.
>
>From:
>
>COM + .NET
>Win32
>NT kernel
>
>to:
>
>COM + .NET
>Win32
>Linux kernel
>
>MS would still need to maintain all the high level stuff where most
>of the work are done.

A significant amount of work is done maintaining drivers, but
inside MSFT and for OEMs. Linux has become the most important
OS in the world, and writing drivers for Windows is notoriously
tedious. Taking the burden off of both OEMs and MSFT to provide
drivers for disparate hardware by outsourcing that to vendors
who are already motivated (read: de facto required, if they want
to be relevant) to do so would be a significant win for
everyone: Microsoft wouldn't have to care, and the vendors would
only have to produce one driver.

- Dan C.

On 1/2/2024 12:41 PM, Dan Cross wrote:
> In article <umvlnj$2cmas$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:s.
>
>> And they have known about both concepts for a long
>> time. WSL1 concept goes back to 90's - Win32 API on
>> top of NT kernel and Win9x kernel.
>
> Not really, but the basic concept of emulating a system
> interface on another system goes much further back than
> that; e.g., PA1050 on TOPS-20, or the DTSS environment on
> Multics.

And lets not forget The Software Tools Virtual Operating System
in 1980 that gave you a bunch of the Unix API on everything from
CP/M to Exec-8 on the Univac 1100 including all of the DEC systems
of the time. :-)

bill

On Tue, 2 Jan 2024 12:46:14 +0000, Andy Burns wrote:

> ... there is a certain technical elegance to the
> WSL1 mechanism.

When Windows NT was first created, it was supposed to support the idea of
“personalities” to allow different kinds of userland apps to run on top of
the same core kernel. For example, Win32 was just one kind of
“personality”, while the POSIX layer was implemented as another kind.

You would think the WSL1 would have been implemented as just another
“personality”. But no. It appears the whole extensibility of the
“personality” architecture has kind of bitrotted away in the years since
the introduction of NT, so WSL1 was implemented in its own unique kind of
way (don’t ask me how).

And, in spite of the fact that it was supposed to be implementing a well-
documented API, with plenty of example source code to refer to, they still
couldn’t get WSL1 to work right. So they had to chuck it away and bring in
a proper Linux kernel instead.