On Wednesday, December 21, 2022 at 3:00:25 PM UTC-6, John Levine wrote:
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >Michael S <already...@yahoo.com> writes:
> >>What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?
> >
> >Something VT220 or VT320 compatible. I don't remember the exact
> >price, but the terminals cost around ATS 10K (~EUR 700). ...
>
> Wikipedia says a DEC VT320 cost $495 in the late 1980s. You couldn't
> get a computer for anything close to that.
<
My first PC was 1990 a 33 MHz 486 with 4MB memory and a 100MB disk
that cost me $600±. A week after buying it I went back and paid $125 for
16 more MB of memory. A few months later I put in a 1GB disk at $300,
and a color printer $350.
<
> >>> replacing the Unix box with a Windows 3.1 system
> >>> would probably also have been a bad idea, because Windows 3.1 is not a
> >>> multi-user system.
> >>
> >>You don't need multi-user OS for server side of client-server app.
> >
> >That would mean replacing the terminals with more versatile clients
> >(e.g., PCs), more expensive. ...
>
> In the 1980s I was using a shared database running on a DOS PC with other
> DOS PCs on a thin coax Ethernet as the clients. It worked fine but as you
> say, dumb terminals would have been cheaper but we'd have needed a more
> capable server.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Wednesday, December 21, 2022 at 3:00:25 PM UTC-6, John Levine wrote:
>> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
>> >Michael S <already...@yahoo.com> writes:=20
>> >>What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 6=
>40 KB RAM?=20
>> >=20
>> >Something VT220 or VT320 compatible. I don't remember the exact
>> >price, but the terminals cost around ATS 10K (~EUR 700). ...=20
>>=20
>> Wikipedia says a DEC VT320 cost $495 in the late 1980s. You couldn't=20
>> get a computer for anything close to that.
><
>My first PC was 1990 a 33 MHz 486 with 4MB memory and a 100MB disk
>that cost me $600=C2=B1. A week after buying it I went back and paid $125 f=
>or
>16 more MB of memory. A few months later I put in a 1GB disk at $300,
>and a color printer $350.=20

I find that hard to believe. In 1993 I bought a 486/66 with 16MB
memory, a 340MB disk, a 14" screen and a keyboard for ATS 40,000 (~USD
3300). The disk proved too small, so I bought a 540MB disk for ATS
4800 (~USD 400) shortly after (in 1994). The Pentium was already out
at the time, so the 486/66 was no longer a high-end model, whereas a
486/33 was the fastest PC you could get in 1990 (the 486/33 only
appeared in May 1990).

The Amiga 1200 with a 14MHz 68EC020, 2MB RAM, and without HDD was
introduced for $599 in 1992.

I also think that hard disks were advancing fast at the time, so a
cheaper and bigger hard disk four years ealier does not look
plausible.
<https://web.archive.org/web/20140728221058/http://ns1758.ca/winch/winchest.html>
shows $9/MB in September 1990 and $0.95/MB in September 1994, and a
Seagate 1GB drive in January 1995 costing $849, and a 520MB HDD
costing $380 in April 1995.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> I find that hard to believe. In 1993 I bought a 486/66 with 16MB
> memory, a 340MB disk, a 14" screen and a keyboard for ATS 40,000 (~USD
> 3300). The disk proved too small, so I bought a 540MB disk for ATS
> 4800 (~USD 400) shortly after (in 1994). The Pentium was already out
> at the time, so the 486/66 was no longer a high-end model, whereas a
> 486/33 was the fastest PC you could get in 1990 (the 486/33 only
> appeared in May 1990).
>
> The Amiga 1200 with a 14MHz 68EC020, 2MB RAM, and without HDD was
> introduced for $599 in 1992.

from a recent archived afc post
http://www.garlic.com/~lynn/2022h.html#38 Christmas 1989

I was posting SJMN sunday adverts on internal IBM forums showing prices
significantly cheaper than IBM Boca/PS2 predictions. Then had of Boca
contracted with Dataquest (since bought by Gartner) to do study of
future of PC ... including several hr video taped round table of silicon
valley experts. The responsible person at Datquest I had known for a
number of years and asked me to be one of the experts ... and promised
to garble my identity so Boca wouldn't recognize me as an IBM employee.

note fall 88 , clone makers on the other side of the pacific, had
built up large inventory of 286 machines for the xmas season ... and
then Intel announce 386sx (386sx consolidated lots of chips needed
for 286 build) and the market/prices drops out of the 286.

....

also reposted in archived long-winded facebook thread which also wanders
into the IBM communication group responsible for the downfall of IBM
http://www.garlic.com/~lynn/2002h.html#104 IBM 360

Not long before leaving IBM, Boca had contracted with Dataquest (since
acquired by Gartner) to do detailed study of PC business and its
future ... including a video taped round table discussion of silicon
valley experts. I had known the person running the Dataquest study for
years and was asked to be one of the silicon valley experts (they
promised to obfuscate by vitals so Boca wouldn't recognize me as IBM
employee ... and I cleared it with my immediate management). I had
also been posting SJMN sunday adverts of quantity one PC prices to IBM
forums for a number of years (trying to show how out of touch with
reality, Boca forecasts were).

....

from long ago archived afc post (with some of the earlier SJMN sunday
adverts)
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)

from ohter PC posts; 30 years of personal computer market share figures
https://arstechnica.com/features/2005/12/total-share/
and has graph of personal computer sales 1975-1980
http://arstechnica.com/articles/culture/total-share/3/
and graph from 1980 to 1984 ... with the only serious competitor to PC in number of sales was commodore 64
http://arstechnica.com/articles/culture/total-share/4/
and then from 1984 to 1987 the ibm pc (and clones) starting to completely swamp
http://arstechnica.com/articles/culture/total-share/5/
market 1990-1994
https://arstechnica.com/features/2005/12/total-share/7/
2001-2004
https://arstechnica.com/features/2005/12/total-share/9/

