From Newsgroup: comp.arch

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

Fairly useful... Any thoughts?

Please try to stay on-topic. Your links to windows APIs
do not seem topical for comp.arch.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 2:20 PM, Scott Lurndal wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

Fairly useful... Any thoughts?

Please try to stay on-topic. Your links to windows APIs
do not seem topical for comp.arch.

Doh. I thought it might be interesting wrt how one can map their systems
to the user to help them make efficient programs?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 5 Jul 2026 14:42:33 -0700, Chris M. Thomasson wrote:

Doh. I thought it might be interesting wrt how one can map their
systems to the user to help them make efficient programs?

Most of the developers who still have Windows systems on their desks
seem to be using them just as a stepping-stone to developing for Linux.

Haven’t you heard about what’s new in WSL 3? Linux-style Coreutils for Windows?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 2:54 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 14:42:33 -0700, Chris M. Thomasson wrote:

Doh. I thought it might be interesting wrt how one can map their
systems to the user to help them make efficient programs?

Most of the developers who still have Windows systems on their desks
seem to be using them just as a stepping-stone to developing for Linux.

Haven’t you heard about what’s new in WSL 3? Linux-style Coreutils for Windows?

I forgot the NUMA mapping functions for Linux. Humm...

https://www.man7.org/linux/man-pages/man5/numa_maps.5.html

?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

The whole aspect is devoid of virtualization considerations. Typical MS.

Consider a HyperVisor system where a Windows OS begins running afresh--
and is allocated 64-GB of virtual-virtual main memory, 64-virtual devices,
and 64-virtual-processors.

Only HV knows whether the vV main memory is all on one node or scattered
across the "system", how many physical-processors are present, and aspects
of the I/O system not revealed to Guest OSs. Over time, HV may grant fewer
than 16-physical processors to that Guest OS, change where its "resident" memory is located, and the paths from virtual-processor to virtual-device.

Applications running under an HV should probably not use Windows tuning features on a virtual-machine supporting system, and when they are used-- expect confusion .
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 5 Jul 2026 15:08:01 -0700, Chris M. Thomasson wrote:

I forgot the NUMA mapping functions for Linux. Humm...

https://www.man7.org/linux/man-pages/man5/numa_maps.5.html

More up-to-date: <https://manpages.debian.org/numa(7)>.

Checking my standard Debian kernel:

ldo@theon:~> grep -iF numa /boot/config-$(uname -r)
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_ACPI_NUMA=y
CONFIG_NUMA_KEEP_MEMINFO=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
CONFIG_NUMA_MEMBLKS=y
CONFIG_NUMA_EMU=y
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 4:54 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 14:42:33 -0700, Chris M. Thomasson wrote:

Doh. I thought it might be interesting wrt how one can map their
systems to the user to help them make efficient programs?

Most of the developers who still have Windows systems on their desks
seem to be using them just as a stepping-stone to developing for Linux.

Haven’t you heard about what’s new in WSL 3? Linux-style Coreutils for Windows?

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools added
to the path, like "GNU Make and similar").

The typical secondary setup is via a Linux style environment, like WSL.

Though generally WSL1, as Windows had at some point decided that the virtualization my computer provides isn't sufficient to actually run
anything under virtualization; so WSL1 works but WSL2 does not.

I generally avoid using anything from the Win32 API without a good
reason; and some amount of my programs (that do anything graphics) also
have backends for SDL2 or similar (generally preferable to bare X11 IMO).


Though, apart from inertia, I am admittedly pretty close to the "just
jump over to Linux or similar" point (or, at least, would rather go to
Linux than to Windows 11...). The end-of-support for Windows 10 hasn't
been a significant issue as of yet (at least any more than the end of
Windows 7 had been initially). Usually takes a few years before
"annoyance issues" start creeping in.

Though this could be buffered some by mostly doing programming stuff and building a lot of stuff myself, so the effects of decaying support from
3rd party software or similar is buffered to some extent.

...


In some ways I can appreciate some of the the engineering in both OS
families, as both have good points and weak areas.

But, in terms of where modern Windows is going in terms of UI or what MS
is doing, not so much a fan.

Like, they managed to reach "peak UI" somewhere around Win2K and then
have spent the next 25 years mostly trying to find ways to screw it up
(then backing off, but some of the damage sticks each time).


Though, not everything is "entirely" bad, like Win11 apparently did go
and add tabs to Explorer and the Command windows, which is arguably at
least a minor good point among the piles of crap, not enough to offset
the other issues though.

But, would rather have had something where they stayed with a core UI
that stuck with a mostly Win2K like style and then incrementally
improved corners for usability, and not just wildly changing stuff for
no good reason and adding random gimmicks (or the mistaken perennial misfeature that keeps reappearing over the past 20 years of them
thinking that people actually want "frosted glass" translucent windows...).

...


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sun, 5 Jul 2026 21:40:07 -0500, BGB wrote:

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools
added to the path, like "GNU Make and similar").

The Windows command-line is fundamentally broken. It basically copies
the architecture from CP/M -- in other words, a hangover from the
8-bit era, even though Windows/MS-DOs was never supposed to be an
8-bit system!

