From Newsgroup: comp.arch

According to quadi <[email protected]d>:

On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:

Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.

That is not the right comparison. If my old 16-bit software doesn't run at >full *native* speed on my shiny new 64-bit computer, then I still have to >run out and buy new software to get my work done faster.

That doesn't strike me as a reasonable argument. Any 16 bit application is likely to be very old, like before 2006. Microsoft ended DOS box support
with Windows Vista, 20 years ago. If the native performance of the program
was good enough 20 years ago, simulated performance today should be plenty fast.

If you want it to run faster, indeed, get newer software that takes advantage of 64 bit architecture and more than 1MB of addressable memory.
--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

quadi <[email protected]d> schrieb:

On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:

Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.

That is not the right comparison. If my old 16-bit software doesn't run at full *native* speed on my shiny new 64-bit computer, then I still have to run out and buy new software to get my work done faster.

At work, I actually use a 16-bit MS-DOS program, which was written
in the early 1990s. Originally, it had run 15-20 minutes; now it
runs in far less than 10 seconds (I never timed it, it is fast).
A newer 64-bit version is available, but I actually don't use it
because the old one works well, and I'm simply too lazy to learn
the new qirks, when I am quite used to the old quirks. It may also
be faster by a factor of 5, I don't care.

By comparison: It takes ages for for me to open an Excel file,
and whenever I change something in a certain complex Excel file,
like moing around a text box in a graph, it decides to recalculate,
taking maybe 30 seconds for me to see that the text box is not
where it should be. (And yes, I have switched off calculation, but
graphics doesn't care).

Although it is correct to say that Microsoft could have done something to fix this, even with the hardware issue as it is. They could have let
people buy just one copy of Windows, and install it twice on the same computer - so as to be able to boot into either the 32-bit version or the 64-bit version.

Haha.

Forcing people to ditch their own computers because they are not
Windows 11 compatible is the Microsoft way.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <[email protected]> posted:

quadi <[email protected]d> schrieb:

On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:

Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.

That is not the right comparison. If my old 16-bit software doesn't run at full *native* speed on my shiny new 64-bit computer, then I still have to run out and buy new software to get my work done faster.

At work, I actually use a 16-bit MS-DOS program, which was written
in the early 1990s. Originally, it had run 15-20 minutes; now it
runs in far less than 10 seconds (I never timed it, it is fast).
A newer 64-bit version is available, but I actually don't use it
because the old one works well, and I'm simply too lazy to learn
the new qirks, when I am quite used to the old quirks. It may also
be faster by a factor of 5, I don't care.

I have an automobile engine simulator* written in eXcel. When run on
my 33 MHz 486, I had time to get up from my chair, walk to the kitchen,
open the fridge, grab a beer, walk back, and the calculations were just finishing. When I got a 200 MHz Pentium Pro the same calculations took
a blink of an eye.

(*) 15 spread sheets, more than 10,000 equations somewhere around
10% of them using SQRT(), SIN(), COS(), EXP(), and LOG().

By comparison: It takes ages for for me to open an Excel file,
and whenever I change something in a certain complex Excel file,
like moing around a text box in a graph, it decides to recalculate,

You can (CAN) turn off automatic recalculation...

taking maybe 30 seconds for me to see that the text box is not
where it should be. (And yes, I have switched off calculation, but
graphics doesn't care).

Although it is correct to say that Microsoft could have done something to fix this, even with the hardware issue as it is. They could have let people buy just one copy of Windows, and install it twice on the same computer - so as to be able to boot into either the 32-bit version or the 64-bit version.

Haha.

Forcing people to ditch their own computers because they are not
Windows 11 compatible is the Microsoft way.

With Intel and AMD support.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

MitchAlsup <[email protected]d> schrieb:

Thomas Koenig <[email protected]> posted:

quadi <[email protected]d> schrieb:

On Thu, 14 May 2026 21:10:32 +0000, Thomas Koenig wrote:

Given that Dosemu runs much faster in emulation than on the original
hardware, that is not such a big loss.

That is not the right comparison. If my old 16-bit software doesn't run at
full *native* speed on my shiny new 64-bit computer, then I still have to >> > run out and buy new software to get my work done faster.

At work, I actually use a 16-bit MS-DOS program, which was written
in the early 1990s. Originally, it had run 15-20 minutes; now it
runs in far less than 10 seconds (I never timed it, it is fast).
A newer 64-bit version is available, but I actually don't use it
because the old one works well, and I'm simply too lazy to learn
the new qirks, when I am quite used to the old quirks. It may also
be faster by a factor of 5, I don't care.

I have an automobile engine simulator* written in eXcel. When run on
my 33 MHz 486, I had time to get up from my chair, walk to the kitchen,
open the fridge, grab a beer, walk back, and the calculations were just finishing. When I got a 200 MHz Pentium Pro the same calculations took
a blink of an eye.

(*) 15 spread sheets, more than 10,000 equations somewhere around
10% of them using SQRT(), SIN(), COS(), EXP(), and LOG().

By comparison: It takes ages for for me to open an Excel file,
and whenever I change something in a certain complex Excel file,
like moing around a text box in a graph, it decides to recalculate,

You can (CAN) turn off automatic recalculation...

And I did. It turns off the calculations in the sheet, but
apparently it still wants to recalculate things when I shift
something in a graph... and that I cannot turn off.

But of course, if I use spill formulas with things like sorting,
and then display sorted data... obviously my fault. Woe betide
anyone who has more than, let's say, 20000 or 30000 data points in
a column. That is obviously too much for a laptop with 16 GB main
memory and eight cores running Microsoft software and Windows 11.

Now I have moved the work on that sheet to my 512 GB workstation
with 48 Xeon cores, things have gotten tolerable (but just barely).

Using Python in Excel sends data to the Microsoft cloud, and does
not work without Internet access. Yuck.

I could try to use VBA, but who on Earth wants to? Plus Excel macros
are notoriously unsafe, and it is a good idea not to use them, and
not to encourage people to switch them on by default.

External programs - sure, I could write a Fortran or ... program to
do this, but then I could no longer distribute it to colleagues
and expect it to work.

taking maybe 30 seconds for me to see that the text box is not
where it should be. (And yes, I have switched off calculation, but
graphics doesn't care).

Although it is correct to say that Microsoft could have done something to >> > fix this, even with the hardware issue as it is. They could have let
people buy just one copy of Windows, and install it twice on the same
computer - so as to be able to boot into either the 32-bit version or the >> > 64-bit version.

Haha.

Forcing people to ditch their own computers because they are not
Windows 11 compatible is the Microsoft way.

With Intel and AMD support.

Or the other way - Microsoft wanted to get their partners their
partners a shot in the arm. Wintel lives... (only very few of
these absolutely working machines will have somebody installing
Linux on them, I think).
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 15/05/2026 18:02, quadi wrote:

On Wed, 13 May 2026 18:07:41 +0000, Anton Ertl wrote:

When I bought my Athlon 64 in October 2003, no 64-bit OSs were readily
available for it, and all the 32-bit and 16-bit stuff I used ran nicely.

Yes. You can run 32-bit Windows 7 on a 64-bit CPU in 32-bit mode, and 16-
bit programs will run just as well.

But apparently without rebooting to get into 32-bit mode, there really is
a hardware reason why 16-bit software can't easily be made to work from 64- bit mode. Whatever the hardware reason is, in my opinion that's a mistake
on the part of the hardware designers.

John Savard

I don't know how easy or not it is to implement the support, but don't remember problems running 16-bit Windows programs on 64-bit XP on an
Athlon. And I've had occasion to run 16-bit Windows programs with Wine
on 64-bit Linux. Maybe this all requires some special effort under the
hood, but it seems to be a solved problem - lack of 16-bit support in
modern 64-bit Windows appears to be a non-technical decision.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Mon, 04 May 2026 18:06:18 +0000, MitchAlsup wrote:

Headers are nothing more than mode-bits that change every block of code.
This means that ISA will be exceptionally difficult to verify, and as
you have found: very difficult to encode.

Your second sentence may well be true.

Your first sentence is definitely true, but it's a feature, not a bug. I intentionally exploited my block headers to achieve what would otherwise require mode bits - allowing instructions to be shorter, because one could switch between alternate sets of instructions - without the great danger
of mode bits for security: someone branching into code written to execute
in one mode while the machine's state specifies a different mode, thus
making code perform unintended actions.

John Savard
--- Synchronet 3.22a-Linux NewsLink 1.2