--
virtualization experience starting Jan1968, online at home since Mar1970

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
> On 12/20/2022 3:09 AM, Michael S wrote:
>> On Tuesday, December 20, 2022 at 12:09:31 PM UTC+2, Anton Ertl wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>> Just what importance did UNIX
>>>> systems have in business in the 1970s and early 1980s, before
>>>> the PC really took off?
>>> In 1991 I worked in a small company that did business applications;
>>> the customers got a Unix server and a bunch of terminals and the
>>> software from this company. The software was written in C and used
>>> IIRC Oracle as database. However, this was not replacing Cobol
>>> software, but instead mostly non-computerized processes. Replacing
>>> the terminals with PCs would have been more expensive and would not
>>> have added value;
>>
>> What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?
>
> I think there were still what we used to call "glass teletypes"
> available. These were basically a keyboard and a character oriented
> screen, an RS232 serial port and whatever minimal hardware logic to
> connect them all, certainly a lot less than a 386SX. No user
> programmability. IIRC, they were in the hundreds of US dollars.

I worked on these for a bit. My first contact with UNIX was on
an institute server (HP 3000?) with HP terminals in the late 1980s.

I tried out a "hello world" in Fortran, just using cat, and
then tried to compile it using the Fortran compiler whose name I
knew, fc.

That turned out badly because fc was also a built-in function in
the shell, to edit the history (still is, in bash). That dropped
me into vi, and I didn't even know what that was, let alone how
to get out of it again...

I am typing this on vi, so I managed to get out of it eventually.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Stephen Fuld <sfuld@alumni.cmu.edu.invalid> schrieb:
>> On 12/20/2022 3:09 AM, Michael S wrote:
>>> On Tuesday, December 20, 2022 at 12:09:31 PM UTC+2, Anton Ertl wrote:
>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>> Just what importance did UNIX
>>>>> systems have in business in the 1970s and early 1980s, before
>>>>> the PC really took off?
>>>> In 1991 I worked in a small company that did business applications;
>>>> the customers got a Unix server and a bunch of terminals and the
>>>> software from this company. The software was written in C and used
>>>> IIRC Oracle as database. However, this was not replacing Cobol
>>>> software, but instead mostly non-computerized processes. Replacing
>>>> the terminals with PCs would have been more expensive and would not
>>>> have added value;
>>>
>>> What sort of terminals was cheaper in 1991 than 386SX PC with VGA and 640 KB RAM?
>>
>> I think there were still what we used to call "glass teletypes"
>> available. These were basically a keyboard and a character oriented
>> screen, an RS232 serial port and whatever minimal hardware logic to
>> connect them all, certainly a lot less than a 386SX. No user
>> programmability. IIRC, they were in the hundreds of US dollars.
>
>I worked on these for a bit. My first contact with UNIX was on
>an institute server (HP 3000?) with HP terminals in the late 1980s.

The HP 3000 operating system was called MPE. It never ran Unix.
(The HP-3000 was a stack architecture machine designed in part
by ex Burroughs engineers).

You're likely thinking about the HP-300.