Though generally WSL1, as Windows had at some point decided that the virtualization my computer provides isn't sufficient to actually run
anything under virtualization; so WSL1 works but WSL2 does not.

WSL3 is out now. Among other things, it improves the file-access
performance of the Linux kernel by basically putting less Windows code
in its way.

But, in terms of where modern Windows is going in terms of UI or
what MS is doing, not so much a fan.

Like, they managed to reach "peak UI" somewhere around Win2K and
then have spent the next 25 years mostly trying to find ways to
screw it up (then backing off, but some of the damage sticks each
time).

Windows NT dates from that time in the 1990s and earlier when it was
thought to be a good idea to build the GUI as an inseparable part of
the OS kernel. Even Apple fell victim to this.

While the Unix-type systems, like Linux and the BSDs, kept the GUI as
a modular, replaceable part even to today. Which is they they are so
much more flexible GUI-wise, as well as in all the other ways.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 7:40 PM, BGB wrote:

On 7/5/2026 4:54 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 14:42:33 -0700, Chris M. Thomasson wrote:

Doh. I thought it might be interesting wrt how one can map their
systems to the user to help them make efficient programs?

Most of the developers who still have Windows systems on their desks
seem to be using them just as a stepping-stone to developing for Linux.

Haven’t you heard about what’s new in WSL 3? Linux-style Coreutils for >> Windows?

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows development (though typically with some amount of GNU style tools added
to the path, like "GNU Make and similar").

The typical secondary setup is via a Linux style environment, like WSL.

Though generally WSL1, as Windows had at some point decided that the virtualization my computer provides isn't sufficient to actually run anything under virtualization; so WSL1 works but WSL2 does not.

I generally avoid using anything from the Win32 API without a good
reason; and some amount of my programs (that do anything graphics) also
have backends for SDL2 or similar (generally preferable to bare X11 IMO).

Though, apart from inertia, I am admittedly pretty close to the "just
jump over to Linux or similar" point (or, at least, would rather go to
Linux than to Windows 11...). The end-of-support for Windows 10 hasn't
been a significant issue as of yet (at least any more than the end of Windows 7 had been initially). Usually takes a few years before
"annoyance issues" start creeping in.

Though this could be buffered some by mostly doing programming stuff and building a lot of stuff myself, so the effects of decaying support from
3rd party software or similar is buffered to some extent.

...

In some ways I can appreciate some of the the engineering in both OS families, as both have good points and weak areas.

But, in terms of where modern Windows is going in terms of UI or what MS
is doing, not so much a fan.

Like, they managed to reach "peak UI" somewhere around Win2K and then
have spent the next 25 years mostly trying to find ways to screw it up
(then backing off, but some of the damage sticks each time).

Though, not everything is "entirely" bad, like Win11 apparently did go
and add tabs to Explorer and the Command windows, which is arguably at
least a minor good point among the piles of crap, not enough to offset
the other issues though.

But, would rather have had something where they stayed with a core UI
that stuck with a mostly Win2K like style and then incrementally
improved corners for usability, and not just wildly changing stuff for
no good reason and adding random gimmicks (or the mistaken perennial misfeature that keeps reappearing over the past 20 years of them
thinking that people actually want "frosted glass" translucent windows...).

...

dx12 is fairly nice and low level. But, I think Vulkan might even lower
level.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups >>

The whole aspect is devoid of virtualization considerations. Typical MS.

Well, say we want a map of the system, the arch. Not a virtual emulation
but the real metal?

Consider a HyperVisor system where a Windows OS begins running afresh--
and is allocated 64-GB of virtual-virtual main memory, 64-virtual devices, and 64-virtual-processors.

Only HV knows whether the vV main memory is all on one node or scattered across the "system", how many physical-processors are present, and aspects
of the I/O system not revealed to Guest OSs. Over time, HV may grant fewer than 16-physical processors to that Guest OS, change where its "resident" memory is located, and the paths from virtual-processor to virtual-device.

Applications running under an HV should probably not use Windows tuning features on a virtual-machine supporting system, and when they are used-- expect confusion .

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 11:14 PM, Chris M. Thomasson wrote:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-
groups

The whole aspect is devoid of virtualization considerations. Typical MS.

Well, say we want a map of the system, the arch. Not a virtual emulation
but the real metal?

CPUID?

Consider a HyperVisor system where a Windows OS begins running afresh--
and is allocated 64-GB of virtual-virtual main memory, 64-virtual
devices,
and 64-virtual-processors.

Only HV knows whether the vV main memory is all on one node or scattered
across the "system", how many physical-processors are present, and
aspects
of the I/O system not revealed to Guest OSs. Over time, HV may grant
fewer
than 16-physical processors to that Guest OS, change where its "resident"
memory is located, and the paths from virtual-processor to virtual-
device.

Applications running under an HV should probably not use Windows tuning
features on a virtual-machine supporting system, and when they are used--
expect confusion .

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups >>

The whole aspect is devoid of virtualization considerations. Typical MS.

While you are right on the facts, consider it from Microsoft's
viewpoint. AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to. I suspect offering virtualization would reduce the number of Windows licenses sold, thus
reducing their revenue. They would much rather you buy another PC and a
second Windows license.

