https://www.vajhoej.dk/arne/articles/rms.html
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?
On Sun, 31 Dec 2023 07:43 +0000 (GMT Standard Time), John Dallman wrote:
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.
Support for STREAM_xx formats in RMS were not added until VMS 4.0, near as
I can tell. And that dates from around the time of the release of the Mac.
On reflection, I think CP/M inherited using CR from a DEC OS, but I
don't know which one: the original author of CP/M was familiar with
multiple operating systems.
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?
Good question. I don't know.
RSX-11? RT-11? RSTS/E? TOPS-10?
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.
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?
On Sun, 31 Dec 2023 21:34 +0000 (GMT Standard Time), John Dallman wrote:
On reflection, I think CP/M inherited using CR from a DEC OS, but I
don't know which one: the original author of CP/M was familiar with
multiple operating systems.
CP/M used CR/LF, which is why MS-DOS did the same, and Windows still does.
As I recall, Gary Kildall did his early cross-development of CP/M on a
PDP-10 machine running TOPS-10.
Clearly, DEC OSes gave him the idea of device names, though he simplified them down to a single letter for his 8-bit OS, just for disks. But then
you needed ways of accessing non-disk devices like serial lines, printers, etc; so either he or Microsoft introduced “reserved” file names for these.
And that’s where you get “PRN”, “COM1” and all the rest.
Then when Microsoft tried to copy some Unix features in MS-DOS 2.x, like hierarchical pathnames, these interacted in rather unfortunate ways with
the “reserved” file names. And that bit of sadness persists in Windows to this day. Along with those 8-bit-era single-letter drive names, for some reason.
Microsoft: “26 drive letters ought to be enough for anybody!”
On 12/31/2023 4:29 PM, Lawrence D'Oliveiro wrote:
Support for STREAM_xx formats in RMS were not added until VMS 4.0, near
as I can tell. And that dates from around the time of the release of
the Mac.
That surprises me. I always thought they had been there since day 1.
But I started with VMS 4.4, so I don't know early VMS first hand.
On 31/12/2023 21:50, Lawrence D'Oliveiro wrote:
Microsoft: “26 drive letters ought to be enough for anybody!”
Along with 64k...
On Sun, 31 Dec 2023 07:43 +0000 (GMT Standard Time), John Dallman wrote:
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.
Support for STREAM_xx formats in RMS were not added until VMS 4.0, near as
I can tell. And that dates from around the time of the release of the Mac.
Most operating systems out there only used stream_lf and stream_cr.
On Sun, 31 Dec 2023 17:11:45 -0500, Arne Vajhøj wrote:
On 12/31/2023 4:29 PM, Lawrence D'Oliveiro wrote:
Support for STREAM_xx formats in RMS were not added until VMS 4.0, near
as I can tell. And that dates from around the time of the release of
the Mac.
That surprises me. I always thought they had been there since day 1.
But I started with VMS 4.4, so I don't know early VMS first hand.
VMS 4.0 was also the version that increased the length of file names from 9-dot-3 to 39-dot-39.
Along with those 8-bit-era single-letter drive names, for some
reason.
Microsoft: “26 drive letters ought to be enough for anybody!”
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.
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”.
And remember, it’s NTFS-specific.
Windows lacks the equivalent of a fully
general VFS layer, for some totally unfathomable reason.
If one is a Windows user that:
* need more than 26 drives
AFAIK there are no current plans to replace NTFS.
WSL is not an attempt to make Windows like Linux.
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.
(it is said that one can make a symlink to UNC if one want to)
And remember, it’s NTFS-specific.
It is specific to the file system used on practically all Windows disks.
Windows lacks the equivalent of a fully general VFS layer, for some
totally unfathomable reason.
I don't think many Windows users miss it.
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.
And remember, it’s NTFS-specific.
It is specific to the file system used on practically all Windows disks.
That’s a pretty shortsighted attitude, when you realize that NTFS is starting to show its age.
Windows lacks the equivalent of a fully general VFS layer, for some
totally unfathomable reason.
I don't think many Windows users miss it.
That’s true of the Windows users/developers that are left. The ones that understand the need, know where to get it. That’s why Microsoft is trying desperately (with WSL2 and other things) to make Windows more like Linux.
On Sun, 31 Dec 2023 21:52:53 -0500, Arne Vajhøj wrote:
WSL is not an attempt to make Windows like Linux.
It is precisely that. It’s even in the name: guess what the “L” stands for?
It stands for Linux, but that does not mean that they are trying to move
the general Windows user to a Linux experience.
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.
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.
On 01/01/2024 04:51, 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.
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
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??
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.
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.
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.
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.
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.
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 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.
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.
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.
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??
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
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.
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/>.
You sort of get both with WSL.
So how do you select from available UNC shares in an application’s
file picker?
You can mount disks without using drive letters with NTFS.
It is just that nobody use it.
Even if your dining room is a phone booth ...
Arne Vajhøj wrote:
You sort of get both with WSL.
No, WSL is terrible! Use WSL2 instead.
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.
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.
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
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
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.
And remember, it?s NTFS-specific. Windows lacks the equivalent of a fully general VFS layer, for some totally unfathomable reason.
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.
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.
... there is a certain technical elegance to the
WSL1 mechanism.
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.
Note that the Windows API is, by design, opaque to application
programs ...
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.
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).
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.
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.
On Tue, 2 Jan 2024 17:41:20 -0000 (UTC), Dan Cross wrote:
Note that the Windows API is, by design, opaque to application
programs ...
Worse than that, it is poorly specified. Compare POSIX, where it is not
just the functionality of each call that is documented, but also the
possible error conditions and what they mean. This is missing from the
Win32 API docs.
This is why the WINE project, for example, took 15 years to get to version >1.0: because they had to determine all the possible error paths in Win32
by exhaustive search.
Jeremy Allison goes into detail about this here ><https://www.samba.org/samba/news/articles/low_point/ >tale_two_stds_os2.html>.
I've read that the posix subsystem did the absolute bare minimum to pass tests, without being in any way in any way useful, just so that WinNT
could tick the "posix" box and be allowed into govt contracts.
I think I did more with MKS Toolkit and Cygwin than WSL.
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. :-)
On Tue, 2 Jan 2024 17:45:58 -0000 (UTC), Dan Cross wrote:
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.
In the words of the infamous “Halloween documents” ><http://www.catb.org/~esr/halloween/halloween2.html>:
An important attribute to note which has led to volume drivers is
the ease with which you can write drivers for linux, and the
relatively powerful debugging infrastructure that linux has.
Finding and installing the DDK, and trying to hook up the kernel
debugger and do any sort of interaction with user-mode without
tearing the NT system to bits is much more challenging than
writing the simple device-drivers for linux. Any idiot could write
a driver in 2 days with a book like "Linux Device Drivers" — there
is no such thing as a 2-day device-driver for NT
Andy Burns wrote:
I've read that the posix subsystem did the absolute bare minimum to pass
tests, without being in any way in any way useful, just so that WinNT
could tick the "posix" box and be allowed into govt contracts.
The true horror of it has to be seen to be believed <https://www.youtube.com/watch?v=BOeku3hDzrM>.
Compare POSIX, where it is not
just the functionality of each call that is documented, but also the
possible error conditions and what they mean
Lawrence D'Oliveiro wrote:
Compare POSIX, where it is not
just the functionality of each call that is documented, but also the
possible error conditions and what they mean
Yet NT *can* pass the NIST/FIPS/Posix tests, so is Posix that good a test?
On 1/2/2024 2:42 PM, Dan Cross wrote:
In article <kvj3t3Fbk87U1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
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. :-)
Indeed! Though that was more about a suite of useful
functionality for source-level compatibility, more than running
unmodified binaries on compatible machines.
One of the big "selling" points for Unix was always source
compatibility. In the early Linux days there were compatibility >compatibility libraries that were supposed to make Linux stuff
run on BSD. I never had much luck with it and usually found it
easier to just recompile under BSD.
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from
outside is fraught.
Strange, isn't it: Microsoft must have access to at least a couple of
orders of magnitude greater development resources than that available to
the Linux kernel project,
yet they cannot keep up with what the Linux developers have achieved.
Furthermore, the rate of change in Linux is high; following along from outside is fraught.
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from
outside is fraught.
Strange, isn't it: Microsoft must have access to at least a couple of >>orders of magnitude greater development resources than that available to >>the Linux kernel project,
Almost certainly the inverse is true.
Don't sell Microsoft short: their kernel engineers are first-rate and incredibly sharp.
On the other hand, don't look at Linux with rose-colored glasses. The
idea of the lone Linux kernel hacker independently building something
that rivals commercial vendors with nothing more than a bag of dorittos
and bottle of Jolt is a distant memory.
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from
outside is fraught.
Strange, isn’t it: Microsoft must have access to at least a couple of >orders of magnitude greater development resources than that available to
the Linux kernel project, yet they cannot keep up with what the Linux >developers have achieved.
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from
outside is fraught.
Strange, isn’t it: Microsoft must have access to at least a couple of >>orders of magnitude greater development resources than that available to >>the Linux kernel project, yet they cannot keep up with what the Linux >>developers have achieved.
This presumes that the high rate of change of Linux is actually good. I rather suspect it is not.
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from
outside is fraught.
Strange, isn’t it: Microsoft must have access to at least a couple of >>orders of magnitude greater development resources than that available to >>the Linux kernel project, yet they cannot keep up with what the Linux >>developers have achieved.
This presumes that the high rate of change of Linux is actually good. I >rather suspect it is not.
On Tue, 2 Jan 2024 20:56:56 -0000 (UTC), Dan Cross wrote:
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from >>>> outside is fraught.
Strange, isn't it: Microsoft must have access to at least a couple of >>>orders of magnitude greater development resources than that available to >>>the Linux kernel project,
Almost certainly the inverse is true.
Yet you yourself have already admitted the opposite.
Don't sell Microsoft short: their kernel engineers are first-rate and
incredibly sharp.
Maybe not quite so sharp;
else why can’t they figure out how to get
select(2)/poll(2) working with pipes <https://docs.python.org/3/library/ >select.html>?
That is the one irritating reason why users of Python
asyncio on Windows have to make a choice between two different, partially- >overlapping event-loop implementations, neither of which is really a
general solution <https://docs.python.org/3/library/asyncio- >eventloop.html#event-loop-implementations>.
On the other hand, don't look at Linux with rose-colored glasses. The
idea of the lone Linux kernel hacker independently building something
that rivals commercial vendors with nothing more than a bag of dorittos
and bottle of Jolt is a distant memory.
It still happens. Look at who created WireGuard, just for a recent
example.
In article <un1uj4$2raer$1@dont-email.me>,from
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 20:56:56 -0000 (UTC), Dan Cross wrote:
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along
tooutside is fraught.
Strange, isn't it: Microsoft must have access to at least a couple of >>>>orders of magnitude greater development resources than that available
the Linux kernel project,
Almost certainly the inverse is true.
Yet you yourself have already admitted the opposite.
I don't believe I have. Perhaps you could tell me where you
think I did?
else why can’t they figure out how to get
select(2)/poll(2) working with pipes <https://docs.python.org/3/library/ >>select.html>?
Probably because they started out with a very different system
architecture and din't care about implementing Unix interfaces
at the time, and now have to retrofit it onto a very large
existing codebase and that's kind of a niche use case.
When you write that about select/poll and pipes and that being
an "irritating reason" for a more general issue, that seems
specious.
On Tue, 2 Jan 2024 23:16:45 -0000 (UTC), Dan Cross wrote:
In article <un1uj4$2raer$1@dont-email.me>,from
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 20:56:56 -0000 (UTC), Dan Cross wrote:
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along
tooutside is fraught.
Strange, isn't it: Microsoft must have access to at least a couple of >>>>>orders of magnitude greater development resources than that available
the Linux kernel project,
Almost certainly the inverse is true.
Yet you yourself have already admitted the opposite.
I don't believe I have. Perhaps you could tell me where you
think I did?
Where you used the word "fraught".
else why can’t they figure out how to get
select(2)/poll(2) working with pipes <https://docs.python.org/3/library/ >>>select.html>?
Probably because they started out with a very different system
architecture and din't care about implementing Unix interfaces
at the time, and now have to retrofit it onto a very large
existing codebase and that's kind of a niche use case.
That "niche" is the reason why they have had to resort to WSL2, to bring >Linux-type APIs to Windows. And why do they need Linux-type APIs on
Windows, anyway? Because that's what the developers are increasingly
relying on. Why didn't WSL1 work? Because the Windows kernel wasn't up to
it.
When you write that about select/poll and pipes and that being
an "irritating reason" for a more general issue, that seems
specious.
Maybe you don't realize how important Python has become in the computing >world lately, with its applications in data science and other areas.
Microsoft is even planning to offer Python access to Excel users (at least >cloud-based ones).
And it's not just Python, of course: Windows limitations affect cross- >platform development across the board. To the point where Microsoft has to
do something to stem the tide of developers simply giving up on the
Windows platform. Hence WSL. Which is essentially a bag duct-taped on the >side of Windows.
Remember why Microsoft needs WSL, clunky as it is: it's not something it >bestowed as a special favour on the Linux or open-source world or anything >like that: it created it because it had to, for sheer business survival.
Lawrence D'Oliveiro wrote:
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.
I didn't do anything other than "play" with WSL1, but I thought
performance was the issue.
I think I did more with MKS Toolkit and Cygwin than WSL.
On 1/2/24 7:24 AM, Arne Vajhøj wrote:
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).
The docs say that WSL2 performance is worse than WSL1 for operations involving file system integration. Details here:
https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
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.
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.
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.
What I said is that it is a fraught proposition to try to keep up with
the rate of change in the Linux kernel from outside of the Linux kernel.
To which I replied that almost certainly the inverse is true; i.e., that
the Linux kernel folks probably have access to several orders of
magnitude more resources than Microsoft can put to Windows.
In article <un26bd$2sllq$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
That "niche" is the reason why they have had to resort to WSL2, to bring >>Linux-type APIs to Windows. And why do they need Linux-type APIs on >>Windows, anyway? Because that's what the developers are increasingly >>relying on. Why didn't WSL1 work? Because the Windows kernel wasn't up
to it.
That seems like speculation on your part.
They surely moved to WSL2 because the best, cheapest way to be "bug compatible" with Linux is to just run Linux.
Python is important; this has does not imply that
Unix-style select/poll on a pipe under Windows in Python is important.
For more general types of asynchronous IO (storage, networking) it says nothing at all, and these are certainly more important than pipes which
are just one kind of IPC mechanism (and not super relevant to Python specifically).
Remember why Microsoft needs WSL, clunky as it is: it's not something it >>bestowed as a special favour on the Linux or open-source world or
anything like that: it created it because it had to, for sheer business >>survival.
I actually agree with this, but I think your argument here is poor.
MSFT needs Linux compatability because the world is trending towards
Linux and they can't keep up, yes. It does not follow that their
engineers are bad, or even that their kernel is bad.
Take, for instance, the lack of internal kernel interfaces and gregkh's insistence that, not only are they unnecessary, they are _bad_: this can
make things very hard to work with, with multiple generations of partial interfaces all coresident at the same time, and little incentive to
clean up the resulting complexity or mess.
Note that Cygwin and WSL does completely different things.
At the same time, Linux had also rewritten its USB stack three times.
But it had the luxury of starting pretty much from scratch each time,
without having to carry around a lot of legacy baggage, because all
the drivers included in the Linux kernel source tree could be updated
at the same time.
On Tue, 2024-01-02 at 13:40 -0600, Craig A. Berry wrote:
On 1/2/24 7:24 AM, Arne Vajhøj wrote:
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).
The docs say that WSL2 performance is worse than WSL1 for operations
involving file system integration. Details here:
https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
Eh? I thought it was WSL1 that had the performance issuses, not WSL2.
On 1/2/2024 2:25 PM, Andy Burns wrote:
Lawrence D'Oliveiro wrote:
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.
I didn't do anything other than "play" with WSL1, but I thought
performance was the issue.
I think I did more with MKS Toolkit and Cygwin than WSL.
Note that Cygwin and WSL does completely different things.
Cygwin:
*nix and/or Windows source--Cygwin toolchain-->Windows executable
WSL:
*nix source--Linux toolchain-->Linux executable
On Tue, 2 Jan 2024 23:21:23 -0000 (UTC), Dan Cross wrote:
Take, for instance, the lack of internal kernel interfaces and gregkh's
insistence that, not only are they unnecessary, they are _bad_: this can
make things very hard to work with, with multiple generations of partial
interfaces all coresident at the same time, and little incentive to
clean up the resulting complexity or mess.
Could be worse. You could be required to carry all that baggage around >forever.
GregKH made this point some years back, about the state of respective USB >support in Windows versus Linux. At that point, Microsoft had rewritten
its USB stack three times, and so it was carrying around three different >driver APIs, and as long as there were third-party drivers using the
obsolete interfaces, would have to continue doing that essentially
forever.
At the same time, Linux had also rewritten its USB stack three times. But
it had the luxury of starting pretty much from scratch each time, without >having to carry around a lot of legacy baggage, because all the drivers >included in the Linux kernel source tree could be updated at the same
time.
Just one of many reasons why Linux is a much trimmer and more efficient OS >than Windows.
On Wed, 3 Jan 2024 00:03:36 -0000 (UTC), Dan Cross wrote:
What I said is that it is a fraught proposition to try to keep up with
the rate of change in the Linux kernel from outside of the Linux kernel.
And that "outside of the Linux kernel" includes the part of the Universe >containing Microsoft. It, too, has a struggle, even with its vast
resources, keeping up with the pace of Linux kernel development.
To which I replied that almost certainly the inverse is true; i.e., that
the Linux kernel folks probably have access to several orders of
magnitude more resources than Microsoft can put to Windows.
Given how much revenue Microsoft is supposedly earning from Windows, don't >you think it should be putting a proportionate level of investment back
into it?
In article <un26bd$2sllq$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
That "niche" is the reason why they have had to resort to WSL2, to bring >>>Linux-type APIs to Windows. And why do they need Linux-type APIs on >>>Windows, anyway? Because that's what the developers are increasingly >>>relying on. Why didn't WSL1 work? Because the Windows kernel wasn't up
to it.
That seems like speculation on your part.
Microsoft's own actions are all the evidence we need. Why abandon
something, after putting so much effort into it, if you could have got it
to work?
They surely moved to WSL2 because the best, cheapest way to be "bug
compatible" with Linux is to just run Linux.
After already putting all that investment into WSL1? That good old NT
kernel not versatile enough to emulate the little quirks as well as the >salient features?
As further evidence, consider how WINE is able to be bug-compatible with >Windows, on top of the Linux kernel. Why can't Microsoft, with more
resources at its disposal than both the Linux kernel and WINE projects >*combined*, return the favour?
Python is important; this has does not imply that
Unix-style select/poll on a pipe under Windows in Python is important.
So how do you run that large installed base of Python code on Windows
without that compatibility?
For more general types of asynchronous IO (storage, networking) it says
nothing at all, and these are certainly more important than pipes which
are just one kind of IPC mechanism (and not super relevant to Python
specifically).
They're a core feature of POSIX. They exist because they make for a very >convenient model for certain common kinds of IPC, as the original Unix >creators discovered in their experiments.
Remember why Microsoft needs WSL, clunky as it is: it's not something it >>>bestowed as a special favour on the Linux or open-source world or >>>anything like that: it created it because it had to, for sheer business >>>survival.
I actually agree with this, but I think your argument here is poor.
MSFT needs Linux compatability because the world is trending towards
Linux and they can't keep up, yes. It does not follow that their
engineers are bad, or even that their kernel is bad.
WSL1 would be evidence to the contrary.
And yes, engineers can be individually smart, yet due to a dysfunctional
and risk-averse corporate culture, they end up producing a mediocre net >product.
https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
Eh? I thought it was WSL1 that had the performance issuses, not
WSL2.
Got a citation? I'd believe it's the other way around; a world
switch into Linux from Windows is going to be more expensive
than a system call, and accessing a filesystem remotely (surely
how they implement access to NTFS from WSL2) will mean
ping-ponging between Windows and Linux several times to satisfy
an IO request.
On Wed, 2024-01-03 at 13:29 +0000, Dan Cross wrote:
https://github.com/microsoft/WSL/issues/4197#issuecomment-604592340
Eh? I thought it was WSL1 that had the performance issuses, not
WSL2.
Got a citation? I'd believe it's the other way around; a world
switch into Linux from Windows is going to be more expensive
than a system call, and accessing a filesystem remotely (surely
how they implement access to NTFS from WSL2) will mean
ping-ponging between Windows and Linux several times to satisfy
an IO request.
With WSL2, both the Windows NT kernel and the Linux kernel run on top
of a hypervisor. It's a nice solution and performance differences
between the two WSL systems should be night and day.
https://thecodeblogger.com/2020/08/22/understanding-differences-between-wsl-1-and-wsl-2/
[...]
<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.
[...]
... also I forgot all about Interix/SFU
On Wed, 2024-01-03 at 02:46 +0000, Lawrence D'Oliveiro wrote:
At the same time, Linux had also rewritten its USB stack three times.
But it had the luxury of starting pretty much from scratch each time,
without having to carry around a lot of legacy baggage, because all the
drivers included in the Linux kernel source tree could be updated at
the same time.
That's true but it is a source of considerable pain for commercial
products such as VMware, VirtualBox, ZFS and others. They all have to
devote substantial engineering resources to release updates for every
kernel release.
Arne Vajhøj schrieb am 02.01.2024 um 15:12:
<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.
[...]
In addition, '+' means no line feed (overprint) and '0' means two new
lines.
(from my Fortran programming days back in the early 80s...)
In article <umv3ll$2adef$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
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.
Then he still hasn't faced up to the reason for its failure.As far as I
can tell, that was because it was too much like desktop/laptop Windows.
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.
That's true but it is a source of considerable pain for commercial
products such as VMware, VirtualBox, ZFS and others. They all have
to devote substantial engineering resources to release updates for
every kernel release.
The usual recommendation is that they should contribute the necessary
drivers to the mainline Linux kernel--along with a commitment to keep maintaining them.
Microsoft discovered this the hard way, when it got some Hyper-V
drivers accepted into the kernel, and then forgot about the part that
every piece of code in the kernel has to have a responsive
maintainer. It took the threat of the code being dropped from the
kernel to make them sit up and take notice.
With WSL2, both the Windows NT kernel and the Linux kernel run on
top
of a hypervisor. It's a nice solution and performance differences
between the two WSL systems should be night and day.
https://thecodeblogger.com/2020/08/22/understanding-differences-between-wsl-1-and-wsl-2/
That doesn't really explain why you'd think that WSL1 would be
appreciably slower (or slower at all) than WSL2. Consider that
Windows is still responsible for running IO devices and
providing access to e.g. the filesystem for Linux in the latter;
this will necessarily require lots of context switching between
the two (where in this context "context" means running in either
a Linux or Windows guest under a shared hypervisor) as Linux
accesses services provided by Windows. In WSL1 there would be
no such overhead.
Imagine saying that Android is ?too much like desktop/laptop/server/ embedded/supercomputer Linux?, because it is: they share essentially the
same kernel. Yet that didn?t stop Android from taking over the mobile
world: in fact, it probably helped.
On Wed, 2024-01-03 at 19:01 +0000, Lawrence D'Oliveiro wrote:
On Wed, 03 Jan 2024 08:54:23 +0000, Single Stage to Orbit wrote:
That's true but it is a source of considerable pain for commercial
products such as VMware, VirtualBox, ZFS and others. They all have to
devote substantial engineering resources to release updates for every
kernel release.
The usual recommendation is that they should contribute the necessary
drivers to the mainline Linux kernel--along with a commitment to keep
maintaining them.
Microsoft discovered this the hard way, when it got some Hyper-V
drivers accepted into the kernel, and then forgot about the part that
every piece of code in the kernel has to have a responsive maintainer.
It took the threat of the code being dropped from the kernel to make
them sit up and take notice.
It's the same old story, costs != profit and beancounters are not always right.
In article <un293n$2tfib$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/2/2024 2:25 PM, Andy Burns wrote:
Lawrence D'Oliveiro wrote:
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.
I didn't do anything other than "play" with WSL1, but I thought
performance was the issue.
I think I did more with MKS Toolkit and Cygwin than WSL.
Note that Cygwin and WSL does completely different things.
Cygwin:
*nix and/or Windows source--Cygwin toolchain-->Windows executable
WSL:
*nix source--Linux toolchain-->Linux executable
More like:
"cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries,
while WSL1
executes Linux-branded ELF binaries using a compatibility layer
in the Windows kernel."
Toolchains are only tangentially
relevant.
In article <umv3ll$2adef$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
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.
Then he still hasn't faced up to the reason for its failure. As far as I
can tell, that was because it was too much like desktop/laptop Windows.
iOS and Android both have pretty gentle learning curves. You don't need
to know much to start using them, and fairly small steps in learning open
up more activities quite quickly.
Windows Phone's GUI was ... kind of complicated. It makes sense to
someone who's been closely following the evolution of desktop Windows
since about the year 2000, and always sticking to the Microsoft defaults. Like, say, Microsoft's UI designers and marketing people.
But it has been a pretty twisty path, and there's a lot of accumulated strangeness. The result is not friendly to someone who has never used Windows, and that's quite hard for someone who is very pro-Windows to understand.
In article <un1s48$2r0sq$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Tue, 2 Jan 2024 19:41:21 -0000 (UTC), Dan Cross wrote:
Furthermore, the rate of change in Linux is high; following along from
outside is fraught.
Strange, isn’t it: Microsoft must have access to at least a couple of
orders of magnitude greater development resources than that available to
the Linux kernel project, yet they cannot keep up with what the Linux
developers have achieved.
This presumes that the high rate of change of Linux is actually good. I rather suspect it is not.
Me, I regarded Windows 2000 as the peak of their GUI design, and it's
been getting worse, on average, ever since.
What made many of them drop WP was the lack of apps.
On Thu, 4 Jan 2024 15:58:10 -0500, Arne Vajhøj wrote:
What made many of them drop WP was the lack of apps.
No it wasn’t.
When Android started, it didn’t have the apps either: for years afterwards, developers still prioritized Apple’s platform, and only grudgingly did apps for Android.
But that didn’t stop Android becoming ridiculously popular and dominating the mobile world. Android was popular because it offered users such a huge choice of device form factors and capabilities, out of the box.
On 1/3/2024 8:31 AM, Dan Cross wrote:
In article <un293n$2tfib$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/2/2024 2:25 PM, Andy Burns wrote:
Lawrence D'Oliveiro wrote:
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.
I didn't do anything other than "play" with WSL1, but I thought
performance was the issue.
I think I did more with MKS Toolkit and Cygwin than WSL.
Note that Cygwin and WSL does completely different things.
Cygwin:
*nix and/or Windows source--Cygwin toolchain-->Windows executable
WSL:
*nix source--Linux toolchain-->Linux executable
More like:
Less like that.
"cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries,
Cygwin does not execute executables. Cygwin produces regular
Windows executables that are executed by Windows line any other
Windows executable.
And as I described above then Cygwin can build both *nix source and
Windows source (and hybrids of those) not just *nix sources.
while WSL1
executes Linux-branded ELF binaries using a compatibility layer
in the Windows kernel."
WSL execute standard Linux binaries - not something just Linux branded.
And being ELF binaries is not sufficient - it has to be Linux binaries.
Toolchains are only tangentially
relevant.
Toolschains are really the only thing that matters.
WSL exist to allow developers to run Linux toolchains.
In article <un75ou$3pjg7$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2024 8:31 AM, Dan Cross wrote:
"cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries,
Cygwin does not execute executables. Cygwin produces regular
Windows executables that are executed by Windows line any other
Windows executable.
Nope. Cygwin is an _environment_ that exists under Windows,
along with a user interface, that supports executing Unix-style
programs. Yes, there's a toolchain, but Cygwin itself is not
only a toolchain. The more important thing, in many ways, is
the Cygwin DLL that supports cygwin execution.
You may quibble with the terminology here; it is true that
technically _windows_ loads and starts those executables running
and the hardware actually does the execution, but it is saying
that "cygwin produced regular Windows executables" is so vague
as to be outright incorrect.
And as I described above then Cygwin can build both *nix source and
Windows source (and hybrids of those) not just *nix sources.
You seem to be referring to the cygwin toolchain, which is only
part of cygwin. See https://cygwin.com/ for more.
Toolchains are only tangentially
relevant.
Toolschains are really the only thing that matters.
Nope.
WSL exist to allow developers to run Linux toolchains.
No, WSL exists to allow Windows users to run a "Linux
environment", full-stop, running unmodified Linux-branded
ELF binaries. Users can, of course, run a toolchain if they
wish, but they are not limited to that; believing so is a
failure of imagination.
On 1/4/2024 5:25 PM, Lawrence D'Oliveiro wrote:
On Thu, 4 Jan 2024 15:58:10 -0500, Arne Vajhøj wrote:
Inserted back:
#But what I heard from most WP users back then was that they #actually
liked the UI.
What made many of them drop WP was the lack of apps.
No it wasn’t.
Are you telling me that you know better than me what I heard back then?
When Android started, it didn’t have the apps either: for
years afterwards, developers still prioritized Apple’s platform, and
only grudgingly did apps for Android.
But that didn’t stop Android becoming ridiculously popular and
dominating the mobile world. Android was popular because it offered
users such a huge choice of device form factors and capabilities, out
of the box.
Companies did create Android apps. I have no idea whether happy or grudgingly. But they did.
It took Google 1 year to reach 100000 apps and 4 years to reach 1
million. Apple took 1 year and 5 years for the same, so practically the
same velocity and same level reached in 2013.
On Thu, 4 Jan 2024 20:13:49 -0500, Arne Vajhøj wrote:
On 1/4/2024 5:25 PM, Lawrence D'Oliveiro wrote:
On Thu, 4 Jan 2024 15:58:10 -0500, Arne Vajhøj wrote:
Inserted back:
#But what I heard from most WP users back then was that they
#actually liked the UI.
What made many of them drop WP was the lack of apps.
No it wasn’t.
Are you telling me that you know better than me what I heard back then?
Yes. I watched it unfold, in my efforts to learn Android development
myself. I saw the comments about apps and lack of apps.
When Android started, it didn’t have the apps either: for >>> years afterwards, developers still prioritized Apple’s platform, and
only grudgingly did apps for Android.
But that didn’t stop Android becoming ridiculously popular and
dominating the mobile world. Android was popular because it offered
users such a huge choice of device form factors and capabilities, out
of the box.
Companies did create Android apps. I have no idea whether happy or
grudgingly. But they did.
Yes, eventually, like I said. Even some years later, you could say that Apple’s platform still had the app advantage. Yet that didn’t stop Android
from outselling it by 3:1. (Not sure what the ratio is now.)
It took Google 1 year to reach 100000 apps and 4 years to reach 1
million. Apple took 1 year and 5 years for the same, so practically the
same velocity and same level reached in 2013.
Not sure about sheer quantity, but there was a definite feeling that the important apps came first to Apple’s platform for many years.
On Thu, 4 Jan 2024 20:13:49 -0500, Arne Vajhøj wrote:
On 1/4/2024 5:25 PM, Lawrence D'Oliveiro wrote:
On Thu, 4 Jan 2024 15:58:10 -0500, Arne Vajhøj wrote:
Inserted back:
#But what I heard from most WP users back then was that they #actually
liked the UI.
What made many of them drop WP was the lack of apps.
No it wasn’t.
Are you telling me that you know better than me what I heard back then?
Yes. I watched it unfold, in my efforts to learn Android development
myself. I saw the comments about apps and lack of apps.
On 1/4/2024 7:34 PM, Dan Cross wrote:
In article <un75ou$3pjg7$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2024 8:31 AM, Dan Cross wrote:
"cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries,
Cygwin does not execute executables. Cygwin produces regular
Windows executables that are executed by Windows line any other
Windows executable.
Nope. Cygwin is an _environment_ that exists under Windows,
along with a user interface, that supports executing Unix-style
programs. Yes, there's a toolchain, but Cygwin itself is not
only a toolchain. The more important thing, in many ways, is
the Cygwin DLL that supports cygwin execution.
You may quibble with the terminology here; it is true that
technically _windows_ loads and starts those executables running
and the hardware actually does the execution, but it is saying
that "cygwin produced regular Windows executables" is so vague
as to be outright incorrect.
It is precisely correct.
Building with Cygwin toolchain produce an executable that
can run on any Windows system as long as the DLL's it use
are present.
It does not need any Cygwin environment.
And as I described above then Cygwin can build both *nix source and
Windows source (and hybrids of those) not just *nix sources.
You seem to be referring to the cygwin toolchain, which is only
part of cygwin. See https://cygwin.com/ for more.
But it is a difference between Cygwin and WSL.
Cygwin GCC accepts both Windows and *nix source. WSL GCC accept only
*nix source.
Toolchains are only tangentially
relevant.
Toolschains are really the only thing that matters.
Nope.
WSL exist to allow developers to run Linux toolchains.
No, WSL exists to allow Windows users to run a "Linux
environment", full-stop, running unmodified Linux-branded
ELF binaries. Users can, of course, run a toolchain if they
wish, but they are not limited to that; believing so is a
failure of imagination.
Microsoft has clearly stated that it is intended for
developers to build for Linux.
I assume that Microsoft knows why they have created WSL.
In article <un7mh8$3ro6t$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/4/2024 7:34 PM, Dan Cross wrote:
In article <un75ou$3pjg7$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2024 8:31 AM, Dan Cross wrote:
"cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries,
Cygwin does not execute executables. Cygwin produces regular
Windows executables that are executed by Windows line any other
Windows executable.
Nope. Cygwin is an _environment_ that exists under Windows,
along with a user interface, that supports executing Unix-style
programs. Yes, there's a toolchain, but Cygwin itself is not
only a toolchain. The more important thing, in many ways, is
the Cygwin DLL that supports cygwin execution.
You may quibble with the terminology here; it is true that
technically _windows_ loads and starts those executables running
and the hardware actually does the execution, but it is saying
that "cygwin produced regular Windows executables" is so vague
as to be outright incorrect.
It is precisely correct.
Building with Cygwin toolchain produce an executable that
can run on any Windows system as long as the DLL's it use
are present.
Go back and reread what I wrote.
It does not need any Cygwin environment.
https://cygwin.com/cygwin-ug-net/overview.html#what-is-it
|What is it?
|
|Cygwin is a Linux-like environment for Windows. It consists of
|a DLL (cygwin1.dll), which acts as an emulation layer providing
|substantial POSIX (Portable Operating System Interface) system
|call functionality, and a collection of tools, which provide a
|Linux look and feel. The Cygwin DLL works with all AMD64
|versions of Windows NT since Windows Vista/Server 2008. The API
|follows the Single Unix Specification as much as possible, and
|then Linux practice. The major differences between Cygwin and
|Linux is the C library (newlib instead of glibc).
|
|With Cygwin installed, users have access to many standard UNIX
|utilities. They can be used from one of the provided shells
|such as bash or from the Windows Command Prompt. Additionally,
|programmers may write Win32 console or GUI applications that
|make use of the standard Microsoft Win32 API and/or the Cygwin
|API. As a result, it is possible to easily port many
|significant UNIX programs without the need for extensive
|changes to the source code. This includes configuring and
|building most of the available GNU software (including the
|development tools included with the Cygwin distribution).
In their own words, "Cygwin is a Linux-like environment for
Windows."
And as I described above then Cygwin can build both *nix source and
Windows source (and hybrids of those) not just *nix sources.
You seem to be referring to the cygwin toolchain, which is only
part of cygwin. See https://cygwin.com/ for more.
But it is a difference between Cygwin and WSL.
Cygwin GCC accepts both Windows and *nix source. WSL GCC accept only
*nix source.
So what?
Toolchains are only tangentially
relevant.
Toolschains are really the only thing that matters.
Nope.
WSL exist to allow developers to run Linux toolchains.
No, WSL exists to allow Windows users to run a "Linux
environment", full-stop, running unmodified Linux-branded
ELF binaries. Users can, of course, run a toolchain if they
wish, but they are not limited to that; believing so is a
failure of imagination.
Microsoft has clearly stated that it is intended for
developers to build for Linux.
I assume that Microsoft knows why they have created WSL.
From, https://learn.microsoft.com/en-us/windows/wsl/about:
|Windows Subsystem for Linux (WSL) is a feature of Windows that
|allows you to run a Linux environment on your Windows machine,
|without the need for a separate virtual machine or dual
|booting.
It is not a toolchain. Is that environment intended for
developers? Yes. Can you do more than run a toolchain?
Yes.
On 1/4/2024 8:46 PM, Dan Cross wrote:
In article <un7mh8$3ro6t$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/4/2024 7:34 PM, Dan Cross wrote:
In article <un75ou$3pjg7$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 1/3/2024 8:31 AM, Dan Cross wrote:
"cygwin executes Windows executables that are built
from Unix-y sources using compatibility libraries,
Cygwin does not execute executables. Cygwin produces regular
Windows executables that are executed by Windows line any other
Windows executable.
Nope. Cygwin is an _environment_ that exists under Windows,
along with a user interface, that supports executing Unix-style
programs. Yes, there's a toolchain, but Cygwin itself is not
only a toolchain. The more important thing, in many ways, is
the Cygwin DLL that supports cygwin execution.
You may quibble with the terminology here; it is true that
technically _windows_ loads and starts those executables running
and the hardware actually does the execution, but it is saying
that "cygwin produced regular Windows executables" is so vague
as to be outright incorrect.
It is precisely correct.
Building with Cygwin toolchain produce an executable that
can run on any Windows system as long as the DLL's it use
are present.
Go back and reread what I wrote.
It does not need any Cygwin environment.
https://cygwin.com/cygwin-ug-net/overview.html#what-is-it
|What is it?
|
|Cygwin is a Linux-like environment for Windows. It consists of
|a DLL (cygwin1.dll), which acts as an emulation layer providing
|substantial POSIX (Portable Operating System Interface) system
|call functionality, and a collection of tools, which provide a
|Linux look and feel. The Cygwin DLL works with all AMD64
|versions of Windows NT since Windows Vista/Server 2008. The API
|follows the Single Unix Specification as much as possible, and
|then Linux practice. The major differences between Cygwin and
|Linux is the C library (newlib instead of glibc).
|
|With Cygwin installed, users have access to many standard UNIX
|utilities. They can be used from one of the provided shells
|such as bash or from the Windows Command Prompt. Additionally,
|programmers may write Win32 console or GUI applications that
|make use of the standard Microsoft Win32 API and/or the Cygwin
|API. As a result, it is possible to easily port many
|significant UNIX programs without the need for extensive
|changes to the source code. This includes configuring and
|building most of the available GNU software (including the
|development tools included with the Cygwin distribution).
In their own words, "Cygwin is a Linux-like environment for
Windows."
Yes.
But when used for development it still produces standard
Windows executables, that does not require Cygwin to run.
WSL is used to create standard Linux executables that
require WSL or another Linux to run.
And as I described above then Cygwin can build both *nix source and
Windows source (and hybrids of those) not just *nix sources.
You seem to be referring to the cygwin toolchain, which is only
part of cygwin. See https://cygwin.com/ for more.
But it is a difference between Cygwin and WSL.
Cygwin GCC accepts both Windows and *nix source. WSL GCC accept only
*nix source.
So what?
It is a difference.
My list of differences had it.
Your list of differences did not have it.
Toolchains are only tangentially >>>>>> relevant.
Toolschains are really the only thing that matters.
Nope.
WSL exist to allow developers to run Linux toolchains.
No, WSL exists to allow Windows users to run a "Linux
environment", full-stop, running unmodified Linux-branded
ELF binaries. Users can, of course, run a toolchain if they
wish, but they are not limited to that; believing so is a
failure of imagination.
Microsoft has clearly stated that it is intended for
developers to build for Linux.
I assume that Microsoft knows why they have created WSL.
From, https://learn.microsoft.com/en-us/windows/wsl/about:
|Windows Subsystem for Linux (WSL) is a feature of Windows that
|allows you to run a Linux environment on your Windows machine,
|without the need for a separate virtual machine or dual
|booting.
And it continues:
# WSL is designed to provide a seamless and productive experience for
# developers who want to use both Windows and Linux at the same time.
It is not a toolchain. Is that environment intended for
developers? Yes. Can you do more than run a toolchain?
Yes.
It is intended for developers to run a standard Linux
build toolchain to enable Linux builds on Windows. MS
want to keep developers on Windows.
It could be used to browse the web, read email and use
word processors and spreadsheets.
But MS has no interest in WSL being used for that.
And I don't think any WSL users use it for that.
In article <un7lua$3rjrl$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Thu, 4 Jan 2024 20:13:49 -0500, Arne Vajhøj wrote:
On 1/4/2024 5:25 PM, Lawrence D'Oliveiro wrote:
On Thu, 4 Jan 2024 15:58:10 -0500, Arne Vajhøj wrote:
Inserted back:
#But what I heard from most WP users back then was that they #actually
liked the UI.
What made many of them drop WP was the lack of apps.
No it wasn’t.
Are you telling me that you know better than me what I heard back then?
Yes. I watched it unfold, in my efforts to learn Android development
myself. I saw the comments about apps and lack of apps.
You don't seem to realize it, but you are responding to a
comment where Arne is talking about people he knows or knew
who talked about why they (that is, those people, specifically)
abandoned the Windows Phone. Whether Arne's set of
aquantances and their personal preferences has any particular
meaning is debatable (it is anecdotal at best), but, as I feel
it same to assume you don't know the people he's specifically
referring to, you are arguing something that is clearly false.
https://www.zdnet.com/article/here-are-the-real-reasons-windows-phone-failed-reveals-ex-nokia-engineer/
Former Nokia engineer
<quote>
"Even if WP got apps and whatever else it lacked, there just wasn't a compelling reason to switch. Even now I sense the number swapping
between iOS and Android is pretty low."
</quote>
Not sure about sheer quantity, but there was a definite feeling
that the important apps came first to Apple's platform for many
years.
That problem still exist for anyone trying to get into the
phone market without being hooked into Apple App Store or
Google Play.
In article <un7lua$3rjrl$1@dont-email.me>, ldo@nz.invalid (Lawrence D'Oliveiro) wrote:
Not sure about sheer quantity, but there was a definite feeling
that the important apps came first to Apple's platform for many
years.
iPhone users are apparently far more willing to spend money on apps. I don't have numbers for this.
On 1/3/2024 4:52 PM, John Dallman wrote:
Me, I regarded Windows 2000 as the peak of their GUI design, and it's
been getting worse, on average, ever since.
Many have that feeling.
Not quite so many if they actually go back.
I had to recently do some work on XP. I was not impressed.
On 2024-01-04, Arne Vajhøj <arne@vajhoej.dk> wrote:
That problem still exist for anyone trying to get into the
phone market without being hooked into Apple App Store or
Google Play.
Sailfish OS seems to have established a niche for itself:
https://sailfishos.org/
It also comes with an optional Android compatibility module if you want it.
Last I heard however, there were restrictions on which countries it is available in.
On 2024-01-04, Arne Vajhřj <arne@vajhoej.dk> wrote:
On 1/3/2024 4:52 PM, John Dallman wrote:
Me, I regarded Windows 2000 as the peak of their GUI design, and it's
been getting worse, on average, ever since.
Many have that feeling.
Not quite so many if they actually go back.
I had to recently do some work on XP. I was not impressed.
I looked at some articles with pictures of the Windows 2000 UI recently
and nothing has changed my impression that it is still one hell of a lot
more usable that the default Windows 10 UI.
For example, which arrogant cretin thought it was OK to _force_ 1px
borders on users in Windows 10 ? Those are not borders, those are piss-takes.
Also, looking at those Windows 2000 UI pictures reminded me of how much
more easier it was to navigate instead of those horrible flat low-contrast
UI elements in Windows 10 where it's sometimes hard to even tell _what_
is clickable.
John is absolutely right about Windows 2000.
I don't know hos much he was thinking about "the Windows Phone 8
code base" versus just "a MS OS for phones".
But what I heard from most WP users back then was that they
actually liked the UI.
What made many of them drop WP was the lack of apps. The WP
apps eco-system could not compete with the gazillion
iOS and Android apps.
Companies only developed apps for iOS and Android, because there
were too few WP users. And there were too few WP users because
companies only developed apps for iOS and Android.
In article <un7652$3pjg7$3@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
I don't know hos much he was thinking about "the Windows Phone 8
code base" versus just "a MS OS for phones".
But what I heard from most WP users back then was that they
actually liked the UI.
Experienced Windows users often did. The majority of Android devices in
the world, and a very large chunk of the iPhones, are used by people who haven't used any other kind of computing device, and thus aren't familiar with Windows.
What made many of them drop WP was the lack of apps. The WP
apps eco-system could not compete with the gazillion
iOS and Android apps.
Companies only developed apps for iOS and Android, because there
were too few WP users. And there were too few WP users because
companies only developed apps for iOS and Android.
Microsoft tried to apply pressure to ISVs that had significant Windows products to put them onto Windows Phone. However, they didn't do this selectively, they just assumed everyone was after the personal apps
market because they were. My experience of this was that they were
annoyingly persistent about trying to get us to do things that didn't
make any business sense.
But there are still around a billion people with Windows experience.
Sound to me like someone at MS really didn't understand the phone
app market.
Microsoft tried to apply pressure to ISVs that had significant Windows products to put them onto Windows Phone.
But Microsoft and Nokia didn't do at all a good job of
selling them phones.
There are lots of niche OS in the phone market.
But the keyword is niche.
Microsoft and Nokia tried to change the big market from 2 to 3 but
failed.
For example, Windows Phone 7 only ran on a single core.
Windows Phone 8
only ran on two cores--no more, no less. This was when contemporary
versions of Android could run on anything from a single core up to--I’m
not sure, there were 4-core, might even have been some 8-core devices by
that time.
On 1/5/2024 6:25 PM, Lawrence D'Oliveiro wrote:
For example, Windows Phone 7 only ran on a single core.
WP7 was a bit limited because it was based on Windows CE.
Windows Phone 8
only ran on two cores--no more, no less. This was when contemporary
versions of Android could run on anything from a single core up to--I’m
not sure, there were 4-core, might even have been some 8-core devices
by that time.
Good story. But it has nothing to do with reality.
WP8 was Windows NT based and supported up to 64 cores.
On Fri, 5 Jan 2024 19:43:49 -0500, Arne Vajhøj wrote:
On 1/5/2024 6:25 PM, Lawrence D'Oliveiro wrote:
For example, Windows Phone 7 only ran on a single core.
WP7 was a bit limited because it was based on Windows CE.
No, it was all the NT kernel.
Windows Phone 8
only ran on two cores--no more, no less. This was when contemporary
versions of Android could run on anything from a single core up to--I’m >>> not sure, there were 4-core, might even have been some 8-core devices
by that time.
Good story. But it has nothing to do with reality.
WP8 was Windows NT based and supported up to 64 cores.
The Windows Phone 8 specs were public knowledge. That’s what Microsoft
told OEMs. I was watching all this unfold at the time.
Certainly it would not run on a single core.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 435 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 148:18:05 |
| Calls: | 9,120 |
| Calls today: | 3 |
| Files: | 13,425 |
| Messages: | 6,033,669 |