HP had been designing the snakes architecture (which became
the HP Precision Architecture (PA-RISC, HP-9000) in the late 1980s.

The HP series 300 was a FOCUS[*] based Unix system in the 1980s, which
is likely the system you were using.

[*] First commercial single-chip 32-bit microprocessor on the market.

scott@slp53.sl.home (Scott Lurndal) writes:
>Thomas Koenig <tkoenig@netcologne.de> writes:
>>My first contact with UNIX was on
>>an institute server (HP 3000?) with HP terminals in the late 1980s.
>
>The HP 3000 operating system was called MPE. It never ran Unix.
>(The HP-3000 was a stack architecture machine designed in part
>by ex Burroughs engineers).

Later HP 3000 machines used PA-RISC, the HP 3000/900 series.

>You're likely thinking about the HP-300.

You may be thinking of HP 9000/300. HP 9000 were the HP/UX systems.

>HP had been designing the snakes architecture (which became
>the HP Precision Architecture (PA-RISC, HP-9000) in the late 1980s.

|The architecture was introduced on 26 February 1986, when the HP 3000
|Series 930 and HP 9000 Model 840 computers were launched

<https://en.wikipedia.org/wiki/PA-RISC>

>The HP series 300 was a FOCUS[*] based Unix system in the 1980s, which
>is likely the system you were using.

Among the HP 9000, series 200, 300, 400 are based on 68k, 500 is based
on HP's FOCUS (32-bit stack architecture), and 800 and 700 are based
on PA-RISC. Later they switched to a different naming scheme.

I consider it more likely that he worked with an 68k or PA-RISC
system. I was an intern at HP's Vienna subsidiary (responsible for
much of eastern Europe) in 1988 and 1989, and they had a number of HP
9000/300 and HP 9000/800 systems around, but I did not see a HP
9000/500. If they had sold a lot of them, I would expect that they
have one around for support reasons, even if they have stopped selling
them by that time.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:

>> [complaints about crummy software]

> Tim, we are really in violent agreement, it is just that either I
> am older than you, or I have given up fixing this before you did.

Nolo contendere.

>> [complaints about wasteful solutions]
>
> Having written some of the most performance-critical code in use
> today, I strongly agree. However, I have found that I need to
> pick my battles to the places where it still really matters. :-(

Just be thankful my complaints here are limited to the issues I
think are *really* important. :)

On Monday, December 19, 2022 at 3:45:35 PM UTC-7, Thomas Koenig wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> schrieb:

> > Not so much on mainframes, but as smaller companies realized they could
> > use a lower cost mini for their business needs.

> Sure, but programming it in C? Just what importance did UNIX
> systems have in business in the 1970s and early 1980s, before
> the PC really took off?

Not much, directly. But before the IBM PC, businesses tended
to use microcomputers running CP/M. C was as important
in developing programs to run on CP/M as it was in developing
programs to run on MS-DOS, even if the business users themselves,
if _they_ programmed their computers, would use one or another
dialect of BASIC.

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:
>But before the IBM PC, businesses tended
>to use microcomputers running CP/M. C was as important
>in developing programs to run on CP/M as it was in developing
>programs to run on MS-DOS

In a way that is true: On both platforms the relevance of C was
approximately 0. More relevant languages for CP/M and MS-DOS were
assembly language, Pascal and PL/M. C became prominent on PCs late in
the 1980s, shortly before Windows took off. E.g., if you look at
<https://en.wikipedia.org/wiki/WordPerfect#History>, it says that they
wanted to program WordPerfect for the IBM PC in C, but no C compilers
were available, so they wrote it in assembly language. C was
eventually used for WordPerfect 5.1, released in 1989.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

jgd@cix.co.uk (John Dallman) writes:
>In article <2023Jan3.092605@mips.complang.tuwien.ac.at>,
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> C became prominent on PCs late in the 1980s, shortly before
>> Windows took off.
>
>The job I was in must have been early: after writing and maintaining a
>CAD system on the Apple II in assembler, we started on a PC version in C
>in 1984. My next job, which I started in 1987, was with a company that
>had been using C on PCs since at least 1985.

Looking at word processors and spreadsheets, it seems that companies
wanted to use C quite a bit earlier, but the products written in
assembly language were more successful. But maybe things were
different in other areas.

Anyway, wrt spreadsheets, the most successful spreadsheet for the IBM
PC and compatibles on DOS was Lotus 1-2-3, written in assembly
language, which won out over Microsoft Multiplan, written in C
(compiled to virtual-machine rather than native code); it also won out
over an 1-2-3 clone written in C called "The Twin". When 1-2-3 was
rewritten in C, it became too large for the smaller machines, and they
had to maintain the assembly-language version in parallel; there may
also have been the second systems effect at work; after all, Microsoft
managed to let Multiplan run on small machines like the C64.

BTW, the reason why Multiplan was written in this (apparently
MS-internal) C was to support porting to the many different platforms
of the early 1980s. Most of these platforms eventually died out, with
the exception of the IBM PC compatible line and the MacIntosh line;
interestingly, the OSs on these platforms changed over time.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>In a way that is true: On both platforms the relevance of C was
>approximately 0. More relevant languages for CP/M and MS-DOS were
>assembly language, Pascal and PL/M. C became prominent on PCs late in
>the 1980s, shortly before Windows took off.

I was one of the authors of Javelin, a nice DOS time-series modelling
package that was unfortunately mis-sold as a spreadsheet. We started
work on it in 1984 and wrote it in C with small bits of assembler for
stuff you can't say in C. I don't recall there being any discussion of
using anything else. It helped that we used Wizard C, a nice little C
compiler from a one-man company that happened to be nearby, and he was
very good at shipping fixes when we sent him bug reports. He later
sold it to Borland who wrapped an IDE around it and sold it as Turbo
C.

I think that you could run Javelin in 512K with very little space for
your model. We used the Phoenix linker, which had an overlay scheme
essentially identical to the one OS/360 used 20 years earlier. One of
my jobs was to do the digital origami to fold the code into overlays
that worked (you can't call into a segment that will be loaded on top
of the caller) and didn't thrash too badly when running off floppies.
We also supported bank switched expanded memory, and one day loaded up
a PC with a then-astonishing 8 megabytes of RAM to make sure we could
use it all.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Dallman <jgd@cix.co.uk> schrieb:

> Yup. Trying to port software for any other OS to classic MacOS was very
> time-consuming and frustrating. You had to call yield() frequently, but
> not so frequently as to waste time, since yield() was not quick. If you
> hadn't designed this in originally, it was hard to get right. In contrast,
> porting to current macOS is relatively easy.

And the Mac enthusiasts were telling you that this was a good thing,
because preemptive multitasking was bad in some way. I forget
what the argument was, but it was mooted by Apple introducing
preemptive multitasking.

I once wrote a scientific program on a Mac (which then froze).
After being told that I was then a programmer, and that I should
have done what you described above in whatever language I used at
the time, I never did so again.

A bit like people arguing in favor of Windows 8 tiles, which
(on a desktop) mostly take up loads of space and do nothing to
help the users. They also had the people arguing vehemently
in favor of them - if Microsoft decrees it, it cannot be bad,
correct?

On 1/4/2023 12:36 AM, Thomas Koenig wrote:
> John Dallman <jgd@cix.co.uk> schrieb:
>
>> Yup. Trying to port software for any other OS to classic MacOS was very
>> time-consuming and frustrating. You had to call yield() frequently, but
>> not so frequently as to waste time, since yield() was not quick. If you
>> hadn't designed this in originally, it was hard to get right. In contrast,
>> porting to current macOS is relatively easy.
>
> And the Mac enthusiasts were telling you that this was a good thing,
> because preemptive multitasking was bad in some way. I forget
> what the argument was, but it was mooted by Apple introducing
> preemptive multitasking.
>

Preemptive multitasking is pros/cons.
Good for a general user OS, not as good for real-time systems.

Sort of issues also when one takes OS's not meant for real-time, and
sort of fudges them into a real-time use-case (such as a CNC controller).

Granted, yes, a background task monopolizing the CPU for an extended
period of time would also be bad.

Also, things like automatic lock-screen (if one doesn't mess with the
mouse/keyboard often enough), or automatic pop-up notifications, are
"not ideal" as far as a CNC controller goes (say, when keyboard inputs
and having input focus on said CNC program are the only way to E-Stop
the thing).

Well, and despite the temptation, one thing that is "generally a bad
idea is trying to use a web-browser while trying to mill something
(something like FireFox able to disrupt things enough to crash the machine).

> I once wrote a scientific program on a Mac (which then froze).
> After being told that I was then a programmer, and that I should
> have done what you described above in whatever language I used at
> the time, I never did so again.
>
> A bit like people arguing in favor of Windows 8 tiles, which
> (on a desktop) mostly take up loads of space and do nothing to
> help the users. They also had the people arguing vehemently
> in favor of them - if Microsoft decrees it, it cannot be bad,
> correct?

It was a stupid design choice for a desktop.
There was seemingly a period where both MS and also Ubuntu and similar,
seemingly thought that desktop PCs were tablets and phones, and so tried
redesigning the UI around this.

OTOH, I have also found a 4K monitor to be pros/cons:
One either uses UI scaling, which defeats the point;
One deals with the slight awkwardness of using a 4K display at 1x scaling.

I have mostly gotten used to it.

I am also starting to have an opinion that for "general
viewing/interaction", it seems like 144 ppi or so may make sense as a
practical limit for a pixel-oriented display.

So, for example, a cell-phone doesn't get much benefit from a screen
much over 1440x720 or so (or a tablet much past 1920x1080).

For a PC monitor, 2160p seems to already be in diminishing returns
territory.
Short of "actually using UI scaling", going much higher resolution than
this would likely be "basically unusable". And, if one needs to use
scaling, what is the point?...

I don't necessarily think "make pixels too small to be seen" is
necessarily a worthwhile goal as far as UI design goes.

Burning 48x64 pixels or something on each font character for the user to
be able to read them is not an effective use of resources IMO.

Say, if your font glyph needs to be larger than 8x12 pixels or so to be
readable, there is little benefit to going to a higher resolution.

But, as-is, does mean that I can tile 5x 640x480 windows side-to-side
across the screen, so it is useful for running simulations.

Still does not solve the issue of losing windows behind each-other though.

Would also be nice if MS were to realize they basically already gotten
the UI right somewhere around Windows 2000, and most stuff they have
been doing since then has been counter-productive in terms of usability.

....

On 2023-01-04 19:35, BGB wrote:
> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>> John Dallman <jgd@cix.co.uk> schrieb:
>>
>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>> time-consuming and frustrating. You had to call yield() frequently, but
>>> not so frequently as to waste time, since yield() was not quick. If you
>>> hadn't designed this in originally, it was hard to get right. In
>>> contrast,
>>> porting to current macOS is relatively easy.
>>
>> And the Mac enthusiasts were telling you that this was a good thing,
>> because preemptive multitasking was bad in some way. I forget
>> what the argument was, but it was mooted by Apple introducing
>> preemptive multitasking.
>>
>
> Preemptive multitasking is pros/cons.
> Good for a general user OS,

Yes.

> not as good for real-time systems.

I disagree, as would many others. Depends somewhat on the criticality of
the system (requirements to limit complexity).

But I agree, of course, that there are OS's that do preemptive
multitasking and _still_are not suitable for real-time systems.

BGB <cr88192@gmail.com> writes:
>On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>> John Dallman <jgd@cix.co.uk> schrieb:
>>
>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>> time-consuming and frustrating. You had to call yield() frequently, but
>>> not so frequently as to waste time, since yield() was not quick. If you
>>> hadn't designed this in originally, it was hard to get right. In contrast,
>>> porting to current macOS is relatively easy.
>>
>> And the Mac enthusiasts were telling you that this was a good thing,
>> because preemptive multitasking was bad in some way. I forget
>> what the argument was, but it was mooted by Apple introducing
>> preemptive multitasking.
>>
>
>Preemptive multitasking is pros/cons.
>Good for a general user OS, not as good for real-time systems.

I would hope you can support that statement, unless you are
specifically limiting yourself to obsolete single-user operating systems.

The only thing that pre-emptive multitasking is useful for is,
well, nothing.

>
>Would also be nice if MS were to realize they basically already gotten
>the UI right somewhere around Windows 2000, and most stuff they have
>been doing since then has been counter-productive in terms of usability.

Windows has never had a good UI, or good anything.

On Wednesday, January 4, 2023 at 11:35:57 AM UTC-6, BGB wrote:
> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
> > John Dallman <j...@cix.co.uk> schrieb:
> >
> >> Yup. Trying to port software for any other OS to classic MacOS was very
> >> time-consuming and frustrating. You had to call yield() frequently, but
> >> not so frequently as to waste time, since yield() was not quick. If you
> >> hadn't designed this in originally, it was hard to get right. In contrast,
> >> porting to current macOS is relatively easy.
> >
> > And the Mac enthusiasts were telling you that this was a good thing,
> > because preemptive multitasking was bad in some way. I forget
> > what the argument was, but it was mooted by Apple introducing
> > preemptive multitasking.
> >
> Preemptive multitasking is pros/cons.
> Good for a general user OS, not as good for real-time systems.
<
I think it depends. The only downside of multitasking in a real time
environment is the cache hierarchy is stale when a task begins
running.
<
Nothing in multitasking prevents fast context switches, of the
highest priority threads, to cores with which they have affinity,
to run at their specified priority (and sometimes higher).
<
Especially if the above paragraph can be made manifest in 10-ish
cycles.
<
The only thing that remains are the core caches and MMU caches
catching up so the RT thread runs as fast as practicable.

On Wednesday, January 4, 2023 at 12:12:42 PM UTC-6, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:
> >On 1/4/2023 12:36 AM, Thomas Koenig wrote:
> >> John Dallman <j...@cix.co.uk> schrieb:
> >>
> >>> Yup. Trying to port software for any other OS to classic MacOS was very
> >>> time-consuming and frustrating. You had to call yield() frequently, but
> >>> not so frequently as to waste time, since yield() was not quick. If you
> >>> hadn't designed this in originally, it was hard to get right. In contrast,
> >>> porting to current macOS is relatively easy.
> >>
> >> And the Mac enthusiasts were telling you that this was a good thing,
> >> because preemptive multitasking was bad in some way. I forget
> >> what the argument was, but it was mooted by Apple introducing
> >> preemptive multitasking.
> >>
> >
> >Preemptive multitasking is pros/cons.
> >Good for a general user OS, not as good for real-time systems.
> I would hope you can support that statement, unless you are
> specifically limiting yourself to obsolete single-user operating systems.
>
> The only thing that pre-emptive multitasking is useful for is,
> well, nothing.
<
How else does one run 1,000 different tasks on a handful of cores
efficiently, securely, and at low overhead ?
> >
> >Would also be nice if MS were to realize they basically already gotten
> >the UI right somewhere around Windows 2000, and most stuff they have
> >been doing since then has been counter-productive in terms of usability.
> Windows has never had a good UI, or good anything.

On 04/01/2023 18:35, BGB wrote:
> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>> John Dallman <jgd@cix.co.uk> schrieb:
>>
>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>> time-consuming and frustrating. You had to call yield() frequently, but
>>> not so frequently as to waste time, since yield() was not quick. If you
>>> hadn't designed this in originally, it was hard to get right. In
>>> contrast,
>>> porting to current macOS is relatively easy.
>>
>> And the Mac enthusiasts were telling you that this was a good thing,
>> because preemptive multitasking was bad in some way. I forget
>> what the argument was, but it was mooted by Apple introducing
>> preemptive multitasking.
>>
>
> Preemptive multitasking is pros/cons.
> Good for a general user OS, not as good for real-time systems.
>
> Sort of issues also when one takes OS's not meant for real-time, and
> sort of fudges them into a real-time use-case (such as a CNC controller).
>
> Granted, yes, a background task monopolizing the CPU for an extended
> period of time would also be bad.
>

I wonder if you are mixing "pre-emptive" with "time-slicing for tasks of
the same priority". All RTOS's - which are designed for real-time tasks
(though you can have a real-time system without an OS at all) - are
pre-emptive. At any time outside short critical regions used to
implement primitives like low-level mutexes, a running task can be
pre-empted by another task of higher priority that becomes runnable. If
higher priority tasks, perhaps triggered by an interrupt, cannot
pre-empt running lower priority tasks then you do not have a real-time
system.

On the other hand, if you have lots of tasks of the same priority, all
runnable, then there are definitely pros and cons as to whether you
allow time-slicing pre-emption. It can be more efficient, and make
inter-process communication easier and caches misses lower if tasks are
only paused when they are ready for it (with a "yield()" call). But
then you need to write the tasks in a cooperative manner.

>>
>> A bit like people arguing in favor of Windows 8 tiles, which
>> (on a desktop) mostly take up loads of space and do nothing to
>> help the users.  They also had the people arguing vehemently
>> in favor of them - if Microsoft decrees it, it cannot be bad,
>> correct?
>
> It was a stupid design choice for a desktop.
> There was seemingly a period where both MS and also Ubuntu and similar,
> seemingly thought that desktop PCs were tablets and phones, and so tried
> redesigning the UI around this.
>

Ubuntu has done a lot to damage the reputation of Linux on desktops by
convincing people that they make the "standard" desktop Linux for
"ordinary" users, while giving them a design that tries to outdo
Microsoft in hideousness and inefficiency.

>
> Would also be nice if MS were to realize they basically already gotten
> the UI right somewhere around Windows 2000, and most stuff they have
> been doing since then has been counter-productive in terms of usability.
>

A desktop should have the tools you need to run your applications, and
provide features such as printing, settings, menus, task switching,
virtual desktops, task control, notifications (of useful things), file
management, and perhaps little applets for things like cpu usage. Apart
from that, it should stay out of the way. I don't want adverts mixed
with my "start menu", or weather maps, or menus that re-arrange
themselves all the time. Apart from a lack of virtual desktops, I agree
that W2K pretty much covered everything. My Windows machine is Win7,
which is not bad once some of the silly settings are fixed. And my
impression of Win11 is that it is has fixed many of the worst mistakes
of Win8.

On Linux, I use Mate (based on Gnome 2). Fancy desktops like KDE are
great for impressing others, but if you actually use your computer for
work, browsing, games, videos, or pretty much anything else, you are
using applications and the desktop should be hidden.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Wednesday, January 4, 2023 at 12:12:42 PM UTC-6, Scott Lurndal wrote:
>> BGB <cr8...@gmail.com> writes:
>> >On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>> >> John Dallman <j...@cix.co.uk> schrieb:
>> >>
>> >>> Yup. Trying to port software for any other OS to classic MacOS was very
>> >>> time-consuming and frustrating. You had to call yield() frequently, but
>> >>> not so frequently as to waste time, since yield() was not quick. If you
>> >>> hadn't designed this in originally, it was hard to get right. In contrast,
>> >>> porting to current macOS is relatively easy.
>> >>
>> >> And the Mac enthusiasts were telling you that this was a good thing,
>> >> because preemptive multitasking was bad in some way. I forget
>> >> what the argument was, but it was mooted by Apple introducing
>> >> preemptive multitasking.
>> >>
>> >
>> >Preemptive multitasking is pros/cons.
>> >Good for a general user OS, not as good for real-time systems.
>> I would hope you can support that statement, unless you are
>> specifically limiting yourself to obsolete single-user operating systems.
>>
>> The only thing that pre-emptive multitasking is useful for is,
>> well, nothing.
><
>How else does one run 1,000 different tasks on a handful of cores
>efficiently, securely, and at low overhead ?

My error; Somehow I read it as cooperative multitasking rather than
pre-emtpive.

On 1/4/2023 11:57 AM, Niklas Holsti wrote:
> On 2023-01-04 19:35, BGB wrote:
>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>> John Dallman <jgd@cix.co.uk> schrieb:
>>>
>>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>>> time-consuming and frustrating. You had to call yield() frequently, but
>>>> not so frequently as to waste time, since yield() was not quick. If you
>>>> hadn't designed this in originally, it was hard to get right. In
>>>> contrast,
>>>> porting to current macOS is relatively easy.
>>>
>>> And the Mac enthusiasts were telling you that this was a good thing,
>>> because preemptive multitasking was bad in some way. I forget
>>> what the argument was, but it was mooted by Apple introducing
>>> preemptive multitasking.
>>>
>>
>> Preemptive multitasking is pros/cons.
>> Good for a general user OS,
>
>
> Yes.
>
>
>> not as good for real-time systems.
>
>
> I disagree, as would many others. Depends somewhat on the criticality of
> the system (requirements to limit complexity).
>

Say...

Pulsing IO pins at 10s of kHz with regular timing, or else a motor loses
position, causing a rapidly spinning cutting tool to not be in the
correct place in relation to a big chunk of steel or similar.

If the position is slightly off, the "tolerances" or similar are messed
up. If it goes off by a larger amount, a "catastrophic failure" can
result (such as the cutting tool exploding).

Say, the cutting tool can happily take off ~ 0.010" in a cut, but if you
suddenly try to take off 0.050" or more in a cut, the tool explodes...

Because, well, steel is kinda hard...

Aluminum is at least a little more forgiving in this sense.

> But I agree, of course, that there are OS's that do preemptive
> multitasking and _still_are not suitable for real-time systems.
>

I was thinking of the whole thing of "try to use Windows or Linux with a
parallel port to drive a CNC machine's stepper drivers".

This sort of setup is "not ideal"...

Like, "try to use a web browser while machining something and your CNC
machine starts jerking and losing its position" levels of bad...

This would possibly be "slightly less bad" with servos, but still not ideal.

Partly, it is because a lot of the PCs which have the needed parallel
port, also typically limited in other ways, say:
Single core 1.67 GHz CPU, 32-bit only;
2GB of RAM;
...

Because, say, most systems with 64-bit capable CPUs, multi-core CPUs,
able to use more RAM, ..., almost invariably lack a dedicated parallel port.

Or, rarely, one can find something with a 64-bit capable dual-core which
still has a parallel port...

Luckily at least, a lot of the commercially made CNC conversion kits
come with controller boxes which seem to handle the G-Code interpreter
internally (for one machine, the parallel cable plugged into this box
rather than directly into the PC; but another machine uses the parallel
port on the PC to directly run the steppers).

Some other kits have the motor drivers directly integrated into the
control box (but the controller box is a lot bigger in this case).

But, then one does have the tradeoff of being limited to the
capabilities of closed-source tools, and needing to contact the CNC kit
company to redo the registration key every time they change something
non-trivial in the PC that is running the software (them using a copy
protection scheme that changes the machine hash pretty much anything
non-trivial changes on the the PC in question).

Though, at least, the software from the other company is happy enough as
long as it sees it is connected to that company's control box (seemingly
using the presence of the control box as its DRM scheme).