Contrast their situation with others. IBM offers virtualization sort of
by accident, as part of a small, sideline project and was developed to
use CMS. The more general use came later. Also, the cost for a use to
buy a second CPU to run a different OS is very large compared to a
second PC, thus reducing the pressure on Microsoft to provide VM. And,
of course, for OSs like Linux, there is no revenue to be lost.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups >>>

The whole aspect is devoid of virtualization considerations. Typical MS.

While you are right on the facts, consider it from Microsoft's
viewpoint. AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to. I suspect offering >virtualization would reduce the number of Windows licenses sold, thus >reducing their revenue. They would much rather you buy another PC and a >second Windows license.

Doesn't microsoft offer virtualization (e.g. WSL) gratis?

Granted it's not general purpose virtualization like you
get with KVM on Linux or VMware, but that is available with
windows server (Hyper-V) I believe.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/6/2026 10:44 AM, Scott Lurndal wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support >>>>
https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

The whole aspect is devoid of virtualization considerations. Typical MS.

While you are right on the facts, consider it from Microsoft's
viewpoint. AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to. I suspect offering
virtualization would reduce the number of Windows licenses sold, thus
reducing their revenue. They would much rather you buy another PC and a
second Windows license.

Doesn't microsoft offer virtualization (e.g. WSL) gratis?

Yes, but I think that only allows you to run Linux under virtualization,
not Windows itself. Thus it doesn't cost Microsoft any license revenue.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 06 Jul 2026 17:44:37 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support >>>
https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

The whole aspect is devoid of virtualization considerations.
Typical MS.

While you are right on the facts, consider it from Microsoft's
viewpoint. AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to. I suspect offering >virtualization would reduce the number of Windows licenses sold,
thus reducing their revenue. They would much rather you buy another
PC and a second Windows license.

Doesn't microsoft offer virtualization (e.g. WSL) gratis?

Granted it's not general purpose virtualization like you
get with KVM on Linux or VMware, but that is available with
windows server (Hyper-V) I believe.

Hyper-V is available for free on non-server Pro (and enterprise)
variants of "client" Windows since Win8, i.e. ages ago.
Before Win8 there was Virtual PC - also free and also sort of
general-purpose.
And of course even before that plenty of people were using Sun's
Virtual Box that was also free.
Not me. I don't like virtualization.






--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support

https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

The whole aspect is devoid of virtualization considerations. Typical MS.

Well, say we want a map of the system, the arch. Not a virtual emulation
but the real metal?

Consider running 18 copies of that very same application !?!

Consider a HyperVisor system where a Windows OS begins running afresh--
and is allocated 64-GB of virtual-virtual main memory, 64-virtual devices, and 64-virtual-processors.

Only HV knows whether the vV main memory is all on one node or scattered across the "system", how many physical-processors are present, and aspects of the I/O system not revealed to Guest OSs. Over time, HV may grant fewer than 16-physical processors to that Guest OS, change where its "resident" memory is located, and the paths from virtual-processor to virtual-device.

Applications running under an HV should probably not use Windows tuning features on a virtual-machine supporting system, and when they are used-- expect confusion .

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

On 7/5/2026 11:14 PM, Chris M. Thomasson wrote:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support >>>
https://learn.microsoft.com/en-us/windows/win32/procthread/processor- >>> groups

The whole aspect is devoid of virtualization considerations. Typical MS.

Well, say we want a map of the system, the arch. Not a virtual emulation but the real metal?

CPUID?

GuestOS gets vCPUID
HostOS gets pCPUID

In any event, My 66000 has, in configuration space, the core-header that contains all of what a physical core has; exactly like a PCIe device has. There is no CPUID instruction.

Consider a HyperVisor system where a Windows OS begins running afresh--
and is allocated 64-GB of virtual-virtual main memory, 64-virtual
devices,
and 64-virtual-processors.

Only HV knows whether the vV main memory is all on one node or scattered >> across the "system", how many physical-processors are present, and
aspects
of the I/O system not revealed to Guest OSs. Over time, HV may grant
fewer
than 16-physical processors to that Guest OS, change where its "resident" >> memory is located, and the paths from virtual-processor to virtual-
device.

Applications running under an HV should probably not use Windows tuning
features on a virtual-machine supporting system, and when they are used-- >> expect confusion .

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 9:59 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 21:40:07 -0500, BGB wrote:

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools
added to the path, like "GNU Make and similar").

The Windows command-line is fundamentally broken. It basically copies
the architecture from CP/M -- in other words, a hangover from the
8-bit era, even though Windows/MS-DOs was never supposed to be an
8-bit system!

Powershell is kind of okay.

Though generally WSL1, as Windows had at some point decided that the
virtualization my computer provides isn't sufficient to actually run
anything under virtualization; so WSL1 works but WSL2 does not.

WSL3 is out now. Among other things, it improves the file-access
performance of the Linux kernel by basically putting less Windows code
in its way.

