• RMS intro

    From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Sat Dec 30 19:28:29 2023
    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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Sun Dec 31 07:43:00 2023
    In article <umqcjd$1er1l$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Sun Dec 31 09:49:55 2023
    On 12/31/2023 2:43 AM, John Dallman wrote:
    In article <umqcjd$1er1l$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
    https://www.vajhoej.dk/arne/articles/rms.html

    Good work. You might want to explain why StreamCR is provided: I doubt it
    is because of traditional Mac format, because VMS predates Mac by several years. Was it used by older DEC OSes?

    Good question. I don't know.

    RSX-11? RT-11? RSTS/E? TOPS-10?

    Anyone?

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 17:11:45 2023
    On 12/31/2023 4:29 PM, Lawrence D'Oliveiro wrote:
    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.

    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.

    And the RMS manual for VMS 2.0:

    https://bitsavers.org/pdf/dec/vax/vms/2.0/AA-D031C-TE_VAX-11_2.0_Record_Management_Services_Reference_Manual_198003.pdf

    does not list the stream formats, so it indeed look like a
    later addition.

    But that is sort of the benefit from RMS. It is possible to
    add an entirely new record format and everything calling
    SYS$GET directly or indirectly via language IO will not
    need any change.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Sun Dec 31 21:50:36 2023
    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!”

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Sun Dec 31 21:34:00 2023
    In article <umrv2j$1ooih$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    wrote:

    Good work. You might want to explain why StreamCR is provided: I
    doubt it is because of traditional Mac format, because VMS
    predates Mac by several years. Was it used by older DEC OSes?

    Good question. I don't know.

    RSX-11? RT-11? RSTS/E? TOPS-10?

    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.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Sun Dec 31 21:29:35 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to John Dallman on Sun Dec 31 23:07:49 2023
    In article <memo.20231231074319.16260W@jgd.cix.co.uk>,
    John Dallman <jgd@cix.co.uk> wrote:
    In article <umqcjd$1er1l$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj) >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?

    Perhaps for direct terminal input. By default, DEC terminals
    like the VT100 only send a CR when the RETURN key is pressed.
    (They can be configured to send CRLF via an option on the setup
    screen, however.) Anyway, I'm speculating, but I can imagine a
    mode in which data is copied directly from a terminal to a file
    preserving the single CR character.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 22:53:01 2023
    On 31/12/2023 21:50, Lawrence D'Oliveiro wrote:
    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!”

    Along with 64k...

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Sun Dec 31 23:13:27 2023
    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.

    I first got my hands on a VMS system in 1979. I was a first-year Comp Sci student, and first-year students were not supposed to have access to time- sharing accounts. But the difference between that and RSTS/E (which I also
    was not supposed to have access to) was like night and day.

    I’m not sure what version of VMS that was. It was likely 2.2, or possibly earlier. There was an interesting privilege-escalation security hole in
    2.2’s handling of message sections, which became quite clear if you read
    the internals manual ... which I only got my hands on after we had
    upgraded to 3.0.

    I can remember quite a few other milestones off the top of my head. Like
    some compatibility issues with the third-party serial drivers in VMS 2.x,
    which went away in 3.0 because the terminal driver was split into a (hardware-independent) “class” driver and a (hardware-specific) “port” driver. This meant that third-party hardware vendors only needed to supply their own “port” driver, and they automatically got all the standard QIO and control-character support, just like DEC’s own terminal drivers.

    VMS 4.0 was also the version that increased the length of file names from 9-dot-3 to 39-dot-39.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Chris Townley on Sun Dec 31 23:04:18 2023
    On Sun, 31 Dec 2023 22:53:01 +0000, Chris Townley wrote:

    On 31/12/2023 21:50, Lawrence D'Oliveiro wrote:

    Microsoft: “26 drive letters ought to be enough for anybody!”

    Along with 64k...

    You mean “640k” ... no, it’s unlikely Bill Gates would ever have said such
    a thing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Dorsey@21:1/5 to ldo@nz.invalid on Sun Dec 31 22:18:06 2023
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    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. Whether
    lf or crlf was used depended a lot on the whims of the original developers. Most terminals had a switch that allowed you to toggle them.
    --scott


    --
    "C'est un Nagra. C'est suisse, et tres, tres precis."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Scott Dorsey on Sun Dec 31 23:15:51 2023
    On 31 Dec 2023 22:18:06 -0000, Scott Dorsey wrote:

    Most operating systems out there only used stream_lf and stream_cr.

    Actually I think the timing of addition of those STREAM_xx formats was a
    little too early to be credited/blamed on the Mac. STREAM_CRLF would have
    been because of the massive popularity of MS-DOS and the IBM PC by that
    time, and STREAM_LF was similarly a sign of feeling the pressure from
    Unix. STREAM_CR ... maybe that was just stuck in for completeness. I
    really don’t know of any other OSes that might have used it, apart from
    old MacOS.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 19:39:09 2023
    On 12/31/2023 6:13 PM, Lawrence D'Oliveiro wrote:
    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.

    That I did know.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 19:38:00 2023
    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.

    It is just that nobody use it.

    Probably because 26 letters actually are more than enough.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jan 1 02:05:59 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 21:36:33 2023
    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.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jan 1 03:09:31 2024
    On Sun, 31 Dec 2023 21:52:53 -0500, Arne Vajhøj wrote:

    If one is a Windows user that:
    * need more than 26 drives

    Or even just wants something more meaningful than a single-letter name for their volumes.

    AFAIK there are no current plans to replace NTFS.

    Not that Microsoft hasn’t tried, somewhat. See ReFS.

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jan 1 02:40:57 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 21:52:53 2023
    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.

    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.

    AFAIK there are no current plans to replace NTFS.

    And when they eventually replace it, then it seems likely that
    the NTFS feature set will be made requirements for the new
    file system. Backwards compatibility is a big thing for Microsoft.

    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.

    WSL is not an attempt to make Windows like Linux.

    WSL is a tool for developers that need to develop for both
    Windows and Linux on Windows.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Sun Dec 31 22:35:34 2023
    On 12/31/2023 10:09 PM, Lawrence D'Oliveiro wrote:
    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.

    It has a rather specific target group.

    To quote from the WSL FAQ:

    <quote>
    Who is WSL for?

    This is primarily a tool for developers, especially web developers,
    those working on open source projects, or deploying to Linux server environments. WSL is for anyone who likes using Bash, common Linux tools
    (sed, awk, etc.) and Linux-first frameworks (Ruby, Python, etc.) but
    also enjoys using Windows productivity tools
    </quote>

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jan 1 04:51:45 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Townley@21:1/5 to Lawrence D'Oliveiro on Mon Jan 1 12:25:44 2024
    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

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Mon Jan 1 09:48:53 2024
    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.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Chris Townley on Mon Jan 1 09:55:44 2024
    On 1/1/2024 7:25 AM, Chris Townley wrote:
    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

    You sort of get both with WSL.

    You get a VM with a Linux distro of your choice (among the
    approx. dozen that MS supports) that behaves pretty much like
    any other Linux VM. Except that there are no visible startup time.

    But you also get the ability to use Linux commands in
    your CMD windows. Example:

    wsl ls -la

    They do some magic to utilize the Linux stuff in the VM.

    I would not use WSL to run a server of any kind. But to
    do a Linux build of some code, then why not.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Mon Jan 1 16:12:41 2024
    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.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Mon Jan 1 11:46:04 2024
    On 1/1/2024 11:12 AM, Dan Cross wrote:
    In article <umujck$282li$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
    It stands for Linux, but that does not mean that they are trying to move >>>> the general Windows user to a Linux experience.

    That seems inevitable, though. At some point it is going to become a
    mandatory part of any Windows install. I’m not saying it was Microsoft’s
    conscious intention when they introduced it, but it will become the path >>> of least resistance.

    MS could roll it out to every Windows user tomorrow if they
    wanted to.

    But why on earth would they want to do that??

    To pave a way for MSFT to jetison Windows in favor of Linux.

    Maintaining an OS like Windows is expensive and requires a
    steady stream of talent. There is more talent working on that
    kind of thing outside of Microsoft than inside, just not on
    Windows: most of the work is happening around Linux. Being able
    to leverage that investment would be a strategic win.

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

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

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

    Does not make any business sense.

    For servers the preference is real ESXi/Hyper-V/KVM not WSL.

    For desktop/laptop the vast majorities of users has no interest
    in Linux at all. Windows are facing serious challenges, but not
    from (traditional) Linux. Windows usage is dropping because
    people are switching to Android/iOS phones/tablets.

    People are switching from a GUI centric OS (Windows) to
    GUI only OS (Android & iOS) for casual use. Expecting them
    to use WSL command line utilities is a non-starter.

    This conflates two things: WSL as a path for moving to Linux
    as the kernel substrate for Microsoft's OS offerings, and using
    WSL as an end user.

    The latter is likely never going to happen outside of developer
    communities. The former could well happen; WSL gives MSFT a
    low-cost way to dip their toe into the waters and explore
    interoperability between the traditional Windows API and Linux.

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

    But WSL does not provide anything for that.

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

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Mon Jan 1 16:52:50 2024
    In article <umuq8b$28tuo$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 11:12 AM, Dan Cross wrote:
    In article <umujck$282li$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
    It stands for Linux, but that does not mean that they are trying to move >>>>> the general Windows user to a Linux experience.

    That seems inevitable, though. At some point it is going to become a
    mandatory part of any Windows install. I’m not saying it was Microsoft’s
    conscious intention when they introduced it, but it will become the path >>>> of least resistance.

    MS could roll it out to every Windows user tomorrow if they
    wanted to.

    But why on earth would they want to do that??

    To pave a way for MSFT to jetison Windows in favor of Linux.

    Maintaining an OS like Windows is expensive and requires a
    steady stream of talent. There is more talent working on that
    kind of thing outside of Microsoft than inside, just not on
    Windows: most of the work is happening around Linux. Being able
    to leverage that investment would be a strategic win.

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

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

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

    Does not make any business sense.

    ...right now.

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

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

    For servers the preference is real ESXi/Hyper-V/KVM not WSL.

    For desktop/laptop the vast majorities of users has no interest
    in Linux at all. Windows are facing serious challenges, but not
    from (traditional) Linux. Windows usage is dropping because
    people are switching to Android/iOS phones/tablets.

    People are switching from a GUI centric OS (Windows) to
    GUI only OS (Android & iOS) for casual use. Expecting them
    to use WSL command line utilities is a non-starter.

    This conflates two things: WSL as a path for moving to Linux
    as the kernel substrate for Microsoft's OS offerings, and using
    WSL as an end user.

    The latter is likely never going to happen outside of developer
    communities. The former could well happen; WSL gives MSFT a
    low-cost way to dip their toe into the waters and explore
    interoperability between the traditional Windows API and Linux.

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

    But WSL does not provide anything for that.

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

    ...and integration at the file level.

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

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

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Froble@21:1/5 to All on Mon Jan 1 12:48:39 2024
    On 12/31/2023 9:52 PM, Arne Vajhøj wrote:
    On 12/31/2023 9:40 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 21:36:33 -0500, Arne Vajhøj wrote:
    On 12/31/2023 9:05 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 19:38:00 -0500, Arne Vajhøj wrote:
    On 12/31/2023 4:50 PM, Lawrence D'Oliveiro wrote:
    Along with those 8-bit-era single-letter drive names, for some
    reason.

    Microsoft: “26 drive letters ought to be enough for anybody!”

    You can mount disks without using drive letters with NTFS.

    As I recall from reading docs, that doesn’t work with network shares or >>>> hot-pluggable storage. Or this thing called “storage spaces”.

    You don't need it for a network share - those can just be accessed
    directly via UNC.

    So how do you select from available UNC shares in an application’s file
    picker?

    (it is said that one can make a symlink to UNC if one want to)

    Windows symlinks have their own share of problems.

    If one is a Windows user that:
    * need more than 26 drives
    * need to use a file picker to choose network drives
    * don't like to create symlinks
    then one has a problem.

    But my guess is that you can invite everyone in the world matching
    that criteria to coffee in your dining room.

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

    Does such even exist anymore?

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Mon Jan 1 14:26:45 2024
    On 1/1/2024 11:52 AM, Dan Cross wrote:
    In article <umuq8b$28tuo$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 11:12 AM, Dan Cross wrote:
    In article <umujck$282li$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
    It stands for Linux, but that does not mean that they are trying to move >>>>>> the general Windows user to a Linux experience.

    That seems inevitable, though. At some point it is going to become a >>>>> mandatory part of any Windows install. I’m not saying it was Microsoft’s
    conscious intention when they introduced it, but it will become the path >>>>> of least resistance.

    MS could roll it out to every Windows user tomorrow if they
    wanted to.

    But why on earth would they want to do that??

    To pave a way for MSFT to jetison Windows in favor of Linux.

    Maintaining an OS like Windows is expensive and requires a
    steady stream of talent. There is more talent working on that
    kind of thing outside of Microsoft than inside, just not on
    Windows: most of the work is happening around Linux. Being able
    to leverage that investment would be a strategic win.

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

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

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

    Does not make any business sense.

    ...right now.

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

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

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

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

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

    For desktop/laptop the vast majorities of users has no interest
    in Linux at all. Windows are facing serious challenges, but not
    from (traditional) Linux. Windows usage is dropping because
    people are switching to Android/iOS phones/tablets.

    People are switching from a GUI centric OS (Windows) to
    GUI only OS (Android & iOS) for casual use. Expecting them
    to use WSL command line utilities is a non-starter.

    This conflates two things: WSL as a path for moving to Linux
    as the kernel substrate for Microsoft's OS offerings, and using
    WSL as an end user.

    The latter is likely never going to happen outside of developer
    communities. The former could well happen; WSL gives MSFT a
    low-cost way to dip their toe into the waters and explore
    interoperability between the traditional Windows API and Linux.

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

    But WSL does not provide anything for that.

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

    ...and integration at the file level.

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

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

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

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Mon Jan 1 20:15:27 2024
    In article <umv3ll$2adef$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 11:52 AM, Dan Cross wrote:
    [snip]
    ...right now.

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

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

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

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

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

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

    For desktop/laptop the vast majorities of users has no interest
    in Linux at all. Windows are facing serious challenges, but not
    from (traditional) Linux. Windows usage is dropping because
    people are switching to Android/iOS phones/tablets.

    People are switching from a GUI centric OS (Windows) to
    GUI only OS (Android & iOS) for casual use. Expecting them
    to use WSL command line utilities is a non-starter.

    This conflates two things: WSL as a path for moving to Linux
    as the kernel substrate for Microsoft's OS offerings, and using
    WSL as an end user.

    The latter is likely never going to happen outside of developer
    communities. The former could well happen; WSL gives MSFT a
    low-cost way to dip their toe into the waters and explore
    interoperability between the traditional Windows API and Linux.

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

    But WSL does not provide anything for that.

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

    ...and integration at the file level.

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

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

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

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

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

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Mon Jan 1 21:57:06 2024
    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/>.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Chris Townley on Mon Jan 1 21:51:42 2024
    On Mon, 1 Jan 2024 12:25:44 +0000, Chris Townley wrote:

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Mon Jan 1 19:34:58 2024
    On 1/1/2024 3:15 PM, Dan Cross wrote:
    In article <umv3ll$2adef$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 11:52 AM, Dan Cross wrote:
    [snip]
    ...right now.

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

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

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

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

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

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

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

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

    For desktop/laptop the vast majorities of users has no interest
    in Linux at all. Windows are facing serious challenges, but not
    from (traditional) Linux. Windows usage is dropping because
    people are switching to Android/iOS phones/tablets.

    People are switching from a GUI centric OS (Windows) to
    GUI only OS (Android & iOS) for casual use. Expecting them
    to use WSL command line utilities is a non-starter.

    This conflates two things: WSL as a path for moving to Linux
    as the kernel substrate for Microsoft's OS offerings, and using
    WSL as an end user.

    The latter is likely never going to happen outside of developer
    communities. The former could well happen; WSL gives MSFT a
    low-cost way to dip their toe into the waters and explore
    interoperability between the traditional Windows API and Linux.

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

    But WSL does not provide anything for that.

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

    ...and integration at the file level.

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

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

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

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

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

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

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

    Arne

    on Windows 7

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Mon Jan 1 19:54:38 2024
    On 1/1/2024 4:57 PM, Lawrence D'Oliveiro wrote:
    On Mon, 1 Jan 2024 09:48:53 -0500, Arne Vajhøj wrote:
    On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
    It stands for Linux, but that does not mean that they are trying to
    move the general Windows user to a Linux experience.

    That seems inevitable, though. At some point it is going to become a
    mandatory part of any Windows install. I’m not saying it was
    Microsoft’s conscious intention when they introduced it, but it will
    become the path of least resistance.

    But why on earth would they want to do that??

    Because Windows is becoming increasingly complex and expensive for
    Microsoft to maintain,

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

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

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

    Windows sale = 20 B$/year.

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

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

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

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

    I can't see that.

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

    The compatibility API solution would not reduce maintenance significant.

    From:

    COM + .NET
    Win32
    NT kernel

    to:

    COM + .NET
    Win32
    Linux kernel

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

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

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to All on Tue Jan 2 11:10:11 2024
    On Mon, 2024-01-01 at 09:55 -0500, Arne Vajhøj wrote:
    You sort of get both with WSL.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Lawrence D'Oliveiro on Tue Jan 2 11:09:06 2024
    On Mon, 2024-01-01 at 02:40 +0000, Lawrence D'Oliveiro wrote:
    So how do you select from available UNC shares in an application’s
    file picker?

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to All on Tue Jan 2 11:08:16 2024
    On Sun, 2023-12-31 at 19:38 -0500, Arne Vajhøj wrote:
    You can mount disks without using drive letters with NTFS.

    It is just that nobody use it.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Dave Froble on Tue Jan 2 11:11:37 2024
    On Mon, 2024-01-01 at 12:48 -0500, Dave Froble wrote:
    Even  if your dining room is a phone booth ...

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Single Stage to Orbit on Tue Jan 2 12:46:14 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Single Stage to Orbit on Tue Jan 2 07:28:37 2024
    On 1/2/2024 6:10 AM, Single Stage to Orbit wrote:
    On Mon, 2024-01-01 at 09:55 -0500, Arne Vajhøj wrote:
    You sort of get both with WSL.

    No, WSL is terrible! Use WSL2 instead.

    I guess I was not being precise enough.

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

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Andy Burns on Tue Jan 2 08:24:40 2024
    On 1/2/2024 7:46 AM, Andy Burns wrote:
    Single Stage to Orbit wrote:
    Arne Vajhøj wrote:
    You sort of get both with WSL.

    No, WSL is terrible! Use WSL2 instead.

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

    Was the problem with WSL1 performance?

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to John Dallman on Tue Jan 2 13:39:52 2024
    On 2023-12-31, John Dallman <jgd@cix.co.uk> wrote:
    In article <umqcjd$1er1l$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj) wrote:

    https://www.vajhoej.dk/arne/articles/rms.html

    Good work. You might want to explain why StreamCR is provided: I doubt it
    is because of traditional Mac format, because VMS predates Mac by several years. Was it used by older DEC OSes?

    John

    Second-system effect ? :-)

    Simon.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to arne@vajhoej.dk on Tue Jan 2 13:39:03 2024
    On 2023-12-30, Arne Vajhj <arne@vajhoej.dk> wrote:
    So I took:
    * what everybody knows about RMS
    * relative file and direct access fixed length file examples
    I recently posted
    * the index-sequential file examples I have used numerous times before
    * some file read and file creation test code I did a few years ago
    and baked it into:

    https://www.vajhoej.dk/arne/articles/rms.html


    Some feedback:

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

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

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

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

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

    Simon.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Simon Clubley on Tue Jan 2 09:12:11 2024
    On 1/2/2024 8:39 AM, Simon Clubley wrote:
    On 2023-12-30, Arne Vajhøj <arne@vajhoej.dk> wrote:
    So I took:
    * what everybody knows about RMS
    * relative file and direct access fixed length file examples
    I recently posted
    * the index-sequential file examples I have used numerous times before
    * some file read and file creation test code I did a few years ago
    and baked it into:

    https://www.vajhoej.dk/arne/articles/rms.html

    Some feedback:

    Thanks. Apperciated.

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

    DCL use record format VFC with carriage control PRN .

    Fortran default use record format VAR with carriage control FTN.

    I hope that is what I communicate:

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

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

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

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

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

    And I would need to mention Fortran segmented files.

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

    I want to but I can't.

    :-)

    I don't have the knowledge.

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

    I should probably mention EXEC mode

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

    Yes.

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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Lawrence D'Oliveiro on Tue Jan 2 13:41:09 2024
    On 2023-12-31, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

    And remember, it?s NTFS-specific. Windows lacks the equivalent of a fully general VFS layer, for some totally unfathomable reason.

    So does VMS. Unfortunately.

    Simon.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Tue Jan 2 17:45:58 2024
    In article <umvmsf$2cq5r$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 4:57 PM, Lawrence D'Oliveiro wrote:
    On Mon, 1 Jan 2024 09:48:53 -0500, Arne Vajhøj wrote:
    On 12/31/2023 11:51 PM, Lawrence D'Oliveiro wrote:
    On Sun, 31 Dec 2023 22:35:34 -0500, Arne Vajhøj wrote:
    It stands for Linux, but that does not mean that they are trying to
    move the general Windows user to a Linux experience.

    That seems inevitable, though. At some point it is going to become a
    mandatory part of any Windows install. I’m not saying it was
    Microsoft’s conscious intention when they introduced it, but it will >>>> become the path of least resistance.

    But why on earth would they want to do that??

    Because Windows is becoming increasingly complex and expensive for
    Microsoft to maintain,

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

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

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

    Windows sale = 20 B$/year.

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

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

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

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

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

    I can't see that.

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

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

    The compatibility API solution would not reduce maintenance significant.

    From:

    COM + .NET
    Win32
    NT kernel

    to:

    COM + .NET
    Win32
    Linux kernel

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

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

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Tue Jan 2 17:41:20 2024
    In article <umvlnj$2cmas$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 3:15 PM, Dan Cross wrote:
    In article <umv3ll$2adef$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    On 1/1/2024 11:52 AM, Dan Cross wrote:
    [snip]
    ...right now.

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

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

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

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

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

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

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

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

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

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

    For desktop/laptop the vast majorities of users has no interest
    in Linux at all. Windows are facing serious challenges, but not
    from (traditional) Linux. Windows usage is dropping because
    people are switching to Android/iOS phones/tablets.

    People are switching from a GUI centric OS (Windows) to
    GUI only OS (Android & iOS) for casual use. Expecting them
    to use WSL command line utilities is a non-starter.

    This conflates two things: WSL as a path for moving to Linux
    as the kernel substrate for Microsoft's OS offerings, and using
    WSL as an end user.

    The latter is likely never going to happen outside of developer
    communities. The former could well happen; WSL gives MSFT a
    low-cost way to dip their toe into the waters and explore
    interoperability between the traditional Windows API and Linux.

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

    But WSL does not provide anything for that.

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

    ...and integration at the file level.

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

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

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

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

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

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

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

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

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

    I do not expect you to understand this.

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

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

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Andy Burns on Tue Jan 2 19:11:40 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Tue Jan 2 19:15:20 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Tue Jan 2 19:20:40 2024
    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>.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Lawrence D'Oliveiro on Tue Jan 2 19:25:02 2024
    Lawrence D'Oliveiro wrote:

    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,

    They've tipped the nomenclature on its head now "windows subsystem for
    linux" rather than "posix subsystem for windows"

    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.

    search for "ncommander posix"

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Craig A. Berry@21:1/5 to All on Tue Jan 2 13:40:33 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Simon Clubley on Tue Jan 2 19:31:05 2024
    On Tue, 2 Jan 2024 13:39:03 -0000 (UTC), Simon Clubley wrote:

    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.

    The symbols have to come from some file that is input to the linker
    (.OLB, .OBJ, .STB). All the system entry points (RMS and the kernel
    proper) reside at absolute locations; this used to be at 80000168 hex
    (note: system space), then later (in either VMS V3 or V4) that was moved
    to 7FFEDF68 (note: P1 space). Not sure why: to allow per-process
    interception of system calls? Of course the old location continued to be
    valid forever for existing services, but all new services added thereafter
    were only available at the new place.

    RMS was one of those things that was quite difficult to explain to new
    users. I was the micro support guy, whom people came to if they had
    trouble moving files between these newfangled PC things and the VAX
    machines. And of course VMS software would typically refuse to work
    properly with files unless they had the right record format attributes
    etc. And files transferred from other systems tended to end up as “fixed- length 512-byte records”, which was just about the least useful format imaginable. So fixing the RMS attributes was a very common need. Assuming
    the users could understand the right settings to use.

    Linus “Mr Linux” Torvalds did apparently use VMS for a while, and he hated it. The reason had to do with RMS.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Tue Jan 2 19:41:21 2024
    In article <un1n5c$2q36g$4@dont-email.me>,
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    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).

    With the caveat that I have no first-hand experience with the
    WSL implementation in the Windows kernel, the mechanism is
    likely to be fairly straight-forward. When the system goes to
    invoke an executable program, it examines the image file; for
    both PECOFF (e.g., Windows .EXE format) and Linux-styled ELF
    binaries, the image formats are pretty well defined and the
    kernel can easily distinguish between them. Depending on which
    it is attempting to run, it can select the appropriate loader
    and it can install a per-process system call handler. Traps
    into the OS for system calls will then consult the local system
    call table for that process and decide how to handle the call.

    The interesting bit is inside the kernel, where the different
    interfaces are handled using (presumably) a common set of
    functionality.

    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.

    This is a well-understood problem in the Linux space; gVisor
    suffers from a similar issue.

    The problem is not that Linux's behavior is well-documented, it
    is also what is not documented. It's not enough to be
    consistent with the documented interfaces, but one must also be "bug-compatible" with the system. Further, Linux has a
    long-standing policy of preserving userspace behaviors, even
    when doing so means that the implementation contradicts a
    documented interface in some way or another.

    Furthermore, the rate of change in Linux is high; following
    along from outside is fraught. And we haven't even gotten
    to things like:
    https://docs.kernel.org/process/stable-api-nonsense.html

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Tue Jan 2 19:44:09 2024
    In article <un1nm8$2q36g$6@dont-email.me>,
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    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>.

    That's a separate issue. That is more about underspecification
    of the documented programmer's interface, but I'm talking about
    the opacity of the kernel/user interface.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Andy Burns on Tue Jan 2 19:42:41 2024
    On Tue, 2 Jan 2024 19:25:02 +0000, 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>.

    I think I did more with MKS Toolkit and Cygwin than WSL.

    Interestingly, Cygwin seems to do a better job in some ways than Windows
    can manage natively, like get select(2)/poll(2) to work with pipes. Maybe
    that was the sort of thing that sank WSL1?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to bill.gunshannon@gmail.com on Tue Jan 2 19:42:29 2024
    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.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Tue Jan 2 19:47:15 2024
    In article <un1nc8$2q36g$5@dont-email.me>,
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    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

    Yeah, NatBro's comment here is a bit dated. WinDbg is actually
    amazing and trounces anything in the Linux/GNU world. The only
    thing comparable might be `mdb` in the Solaris/illumos world.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Lawrence D'Oliveiro on Tue Jan 2 19:57:22 2024
    Lawrence D'Oliveiro wrote:

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

    Yes, that's the "ncommander posix" search that I referred to

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to Lawrence D'Oliveiro on Tue Jan 2 19:44:49 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to usenet@andyburns.uk on Tue Jan 2 19:48:50 2024
    In article <kvj7djF8sf8U8@mid.individual.net>,
    Andy Burns <usenet@andyburns.uk> wrote:
    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?

    Not really. POSIX is sort of a least-common-denominator thing,
    and has become increasingly less relevant over time. z/OS is
    POSIX compliant, IIRC; make of that what you will. :-)

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to bill.gunshannon@gmail.com on Tue Jan 2 21:01:17 2024
    In article <kvjaabF2supU1@mid.individual.net>,
    bill <bill.gunshannon@gmail.com> wrote:
    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.

    Yeah. It's much easier to take source and get it to run
    somewhere else, though increasingly often I find Linux
    assumptions baked into a lot of code. But Linux is the big boy
    on the block, so they can get away with it.

    I similarly found the Linux binary compatibility stuff in BSD
    did a mediocre job. Similarly with other compability things
    over the years: I brought up Torek's port of 4.4BSD-Lite on a
    SPARCstation 1 by backporting some bits from -Encumbered, and
    while it _could_ run SunOS 4.x binaries, they dumped core
    disturbingly often.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Tue Jan 2 20:56:56 2024
    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. Indeed, this is _why_, if
    I were MSFT, I would be looking at how I could leverage the rest
    of the world's investment in Linux while minimizing my own cost
    for maintaining Windows.

    yet they cannot keep up with what the Linux developers have achieved.

    Don't sell Microsoft short: their kernel engineers are
    first-rate and incredibly sharp. But they only have so many,
    and regardless of how many they have, they have fewer than
    Linux.

    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. The reality is that _most_ Linux development is heavily
    subsidized by commercial interests these days; getting something
    non-trivial into the kernel requires lots of time and resources.
    In theory an individual could do it, but in practice that's
    pretty rare.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Tue Jan 2 20:36:24 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Tue Jan 2 21:18:28 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Dorsey@21:1/5 to ldo@nz.invalid on Tue Jan 2 22:05:31 2024
    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.
    --scott
    --
    "C'est un Nagra. C'est suisse, et tres, tres precis."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Scott Dorsey on Tue Jan 2 23:03:30 2024
    On 2 Jan 2024 22:05:31 -0000, Scott Dorsey 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, 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.

    You can think in terms of passive users of a project, versus active contributors to the project.

    In the open-source world, those passive users don’t matter so much: the
    ones that matter are the active contributors.

    The passive users also include the type who like to complain about things
    and bemoan the fact that the project doesn’t cater to their needs.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to Scott Dorsey on Tue Jan 2 23:21:23 2024
    In article <un21bb$7ea$1@panix2.panix.com>,
    Scott Dorsey <kludge@panix.com> 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, 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.

    I think there's a lot of churn. What's missing is a lot of
    principled engineering; Linux has evolved, and it's impressive
    what it has evolved into (honestly the world's most important
    operating system) but that doesn't necessarily mean that it is
    _good_ in all respects (it is objectively not).

    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. Honestly, I'm often surprised that it works
    as well as it does. Compare to Solaris, on the other hand, that
    has documented stable interfaces all over. Sure, there are some
    cases where they're not used (or used well...) but this means
    that binary modules compiled out-of-tree can work across
    multiple versions of the operating system, which is pretty cool.
    And neigh impossible for non-trivial things in the Linux world.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Tue Jan 2 23:16:45 2024
    In article <un1uj4$2raer$1@dont-email.me>,
    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 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.

    I don't believe I have. Perhaps you could tell me where you
    think I did?

    Don't sell Microsoft short: their kernel engineers are first-rate and
    incredibly sharp.

    Maybe not quite so sharp;

    I've worked closely with at least six engineers who worked on
    the Windows kernel. I can assure you that they are excellent,
    and based on what they told me, they were representative of
    most Windows kernel people.

    I recongize that's anecdotal, but I see no disconfirming
    evidence.

    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.

    I'm curious: have you ever actually had a serious technical
    conversation with someone who's worked on Windows? Did you ask
    them this question, and if so, what was their answer?

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

    When you write that about select/poll and pipes and that being
    an "irritating reason" for a more general issue, that seems
    specious. Different systems do things differently; sadly Python
    exposes that to the programmer. Oh well, but that's about par
    for the course.

    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.

    What about WireGuard? The implementation was funded.

    Anyway, anecdotal evidence, at best, I'm afraid. I'm using
    conversations with primary sources for my assertion (Ts'o et
    al).

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Tue Jan 2 23:30:53 2024
    On Tue, 2 Jan 2024 23:16:45 -0000 (UTC), Dan Cross wrote:

    In article <un1uj4$2raer$1@dont-email.me>,
    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
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Wed Jan 3 00:03:36 2024
    In article <un26bd$2sllq$2@dont-email.me>,
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    On Tue, 2 Jan 2024 23:16:45 -0000 (UTC), Dan Cross wrote:

    In article <un1uj4$2raer$1@dont-email.me>,
    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
    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.

    I don't believe I have. Perhaps you could tell me where you
    think I did?

    Where you used the word "fraught".

    I don't see it.

    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.

    On the other hand, you said,

    |Microsoft must have access to at least a couple
    |of orders of magnitude greater development resources than that
    |available to the Linux kernel project

    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.

    The two are unrelated.

    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.

    That seems like speculation on your part. Do you have any
    special expertise in this area?

    They surely moved to WSL2 because the best, cheapest way to be
    "bug compatible" with Linux is to just run Linux. That really
    doesn't say much about what the Windows kernel is, or is not,
    capable of. It might say something about their development
    priorities, though.

    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.

    Non sequitur. 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).

    Microsoft is even planning to offer Python access to Excel users (at least >cloud-based ones).

    Again, this is conflating "python" (which I understand runs on
    Windows just fine; I wouldn't know, as I don't do Windows) with
    pipes+select and python.

    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.

    This seems like pure speculation.

    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. It does mean that their kernel was designed with
    different goals than Linux (which is a Unix knock-off).

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Andy Burns on Tue Jan 2 19:18:01 2024
    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

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Craig A. Berry on Wed Jan 3 00:30:41 2024
    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.
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to All on Tue Jan 2 20:32:54 2024
    On 1/2/2024 9:12 AM, Arne Vajhøj wrote:
    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.

    Updated:
    * add Groovy examples
    * add examples using byte offset seek to mimic access by
    record number to fixed length records
    * add a lot about record size
    * add note about RMS being exec mode and lengths being little endian

    Still:

    https://www.vajhoej.dk/arne/articles/rms.html

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Wed Jan 3 02:56:25 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Dan Cross on Wed Jan 3 02:46:26 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Burns@21:1/5 to All on Wed Jan 3 09:03:17 2024
    Arne Vajhøj wrote:

    Note that Cygwin and WSL does completely different things.

    Sure, but they all fall into my "mixing windowsy things with unixy
    things" slot ... also I forgot all about Interix/SFU

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Lawrence D'Oliveiro on Wed Jan 3 08:54:23 2024
    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.
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to alex.buell@munted.eu on Wed Jan 3 13:29:59 2024
    In article <7b209da2cb6d3666421c56fefbd470ceba999f36.camel@munted.eu>,
    Single Stage to Orbit <alex.buell@munted.eu> wrote:
    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.

    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.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Wed Jan 3 13:31:44 2024
    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.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Wed Jan 3 13:35:40 2024
    In article <un2hq1$2vhkg$3@dont-email.me>,
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    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.

    You are conflating _internal_ interfaces and _external_
    interfaces. Linux has none of the former; it has strong
    backwards compatibility guarantees for the latter ("thou shalt
    not break userspace").

    The lack of internal interfaces mean that it's difficult to
    evolve kernel internals without significant churn. E.g.,
    filesystems are deeply entwined with the virtual memory
    subsystem, as is networking; everything speaks directly to
    the process code, etc.

    Linux is extraordinarily bloated.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Wed Jan 3 13:27:25 2024
    In article <un2icp$2vhkg$4@dont-email.me>,
    Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
    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.

    A) you are clearly speculating about the "resources" you think
    that Microsoft can apply to Windows. B) you have not
    acknowledged that, whatever resources MSFT can bring to bear,
    Linux can _bring more_.

    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?

    A amateurish attempt to change the subject, but regardless,
    that's a business, not a technical, decision at Microsoft. It
    could be that they see the writing on the wall and don't feel
    that it's a good investment.

    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?

    Your logical fallacy is assuming that because they _dont't_ do
    something that that implies that they _can't_ do that thing.
    There are many reasons that they may choose not to do something
    that are totally independent from their ability to do that
    thing.

    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?

    Strawman. We've already discussed why they decided to move to
    WSL2. Here, their inability to keep up with Linux is not about
    technical ability, it's about resources, which (again) they have
    fewer of than the rest of the world combined applies to Linux.

    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?

    Again, you are assuming that Microsoft has "more resources at
    its disposal" than Linux, but I see no evidence of that; in fact
    I see significant evidence to the contrary.

    Go ahead and browse the commit lots in the Linux kernel git
    repo: how many author addresses end with meta.com, amazon.com,
    google.com, ibm.com, intel.com, amd.com, redhat.com, nvidia.com,
    adobe.come, etc? Or, for that matter, microsoft.com? And we're
    not even talking about the smaller companies (altera, et al).

    Even for those that don't, how many of the remaining offers work
    for one of the FAANG companies? Do you really think that
    Microsoft has more resources _combined_ working on Windows than
    the rest of those companies are devoting to Linux?

    As for WINE, it's compatibilty is not great.

    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?

    Since the vast bulk of Python code out there probably doesn't
    try to mix pipes with select or poll, I'd imagine you just run
    it.

    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.

    "...in their experiments." Um, sure. Doug proposed it and Ken
    implemented it in a weekend. It was relevatory in the context
    of Unix, but not necessarily in other systems.

    But so what? We're talking about Python code here, which mostly
    insulates the programmer from something as low-level as POSIX.
    Again, it seems like the thing that the vast, vast majority of
    the tiny fraction of Python programmers who deal with such
    things are going to care about is asynchronous IO for networking
    and storage, not pipes. Honing in on that one aspect of
    incompatibility doesn't really go very far to prove a general
    point.

    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.

    Not really; see above.

    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.

    Maybe, but that's a different matter. I think the probability
    that you know someone who's worked on both Linux and Windows at
    the kernel level is approximately 0, as evidenced by your lack
    of understanding of the technical and business issues involved.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Dan Cross on Wed Jan 3 14:45:07 2024
    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/
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to alex.buell@munted.eu on Wed Jan 3 15:16:30 2024
    In article <58a152d7482131319b40481943ad2ff6ce71c166.camel@munted.eu>,
    Single Stage to Orbit <alex.buell@munted.eu> wrote:
    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/

    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.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hans Bachner@21:1/5 to All on Wed Jan 3 18:21:01 2024
    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...)

    Hans.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Andy Burns on Wed Jan 3 19:03:22 2024
    On Wed, 3 Jan 2024 09:03:17 +0000, Andy Burns wrote:

    ... also I forgot all about Interix/SFU

    Apparently Interix/SFU was the result of a temporary lapse on the part of Microsoft. In those days, it was possible to get documentation from them
    for how to write your own “personality” on top of the NT kernel, which Interix did.

    Then Microsoft decided it didn’t want this knowledge becoming publicly
    known. So they acquired Interix to stop it spreading further.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Single Stage to Orbit on Wed Jan 3 19:01:05 2024
    On Wed, 03 Jan 2024 08:54:23 +0000, Single Stage to Orbit wrote:

    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Hans Bachner on Wed Jan 3 16:10:37 2024
    On 1/3/2024 12:21 PM, Hans Bachner wrote:
    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...)

    Yes. I guess I was lazy and just noted those that I use.

    + and 0 still works fine.

    $ type z.txt
    AAA
    +B
    0CC
    $ set file/attr=rat=ftn z.txt
    $ type z.txt
    BAA

    CC

    I will update.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Wed Jan 3 21:59:04 2024
    On Wed, 3 Jan 2024 21:52 +0000 (GMT Standard Time), John Dallman wrote:

    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.

    There you have in a nutshell, this conflation between the core OS and the
    GUI that should be a separate layer on top of the OS. Remember, the whole “tiles” interface was developed as part of the emphasis on mobile, and
    then Windows 8 tried to retrofit it onto the desktop, which people hated.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Wed Jan 3 21:52:00 2024
    In article <umv3ll$2adef$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    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.

    Me, I regarded Windows 2000 as the peak of their GUI design, and it's
    been getting worse, on average, ever since.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Lawrence D'Oliveiro on Thu Jan 4 09:30:20 2024
    On Wed, 2024-01-03 at 19:01 +0000, Lawrence D'Oliveiro 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.
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Single Stage to Orbit@21:1/5 to Dan Cross on Thu Jan 4 09:29:02 2024
    On Wed, 2024-01-03 at 15:16 +0000, Dan Cross wrote:

    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.

    You've tickled my curiousity now. When I've time I'll spin up a couple
    Windows VMs, one with WSL1, and one with WSL2, and do some benchmarks.
    See who's right.
    --
    Tactical Nuclear Kittens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to Lawrence D'Oliveiro on Thu Jan 4 13:40:46 2024
    On 2024-01-03, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

    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.

    Yes. I have the Alpine Linux userland running just fine on my Android
    phone for some basic stuff (with the help of PRoot). Unfortunately,
    I have to use vi on my phone because emacs requires a proper keyboard... :-)

    Simon.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Single Stage to Orbit on Thu Jan 4 19:28:27 2024
    On Thu, 04 Jan 2024 09:30:20 +0000, Single Stage to Orbit wrote:

    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.

    And yet you’d think those beancounters would notice the very opportunity
    to save money mentioned above, and stop having to “devote substantial engineering resources to release updates for every kernel release”.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Thu Jan 4 15:51:42 2024
    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.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Thu Jan 4 15:58:10 2024
    On 1/3/2024 4:52 PM, John Dallman wrote:
    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.

    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.

    (they hated the Windows 8 attempt to look like WP8 though)

    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.

    That problem still exist for anyone trying to get into the
    phone market without being hooked into Apple App Store or
    Google Play.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Scott Dorsey on Thu Jan 4 16:04:02 2024
    On 1/2/2024 5:05 PM, Scott Dorsey 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, 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.

    I am also skeptical about that.

    But so far the industry does not consider it a problem.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Thu Jan 4 16:00:40 2024
    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.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Thu Jan 4 22:25:47 2024
    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.

    Microsoft was too focused on emulating the locked-down Apple model.
    Windows Phone devices were more defined by what they *couldn’t* do, rather than what they *could*. That’s why they failed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Thu Jan 4 20:13:49 2024
    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?

    Interesting.

    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.

    There seemed to be accept in the market that 2 apps are OK but
    3 are too much.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Fri Jan 5 00:34:07 2024
    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:
    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.

    Nope.

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

    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.

    These two statements are contradictory. Colloquially, we call
    ELF binaries that are specific to a given ABI "branded" for that
    ABI. From e.g. the FreeBSD manual:

    ---
    BRANDELF(1) FreeBSD General Commands Manual BRANDELF(1)

    NAME
    brandelf --- mark an ELF binary for a specific ABI

    SYNOPSIS
    brandelf [-lv] [-f ELF_ABI_number] [-t string] file ...

    DESCRIPTION
    The brandelf utility marks an ELF binary to be run under a certain ABI
    for FreeBSD.
    ---

    (So, for example, `brandelf -t Linux file`.)

    So a, "Linux-branded ELF binary" is an "ELF binary" and a "Linux
    binary." People who are familiar with systems programming
    understand this terminology readily, but if you have no
    experience at this low of a level, it doesn't surprise me that
    you would be confused.

    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,
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Thu Jan 4 20:37:43 2024
    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.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Fri Jan 5 01:27:39 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Thu Jan 4 20:44:59 2024
    On 1/4/2024 8:27 PM, Lawrence D'Oliveiro 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.

    Did you read what I wrote?

    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.

    There may have been such a feeling.

    But the numbers show that it took very little time for Android to get
    get apps.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to ldo@nz.invalid on Fri Jan 5 01:50:43 2024
    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.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Fri Jan 5 01:46:20 2024
    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.

    Do you even know what developers working on Linux do? Have you
    ever used Unix or Linux professionally?

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Thu Jan 4 20:58:59 2024
    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.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to arne@vajhoej.dk on Fri Jan 5 02:11:18 2024
    In article <un7np4$3rs6u$1@dont-email.me>,
    Arne Vajhøj <arne@vajhoej.dk> wrote:
    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.

    It requires the Cygwin DLL; a part of Cygwin.

    WSL is used to create standard Linux executables that
    require WSL or another Linux to run.

    No, WSL is used to _run_ standard Linux executables. How you
    create them is independent of that. Of course, you _can_ create
    them using WSL, of you can create them by some other means; WSL
    doesn't care.

    This is the distinction you seem stubbornly unable to grasp.

    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.

    So?

    My list of differences had it.

    Your list of differences did not have it.

    Because it's not relevant.

    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.

    Yes. That's what I meant when I said, "Is that environment
    intended for developers? Yes." Note that I said that in the
    next bit of text that you quoted, immediately below this.

    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.

    No. It is intended for developers to run Linux-branded ELF
    binaries under Windows. Again, full-stop. Is the primary
    objective of that to be able to perform development tasks? Yes,
    but that is independent of being able to, "run a standard Linux
    build toolchain to enable Linux builds on Windows." Do you even
    know what that means?

    It could be used to browse the web, read email and use
    word processors and spreadsheets.

    Correct.

    But MS has no interest in WSL being used for that.

    That may well be true; they're clearly interested in development
    tasks, but that includes a lot more than just "running a
    toolchain." For example, using revision control, running CI/CD
    runs, running automated integration test suites, deployment
    pipelines, running scripts that pre- or post-process output of
    some kind or another, using familiar text editors, etc. They
    may not even be using a compiled language at all.

    Again, do you have any idea what developers who use Linux as a
    development platform regularly actually do with it? There's a
    lot more to it than typing "make" and letting GCC do its thing.

    Do you actually have any professional experience using Linux?

    And I don't think any WSL users use it for that.

    I think you probably don't know any WSL users, or what they do.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Dan Cross on Thu Jan 4 21:51:26 2024
    On 1/4/2024 8:50 PM, Dan Cross wrote:
    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.

    Definitely anecdotal.

    More anecdotes:

    https://www.windowscentral.com/phones/windows-phone/carrier-disinterest-led-to-windows-phone-downfall-says-former-lead-developer

    Brandon Watson, former head of the Windows Phone Developer Experience

    <quote>
    "We had a lot of the major apps, but if you're missing that one core app
    that a salesperson used in the top 50, that ripple effect from that one salesperson was a really rough go. The combinatorial math got out of
    control when you consider the number of salespeople and the likelihood
    of one of their required top 50 apps not being on the Windows Phone
    platform."
    </quote>

    https://www.latimes.com/business/technology/la-fi-tn-nokia-frustrated-lack-of-apps-windows-phone-20130729-story.html

    Bryan Biniak, Nokia VP

    <quote>
    “We are releasing new devices frequently and for every new device, if
    there is an app that somebody cares about that’s not there, that’s a
    missed opportunity of a sale,”
    ...
    “It’s not just about the hardware, it’s about the tools that are on the hardware,” he said. “You can’t sell a phone without the apps, you just can’t.”
    </quote>

    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>

    There were undoubtedly more than one reason behind WP failure,
    but the above should show that people that were close to WP
    did consider lack of app at least "a" reason for WP failure.

    (they also list various other problems)

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Fri Jan 5 03:05:50 2024
    On Thu, 4 Jan 2024 21:51:26 -0500, Arne Vajhøj wrote:

    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>

    Note this part:

    Finally, by 2014, mobile users had already aligned themselves with
    either iOS or Android.

    So we’re not talking about the beginnings of Windows Phone, but after
    it had already been on the market for some years, and failed to pick
    up a customer base by then. Android was able to start from an equal
    market position (or lack of it), and grow to success because of its attractiveness to customers right out of the starting gate, where
    Microsoft was not.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to D'Oliveiro on Fri Jan 5 09:08:00 2024
    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.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to arne@vajhoej.dk on Fri Jan 5 13:33:52 2024
    On 2024-01-04, Arne Vajhj <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.

    Simon.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Fri Jan 5 08:52:54 2024
    On 1/5/2024 4:08 AM, John Dallman wrote:
    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.

    That is pretty well known.

    iPhone are more expensive than average Android phone (Samsung sell
    expensive models, but there are sold a lot of cheap phones as well).
    iPhone users at average have significant larger income than
    Android users. iPhone users spend more money on apps than
    Android users.

    A random source:

    https://explodingtopics.com/blog/iphone-android-users

    <quote>
    Mobile apps are projected to generate $542 billion in global revenue in
    2023. By 2027, that number could reach $732 billion.

    Consumers spent $85.1 billion in the App Store in 2021, while
    Google Play’s apps generated $47.9 billion. The App Store is clearly the winner in revenue, which seems counterintuitive when you consider that
    both devices have a similar spread of free vs. paid apps.
    iPhone’s apps are 95% free and 5% paid. Android’s apps are 97% free and 3% paid. That suggests that iPhone users may be more willing to
    spend money on apps than Android users.
    On average, iPhone user spends $12.77 per app. By comparison, the
    average Android user spends $6.19 on each app. For in-app purchases, the average transaction on iPhones is $1.07, while the average transaction
    on Android is $0.43.
    </quote>

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Clubley@21:1/5 to arne@vajhoej.dk on Fri Jan 5 13:42:58 2024
    On 2024-01-04, Arne Vajhj <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.

    Simon.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Simon Clubley on Fri Jan 5 08:59:53 2024
    On 1/5/2024 8:33 AM, Simon Clubley wrote:
    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.

    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.

    I don't see Sailfish or any other OS succeed at large
    scale. In the west.

    If the government in China decide that Chinese people
    has to use a Chinese OS on their phone, then such
    could succeed in China and be sold in hundreds of millions
    of copies. But that would be non-technical and non-market
    driven.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Cross@21:1/5 to clubley@remove_me.eisner.decus.org- on Fri Jan 5 14:02:46 2024
    In article <un9111$5lv4$3@dont-email.me>,
    Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
    On 2024-01-04, Arne Vajhj <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'll confess, I never cared for the Windows GUI. It was (and
    is) too "busy" for my tastes, starting from the early days and
    continuing to the present.

    For years and years, twm with X11 was my preferred environment,
    then Plan 9. DECwindows was kind of cool, as a port of Motif to
    VMS, but I rarely used it.

    I vividly remember Dennis Ritchie demonstrating Plan 9 to me in
    his office at Bell Labs one day. A comment he made has always
    stuck with me; it was something along the lines of text being a
    body one could manipulate, distinct from the small glyphs that
    were, in contrast, static and immutable, but that permeated most
    user interfaces at the time. THAT was a relevation.

    Sadly, the world moved on. Now we have the web. Oh well.

    - Dan C.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Fri Jan 5 15:27:00 2024
    In article <un7652$3pjg7$3@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    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.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to John Dallman on Fri Jan 5 13:13:05 2024
    On 1/5/2024 10:27 AM, John Dallman wrote:
    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.

    True.

    But there are still around a billion people with Windows experience.

    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.

    Sound to me like someone at MS really didn't understand the phone
    app market.

    Most of the critical apps does not even come from ISV's. They
    come from companies offering non-software services that can
    be delivered via app. Google search, bank, weather service,
    grocery shop, Facebook etc..

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Dallman@21:1/5 to All on Fri Jan 5 18:58:00 2024
    In article <un9grg$80t4$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhj)
    wrote:

    But there are still around a billion people with Windows experience.

    There are. But Microsoft and Nokia didn't do at all a good job of selling
    them phones.

    Sound to me like someone at MS really didn't understand the phone
    app market.

    In fairness, it was a less developed in 2012 when they released WP8.
    However, they stayed with their strategy far too long when it wasn't
    working.

    John

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Fri Jan 5 23:25:25 2024
    On Fri, 5 Jan 2024 15:27 +0000 (GMT Standard Time), John Dallman wrote:

    Microsoft tried to apply pressure to ISVs that had significant Windows products to put them onto Windows Phone.

    They also I think paid money to makers of Android phones (like HTC) to
    bring out Windows Phone versions of their products. This only highlighted
    the disparity between the inflexibility of their platform, versus the versatility of Android.

    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.

    There was an interesting ARM chip (from NVidia? Qualcomm?), used in some tablets, that had 5 cores: 4 full-power ones, one low-power one. The
    latter only engaged when the load on the machine was low, when the full-
    power cores would shut down.

    Linux could handle this dynamic reconfiguration of cores without a reboot;
    the NT kernel could not.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to John Dallman on Fri Jan 5 23:28:08 2024
    On Fri, 5 Jan 2024 18:58 +0000 (GMT Standard Time), John Dallman wrote:

    But Microsoft and Nokia didn't do at all a good job of
    selling them phones.

    Windows Phone was just an inferior product.

    When Elop took over at Nokia, work was already well under way on the N9,
    which ran some kind of Debian derivative. He couldn’t kill off the
    project, but he could ensure there was no followup, and that the release
    would be very limited.

    As I recall, when it came out, there were rave reviews everywhere it sold.
    And then when stocks ran out, that was the end of it: the potential for a successful range of products that could have saved Nokia, killed off by
    its blind allegiance to Microsoft.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Fri Jan 5 23:21:07 2024
    On Fri, 5 Jan 2024 08:59:53 -0500, Arne Vajhøj wrote:

    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.

    They probably managed more sales than those “niche” OSes, yet that still counts as “failure”.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Fri Jan 5 19:43:49 2024
    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. Probably
    never tested above 8 though due to CPU's available.

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to All on Sat Jan 6 01:26:57 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Arne_Vajh=C3=B8j?=@21:1/5 to Lawrence D'Oliveiro on Fri Jan 5 20:46:38 2024
    On 1/5/2024 8:26 PM, Lawrence D'Oliveiro wrote:
    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.

    I don't know where you get all those weird ideas from.

    Everybody know that WP7 was CE based.

    One of many sources:

    https://www.engadget.com/2010-03-18-windows-phone-7-series-the-complete-guide.html

    <quote>
    Windows Phone 7 is the successor to Microsoft's line of Windows Mobile
    phone operating systems. It's based on the Windows CE 6 kernel, like the
    Zune HD, while current versions of Windows Mobile are based on Windows
    CE 5.
    </quote>

    There has been some debate whether WP7 was actually using a pre-release
    of Windows CE 7.0 instead of Windows CE 6.0. But no doubt about the CE
    part.

    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.

    Not supporting 1 core may be true.

    But MS publicly stated the support for up to 64 cores.

    One of many sources:

    <quote>
    Microsoft is on stage at the Windows Phone Developer Summit offering us
    a bite of what's to come in Windows Phone 8, and one of the tastiest
    morsels may just be the noticeably more diverse hardware it will
    support. The new platform won't just support dual-core processors -- it
    will support as many as 64 cores, should such massively parallel chips
    come to exist in the platform's lifetime.
    </quote>

    Arne

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)