Either way, the controller boxes are "not exactly cheap".

....

This does sort of create a desire though for "some other option"...

Many people doing "full custom" machines typically also seem to write
their own CNC controller software (often using a microcontroller as the
go-between).

I had before tried using a RasPi (for a few experimental machines), but
task-scheduling within Linux interfered with my ability to get the
desired level of timing stability.

One can use an FPGA or microcontroller, but (if plugging into a PC) are
mostly limited to options which have an FTDI chip or similar (other
option being to use an RS232 serial port, which is at least still a
little easier to find on a PC than a parallel port).

Mostly, this matters in that it means one needs something like an
LaunchPad or Arduino or something, rather than being able to use a bare
AVR8 or MSP430 in a DIP socket (since, natively, these lack any way to
communicate natively over USB; and would usually do so via an FTDI chip
or similar on the board; with the microcontroller itself using an RS232
interface or similar to talk to the FTDI chip).

But, yeah, something like the RasPi Pico could also fall into this camp
(and is arguably a bit more capable than a lot of the AVR based Arduino
devices).

....

On 1/4/2023 1:59 PM, Scott Lurndal wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> On Wednesday, January 4, 2023 at 12:12:42 PM UTC-6, Scott Lurndal wrote:
>>> BGB <cr8...@gmail.com> writes:
>>>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>>>> John Dallman <j...@cix.co.uk> schrieb:
>>>>>
>>>>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>>>>> time-consuming and frustrating. You had to call yield() frequently, but
>>>>>> not so frequently as to waste time, since yield() was not quick. If you
>>>>>> hadn't designed this in originally, it was hard to get right. In contrast,
>>>>>> porting to current macOS is relatively easy.
>>>>>
>>>>> And the Mac enthusiasts were telling you that this was a good thing,
>>>>> because preemptive multitasking was bad in some way. I forget
>>>>> what the argument was, but it was mooted by Apple introducing
>>>>> preemptive multitasking.
>>>>>
>>>>
>>>> Preemptive multitasking is pros/cons.
>>>> Good for a general user OS, not as good for real-time systems.
>>> I would hope you can support that statement, unless you are
>>> specifically limiting yourself to obsolete single-user operating systems.
>>>
>>> The only thing that pre-emptive multitasking is useful for is,
>>> well, nothing.
>> <
>> How else does one run 1,000 different tasks on a handful of cores
>> efficiently, securely, and at low overhead ?
>
> My error; Somehow I read it as cooperative multitasking rather than
> pre-emtpive.