Cool. But still, it cannot compete with a raw Linux install? Well, I
never tried WSL in any version. I did use mingw and cygwin a lot in the
past, worked for what I needed it to. Actually, its funny. In the past,
20+ years ago. I had a stack of HD caddies each with a different os. So,
to switch an od, I shutdown... Plug the new caddie in, boot, bam! I had solaris! Or Linux, etc...

But, in terms of where modern Windows is going in terms of UI or
what MS is doing, not so much a fan.

;^)

Like, they managed to reach "peak UI" somewhere around Win2K and
then have spent the next 25 years mostly trying to find ways to
screw it up (then backing off, but some of the damage sticks each
time).

Windows NT dates from that time in the 1990s and earlier when it was
thought to be a good idea to build the GUI as an inseparable part of
the OS kernel. Even Apple fell victim to this.

I had to use WinNT 4.0 a lot back in the day. Sigh. Mainly for a
business app. Home/Pool inspections using visual basic, access, word 6,
etc. Fwiw, I don't like creating GUI's anyway. My proxy server code had
a gui but it was served as HTML. So, I can log into the server using a browser.

While the Unix-type systems, like Linux and the BSDs, kept the GUI as
a modular, replaceable part even to today. Which is they they are so
much more flexible GUI-wise, as well as in all the other ways.

Have you ever used imgui? I use it for a nice, quick way to get a gui in
some of my 3d engine work.

https://imgui.org/

It works well with raw dx12 and modern opengl.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 6 Jul 2026 12:01:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 7/5/2026 9:59 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 21:40:07 -0500, BGB wrote:

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools
added to the path, like "GNU Make and similar").

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Powershell is kind of okay.

When scripting in Powershell, I feel like programming rather than shell-scripting.
Which is not a compliment.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/5/2026 11:59 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 21:40:07 -0500, BGB wrote:

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools
added to the path, like "GNU Make and similar").

The Windows command-line is fundamentally broken. It basically copies
the architecture from CP/M -- in other words, a hangover from the
8-bit era, even though Windows/MS-DOs was never supposed to be an
8-bit system!

Well, it is not the same as Bash or similar, but it is not unusable
either, just different.

Basic command syntax and program execution remains similar either way,
apart from the different path name structure and different conventions
for designating command-line switches ('/opt' vs '-opt' or '--opt', ...).

More advanced functionality is different, but neither ".BAT" nor
shell-scripts are particularly "good" beyond trivial command execution,
just bad in different ways.

Though generally WSL1, as Windows had at some point decided that the
virtualization my computer provides isn't sufficient to actually run
anything under virtualization; so WSL1 works but WSL2 does not.

WSL3 is out now. Among other things, it improves the file-access
performance of the Linux kernel by basically putting less Windows code
in its way.

Doesn't matter as I don't run Windows 11 on my main PC.

Well, and MS views the CPU I am running as too old to support Win 11,
along with the lack of TPM, etc...


Basically, as-is, my PC can *only* run WSL1.

And, if I were to build a new PC, would probably jump to Linux, and
don't necessarily want to buy an OEM PC, more so as OEM PC's at this
point with any significant amount of RAM are very expensive.

...

But, in terms of where modern Windows is going in terms of UI or
what MS is doing, not so much a fan.

Like, they managed to reach "peak UI" somewhere around Win2K and
then have spent the next 25 years mostly trying to find ways to
screw it up (then backing off, but some of the damage sticks each
time).

Windows NT dates from that time in the 1990s and earlier when it was
thought to be a good idea to build the GUI as an inseparable part of
the OS kernel. Even Apple fell victim to this.

While the Unix-type systems, like Linux and the BSDs, kept the GUI as
a modular, replaceable part even to today. Which is they they are so
much more flexible GUI-wise, as well as in all the other ways.

FWIW:
In my case, TestKern has both graphics/GUI stuff and also the OpenGL
backend in the kernel, but a TODO would be to fold these into a loadable component.


Though, a partial issue is that the same COM-object interface is used
both for GUI and for more basic graphics/sound (when not running a GUI), meaning either this API needs to remain kernel space (with the loadable component more narrowly focused on Window management and maybe OpenGL).

Well, partly it is because this subsystem partly predates me getting DLL loading working (this was one of the TODO issues that initially delayed
my Quake3 port as well, along with generally working support for virtual memory).

So, both Quake 2 and 3 had basically required DLL (or shared-object)
loading along with something like "mmap()" or "VirtualAlloc()".



Had initially skipped over Quake 2 as merely being "in between" Quake 1
and 3.

But, looking more into it, Quake 2 has more promise:
Much more efficient geometry in the BSPs;
Geometry is clipped sensibly, and the PVS's are is tighter.
Big chunky polygons, not a bunch of long/narrow pieces;
PVS mostly only includes stuff that is actually visible.
Had a more lightweight renderer design:
More like a cleaned up Quake 1.


Was working some initially on adding a few more optimization cases to it:
A vertex lighting mode;
Falling back to using sprites for distant models.
The sprites are down-rendered from the alias models.
Used when the model would fall below a certain on-screen size.
Or, when alias models have already reached a triangle limit.
...

Will also need to try to optimize its memory use some.
As-is, it is using around 170MB, which is a bit too much.
And puts large arrays onto the stack.
While BGBCC can sort-of deal with this by folding them to the heap;
Doing so is not ideal.
...


