According to Johnny Billquist <bqt@softjar.se>:
The claim has another problem. While an x86 might be considered more >>powerful in some ways, it does not have nearly as capably MMU as the >>PDP-11,
The 8086 had no MMU at all, but small model code gave you 64K each of instructions and data, the same as what the 11's MMU gave you. There was no hardware protection so a malicious or badly broken program could crash the system but they rarely did.
That would require instructions that the C compiler
didn't generate.
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't
generate" is just not true. Without memory protection, there are
plenty of ways to crash the system - e.g. overwriting the operating
system code due to a bug in an application.
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 ;-)
I haven't tried Unix on 8086 ...
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.
John Levine <johnl@taugh.com> wrote:
According to Johnny Billquist <bqt@softjar.se>:
The claim has another problem. While an x86 might be considered more
powerful in some ways, it does not have nearly as capably MMU as the
PDP-11,
The 8086 had no MMU at all, but small model code gave you 64K each of
instructions and data, the same as what the 11's MMU gave you. There was no >> hardware protection so a malicious or badly broken program could crash the >> system but they rarely did.
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 ;-)
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate" is just not true. Without memory protection, there are plenty of ways to crash
the system - e.g. overwriting the operating system code due to a bug in an application.
Kind regards,
Alex.
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.
On Wed, 27 Aug 2025 16:40:27 +0200
Alexander Schreiber <als@usenet.thangorodrim.de> wrote:
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't
generate" is just not true. Without memory protection, there are
plenty of ways to crash the system - e.g. overwriting the operating
system code due to a bug in an application.
It's certainly true that there's no *real* protection on the 8086.
AFAIUI the logic is that, if generated code doesn't touch the segment registers and the OS allocates either 64KB shared or 64KB code + 64KB
data, a 16-bit address won't ever overstep into the next 64KB of RAM,
but x86 addressing can have up to three 16-bit components (two index registers plus a fixed offset,) so it's entirely possible for basic addressing operations to overstep that boundary, unless the compiler
just forgoes complex addressing entirely.
On 8/27/25 10:40 AM, Alexander Schreiber wrote:
John Levine <johnl@taugh.com> wrote:
According to Johnny Billquist˙ <bqt@softjar.se>:
The claim has another problem. While an x86 might be considered more
powerful in some ways, it does not have nearly as capably MMU as the
PDP-11,
The 8086 had no MMU at all, but small model code gave you 64K each of
instructions and data, the same as what the 11's MMU gave you. There
was no
hardware protection so a malicious or badly broken program could
crash the
system but they rarely did.
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 ;-)
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't
generate"
is just not true. Without memory protection, there are plenty of ways
to crash
the system - e.g. overwriting the operating system code due to a bug
in an
application.
Kind regards,
˙˙˙˙˙˙˙˙˙˙˙ Alex.
˙ In any case there WERE "Unix Variants" even for the
˙ early x86 IBM-PCs. M$ sold Xenix, a bit later there
˙ was SCO Unix.
˙ The old 8088 was NOT super good for -IX systems but
˙ they DID make them (sort of) work. The 386 was much
˙ better, but that was some years later. I still
˙ remember the PCs coming with a DOS and CP/M-86
˙ floppy. Choose.
˙ My old boss and I debated about dedicating The Company
˙ to DOS or Unix. For sure Unix was generally "better",
˙ but alas NOT well suited to all the hardware we had.
˙ SO, in the end, it was DOS/Win. Many MANY more apps
˙ for DOS/Win ... so, in retrospect .......
˙ Later, M$ went Dark Side .....
˙ DID find an old Xenix on an antique software site.
˙ It's *41* floppies worth. Kept it, but not sure if
˙ I'll ever make a VM out of it. Interest/energy
˙ kinda compete :-)
On 8/28/25 00:26, c186282 wrote:
In any case there WERE "Unix Variants" even for the early x86
IBM-PCs.
Minix
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 ;-)
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate" is just not true. Without memory protection, there are plenty of ways to crash
the system - e.g. overwriting the operating system code due to a bug in an application.
On 2025-08-27, 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 ;-)
Unfortunately, at about that time the reset button vanished (probably due
to the DMCA or whatever preceded it).
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate" >> is just not true. Without memory protection, there are plenty of ways to crash
the system - e.g. overwriting the operating system code due to a bug in an >> application.
If you didn't want to live entirely in a 64K segment, though, you probably told your C compiler to generate code for the various larger memory modules, which gave you the ability to scribble over the entire 640K (plus system storage).
On 2025-08-27, 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 ;-)
Unfortunately, at about that time the reset button vanished (probably due
to the DMCA or whatever preceded it).
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate" >> is just not true. Without memory protection, there are plenty of ways to crash
the system - e.g. overwriting the operating system code due to a bug in an >> application.
If you didn't want to live entirely in a 64K segment, though, you probably told your C compiler to generate code for the various larger memory modules, which gave you the ability to scribble over the entire 640K (plus system storage).
On 2025-08-27, 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 ;-)
Unfortunately, at about that time the reset button vanished (probably due
to the DMCA or whatever preceded it).
Really? System boards bought this year still have a reset line and my workstation tower case (about 10-15y old now) still has a reset button.
PCs bought in the 1990s and 2000s still tended to have nicely accessible reset buttons. Not that hiding the reset button would help, when one can
just flip the power.
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate" >> is just not true. Without memory protection, there are plenty of ways to crash
the system - e.g. overwriting the operating system code due to a bug in an >> application.
If you didn't want to live entirely in a 64K segment, though, you probably >told your C compiler to generate code for the various larger memory modules,
According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>:PDP I worked on was 64k code, 64k data/stack
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate" >>> is just not true. Without memory protection, there are plenty of ways to crash
the system - e.g. overwriting the operating system code due to a bug in an >>> application.
If you didn't want to live entirely in a 64K segment, though, you probably >> told your C compiler to generate code for the various larger memory modules,
Not the PC/IX compiler. It was small mode only, which was plenty to compile all of the PDP-11 source code. x86 object code was a little smaller than PDP-11 code, the data would have been thes same size.
We got complaints from people who wanted to be able to run larger programs. Sorry, doesn't do that, you can use several processes talking though pipes.
According to Johnny Billquist <bqt@softjar.se>:
The claim has another problem. While an x86 might be considered more
powerful in some ways, it does not have nearly as capably MMU as the
PDP-11,
The 8086 had no MMU at all, but small model code gave you 64K each of instructions and data, the same as what the 11's MMU gave you. There was no hardware protection so a malicious or badly broken program could crash the system but they rarely did. That would require instructions that the C compiler
didn't generate.
I worked on PC/IX which was a straightforward port of PDP-11 System III Unix to
the PC. It wasn't particularly fast, but all the C programs that ran on the 11
also ran on PC/IX. It was quite reliable. I recall that we got a bug report about something that only broke if the system had been up continuously for a year.
On Fri, 29 Aug 2025 12:46:49 +0200, Alexander Schreiber wrote:
Really? System boards bought this year still have a reset line and my
workstation tower case (about 10-15y old now) still has a reset button.
PCs bought in the 1990s and 2000s still tended to have nicely accessible
reset buttons. Not that hiding the reset button would help, when one can
just flip the power.
The original PC didn't have one. I remember fitting one to mine!
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.
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...
On 29/08/2025 18:09, John Levine wrote:
According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>:PDP I worked on was 64k code, 64k data/stack
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate"
is just not true. Without memory protection, there are plenty of ways to >>>> crash the system - e.g. overwriting the operating system code due to a bug >>>> in an application.
If you didn't want to live entirely in a 64K segment, though, you probably >>> told your C compiler to generate code for the various larger memory modules,
Not the PC/IX compiler. It was small mode only, which was plenty to compile >> all of the PDP-11 source code. x86 object code was a little smaller than
PDP-11 code, the data would have been thes same size.
We got complaints from people who wanted to be able to run larger programs. >> Sorry, doesn't do that, you can use several processes talking though pipes.
C was designed for that
My PC compilers could do large model. But oit wasnt really worth it
until the 386 came along
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).
Given the rock-solid stability and reliability of the MS-DOS environment
and its applications *cough* *cough* that sounds like an interesting
design oversight.
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.
On Fri, 29 Aug 2025 23:51:17 GMT, Charlie Gibbs wrote:
It was for us. We needed all that memory. It was only a few years ago
that I finally got rid of all the hacks I wrote in to normalize pointers
and deal with segment wrap-arounds. It was horrible. Forget the 640K
barrier - the 64K barrier was alive and well on the 8086/8088/80286.
Tiny, Small, Large, Bigger & Humongous. I have the names wrong but I'm
pretty sure there were 5 sets of libraries that you had to chose to do a build. Then there was what was referred to as the 'thunk' in DJGPP circles when you need to get real.
On 2025-08-29, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 29/08/2025 18:09, John Levine wrote:
According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>:
That would require instructions that the C compiler
didn't generate.
That claim "would require instructions that the C compiler didn't generate"
is just not true. Without memory protection, there are plenty of ways to >>>>> crash the system - e.g. overwriting the operating system code due to a bug
in an application.
If you didn't want to live entirely in a 64K segment, though, you probably >>>> told your C compiler to generate code for the various larger memory modules,
Not the PC/IX compiler. It was small mode only, which was plenty to compile
all of the PDP-11 source code. x86 object code was a little smaller than >>> PDP-11 code, the data would have been thes same size.
We got complaints from people who wanted to be able to run larger programs. >>> Sorry, doesn't do that, you can use several processes talking though pipes. >> PDP I worked on was 64k code, 64k data/stack
C was designed for that
My PC compilers could do large model. But oit wasnt really worth it
until the 386 came along
It was for us. We needed all that memory. It was only a few years ago
that I finally got rid of all the hacks I wrote in to normalize pointers
and deal with segment wrap-arounds. It was horrible. Forget the 640K barrier - the 64K barrier was alive and well on the 8086/8088/80286.
On 8/30/25 1:54 AM, rbowman wrote:
On Fri, 29 Aug 2025 23:51:17 GMT, Charlie Gibbs wrote:
It was for us.˙ We needed all that memory.˙ It was only a few years ago
that I finally got rid of all the hacks I wrote in to normalize pointers >>> and deal with segment wrap-arounds.˙ It was horrible.˙ Forget the 640K
barrier - the 64K barrier was alive and well on the 8086/8088/80286.
Tiny, Small, Large, Bigger & Humongous. I have the names wrong but I'm
pretty sure there were 5 sets of libraries that you had to chose to do a
build. Then there was what was referred to as the 'thunk' in DJGPP
circles
when you need to get real.
˙ Tbe original 8088 had all the needed registers.
˙ Could minimum deliver at LEAST an easy 64k code
˙ space and at LEAST another 64k data area. A few
˙ tricks and .......
˙ So YEA - you COULD run some kind of -IX on
˙ the original PCs. Not super fast/efficient
˙ but it COULD work. Remember early versions
˙ of SCO.
˙ 286/386 ... MUCH better - but it came LATER.
On 30/08/2025 08:06, c186282 wrote:
On 8/30/25 1:54 AM, rbowman wrote:
On Fri, 29 Aug 2025 23:51:17 GMT, Charlie Gibbs wrote:
It was for us.˙ We needed all that memory.˙ It was only a few years ago >>>> that I finally got rid of all the hacks I wrote in to normalize
pointers
and deal with segment wrap-arounds.˙ It was horrible.˙ Forget the 640K >>>> barrier - the 64K barrier was alive and well on the 8086/8088/80286.
Tiny, Small, Large, Bigger & Humongous. I have the names wrong but I'm
pretty sure there were 5 sets of libraries that you had to chose to do a >>> build. Then there was what was referred to as the 'thunk' in DJGPP
circles
when you need to get real.
˙˙ Tbe original 8088 had all the needed registers.
˙˙ Could minimum deliver at LEAST an easy 64k code
˙˙ space and at LEAST another 64k data area. A few
˙˙ tricks and .......
˙˙ So YEA - you COULD run some kind of -IX on
˙˙ the original PCs. Not super fast/efficient
˙˙ but it COULD work. Remember early versions
˙˙ of SCO.
˙˙ 286/386 ... MUCH better - but it came LATER.
The big trouble was that Unix was expanding faster than the PC
architecture could handle until the 386 made it all easy.
Then SCO Unix made it all not just possible, but extremely handy.
But we never got a serious graphical user interface on Unix. By the time
X windows had stabilised and cent window managers evolved Linux had
arrived.
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. Basically, programs can be
way larger than 64K code. You can place functions in different overlays,
and call between them, and you can run up to many hundred of K of code
very easy and straight forward on the PDP-11, and it's all because the
MMU helps you out with it, moving the pages mapping around as needed.
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...
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 8/30/25 3:28 AM, The Natural Philosopher wrote:
On 30/08/2025 08:06, c186282 wrote:
On 8/30/25 1:54 AM, rbowman wrote:
On Fri, 29 Aug 2025 23:51:17 GMT, Charlie Gibbs wrote:
It was for us.˙ We needed all that memory.˙ It was only a few years >>>>> ago
that I finally got rid of all the hacks I wrote in to normalize
pointers
and deal with segment wrap-arounds.˙ It was horrible.˙ Forget the 640K >>>>> barrier - the 64K barrier was alive and well on the 8086/8088/80286.
Tiny, Small, Large, Bigger & Humongous. I have the names wrong but I'm >>>> pretty sure there were 5 sets of libraries that you had to chose to
do a
build. Then there was what was referred to as the 'thunk' in DJGPP
circles
when you need to get real.
˙˙ Tbe original 8088 had all the needed registers.
˙˙ Could minimum deliver at LEAST an easy 64k code
˙˙ space and at LEAST another 64k data area. A few
˙˙ tricks and .......
˙˙ So YEA - you COULD run some kind of -IX on
˙˙ the original PCs. Not super fast/efficient
˙˙ but it COULD work. Remember early versions
˙˙ of SCO.
˙˙ 286/386 ... MUCH better - but it came LATER.
The big trouble was that Unix was expanding faster than the PC
architecture could handle until the 386 made it all easy.
˙ Agreed.
Then SCO Unix made it all not just possible, but extremely handy.
˙ Well ... not "handy" enough.
˙ My boss at the time - a very smart nerd - and I did
˙ discuss DOS -vs- Unix for The Outfit.
˙ We eventually decided on DOS, and ultimately Win.
˙ MORE stuff. MORE support.
But we never got a serious graphical user interface on Unix. By the
time X windows had stabilised and cent window managers evolved Linux
had arrived.
˙ Hey, DEALT with 'X' and WMs on the first versions
˙ of Linux you could get. NOT super-easy all the time.
˙ Spent like 48 hours getting it to rec my damned mouse
˙ with RH.
˙ NOT encouraging.
˙ However Linux GOT BETTER. Soon I had all the needed
˙ office servers on Linux - Just Because.
˙ But, alas, the Staff - Winders Forever And Always.
˙ Typical "split environment".
On 8/29/25 11:27 PM, Lawrence D’Oliveiro wrote:
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.
Hmmm ... how did they implement that ? How did it
differ from just using the power switch ???
In THEORY that kind of 'reset' SHOULD include at
least ATTEMPTS to shut down a few important daemons.
MOST important, the HDD cache ... DO try yer best
to write-out the cache before going off.
"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 30/08/2025 10:30, c186282 wrote:
On 8/30/25 3:28 AM, The Natural Philosopher wrote:
On 30/08/2025 08:06, c186282 wrote:
On 8/30/25 1:54 AM, rbowman wrote:
On Fri, 29 Aug 2025 23:51:17 GMT, Charlie Gibbs wrote:
It was for us.˙ We needed all that memory.˙ It was only a fewTiny, Small, Large, Bigger & Humongous. I have the names wrong but I'm >>>>> pretty sure there were 5 sets of libraries that you had to chose to >>>>> do a
years ago
that I finally got rid of all the hacks I wrote in to normalize
pointers
and deal with segment wrap-arounds.˙ It was horrible.˙ Forget the >>>>>> 640K
barrier - the 64K barrier was alive and well on the 8086/8088/80286. >>>>>
build. Then there was what was referred to as the 'thunk' in DJGPP
circles
when you need to get real.
˙˙ Tbe original 8088 had all the needed registers.
˙˙ Could minimum deliver at LEAST an easy 64k code
˙˙ space and at LEAST another 64k data area. A few
˙˙ tricks and .......
˙˙ So YEA - you COULD run some kind of -IX on
˙˙ the original PCs. Not super fast/efficient
˙˙ but it COULD work. Remember early versions
˙˙ of SCO.
˙˙ 286/386 ... MUCH better - but it came LATER.
The big trouble was that Unix was expanding faster than the PC
architecture could handle until the 386 made it all easy.
˙˙ Agreed.
Then SCO Unix made it all not just possible, but extremely handy.
˙˙ Well ... not "handy" enough.
˙˙ My boss at the time - a very smart nerd - and I did
˙˙ discuss DOS -vs- Unix for The Outfit.
˙˙ We eventually decided on DOS, and ultimately Win.
˙˙ MORE stuff. MORE support.
I was the boss. SCO Unix for the networked servers and Win 3 for the desktops
SUN PC-NFS to hang it all together.
I waited. By around 2003 Debian had some sort of GUIBut we never got a serious graphical user interface on Unix. By the
time X windows had stabilised and cent window managers evolved Linux
had arrived.
˙˙ Hey, DEALT with 'X' and WMs on the first versions
˙˙ of Linux you could get. NOT super-easy all the time.
˙˙ Spent like 48 hours getting it to rec my damned mouse
˙˙ with RH.
˙˙ NOT encouraging.
˙˙ However Linux GOT BETTER. Soon I had all the neededYup. Of course
˙˙ office servers on Linux - Just Because.
˙˙ But, alas, the Staff - Winders Forever And Always.
˙˙ Typical "split environment".
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.
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.
In article <108vigs$2q3n5$1@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:
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.
I remember that one -- I had to do printer support over PC-NFS with a filter to convert the Diablo-630 emulation to something the network printer could use. The people actually using the program called it "Unable".
Lawrence D’Oliveiro <ldo@nz.invalid> wrote at 03:27 this Saturday (GMT):
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) ...
That's pretty cool, I always wished there was a physical switch to
trigger a debugger since the system might be frozen...
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.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 12 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 14:34:46 |
| Calls: | 173 |
| Files: | 21,502 |
| Messages: | 79,265 |