I was thinking that cooperative multitasking could make sense for some
sorts of embedded real-time systems.

Whereas pre-emptive makes a lit more sense for user-facing systems since
it can give the illusion of everything on the system running at the same
time.

For normal user-facing applications we straight up don't care about
microsecond accurate timing, but it is painfully obvious if the OS
temporarily (or non-temporarily) locks up because some program was
spinning in a loop.

Of course, if using cooperative multitasking in a real-time system, a
task getting unexpectedly caught for an extended period in such a loop
is, very likely, catastrophic...

On 1/4/2023 12:55 PM, MitchAlsup wrote:
> On Wednesday, January 4, 2023 at 11:35:57 AM UTC-6, BGB wrote:
>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>> John Dallman <j...@cix.co.uk> schrieb:
>>>
>>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>>> time-consuming and frustrating. You had to call yield() frequently, but
>>>> not so frequently as to waste time, since yield() was not quick. If you
>>>> hadn't designed this in originally, it was hard to get right. In contrast,
>>>> porting to current macOS is relatively easy.
>>>
>>> And the Mac enthusiasts were telling you that this was a good thing,
>>> because preemptive multitasking was bad in some way. I forget
>>> what the argument was, but it was mooted by Apple introducing
>>> preemptive multitasking.
>>>
>> Preemptive multitasking is pros/cons.
>> Good for a general user OS, not as good for real-time systems.
> <
> I think it depends. The only downside of multitasking in a real time
> environment is the cache hierarchy is stale when a task begins
> running.
> <
> Nothing in multitasking prevents fast context switches, of the
> highest priority threads, to cores with which they have affinity,
> to run at their specified priority (and sometimes higher).
> <
> Especially if the above paragraph can be made manifest in 10-ish
> cycles.
> <
> The only thing that remains are the core caches and MMU caches
> catching up so the RT thread runs as fast as practicable.