I used a different approach for the sprites this time than I had used in
my GLQuake port:
It had generated orthogonal views of each frame and then would render overlapping quads representing every possible view (that would rotate
the same as the original model).

For the Quake2 version, decided to go with rendering a single billboard
sprite that will render one of a set of sub-angles depending on the
viewing angle. Though, for now it is doing it "Doom style", with 8
possible views (roughly an octagonal cylinder view).


The "best case" (for approximating full 3D with billboard sprites) would
be to render as essentially a dodecahedron, but the more likely option
would be to also render a top/bottom view, and then switch to rendering
it like in my GLQuake port if the player is looking at the entity from
outside a +/- 45 degree pitch angle.

While better for arbitrary 3D, a dodecahedron would be worse for typical Doom/Quake like scenarios, with 8 angles, or 10 with a top/bottom. The approach I used for GLQuake used 6 views (3 visible at a time), but all
6 would be contained in the prior 10 vies.

IIRC, Doom uses a trick that could reduce many models to 5 views (with
the remaining 3 being horizontal flips); could maybe either detect this
or employ a "close enough" heuristic. Doom had also typically eliminated alternate angles for things like dead enemies.

Then again, they had a stronger incentive because Doom sprites were
typically also bigger (~ 60 to 80 pixels tall).

Well, also as-is the generated sprites look pretty awful, for better
results would need to render at a higher resolution and then downsample,
but then would need to use a proper triangle rasterizer for them. Had
used a very poor-man's solution that only really works at low
resolutions: Plot the corner points, and then subdivide if the there
would be gaps between the points. If rendering at 128x128 or similar,
would likely need a proper edge-walking rasterizer.

Ironically, TKRA-GL uses a similar trick internally:
If the primitive is very small, but not enough to be discarded entirely,
it can be drawn as the corner points or similar.


An intermediate option being to go to rendering the sprites at 64x64,
and then trying for quality more on-par with Doom (would likely require rendering at 256x256 or similar and then downsampling). Though, alas,
doing so would still require adding the code footprint for something
like an at least semi-correct triangle rasterizer (while Quake2 already
had one, it is off in "ref_soft", and I need it in "ref_gl", and the
original version was written to draw to the screen buffer rather than an offline buffer, ...).

Well, or just use the existing "subdivide and draw points" strategy,
which becomes increasingly inefficient as resolution increases (despite
being the most efficient option when triangles are tiny).



This port also differs in that I am rendering the alias models to
sprites dynamically for now, rather than pre-rendering them to offline
atlases (in the GLQuake port, this mostly required an additional PAK
mostly full of DDS textures for all the converted textures and generated sprite sheets).

In this case, the sprites are being rendered as 32x32, so don't exactly represent high fidelity. More something that functions as a better
stand-in than the alias model simply disappearing (then you only draw
alias models that are sufficiently near to the camera, them sprites,
then skip rendering anything).

Like, if the model would only be a few pixels tall on screen, don't need
to draw anything.


Granted, still don't know if I would be able to get Quake 2 above
single-digit framerates...


...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/6/2026 1:33 PM, Michael S wrote:

On Mon, 06 Jul 2026 17:44:37 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-support >>>>>
https://learn.microsoft.com/en-us/windows/win32/procthread/processor-groups

The whole aspect is devoid of virtualization considerations.
Typical MS.

While you are right on the facts, consider it from Microsoft's
viewpoint. AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to. I suspect offering
virtualization would reduce the number of Windows licenses sold,
thus reducing their revenue. They would much rather you buy another
PC and a second Windows license.

Doesn't microsoft offer virtualization (e.g. WSL) gratis?

Granted it's not general purpose virtualization like you
get with KVM on Linux or VMware, but that is available with
windows server (Hyper-V) I believe.

Hyper-V is available for free on non-server Pro (and enterprise)
variants of "client" Windows since Win8, i.e. ages ago.
Before Win8 there was Virtual PC - also free and also sort of general-purpose.
And of course even before that plenty of people were using Sun's
Virtual Box that was also free.
Not me. I don't like virtualization.

They worked before, then the stopped, which is annoying...

This just leaves DOSBox and QEMU.
Though with QEMU there is the annoyance of no good way to share part of
the host's filesystem with the guest, which eliminates one of the main use-cases some of the others have, and why I had used them.

DOSBox at least sorta works here, but as noted is limited.
Runs DOS programs, can run Win 3.x stuff...




But, then again, could almost go and try to write a clone MS BitEdit.

While apparently there are modern pixel-art programs, most have a
similar downside (to Paint.NET):
While they do offer the ability to plot pixels and have a limited color palette... They still save and reload as true-color PNGs or similar.

Not as much option ATM for working natively with fixed-palette 16-color
or 256-color BMP or PCX images. Or, when 256-color BMP or similar is supported, it is almost invariably with an optimized palette rather than
a fixed user-supplied palette.

Granted, one can edit as a PNG and then use a converter tool to generate
a BMP with the desired palette, but, alas.

