My Vintage Dream PC

[Richard Cranium]

I was writing and distributing code so you kids could play with
transporting bits over wires .

/BAH

I was banging Al Gore's mom - I'm his real dad - and HE INVENTED THE
INTERNET!

Top that one!

 

[Anne & Lynn Wheeler]

Another newbie. I have been reading since 1983, clear back when there
barely was USENET.

i've been blamed for computer conferencing on the internal network in
the late 70s and early 80s ...

the internal network was larger than the arpanet/internet from just
about the beginning until possibly late '85 or early '86 ... misc. past
posts
http://www.garlic.com/~lynn/subnetwork.html#internalnet

some old pictures including online at home between 77 & mid-80s (still
haven't found any pictures of online at home from early 70s):
http://www.garlic.com/~lynn/lhwemail.html#oldpicts

 

[Roland Hutchinson]

The monitor and the interface are the same for late versions of
Windows. They are released together, sold together, and used together.


Oh, Windows has so *many* bugs, I'd hate to ascribe all of them to
just *one* of its design flaws...

And besides design, there's also execution. One wonders just how much of
that code base (Microsoft's precious Intellectual Property jewel) was
written by 20-year-old coders without adult supervision, for example.


--
Roland Hutchinson

He calls himself "the Garden State's leading violist da gamba,"
.... comparable to being ruler of an exceptionally small duchy.
--Newark (NJ) Star Ledger ( http://tinyurl.com/RolandIsNJ )

 

[Roland Hutchinson]

Patrick Scheible wrote:

Bill Leary wrote:
Patrick Scheible wrote:

Hi:

My vintage dream PC contains the most advanced motherboard [in
terms of ability to handle the highest processor speed of it's
type as well as maximum RAM capability] that contains the most
amount of 16-bit ISA slots but does not contain any PCI or other
non ISA also. It does not even have any EISA or SCSI.

Here are the other specs of my vintage dream PC

1. OSes: Windows 3.0 [not 3.0a, just 3.0] and the most advanced
version of DOS fully compatible with the other
softwares/hardwares in my vintage dream PC.
[snip]

Windows 3.0?? More like my vintage nightmare PC.
Dammit! Windows is not, I repeat, NOT an OS.
For the version under discussion, yes, this is/was pretty much true.

Today, and for some time, it actually was/is an OS.
Not really. What do you think the terms NT and Vista exist?
Because "Windows" by itself is too vague to trademark. (And also to
designate specific releases.)
Monitor releases which is not the app.
The monitor and the interface are the same for late versions of
Windows. They are released together, sold together, and used together.

Note that I'm not saying a thing about whether that's good or not.
Or even if it's good or not.

Windows is the app.
In Windows 3.x, 95, 98, and ME, yes. In Windows NT, XP, and Vista,
the windows interface is inseparable from any other part of the OS.
I don't care if it's inseparable; that was a battle that Cutler
lost. Allowing the app to have hard wired roots in the monitor is,
probably, The source of all its bugs.
Oh, Windows has so *many* bugs, I'd hate to ascribe all of them to
just *one* of its design flaws...

I would be interested in hearing from you an OS that is free from
bugs.

This is s specious argument. Since no OS is perfect, therefore all are
equally buggy. Obviously some are more buggy than others which were
designed for reliability, not for flash.

What is desired is an OS that tends to be robust even in the face of bugs.

The way NT let the nose of the display-system-and-UI camel in under the flap
of the OS kernel is a good example -- indeed, by now a textbook example --
of how _not_ to achieve this.

--
Roland Hutchinson

He calls himself "the Garden State's leading violist da gamba,"
.... comparable to being ruler of an exceptionally small duchy.
--Newark (NJ) Star Ledger ( http://tinyurl.com/RolandIsNJ )

 

[jmfbahciv]

At one stage in the NT development there were "pipelines of piss
flowing" between competing groups.

Good book: read it.

Did the book mention the work that JMF and his group were doing
w.r.t. NT developement? Does it mention the work that MS
contracted DEC to do w.r.t. NT development?

/BAH

 

[jmfbahciv]

I ran a PDP-11 RSTS timeshare system in the 1970's. It would emulate
multiple OS shells which ran *outside* the kernal and they would run
assembly, BASIC, Cobol, Fortran, whatever. It was impossible to break
from the user side, and would run for months between power failures.
It had the obvious hardware and software protection of the OS from
user code.

And that's why the monitor needs to be "separate" from the user
code. MS' development tradition is to take the "shortcuts" and
directly access exec code or put the app code in the exec. this
allows any old user mode program to spray bits all over the disks
and core even it's protected with hardware.

It takes time and lots of design meetings to get people to agree
on a UUO or CALLI interface. MS' development folklore was to
always to this stuff the "short" way, w.r.t. wallclock time.

Just look at the mindset of Gates when he was getting started.
This mindset was carried into corporate and has become part of
its folklore.

/BAH

 

[jmfbahciv]

Richard Cranium wrote:

I was banging Al Gore's mom - I'm his real dad - and HE INVENTED THE
INTERNET!

Top that one!

Thus, you weren't very productive then and you are less productive
now.

/BAH

 

[jmfbahciv]

SO the enemy has got their thinking wrong. Another reason they are the enemy.

I had understood the reference of "enemy" to be the in-house politics
of Microsoft and not about the quality of their ships.

In the Internet world, or should we rather call int the "open world", we took
those fights, against X.25, GOSIP, CONS/CLNS, SNA, H.323 and more.

I know DEC was structured so those fights were impossible. But the fight
against spectacularly bad design must be taken, even it (or, especially if)
it is promoted by PHBs.

I agree. That is why I'm writing my comments about monitor vs. app
development. Lynn and I know what kinds of work is involved to
create a secure "gateway" between an app and the monitor during
a development cycle. Granted, this was in the old days but our
methods worked. You cannot edict a million lines of code written
in two months and expect any sensible overall design. MS' usage
of developers is to make them work 7x24 until they burn out (less
than a year or two). That means that no learning of previous
developments ever gets used in the next software release. So
the old mistakes are recreated, ad infinitum. Functional and
architectural designs are only as good as the amount of
old learning about what not to do is included in those designs.

I wrote that badly but I can't seem to do a rewrite...

Anyway, taking the lead time to do the designs properly determines
the ease of getting rid of the bugs that are written and/or
resurrected. The amount of this lead time goes up exponentially
with the number of developers involved in a development cycle.
Lynn? Formula might be e^n, n=number of humans doing the
development, testing, and documenting the software.

No where is there a group of three anymore. Three is the ideal
number.

/BAH


/BAH

not to do

 

[jmfbahciv]

Michael A. Terrell wrote:

Al Gore didn't have a mother. His dad gave himself a sex change,
then impregnated himself with a frozen sperm sample he'd saved in the
old freezer in his basement. The disguised the sample as popsicle.
Unfortunately for Al, the sample developed extreme freezer burn. That
is the only plausible explanation for him inventing the global warming
bullshit.

Nope. there is another plausible explanation which also fits all the
other shit he did.

<snip.

/BAH

 

[jmfbahciv]

Bill Leary wrote:

The "home terminal" with the roll of thermal paper. I used one of
those too. I'm trying to remember the name of the hardware, but the
best I'm coming up with is that it began with a "T." I also recall that
that paper tended to do bad things if left exposed to sunlight. It
faded even if stored away from light too.

Terminex?

 

[Peter Flass]

Bill Leary wrote:

Terminex?

I was going to say Texas Instruments, but that doesn't look like the
one I remember. What a great feeling to get a lightweight terminal that
ran 3X as fast as a "standard" TTY and had a built-in acoustic coupler
instead of a separate unit. In this respect, at least, times have
changed for the better.

 

[Richard Cranium]

Richard Cranium wrote:


Thus, you weren't very productive then and you are less productive
now.

/BAH

Excuse me ... if I wanted to hear from an asshole, I would have
farted!

 

[Richard Cranium]

I was going to say Texas Instruments, but that doesn't look like the
one I remember. What a great feeling to get a lightweight terminal that
ran 3X as fast as a "standard" TTY and had a built-in acoustic coupler
instead of a separate unit. In this respect, at least, times have
changed for the better.

I think you're right - it was likely the TI Silent 700. I used to
take one home from the office to connect to National CSS via the
integral acoustic coupler.

 

[Walter Bushell]

MS' development folklore was to
always to this stuff the "short" way, w.r.t. wallclock time.

Wallclock time for development or at run time? Both will lead to
instability and security problems mentioned here. But our computers are
so fast that history is running in reverse, people are buying netbooks,
which are a *serious* step down in power.

 

[Anne & Lynn Wheeler]

The "home terminal" with the roll of thermal paper. I used one of
those too. I'm trying to remember the name of the hardware, but the
best I'm coming up with is that it began with a "T." I also recall
that that paper tended to do bad things if left exposed to sunlight.
It faded even if stored away from light too.

re:
http://www.garlic.com/~lynn/2009h.html#30 My Vintage Dream PC

a couple of the "old" pictures
http://www.garlic.com/~lynn/lhwemail.html#oldpicts

are CDI miniterm i had at home (as well as compact microfiche viewer at
home) ... that used rolls of thermal paper ... similar to what i've had
in recent fax machines ... thread from last year
http://www.garlic.com/~lynn/2008m.html#37
http://www.garlic.com/~lynn/2008m.html#38
http://www.garlic.com/~lynn/2008m.html#51

before that ... for most of the 70s at home, it was 2741 selectric
.... that could take individual sheets ... pretty much like selectric
typewriter ... however most of the time i had boxes of greenbar,
fan-fold printer paper (i still have selectric apl typeball and there
are a couple recent picutres)

 

[Anne & Lynn Wheeler]

I was going to say Texas Instruments, but that doesn't look like the
one I remember. What a great feeling to get a lightweight terminal
that ran 3X as fast as a "standard" TTY and had a built-in acoustic
coupler instead of a separate unit. In this respect, at least, times
have changed for the better.

re:
http://www.garlic.com/~lynn/2009h.html#30
http://www.garlic.com/~lynn/2009h.html#31

there is some vague recollection that cdi miniterm had earlier been TI
miniterm; 300 baud instead of standard tty 110 baud. possibly that TI
spun-off/sold-off miniterm(?) ... that or it was purely a clone.

an (ascii) 3101 (glass teletype) with 1200 baud modem ... replaced the
cdi miniterm at home ... before getting an (my own personal) ibm/pc at
home to replace the 3101.

 

[Anne & Lynn Wheeler]

And that's why the monitor needs to be "separate" from the user
code. MS' development tradition is to take the "shortcuts" and
directly access exec code or put the app code in the exec. this
allows any old user mode program to spray bits all over the disks
and core even it's protected with hardware.

It takes time and lots of design meetings to get people to agree
on a UUO or CALLI interface. MS' development folklore was to
always to this stuff the "short" way, w.r.t. wallclock time.

Just look at the mindset of Gates when he was getting started.
This mindset was carried into corporate and has become part of
its folklore.

slightly related recent thread about security/integrity
(and system design point)
http://www/garlic.com/~lynn/2009h.html#28 Comuter virus strikes US Marshals, FBI affected

one of the things about current mainframe batch system is that its (360)
heritage was from small/limited real-memory (single address, no virtual
memory) ... supervisor/kernel code was in same address space as
application code. pervasive use of pointer passing in API between
application code and supervisor/kernel.

initial translation of this paradigm into (370) virtual memory was
single (16mbyte/24bit) virtual address space ... basically simulated 360
envorinment but with the appearance of larger real memory; the
supervisor/kernel still occupied the same address space as applications
and retained extensive pointer-passing API.

next morph was to have multiple virtual address spaces ... one per
application. it almost simulated 360 environment ... supervisor/kernel
and application occupying same address space ... but now there was one
virtual address space per application (with the same supervisor/kernel
image appearing in each address space).

this had some unintended consequences. 370 was 16mbyte/24bit virtual
address space ... which was laid out with 8mbytes of the
kernel/supervisor image in each adderss space ... and theoritically
8mbytes for each application.

the problem was a number of "sub-system" services which had been outside
the kernel/supervisor ... and were now in their own unique virtual
address space (just like applications) ... however there was problem
with conventions that normal application pointer-passing API "calling"
these subsysttem services (which no longer resided in the same virtual
address space). the hack/work-around was something called the "common
segment" that appeared in every virtual address space (similar to the
kernel/supervisor image). applications would reserve space in the common
segment, move API parameters into their reserved common segment space
and perform sub-system service call, passing pointer to the common
system area. This common system area could also be used by subsystem to
return values to the application.

The problem was that size of common segment was basically proportional
to number of subsystems and application activity. By the time of 3033,
large installation were needing common segment area that were 5-6 mbytes
in size ... leaving only 2-3 mbytes for application use (each
application had dedicated 16mbyte virtual address space ... but half
that went to the supervisor/kernel image and then 5-6 mbytes for common
segment).

misc. past posts mentioning common segment and pointer passing API
http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#0 Handling variable page sizes?
http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#57 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005p.html#18 address space
http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#44 virtual memory
http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#23 threads versus task
http://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
http://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
http://www.garlic.com/~lynn/2007o.html#73 The name "shell"
http://www.garlic.com/~lynn/2007o.html#75 The name "shell"
http://www.garlic.com/~lynn/2007q.html#26 Does software life begin at 40? IBM updates IMS database
http://www.garlic.com/~lynn/2007q.html#68 Direction of Stack Growth
http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'
http://www.garlic.com/~lynn/2007r.html#69 CSA 'above the bar'
http://www.garlic.com/~lynn/2007t.html#16 segmentation or lack thereof
http://www.garlic.com/~lynn/2007t.html#75 T3 Sues IBM To Break its Mainframe Monopoly
http://www.garlic.com/~lynn/2008c.html#35 New Opcodes
http://www.garlic.com/~lynn/2008d.html#69 Regarding the virtual machines
http://www.garlic.com/~lynn/2008e.html#14 Kernels
http://www.garlic.com/~lynn/2008e.html#33 IBM Preview of z/OS V1.10
http://www.garlic.com/~lynn/2008g.html#60 Different Implementations of VLIW
http://www.garlic.com/~lynn/2008h.html#29 DB2 & z/OS Dissertation Research
http://www.garlic.com/~lynn/2008o.html#53 Old XDS Sigma stuff
http://www.garlic.com/~lynn/2008p.html#40 Opsystems
http://www.garlic.com/~lynn/2008q.html#31 TOPS-10
http://www.garlic.com/~lynn/2008r.html#32 What if the computers went back to the '70s too?
http://www.garlic.com/~lynn/2008r.html#34 What if the computers went back to the '70s too?
http://www.garlic.com/~lynn/2009.html#55 Graphics on a Text-Only Display
http://www.garlic.com/~lynn/2009c.html#59 Why do IBMers think disks are 'Direct Access'?

 

[Andrew Gabriel]

On Mon, 25 May 2009 03:16:56 -0400, Roland Hutchinson

The advantage of a small kernal OS is that a small number of very good
people - as few as one - can write the core of the OS. Once you move
stuff like GUIs into the kernal space, you have hundreds of
programmers dumping thousands of modules into the part that can crash
and take the whole system down.

The ultimate OS should maybe be hardware, fpga probably, or an

You just described OS4000, running on the GEC 4000 series minicomputers.
The only code you can run on the system runs in processes. The Kernel
is all hardware and firmware, and you can't change or modify it.
The later models in the range were fpga instead.

entirely separate processor that runs nothing but the os.

GEC did experiment with such a system too, but it never turned into a
product.

 

[Peter Flass]

The ultimate OS should maybe be hardware, fpga probably, or an
entirely separate processor that runs nothing but the os.

CDC-6600.

 

[Ahem A Rivet's Shot]

In a few years, when most any decent CPU has 64 or so cores, I suspect
we'll have one of them run just the OS. But Microsoft will f*** that
up, too.

1 for the OS
3 for the GUI
50 for DRM
9 for WGA
1 for the apps