I guess a lot depends on how the RT tasks are triggered to run.
Fast interrupt handling and task switching makes sense if the
hardware-level interfaces are interrupt driven.

This approach is much less workable if the hardware interfaces use
polling IO.

And, say, your task is mostly poll and update IO pins at 32 or 64 kHz
based mostly on the results fairly simple arithmetic and logic
calculations (and periodically running more complex logic).

I guess one potential test for timing accuracy could be, say, if one
could modulate intelligible speech or music playback into the output of
a spinning stepper motor...

Say, to PWM modulate the vibrations of a spinning stepper motor for PCM
audio playback likely requiring timing accuracy of around 1us or so
(well, assuming the stepper driver is itself accurate to this degree).

Well, going this route would likely also require a stepper that can be
spun at upwards of 1200 or 2400 RPM (to give the base carrier to try to
modulate the audio into).

Well, nevermind the squeal of the stepper motor itself (not actually
sure if it is possible to get a stepper spinning fast enough to push
this outside of audible range). Though I guess if one used a flywheel
and rubber dampeners, it could be possible to reduce this noise.

....

On 1/4/2023 1:19 PM, David Brown wrote:
> On 04/01/2023 18:35, BGB wrote:
>> On 1/4/2023 12:36 AM, Thomas Koenig wrote:
>>> John Dallman <jgd@cix.co.uk> schrieb:
>>>
>>>> Yup. Trying to port software for any other OS to classic MacOS was very
>>>> time-consuming and frustrating. You had to call yield() frequently, but
>>>> not so frequently as to waste time, since yield() was not quick. If you
>>>> hadn't designed this in originally, it was hard to get right. In
>>>> contrast,
>>>> porting to current macOS is relatively easy.
>>>
>>> And the Mac enthusiasts were telling you that this was a good thing,
>>> because preemptive multitasking was bad in some way. I forget
>>> what the argument was, but it was mooted by Apple introducing
>>> preemptive multitasking.
>>>
>>
>> Preemptive multitasking is pros/cons.
>> Good for a general user OS, not as good for real-time systems.
>>
>> Sort of issues also when one takes OS's not meant for real-time, and
>> sort of fudges them into a real-time use-case (such as a CNC controller).
>>
>> Granted, yes, a background task monopolizing the CPU for an extended
>> period of time would also be bad.
>>
>
> I wonder if you are mixing "pre-emptive" with "time-slicing for tasks of
> the same priority".  All RTOS's - which are designed for real-time tasks
> (though you can have a real-time system without an OS at all) - are
> pre-emptive.  At any time outside short critical regions used to
> implement primitives like low-level mutexes, a running task can be
> pre-empted by another task of higher priority that becomes runnable.  If
> higher priority tasks, perhaps triggered by an interrupt, cannot
> pre-empt running lower priority tasks then you do not have a real-time
> system.
>

