From Newsgroup: comp.os.linux.advocacy

A candid admission from a Microsoft exec that the 30-over-year-old
rCLWin32rCY API still lies at the heart of Windows today <https://www.tomshardware.com/software/windows/microsoft-cto-confesses-that-30-year-old-code-from-the-mid-90s-still-forms-the-bedrock-of-windows-11-ancient-win32-api-still-the-backbone-but-cto-says-its-more-relevant-than-ever-in-2026>.

With 64-bit machines now commonplace and 32-bit ones practically
extinct (outside of some embedded uses), whatever happened to rCLWin64rCY?

Linux and *BSD systems base their APIs on POSIX, which was cleverly
designed right from the beginning not to have any assumptions about
being 32-bit versus 64-bit. The first 64-bit workstations were already beginning to appear back then (though they were still unheard of in
the Windows world), so the *nix standards folks had to confront the
future pretty much from the beginning, they couldnrCOt put it off for
another decade, as Microsoft did.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

A candid admission from a Microsoft exec that the 30-over-year-old rCLWin32rCY API still lies at the heart of Windows today <https://www.tomshardware.com/software/windows/microsoft-cto-confesses-that-30-year-old-code-from-the-mid-90s-still-forms-the-bedrock-of-windows-11-ancient-win32-api-still-the-backbone-but-cto-says-its-more-relevant-than-ever-in-2026>.

With 64-bit machines now commonplace and 32-bit ones practically
extinct (outside of some embedded uses), whatever happened to rCLWin64rCY?

The name simply stuck. There are too many software for Windows by then,
and you clearly don't want to make things harder to port with a vastly
changed API "for the 64-bit age". Given the conservativeness of
Microsoft on technical decisions back then (they even went for 32-bit
longs on 64-bit platforms at the C ABI level), they probably won't even consider the notion of just renaming the Win32 API to Win64.

Linux and *BSD systems base their APIs on POSIX, which was cleverly
designed right from the beginning not to have any assumptions about
being 32-bit versus 64-bit. The first 64-bit workstations were already beginning to appear back then (though they were still unheard of in
the Windows world), so the *nix standards folks had to confront the
future pretty much from the beginning, they couldnrCOt put it off for
another decade, as Microsoft did.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Tue, 12 May 2026 12:27:27 +0800, makendo wrote:

On Mon, 11 May 2026 01:18:44 -0000 (UTC), Lawrence DrCOOliveiro wrote:

With 64-bit machines now commonplace and 32-bit ones practically
extinct (outside of some embedded uses), whatever happened to
rCLWin64rCY?

The name simply stuck. There are too many software for Windows by
then, and you clearly don't want to make things harder to port with
a vastly changed API "for the 64-bit age". Given the
conservativeness of Microsoft on technical decisions back then (they
even went for 32-bit longs on 64-bit platforms at the C ABI level)
...

Which was a bloody stupid thing to do. Dave Cutler was supposed to be
creating a rCLNew TechnologyrCY OS, supposedly to be portable across
multiple architectures from that point on into the foreseeable future.
DidnrCOt he notice that 64-bit architectures were already making an
appearance in the Unix world? The POSIX folk were already taking this
into account in their standardized API spec, which was under way
*years* before NT development started; why was he not able to learn
the lesson from them?

ItrCOs more than just a name sticking. Consider the difference between
the SYSTEM32 and SYSTEM directories on a Windows install: guess which
one holds the 64-bit binaries on a 64-bit system?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Tue, 12 May 2026 12:27:27 +0800, makendo wrote:

The name simply stuck. There are too many software for Windows by then,
and you clearly don't want to make things harder to port with a vastly changed API "for the 64-bit age". Given the conservativeness of
Microsoft on technical decisions back then (they even went for 32-bit
longs on 64-bit platforms at the C ABI level), they probably won't even consider the notion of just renaming the Win32 API to Win64.

It takes imagination to create SysWow64 to hold the 32 bit binaries. I
think they finally corrected it or made it more apparent but odbcad32.exe existed in both the 64 and 32 bit folders. If you had a 32bit DB2
installation and used the 64 bit odbcad32.exe you'd get 64 bit drivers
that wouldn't work. Our support people were justifiably confuse. 'No, you
have to use the odbcad32.exe that is in the director that sounds like it should have the 64 bit programs. The 64 bit one are in system32.

If that's not fucked I don't know what is.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Tue, 12 May 2026 04:52:13 -0000 (UTC), Lawrence DrCOOliveiro wrote:

ItrCOs more than just a name sticking. Consider the difference between the SYSTEM32 and SYSTEM directories on a Windows install: guess which one
holds the 64-bit binaries on a 64-bit system?

And what's in SysWow64?
--- Synchronet 3.22a-Linux NewsLink 1.2