But, alas, maybe these use-cases are just too niche even for "pixel
art"... And, seemingly the only tools that really did a good job at this
were some obscure MS tools from the Win 3.x era...

And, my seeming inertia to never getting and writing proper clones.
But, could maybe write a graphics editor at some point, then maybe have
the secondary purpose that is could be a "PaintBrush" stand-in for TestKern.


Granted, if intended to be general, might need both indexed color and hicolor/truecolor modes, so, likely modes:
Monochrome: 1bpp, 2-color palette, default=black/white
4-color : 2bpp, 4-color palette, default=TBD
(4 grays, black/white/cyan/magenta, ...)
16-color : 4bpp, 16-color palette, default=CGA/EGA colors
The original CGA palette had an orange/brown, which was useful.
The VGA palette changed the values and removed orange, less good.
Not sure why convention made the basic 16-colors actively worse.
Or why nearly everyone else has defaulted to the less-good option
256 color : 8 bpp, default TBD, assume user specified.
32K color : 15 bpp hi-color (RGB555 is better IMO vs RGB565).
16M color : 24/32 bpp

Some tools, like airbrushing, only really make sense in hicolor or
truecolor modes. In indexed mode, primary tool would be pencil tool or similar.

Would need to decide on to whether to support layers. Layers don't map
to simple formats though, like BMP, and there isn't really any
standardized format for layered images.

Would probably support transparency though in any case:
1/2/4/8 bpp modes: Requires giving up one of the palette colors;
RGB555: Typically the MSB is a transparent bit;
Could also use my variant with a 3-bit alpha.
RGBA32: Typically uses a full 8-bit alpha channel.

For implementation simplicity, the 1/2/4 bpp modes would likely still
use 8-bpp in memory. The RGB555 mode could possibly also be represented
via true-color and then down-converted to RGB555.


Well, and also need to figure out how to best represent such a UI in a
320x200 screen/window size. Don't want to burn too much screen area with toolbars, but have noted that many people don't like shortcut-driven UIs.

Original PaintBrush and similar seemed to assume 640x480 as nominal, but
then ate a chunk of the screen for tool selector and palette. Would need
to be more economical for 320x200. Would likely need to keep the UI
stuff down to a 32x200 toolbar (maybe 8x8 or 16x16 for tool icons).


TBD...



Well, and ironically as well: PaintBrush/Paint:
Actually lost features as time went on...
Like, they tried to "simplify" the interface, only to lose sort of what
made the early versions "actually useful" (they added PNG and JPG
support, but most other "technical" features were removed).

...


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/6/2026 2:27 PM, Michael S wrote:

On Mon, 6 Jul 2026 12:01:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 7/5/2026 9:59 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 21:40:07 -0500, BGB wrote:

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools
added to the path, like "GNU Make and similar").

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Powershell is kind of okay.

When scripting in Powershell, I feel like programming rather than shell-scripting.
Which is not a compliment.

I never really got Powershell, so mostly stuck with the Windows CMD
shell except for the rare few things that actually needed Powershell
(like, for whatever reason, seemingly need to use it to create
case-sensitive directories or similar on Win10).


As for WSL, works well, but in my case still only WSL1 works.

I think there was a thing with WSL2 that Windows would provide its own
X11 server, vs with WSL1 where one needs to run an independent X11
server. Why the difference? Dunno...

If anything almost seems like it would have been easier to provide the
X11 server via WSL1, vs seemingly needing to run something inside the
Linux environment and somehow routing it out to the external Windows GDI
stuff or similar.

...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 6 Jul 2026 14:36:25 -0500, BGB wrote:

On 7/5/2026 11:59 PM, Lawrence D’Oliveiro wrote:

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Well, it is not the same as Bash or similar, but it is not unusable
either, just different.

Remember that, on Unix-type systems, the command line is an array of
strings. Whereas on Windows, as on CP/M, it is just a simple string
buffer. This means that, on Windows, you have to worry about
shell-escaping conventions for command arguments even if you are
spawning one program directly from another with no shell involved!
This is quite unnecessary on Unix-type systems.

Here are 3 different specifications of the convention for doing the shell-escaping: <https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments>
<https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw>
<https://learn.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-170>.

Are they exactly logically equivalent? What happens if they’re not?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 6 Jul 2026 15:43:55 -0500, BGB wrote:

Though with QEMU there is the annoyance of no good way to share part
of the host's filesystem with the guest ...

I see the -virtfs option <https://manpages.debian.org/qemu-system(1)>
is described thus:

Define a new virtual filesystem device and expose it to the guest
using a virtio-9p-device (a.k.a. 9pfs), which essentially means
that a certain directory on host is made directly accessible by
guest as a pass-through file system by using the 9P network
protocol for communication between host and guests, if desired
even accessible, shared by several guests simultaneously.

And that’s not the only one: see also -fsdev and -semihosting.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted:

On Mon, 6 Jul 2026 14:36:25 -0500, BGB wrote:

On 7/5/2026 11:59 PM, Lawrence D’Oliveiro wrote:

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Well, it is not the same as Bash or similar, but it is not unusable
either, just different.

Remember that, on Unix-type systems, the command line is an array of
strings.