I am familiar with real-time systems typically implemented more in terms
of a tight-spinning event-dispatcher loop and a microsecond-accurate clock.

Here, spinning in a loop (or otherwise failing to yeild) is not allowed
(and a task taking more than a certain number of microseconds can be
logged as an error).

Though, this was typically with C level scheduling (via structs and
function pointers), rather than full context switches.

Annoyingly, BJX2 is slow enough that holding 10us with a loop-based
task-scheduler is not really workable in this case either (so, the
timing sensitive parts may likely require FPGA logic).

Luckily, holding stable <1us timing is a non-issue for an FPGA, and most
of the other logic has looser requirements (if one excludes motor pulse
generation, timing loosens to around 100us).

With an MSP430, assuming the logic is "simple enough", one can get a
stable 30us via a 32kHz timer interrupt.

But, also sadly, BJX2's interrupt handling is slow enough that it can't
really manage a 32kHz timer IRQ (despite having around a 3x higher clock
speed than the MSP430).

Well, unless maybe I added a dedicated ISR entry point specifically for
a high-speed timer interrupt, and then have the interrupt handler being
written in ASM (then one doesn't need to save/restore the entire
register space).

But, OTOH, something like an MSP430 isn't really powerful enough to run
something like a G-Code interpreter. It is able to run something like a
motor driver or similar though (so, say, I can use it effectively to run
an H-Bridge driver and process step/direction pulses or PWM or similar,
but running G-Code or managing multiple motors at the same time, not so
much).

AVR8 has more RAM and ROM (so can handle more complex logic), but code
seems to run a little slower (relative to clock speed) if compared with
an MSP430.

> On the other hand, if you have lots of tasks of the same priority, all
> runnable, then there are definitely pros and cons as to whether you
> allow time-slicing pre-emption.  It can be more efficient, and make
> inter-process communication easier and caches misses lower if tasks are
> only paused when they are ready for it (with a "yield()" call).  But
> then you need to write the tasks in a cooperative manner.
>

Writing purely cooperative scheduled tasks are what is assumed in this case.

Granted, if one does write cooperative-scheduled tasks which yield at
the right moment, then arguably a preemptive scheduler is (merely) a
safety net for tasks which fail to yield in a timely manner.

But, on an OS like Linux on a RasPi, calling "usleep(0)" almost
invariably means control wont come back around until 200-500us later,
which isn't really usable for the sorts of tasks I was using it for.

Like, on the RasPi, there is almost invariably something else waiting in
the background to eat a big chunk of clock-cycles.

Even with Linux CNC (itself built on a modified real-time Linux), it
still gives warning messages as the CNC controller seemingly can't hold
its timing tolerance (seemingly LinuxCNC trying to hold a 150us
tolerance, but still failing to do so reliably).

