scott@slp53.sl.home (Scott Lurndal) writes:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
Using overlays was never straightforward, on any OS.
Typical troll comment.
There are existance proofs counter to your unsupported blanket statement.
Burroughs medium systems for example, where using overlays was built into the
compilation tools (including the COBOL compiler) and the operating system. >> Even the operating system used overlays for rarely used functionality.
Far be it from me to defend the troll, but I will say that my experience (56 years and counting) agrees with his comment.
IIRC, I have made changes to exactly one (1) overlaid program in all that time,
having been forced to do that instead of a complete rewrite because it had to work quickly at the museum.
That's with experience on OS/360, SVS and MVS on /370, Tops-10 and TOPS-20, and
RSX-11M/-20F.
Overlays are like a coyote ugly bed partner: I'd rather chew my arm off.
In article <108uhef$26t$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
As for ease of use, you got it backward. While overlays in DEC OSes
actually are way more advanced, and capable that overlays in Unix on the
PDP-11, using them on the Unix side is basically a no brainer. You don't
need to do anything at all. You just put modules wherever you want to,
and it works.
With the DEC OSes, you have to create an overlay description in a weird
language, and you can't call cross overlay trees, and you need to be
careful if you call upstream, which might change mapping, and all that.
None of those restrictions apply for Unix overlays. The only thing you
need to keep an eye out for is just that the size is kept within some rules. >>
Johnny
Since you've done it, I defer. I just recall that when we got 2.9BSD, I considered trying to port some big Vax program to the 11 and from reading
the man pages I got the impression I would have to get intimately familiar with said program's call graph (which I definitely was not) to partition
out the overlays and ended up moving on to something else.
˙ "Reset" buttons are mostly good, but on the company
˙ servers I always disconnected those, so no dink could
˙ just accidentally bump into the switch while looking
˙ for something else. REAL power switch, like a 3-sec
˙ delay before anything happens.
On 29 Aug 2025 20:52:10 GMT, Ted Nolan <tednolan> wrote:
In article <108su32$3e8$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
But even more important, on the PDP-11, there is support for overlaid
programs, which makes heavy use of the MMU.
No, it didn’t make use of the MMU at all. It was a purely software thing, involving replacing in-memory parts of the program with other parts loaded from the executable file.
My memory is that at leat for BSD Unix, overlays were not supported
until um, 2.9BSD I think, and that using them was not at all
straight-forward. It may have been easier for official DEC OSes...
Using overlays was never straightforward, on any OS.
On 2025-08-30 19:39, Ted Nolan <tednolan> wrote:
In article <108uhef$26t$1@news.misty.com>,
Johnny Billquist˙ <bqt@softjar.se> wrote:
As for ease of use, you got it backward. While overlays in DEC OSes
actually are way more advanced, and capable that overlays in Unix on the >>> PDP-11, using them on the Unix side is basically a no brainer. You don't >>> need to do anything at all. You just put modules wherever you want to,
and it works.
With the DEC OSes, you have to create an overlay description in a weird
language, and you can't call cross overlay trees, and you need to be
careful if you call upstream, which might change mapping, and all that.
None of those restrictions apply for Unix overlays. The only thing you
need to keep an eye out for is just that the size is kept within some
rules.
˙˙ Johnny
Since you've done it, I defer.˙ I just recall that when we got 2.9BSD, I
considered trying to port some big Vax program to the 11 and from reading
the man pages I got the impression I would have to get intimately
familiar
with said program's call graph (which I definitely was not) to partition
out the overlays and ended up moving on to something else.
You can basically just take the different object files, and put them
into different overlays, and that's it. No need to think anything over
with call graphs or anything. You do get headaches if individual object files are just huge, of course. And total data cannot be more than 64K.
It's only code that is overlaid. But compared to the DEC overlay scheme, it's really simple.
With the DEC stuff, you do need to keep track of call graphs, and stuff. Also, it is done in it's own language, which in itself is also a bit of
a thing to get in to. But you can do a lot of stuff with the DEC overlay stuff that isn't at all possible to do under Unix.
So it's a tradeoff (as usual).
˙ Johnny
The Linux kernel offers something similar, but again that assumes that keyboard handling (or alternatively, serial port handling) is still functioning <https://docs.kernel.org/admin-guide/sysrq.html>.
On 2025-08-30 06:25, c186282 wrote:
˙ "Reset" buttons are mostly good, but on the company
˙ servers I always disconnected those, so no dink could
˙ just accidentally bump into the switch while looking
˙ for something else. REAL power switch, like a 3-sec
˙ delay before anything happens.
Some reset buttons have to be pressed deep to work.
On 8/31/25 03:40, Johnny Billquist wrote:
On 2025-08-30 19:39, Ted Nolan <tednolan> wrote:
In article <108uhef$26t$1@news.misty.com>,
Johnny Billquist˙ <bqt@softjar.se> wrote:
As for ease of use, you got it backward. While overlays in DEC OSes
actually are way more advanced, and capable that overlays in Unix on
the
PDP-11, using them on the Unix side is basically a no brainer. You
don't
need to do anything at all. You just put modules wherever you want to, >>>> and it works.
With the DEC OSes, you have to create an overlay description in a weird >>>> language, and you can't call cross overlay trees, and you need to be
careful if you call upstream, which might change mapping, and all that. >>>> None of those restrictions apply for Unix overlays. The only thing you >>>> need to keep an eye out for is just that the size is kept within
some rules.
˙˙ Johnny
Since you've done it, I defer.˙ I just recall that when we got 2.9BSD, I >>> considered trying to port some big Vax program to the 11 and from
reading
the man pages I got the impression I would have to get intimately
familiar
with said program's call graph (which I definitely was not) to partition >>> out the overlays and ended up moving on to something else.
You can basically just take the different object files, and put them
into different overlays, and that's it. No need to think anything over
with call graphs or anything. You do get headaches if individual
object files are just huge, of course. And total data cannot be more
than 64K. It's only code that is overlaid. But compared to the DEC
overlay scheme, it's really simple.
With the DEC stuff, you do need to keep track of call graphs, and
stuff. Also, it is done in it's own language, which in itself is also
a bit of a thing to get in to. But you can do a lot of stuff with the
DEC overlay stuff that isn't at all possible to do under Unix.
So it's a tradeoff (as usual).
˙˙ Johnny
Sort of. Assuming overlays on DEC function like all others I've seen,
you need to organize. What goes into the root? (used by all overlays),
then group object files so that things used together are in the same overlay.
On 2025-08-31 01:34, Rich Alderson wrote:
That's with experience on OS/360, SVS and MVS on /370, Tops-10 and
TOPS-20, and
RSX-11M/-20F.
Overlays are like a coyote ugly bed partner:˙ I'd rather chew my arm off.
I know where you're coming from, Rich. And for the overlay
functionality, and how to use it, on DEC OSes, I sortof agree with you.
They are not easy.
The overlay scheme/technology in Unix, while not as capable, are dead
easy to use.
On my very first PC (80386DX CPU clocked at a blistering 40 MHz), the
desktop case had the reset button right next to the turbo button and of course they looked identical except for the text label above them. Nice
big flat buttons too, flush with the case surface, so easy to press. Thankfully, I usually didn't need the turbo button.
Most later machines of mine had the reset button recessed making it much harder to press by accident.
On Sun, 31 Aug 2025 18:23:23 +0200, Alexander Schreiber wrote:
On my very first PC (80386DX CPU clocked at a blistering 40 MHz), the
desktop case had the reset button right next to the turbo button and of
course they looked identical except for the text label above them. Nice
big flat buttons too, flush with the case surface, so easy to press.
Thankfully, I usually didn't need the turbo button.
Most later machines of mine had the reset button recessed making it much
harder to press by accident.
I can see the one contrarian interoffice memo now:
“Why not recess the turbo button instead, and make it harder to press? Because it can cause compatibility problems with older software designed
to run only at a CPU speed of 4.77MHz, so the user should think twice
before pressing it. The reset button should be easier to press, because
when you need it, you really need it!”
;)
On 2025-08-30 01:34, Lawrence D’Oliveiro wrote:
Using overlays was never straightforward, on any OS.
It was trivial on Turbo Pascal.
scott@slp53.sl.home (Scott Lurndal) writes:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
Using overlays was never straightforward, on any OS.
Typical troll comment.
There are existance proofs counter to your unsupported blanket statement.
Burroughs medium systems for example, where using overlays was built into the
compilation tools (including the COBOL compiler) and the operating system. >> Even the operating system used overlays for rarely used functionality.
Far be it from me to defend the troll, but I will say that my experience (56 years and counting) agrees with his comment.
IIRC, I have made changes to exactly one (1) overlaid program in all that time,
having been forced to do that instead of a complete rewrite because it had to work quickly at the museum.
That's with experience on OS/360, SVS and MVS on /370, Tops-10 and TOPS-20, and
RSX-11M/-20F.
Overlays are like a coyote ugly bed partner: I'd rather chew my arm off.
On Sun, 31 Aug 2025 13:44:17 +0200, Carlos E.R. wrote:
On 2025-08-30 01:34, Lawrence D’Oliveiro wrote:
Using overlays was never straightforward, on any OS.
It was trivial on Turbo Pascal.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did Turbo Pascal use?
On OS/360 in Cobol, overlays were easy.
On Sun, 31 Aug 2025 13:44:17 +0200, Carlos E.R. wrote:
On 2025-08-30 01:34, Lawrence D’Oliveiro wrote:
Using overlays was never straightforward, on any OS.
It was trivial on Turbo Pascal.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did Turbo Pascal use?
On 8/31/25 10:36 PM, Lawrence D’Oliveiro wrote:
On Sun, 31 Aug 2025 13:44:17 +0200, Carlos E.R. wrote:
On 2025-08-30 01:34, Lawrence D’Oliveiro wrote:
Using overlays was never straightforward, on any OS.
It was trivial on Turbo Pascal.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did Turbo Pascal use?
˙ I bought v1.x ... and then on. Best money I ever
˙ spent. DID need overlays for a large pgm in v3.x -
˙ something between a graphic and mini-GIS app.
˙ STILL use FPC/Lazarus fairly often. GREAT language.
˙ And, unlike 'C', you can actually kind of read and
˙ understand your own code years later :-)
˙ And the overlays WERE super easy. WERE limited
˙ to 64k however. The older TPs came for both x86/DOS
˙ and CP/M-86. Similar, though not quite identical,
˙ tricks and solutions.
˙ Foley & Van Dam - "Fundamentals Of Interactive
˙ Computer Graphics" - has all the good algos
˙ (IN Pascal).
˙ Hey, did use the M$/IBM multi-pass Pascal compiler
˙ (still have it in a VM somewhere) but TP was just
˙ a *revolution*. Even found a good use for the
˙ 'turtle' in v3.x
In alt.folklore.computers Rich <rich@example.invalid> wrote:
In comp.os.linux.misc c186282 <c186282@nnada.net> wrote:
... REAL power switch, like a 3-sec
delay before anything happens.
Only for ATX PSU based machines. The old AT PSU spec had the power
switch as an actual switch that interrupted mains power.
Granted, few remember AT PSU based systems anymore, and even fewer of
them are still in service.
Many PC have real power switch. There is software controlled one at
the front and real one built into the power supply.
On 2025-09-01 00:24, Lawrence D’Oliveiro wrote:
On Sun, 31 Aug 2025 18:23:23 +0200, Alexander Schreiber wrote:
On my very first PC (80386DX CPU clocked at a blistering 40 MHz), the
desktop case had the reset button right next to the turbo button and of
course they looked identical except for the text label above them. Nice
big flat buttons too, flush with the case surface, so easy to press.
Thankfully, I usually didn't need the turbo button.
Most later machines of mine had the reset button recessed making it much >>> harder to press by accident.
I can see the one contrarian interoffice memo now:
“Why not recess the turbo button instead, and make it harder to press?
Because it can cause compatibility problems with older software designed
to run only at a CPU speed of 4.77MHz, so the user should think twice
before pressing it. The reset button should be easier to press, because
when you need it, you really need it!”
;)
Wow! :-(
On 8/31/25 10:36 PM, Lawrence D’Oliveiro wrote:
On Sun, 31 Aug 2025 13:44:17 +0200, Carlos E.R. wrote:
On 2025-08-30 01:34, Lawrence D’Oliveiro wrote:
Using overlays was never straightforward, on any OS.
It was trivial on Turbo Pascal.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did Turbo Pascal use?
˙ I bought v1.x ... and then on. Best money I ever
˙ spent. DID need overlays for a large pgm in v3.x -
˙ something between a graphic and mini-GIS app.
˙ STILL use FPC/Lazarus fairly often. GREAT language.
˙ And, unlike 'C', you can actually kind of read and
˙ understand your own code years later :-)
˙ And the overlays WERE super easy. WERE limited
˙ to 64k however. The older TPs came for both x86/DOS
˙ and CP/M-86. Similar, though not quite identical,
˙ tricks and solutions.
˙ Foley & Van Dam - "Fundamentals Of Interactive
˙ Computer Graphics" - has all the good algos
˙ (IN Pascal).
˙ Hey, did use the M$/IBM multi-pass Pascal compiler
˙ (still have it in a VM somewhere) but TP was just
˙ a *revolution*. Even found a good use for the
˙ 'turtle' in v3.x
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:
Oops, I forgot about that. They did make a comeback, didn't they?
But there definitely was a period before that where the button vanished
(although there would have been motherboard pins if you wanted to dig
into it).
I think reset buttons may have vanished from branded PCs or maybe those
never had them? IBM probably didn't. OTOH, the PC cases I've bought have always come with a reset button (since about 1990) and all motherboards
I've bought have had pins where to connect said button. I don't think
I've ever had a laptop with a reset button though.
On Sun, 31 Aug 2025 23:00:26 -0400, geodandw wrote:
On OS/360 in Cobol, overlays were easy.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did COBOL use?
On 8/31/25 22:52, c186282 wrote:
On 8/31/25 10:36 PM, Lawrence D’Oliveiro wrote:
On Sun, 31 Aug 2025 13:44:17 +0200, Carlos E.R. wrote:
On 2025-08-30 01:34, Lawrence D’Oliveiro wrote:
Using overlays was never straightforward, on any OS.
It was trivial on Turbo Pascal.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did Turbo Pascal use?
˙˙ I bought v1.x ... and then on. Best money I ever
˙˙ spent. DID need overlays for a large pgm in v3.x -
˙˙ something between a graphic and mini-GIS app.
˙˙ STILL use FPC/Lazarus fairly often. GREAT language.
˙˙ And, unlike 'C', you can actually kind of read and
˙˙ understand your own code years later :-)
˙˙ And the overlays WERE super easy. WERE limited
˙˙ to 64k however. The older TPs came for both x86/DOS
˙˙ and CP/M-86. Similar, though not quite identical,
˙˙ tricks and solutions.
˙˙ Foley & Van Dam - "Fundamentals Of Interactive
˙˙ Computer Graphics" - has all the good algos
˙˙ (IN Pascal).
˙˙ Hey, did use the M$/IBM multi-pass Pascal compiler
˙˙ (still have it in a VM somewhere) but TP was just
˙˙ a *revolution*. Even found a good use for the
˙˙ 'turtle' in v3.x
I don't think I ever used TP, but I did use Turbo-C. Borland had great software, much better than any of its successors,
On 8/31/25 22:46, Lawrence D’Oliveiro wrote:
On Sun, 31 Aug 2025 23:00:26 -0400, geodandw wrote:
On OS/360 in Cobol, overlays were easy.
There were two kinds of overlay system: the one where the calling code
could be swapped out while the called code (needing a possible segment
swap when returning from the callee) and the one where it couldn’t
(needing more memory).
Which one did COBOL use?
https://en.wikipedia.org/wiki/Overlay_(programming) - see example.
Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 03:27 this Saturday (GMT):
On Fri, 29 Aug 2025 23:51:18 GMT, Charlie Gibbs wrote:
But there definitely was a period before that where the button vanished
(although there would have been motherboard pins if you wanted to dig
into it).
Apple included a little springy clip thing (the “Programmers’s Switch”) in
the box with each of those original classic-form-factor Macintoshes. When >> installed, pressing one side triggered NMI (used for invoking the resident >> debugger), while the other side triggered the RESET line (hard reboot).
I still have the muscle memory: seated in front of the machine, reach
around with right hand, far side was NMI, near side was RESET.
That's pretty cool, I always wished there was a physical switch to
trigger a debugger since the system might be frozen...
On 8/30/25 08:54, Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 29 Aug 2025 20:52:10 GMT, Ted Nolan <tednolan> wrote:
Using overlays was never straightforward, on any OS.
Typical troll comment.
There are existance proofs counter to your
unsupported blanket statement.
Burroughs medium systems for example, where using overlays was built
into the compilation tools (including the COBOL compiler) and the
operating system. Even the operating system used overlays for
rarely used functionality.
OS/360 and applications made extensive use of overlays.
I remember a (PC)-Dos application called "Enable" that overlayed like crazy.
It was typical to low-ball memory requirements to get a sale, then
sell the customer more memory afterwards when the system turned out
to be painfully slow and it was too late to back out.
On 2025-08-30, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 03:27 this Saturday (GMT): >>
On Fri, 29 Aug 2025 23:51:18 GMT, Charlie Gibbs wrote:
But there definitely was a period before that where the button vanished >>>> (although there would have been motherboard pins if you wanted to dig
into it).
Apple included a little springy clip thing (the “Programmers’s Switch”) in
the box with each of those original classic-form-factor Macintoshes. When >>> installed, pressing one side triggered NMI (used for invoking the resident >>> debugger), while the other side triggered the RESET line (hard reboot).
That's pretty cool, I always wished there was a physical switch to
trigger a debugger since the system might be frozen...
And that, ladies and gentlemen, is why you want a reset button
rather than having to resort to the power switch.
On 2025-08-30, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 03:27 this Saturday (GMT): >>
On Fri, 29 Aug 2025 23:51:18 GMT, Charlie Gibbs wrote:
But there definitely was a period before that where the button vanished >>>> (although there would have been motherboard pins if you wanted to dig
into it).
Apple included a little springy clip thing (the “Programmers’s Switch”) in
the box with each of those original classic-form-factor Macintoshes. When >>> installed, pressing one side triggered NMI (used for invoking the resident >>> debugger), while the other side triggered the RESET line (hard reboot).
I still have the muscle memory: seated in front of the machine, reach
around with right hand, far side was NMI, near side was RESET.
That's pretty cool, I always wished there was a physical switch to
trigger a debugger since the system might be frozen...
And that, ladies and gentlemen, is why you want a reset button
rather than having to resort to the power switch.
On Tue, 02 Sep 2025 21:22:36 GMT, Charlie Gibbs wrote:
On 2025-08-30, candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote:
Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 03:27 this Saturday (GMT): >>>
On Fri, 29 Aug 2025 23:51:18 GMT, Charlie Gibbs wrote:That's pretty cool, I always wished there was a physical switch to
But there definitely was a period before that where the button vanished >>>>> (although there would have been motherboard pins if you wanted to dig >>>>> into it).
Apple included a little springy clip thing (the “Programmers’s Switch”) in
the box with each of those original classic-form-factor Macintoshes. When >>>> installed, pressing one side triggered NMI (used for invoking the resident
debugger), while the other side triggered the RESET line (hard reboot). >>>
trigger a debugger since the system might be frozen...
And that, ladies and gentlemen, is why you want a reset button
rather than having to resort to the power switch.
Interrupt button, surely.
On Tue, 02 Sep 2025 21:22:39 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
It was typical to low-ball memory requirements to get a sale, then
sell the customer more memory afterwards when the system turned out
to be painfully slow and it was too late to back out.
...whereas nowadays, we have to recommend our customers spec out twice
the memory they'd actually need as between Win10/11, the nine million
browser tabs everyone keeps open at all times, vendor bloatware, and
special gold-medal memory hogs like QuickBooks, an entry-level system
is full to bursting and swapping madly before they even load *our* >application...
...and half the damn time they buy the entry-level system anyway, and
then complain about *our* software being slow :/
On 2025-09-02, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
On Tue, 02 Sep 2025 21:22:36 GMT, Charlie Gibbs wrote:
On 2025-08-30, candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote:
Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 03:27 this Saturday (GMT): >>>>
On Fri, 29 Aug 2025 23:51:18 GMT, Charlie Gibbs wrote:That's pretty cool, I always wished there was a physical switch to
But there definitely was a period before that where the button vanished >>>>>> (although there would have been motherboard pins if you wanted to dig >>>>>> into it).
Apple included a little springy clip thing (the “Programmers’s Switch”) in
the box with each of those original classic-form-factor Macintoshes. When
installed, pressing one side triggered NMI (used for invoking the resident
debugger), while the other side triggered the RESET line (hard reboot). >>>>
trigger a debugger since the system might be frozen...
And that, ladies and gentlemen, is why you want a reset button
rather than having to resort to the power switch.
Interrupt button, surely.
Maybe we need a series of buttons in a row, e.g. NMI, reset, power...
And don't call me Shirley.
"What would YOU do with 128 GiB of RAM, Dan?"
"Run two electron apps at the same time...."
In alt.folklore.computers Kerr-Mudd, John <admin@127.0.0.1> wrote:
On Wed, 27 Aug 2025 16:40:27 +0200
Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
[]
I haven't tried Unix on 8086, but DOS on x86 essentially relied on applications
being reasonably correct and not too buggy. Having the reset button conveniently
accessible was effectively a requirement for any DOS PC ;-)
Unix on an early IBM PC (8086, 10M hard drive) would have been quite a shoehorning job. 'Slow' would probably be a generous word to use.
That reminds me to check on how:
https://github.com/ghaerr/elks
is doing. Still seems to be alive and kicking, most recent release in October.
Fits in 512KB of RAM on an 8086 and uses a single floppy.
Of course it's Linux(ish) and not Unix.
On 2025-09-04, Rich <rich@example.invalid> wrote:
For the pre ATX PSU's (AT PSU's), the physical power switch that interrupted mains power was the switch that was mounted in the front of the case that user's used to turn on/off the machine.
I saw some machines where the actual switch was in the power supply
at the back of the machine, but it was activated via a long rod that
ended in a button on the front panel.
On Thu, 04 Sep 2025 18:38:23 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
On 2025-09-04, Rich <rich@example.invalid> wrote:
For the pre ATX PSU's (AT PSU's), the physical power switch that
interrupted mains power was the switch that was mounted in the front of
the case that user's used to turn on/off the machine.
I saw some machines where the actual switch was in the power supply
at the back of the machine, but it was activated via a long rod that
ended in a button on the front panel.
PS2 ?
https://en.wikipedia.org/wiki/IBM_PS/2_Model_30#/media/File:IBM_PS-2_Model_30_286_open_top.jpg
rbowman <bowman@montana.com> writes:
On Thu, 04 Sep 2025 18:38:23 GMT, Charlie Gibbs wrote:
On 2025-09-04, Rich <rich@example.invalid> wrote:
For the pre ATX PSU's (AT PSU's), the physical power switch that
interrupted mains power was the switch that was mounted in the front of >>>> the case that user's used to turn on/off the machine.
I saw some machines where the actual switch was in the power supply at
the back of the machine, but it was activated via a long rod that ended
in a button on the front panel.
All I know is at some point the power button on front of the box would
turn the machine on. Pushing it again was a mild suggestion that the
machine shut down if it felt like it. The cord was usually easier to find
when groping around than the toggle on the PS.
The firmware has managed the power switch for the last couple of
decades. The OS can arrange with the SMM firmware (through ACPI) to
manage the power button to ensure that on-disk state remains
consistent by shutting down the applications and operating systems
cleanly.
Works pretty well with Linux. Some windows applications have not,
in the past, played well with soft power switches, and some
BIOS implementations have been sub-par, to put it kindly.
To put it kindly .........
-IX has become better at dealing with soft-shutdown than Win.
On Fri, 5 Sep 2025 05:08:43 -0400
c186282 <c186282@nnada.net> wrote:
To put it kindly .........
-IX has become better at dealing with soft-shutdown than Win.
Win10 started playing all kinds of games with true shutdown vs. some
kind of "deep suspend" - I'm pretty sure they were trying to improve
"boot time" without actually having to *improve boot time,* but it was immensely counterproductive since NT has always leaked memory like a
sieve and a full reboot is the only way to clear it up. I think they
walked back some of the shenanigans in later updates, but on early
revisions of 10 it was practically impossible to get it to perform a
clean shutdown without holding in the power button 'til the machine
itself cut out, though invoking shutdown from the command line
sometimes seemed to work.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 14 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 135:01:23 |
| Calls: | 185 |
| Calls today: | 1 |
| Files: | 21,502 |
| Messages: | 82,193 |