A command line being a vector of strings goes back to at least TSS
(IBM 360/67 1971). PLUS TSS had the !! (no-you-fool) cooncept where
the command was passed back to the parent (shell) of whatever you
were currently in.

Whereas on Windows, as on CP/M, it is just a simple string
buffer. This means that, on Windows, you have to worry about
shell-escaping conventions for command arguments even if you are
spawning one program directly from another with no shell involved!
This is quite unnecessary on Unix-type systems.

Here are 3 different specifications of the convention for doing the shell-escaping: <https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments>
<https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw>
<https://learn.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-170>.

Are they exactly logically equivalent? What happens if they’re not?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/6/2026 1:43 PM, BGB wrote:

On 7/6/2026 1:33 PM, Michael S wrote:

On Mon, 06 Jul 2026 17:44:37 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

On 7/5/2026 4:38 PM, MitchAlsup wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> posted:

Fairly useful... Any thoughts?

https://learn.microsoft.com/en-us/windows/win32/procthread/numa-
support

https://learn.microsoft.com/en-us/windows/win32/procthread/
processor-groups

The whole aspect is devoid of virtualization considerations.
Typical MS.

While you are right on the facts, consider it from Microsoft's
viewpoint.  AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to.  I suspect offering
virtualization would reduce the number of Windows licenses sold,
thus reducing their revenue. They would much rather you buy another
PC and a second Windows license.

Doesn't microsoft offer virtualization (e.g. WSL) gratis?

Granted it's not general purpose virtualization like you
get with KVM on Linux or VMware, but that is available with
windows server (Hyper-V) I believe.

Hyper-V is available for free on non-server Pro (and enterprise)
variants of "client" Windows since Win8, i.e. ages ago.
Before Win8 there was Virtual PC - also free and also sort of
general-purpose.
And of course even before that plenty of people were using Sun's
Virtual Box that was also free.
Not me. I don't like virtualization.

They worked before, then the stopped, which is annoying...

This just leaves DOSBox and QEMU.
Though with QEMU there is the annoyance of no good way to share part of
the host's filesystem with the guest, which eliminates one of the main use-cases some of the others have, and why I had used them.

DOSBox at least sorta works here, but as noted is limited.
  Runs DOS programs, can run Win 3.x stuff...

Actually, iirc I had windows me and xp on Dosbox. They seemed to work fine.