Granted, I am not entirely sure how it does pulse generation effectively
at a 150us tolerance.

My guess is that it makes use of the parallel port having a FIFO to
effectively function sort of like how one would use SERDES on an FPGA.

Well, unlike GPIO, where one would need to hold a 10us tolerance to pull
off a similar effect.

Though, one can loosen the requirements slightly at least be using
full-stepping or half-stepping rather than micro-stepping (it being a
lot easier to hold timings when spinning a motor at 400 steps/rev rather
than 1600 or 3200 steps/rev).

Say:
Spin motor at 1000 RPM with 3200 steps per rev:
Would need ~ 53000 steps per second, ~ 18 us per step
Spin motor at 1000 RPM with 400 steps per rev:
Would need ~ 6625 steps per second, ~ 151 us per step

But, for reasons, one needs the timing tolerance to be smaller than the
pulse step needed to spin the motor (and at least 2x faster, since one
needs to be able to toggle the pin twice per step).

Say, for a 20us step:
0us: Update Dir pin;
Set Step Pin
10us: Clear Step Pin
20us: Repeat

But, yeah, trying to get all this to work reliably on a RasPi was a
source of much frustration...

>>>
>>> A bit like people arguing in favor of Windows 8 tiles, which
>>> (on a desktop) mostly take up loads of space and do nothing to
>>> help the users.  They also had the people arguing vehemently
>>> in favor of them - if Microsoft decrees it, it cannot be bad,
>>> correct?
>>
>> It was a stupid design choice for a desktop.
>> There was seemingly a period where both MS and also Ubuntu and
>> similar, seemingly thought that desktop PCs were tablets and phones,
>> and so tried redesigning the UI around this.
>>
>
> Ubuntu has done a lot to damage the reputation of Linux on desktops by
> convincing people that they make the "standard" desktop Linux for
> "ordinary" users, while giving them a design that tries to outdo
> Microsoft in hideousness and inefficiency.
>

Basically my sentiment as well.

I had generally preferred RedHat variants, like Fedora and CentOS.
But, CentOS has nowhere near the mindshare of Ubuntu.

>>
>> Would also be nice if MS were to realize they basically already gotten
>> the UI right somewhere around Windows 2000, and most stuff they have
>> been doing since then has been counter-productive in terms of usability.
>>
>
> A desktop should have the tools you need to run your applications, and
> provide features such as printing, settings, menus, task switching,
> virtual desktops, task control, notifications (of useful things), file
> management, and perhaps little applets for things like cpu usage.  Apart
> from that, it should stay out of the way.  I don't want adverts mixed
> with my "start menu", or weather maps, or menus that re-arrange
> themselves all the time.  Apart from a lack of virtual desktops, I agree
> that W2K pretty much covered everything.  My Windows machine is Win7,
> which is not bad once some of the silly settings are fixed.  And my
> impression of Win11 is that it is has fixed many of the worst mistakes
> of Win8.
>

Still using Win10 here; partly because MS sort of railroaded everyone
into needing to move to Win10 from Win7.

> On Linux, I use Mate (based on Gnome 2).  Fancy desktops like KDE are
> great for impressing others, but if you actually use your computer for
> work, browsing, games, videos, or pretty much anything else, you are
> using applications and the desktop should be hidden.
>

OK.

LinuxCNC is using XFCE.
CentOS uses GNOME.
....

>
>
>

BGB <cr88192@gmail.com> writes:
>On 1/4/2023 1:19 PM, David Brown wrote:

>> Ubuntu has done a lot to damage the reputation of Linux on desktops by
>> convincing people that they make the "standard" desktop Linux for
>> "ordinary" users, while giving them a design that tries to outdo
>> Microsoft in hideousness and inefficiency.
>>
>
>Basically my sentiment as well.
>
>I had generally preferred RedHat variants, like Fedora and CentOS.
>But, CentOS has nowhere near the mindshare of Ubuntu.

Centos is very widely used in the server space. Particularly for
chip development (synopsis, cadence, mentor) toolsets.

On Tue, 3 Jan 2023 16:15 +0000 (GMT Standard Time), jgd@cix.co.uk
(John Dallman) wrote:

>... Trying to port software for any other OS to classic MacOS was very
>time-consuming and frustrating. You had to call yield() frequently, but
>not so frequently as to waste time, since yield() was not quick. If you
>hadn't designed this in originally, it was hard to get right. In contrast,
>porting to current macOS is relatively easy.
>
>John

I didn't do a lot with 68K MacOS, and what I did was not time
sensitive. I suspect though that the problem was slow CPU rather than
just inefficient code.

I wrote some SemiHard-RT applications on Windows 3.1 using multiple
processes sharing code as ersatz 'threads'.

The 'thread' processes controlled bus mounted image processing
hardware. [this was before (Intel) SIMD, and even when SIMD appeared
it could not keep up with dedicated hardware until SSE2 on Pentium4].

Most of the code (of necessity) was in the main GUI process - the RT
'threads' would call into it as needed, passing flags to indicate the
source of the call and determine whether the image hardware should be
run with/without interrupts enabled.

In practice, the 'threads' would initiate some function on their
repspective hardware that might take several ms, and then sleep
waiting for a completion interrupt - which was turned into an
application message by its interrupt handler. They did not yield
explicitly, but rather called GetMessage() (or PeekMessage()
depending) which performed an implicit yield.

On 40MHz i486-DX running 7 processes - GUI and 6 RT 'threads' - the
context switch time was under 10 /microseconds/. Sounds like a lot
[and it is] but we had 650..900ms to do our work (depending on app),
so the context switching was not a problem.

Later some of these apps were ported to Win98. On 120MHz Pentium,
using real threads and blocking events, the context switch time got
down reliably under 2 microseconds.

And then things were made complicated by NT when user mode interrupt
handling became impossible. Fortunately, by that point we were able to
wean off the dedicated image hardware and start using SIMD for the
image processing. But we still had some custom interface I/O boards
that needed interrupt service. 8-|

YMMV,
George