[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 7/6/2026 12:27 PM, Michael S wrote:

On Mon, 6 Jul 2026 12:01:11 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

On 7/5/2026 9:59 PM, Lawrence D’Oliveiro wrote:

On Sun, 5 Jul 2026 21:40:07 -0500, BGB wrote:

Most native code I write can work under either; though had ended up
using the Windows command-line and MSVC mostly for native Windows
development (though typically with some amount of GNU style tools
added to the path, like "GNU Make and similar").

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Powershell is kind of okay.

When scripting in Powershell, I feel like programming rather than shell-scripting.
Which is not a compliment.

Yeah. I see that for sure.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 07 Jul 2026 17:51:49 GMT, MitchAlsup wrote:

On Mon, 6 Jul 2026 21:07:04 -0000 (UTC), Lawrence D’Oliveiro wrote:

Remember that, on Unix-type systems, the command line is an array
of strings.

A command line being a vector of strings goes back to at least TSS
(IBM 360/67 1971). PLUS TSS had the !! (no-you-fool) cooncept where
the command was passed back to the parent (shell) of whatever you
were currently in.

Bell Labs Unix 1st Edition dates from the same year, but development
on the earliest PDP-11 versions started in 1970 <https://www.nokia.com/bell-labs/about/dennis-m-ritchie/hist.html>.

What kind of command line did Multics have?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted:

On Tue, 07 Jul 2026 17:51:49 GMT, MitchAlsup wrote:

On Mon, 6 Jul 2026 21:07:04 -0000 (UTC), Lawrence D’Oliveiro wrote:

Remember that, on Unix-type systems, the command line is an array
of strings.

A command line being a vector of strings goes back to at least TSS
(IBM 360/67 1971). PLUS TSS had the !! (no-you-fool) cooncept where
the command was passed back to the parent (shell) of whatever you
were currently in.

Bell Labs Unix 1st Edition dates from the same year, but development
on the earliest PDP-11 versions started in 1970 <https://www.nokia.com/bell-labs/about/dennis-m-ritchie/hist.html>.

What kind of command line did Multics have?

I never used it, so, I don't know.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 07 Jul 2026 17:51:49 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted:

On Mon, 6 Jul 2026 14:36:25 -0500, BGB wrote:

On 7/5/2026 11:59 PM, Lawrence D’Oliveiro wrote:

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Well, it is not the same as Bash or similar, but it is not
unusable either, just different.

Remember that, on Unix-type systems, the command line is an array of strings.

A command line being a vector of strings goes back to at least TSS
(IBM 360/67 1971).

Wikipedia says that TSS/360 was *canceled* in 1971.
Released in 1967, although not early enough in 1967 to be available
when 360-67 arrived to University of Michigan in January.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 08 Jul 2026 17:49:30 GMT, MitchAlsup wrote:

On Wed, 8 Jul 2026 00:43:39 -0000 (UTC), Lawrence D’Oliveiro wrote:

What kind of command line did Multics have?

I never used it, so, I don't know.

I had a quick look at some docs at BitSavers. And it does indeed seem
like the idea of a more structured command line originated with
Multics, as with so many other ideas.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Michael S <already5chosen@yahoo.com> posted:

On Tue, 07 Jul 2026 17:51:49 GMT
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted:

On Mon, 6 Jul 2026 14:36:25 -0500, BGB wrote:

On 7/5/2026 11:59 PM, Lawrence D’Oliveiro wrote:

The Windows command-line is fundamentally broken. It basically
copies the architecture from CP/M -- in other words, a hangover
from the 8-bit era, even though Windows/MS-DOs was never supposed
to be an 8-bit system!

Well, it is not the same as Bash or similar, but it is not
unusable either, just different.

Remember that, on Unix-type systems, the command line is an array of strings.

A command line being a vector of strings goes back to at least TSS
(IBM 360/67 1971).

Wikipedia says that TSS/360 was *canceled* in 1971.

I arrived at CMU in Aug 1971. CMU ran its /67 until way after 77 when I
left (after graduating and working at the school). CMU did hire a student
who rewrote much of TSS (getting rid of functionality not configured on
out /67) and changed up time from 8-ish hours to months between unscheduled downtime.

Released in 1967, although not early enough in 1967 to be available
when 360-67 arrived to University of Michigan in January.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 07 Jul 2026 17:51:49 GMT, MitchAlsup wrote:

A command line being a vector of strings goes back to at least TSS
(IBM 360/67 1971).

Did TSS have the concept of one program being able to directly invoke
another without having to go through a shell or “command processor”?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

While you are right on the facts, consider it from Microsoft's
viewpoint. AFAICT, they have little incentive to offer any
virtualization of Windows, and incentive not to.

Unless they switch to a different licensing model where they can get
each virtual machine to pay for a distinct license (e.g. via one of
those dreaded license servers). Then they would love you to run
N virtual Windows instances on your PC. 🙂

More seriously, I think MS sees Windows as a legacy system which gives
them a good rent for now (and which they'll keep alive for as long as
they can) but which has no real future.


=== Stefan
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Wed, 08 Jul 2026 12:30:04 -0400, Stefan Monnier wrote:

More seriously, I think MS sees Windows as a legacy system which
gives them a good rent for now (and which they'll keep alive for as
long as they can) but which has no real future.

I’d go further. I don’t think the rent is as good right now as it once
was. You see the result of that in the declining quality of Windows
updates: as the return on investment declines, it becomes less
attractive to plough futher investment into it. And so you see corners
cut on QA, plus the introduction of other ways to try to squeeze more
revenue out of the product, like showing ads in the UI etc.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

I had a quick look at some docs at BitSavers. And it does indeed seem
like the idea of a more structured command line originated with
Multics, as with so many other ideas.

However, like a lot of features in Multics (and later Unix), this was
itself inherited from CTSS. The 1963 CTSS Programmer's Guide says:

| Whenever a user issues a command at his console, the command name
| and parameter segments are placed in order in a command parameter
| list, and the corresponding command program is located and started
| wherever indicated by the initial machine conditions of the program.
| The command program reads the parameter segments by issuing supervisor
| calls. [...]
| A useful property of the command mechanism is the ability of one
| command to call another command. The setting of the next command name
| and parameter list is done by the operating command program issuing
| appropriate supervisor calls.

There's a more detailed description in the 1965/1969 Programmer's Guide (section AG.8). By that point CTSS had a "chains of commands" mechanism
that let you run a sequence of programs with each chaining into the next
when it completed, without needing a supervising shell. The userspace
command for launching a chain is RUNCOM, which is where the Unix "rc"
name for scripts came from.

(If anyone wants to play with Multics or CTSS, SDF runs public-access
emulated systems for both at <https://sdf.org/?ssh>, and there's some
great getting-started material at <https://timereshared.com/>.)
--
Adam Sampson <ats@offog.org> <http://offog.org/>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Thu, 09 Jul 2026 02:42:19 +0100, Adam Sampson wrote:

Lawrence D’Oliveiro <ldo@nz.invalid> writes:

I had a quick look at some docs at BitSavers. And it does indeed
seem like the idea of a more structured command line originated
with Multics, as with so many other ideas.

However, like a lot of features in Multics (and later Unix), this
was itself inherited from CTSS.

...

There's a more detailed description in the 1965/1969 Programmer's
Guide (section AG.8). By that point CTSS had a "chains of commands"
mechanism that let you run a sequence of programs with each chaining
into the next when it completed, without needing a supervising
shell. The userspace command for launching a chain is RUNCOM, which
is where the Unix "rc" name for scripts came from.

I found the description of RUNCOM in section AH.10.01 of the December
1969 Programmer’s Guide. What it is, is a very basic kernel-resident shell-script interpreter. It can substitute values for placeholders in
the command lines. But the command lines are still simple strings.

Not what I was talking about at all.
--- Synchronet 3.22a-Linux NewsLink 1.2