some problems for an introductory python test

[Chris Angelico]

On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle <hrouselle at jevedi.com> wrote:
>
> Chris Angelico <rosuav at gmail.com> writes:
>
> > History lesson!
> >
> > Once upon a time, IBM and Microsoft looked at what Intel was
> > producing, and went, hey, we need to design an operating system that
> > can take advantage of the fancy features of this 80286 thing. So they
> > collaborate on this plan to make a 16-bit protected mode OS.
> > Unfortunately, things didn't work out too well, partly because this
> > was when Microsoft was at its most monopolistic, and they ended up
> > parting company. IBM continued to make OS/2, but Microsoft took their
> > part of the code and made Windows NT out of it.
>
> How is it possible that Microsoft would take part of the code of OS/2?
> Did IBM just hand it to them?

I presume both companies had all of the code. It was a matter of
licensing, though. There were a few components that were saddled with
awkward restrictions due to the dual ownership (for instance, HPFS386
was Microsoft-controlled, but vanilla HPFS was fine - kinda like the
difference between LZW and LZ77).

> > (Aside: Windows NT's 16-bit applications and OS/2's 16-bit
> > applications were actually identical and compatible. Unfortunately,
> > Win32 introduced a very new API, so as soon as everyone moved to
> > 32-bit everything, the schism became problematic. But it was actually
> > possible to package up a single .EXE file with a 16-bit MS-DOS loader,
> > a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.
>
> Beautiful. :-) So if all libraries were around in each system, they had
> perfect compatibility?

The 16-bit loaders were fine, but the 32-bit loaders were different,
so this trick basically meant having three different copies of the
code wrapped up in a single executable.

> > Plus, it had this fancy
> > concept of "extended attributes"; on older systems (like MS-DOS's
> > "FAT" family), a file might be Read-Only, Hidden, a System file, or
> > needing to be Archived, and that was it - but on HPFS, you could
> > attach arbitrary data like "File type: DeScribe Word Processor" or
> > "Double click action: Run CASMake.cmd". This allowed the GUI to store
> > all kinds of information *on the file itself* instead of needing
> > hidden files (or, in Windows' case, the registry) to track that kind
> > of thing.
>
> Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
> sequence of bytes?  Users decide what to put in them?  So OS/2 was
> taking advantage of that to integrate it well with the system.  Windows
> was doing the same, but integrating the system with files in odd ways
> --- such as a registry record to inform the system which programs open
> which files?  (That does sound more messy.)

Something like that, but with a lot more metadata. Modern OSes don't
seem to work that way any more.

> UNIX's execve() is able to read the first line of an executable and
> invoke its interpreter.  I guess OS/2 was doing precisely that in a
> different way?

Kinda, but instead of having the choice of interpreter be inside the
file contents itself, the choice was in the file's metadata. Still
part of the file, but if you open and read the file, it isn't any
different.

> > The default command interpreter and shell on OS/2 was fairly primitive
> > by today's standards, and was highly compatible with the MS-DOS one,
> > but it also had the ability to run REXX scripts. REXX was *way* ahead
> > of its time. It's a shell language but remarkably well suited to
> > building GUIs and other tools (seriously, can you imagine designing a
> > GUI entirely in a bash script??).
>
> I cannot imagine.  I always wondered what REXX was about --- I saw
> programs sometimes written in some website whose name is something like
> Rosetta Code.  REXX looked so weird.  (``Who would program in that?'')
> But I see now there is a context to it.

Yeah. It was a strange choice by today's standards, but back then,
most of my GUI programs were written in REXX.

https://en.wikipedia.org/wiki/VX-REXX
http://www.edm2.com/0206/vrexx.html

(There were other tools too - VisPro REXX, VREXX, DrDialog, and
various others - but VX-REXX was where most of my dev work happened.)

> > Probably the most
> > notable feature, by today's standards, was that it had a single input
> > queue. ... This means that, if the response to a
> > keystroke is to change focus, then *even in a slow and lagged out
> > system*, subsequent keys WOULD be sent to the new target window. That
> > was AWESOME, and I really miss it. Except that I also don't. Because
> > if a single application is having issues, now your entire keyboard and
> > mouse is locked up... which kinda slightly sucks. Good luck resolving
> > that problem. (We had some neat tools like WatchCat that could get
> > around the single input queue via interrupt signals, and regain
> > control. But it was still problematic.)
>
> Wow, I kinda feel the same as you here.  I think this justifies perhaps
> using a hardware solution.  (Crazy idea?! Lol.)

uhhh........ Yes. Very crazy idea. Can't imagine why anyone would ever
think about doing that.

Certainly nobody in his right mind would have WatchCat listening on
the serial port's Ring Indicator interrupt, and then grab a paperclip
to bridge the DTR and RI pins on an otherwise-unoccupied serial port
on the back of the PC. (The DTR pin was kept high by the PC, and could
therefore be used as an open power pin to bring the RI high.)

If you're curious, it's pins 4 and 9 - diagonally up and in from the
short corner. http://www.usconverters.com/index.php?main_page=page&id=61&chapter=0

And of COURSE nobody would ever take an old serial mouse, take the
ball out of it, and turn it into a foot-controlled signal... although
that wasn't for WatchCat, that was for clipboard management between my
app and a Windows accounting package that we used. But that's a
separate story.

> Maybe machine and OS
> could have a desktop-version that would have a hardware that could
> effectively be like a second keyboard --- a button.  So our keywords
> would have a button that we press it, we could interrupt the OS to
> handle such lock-up more gracefully.  I suppose this is expensive,
> complex and so on.  But at the same time, it could be worth it.

SysRq should theoretically be that. (That's Alt+PrtSc on a lot of
keyboards.) I'm not sure how it could best be handled though. It might
be that today's GUI systems (X11, Wayland, Cocoa, Win32, etc) just
wouldn't work with a single input queue. Would be curious to see if
any modern OS/GUI pair has a synchronous input queue like that.

> > So, yeah. It was spectacular in its day.... but it kinda got left
> > behind as the world moved on. These days, instead of running REXX code
> > on OS/2 in a system that uses eight-bit text for most things, I use
> > Python on Linux and full Unicode. But OS/2 was an important part of
> > history, both my own personal journey, and the history of the world of
> > PCs.
>
> Very nice.  Thanks a lot for sharing.  I care a lot about such
> histories.  In fact, if you could point out from the top of your head
> the best reference on the facts you mentioned here, I would love to
> write it down for future reference.  (You probably read books that
> perhaps explained how the queue of windows messages worked et cetera.)
>
> Thank you!

Thank you for asking questions about it! Aside from making me feel old
(which, let's face it, is kinda inevitable), it's great to dig through
some of the history and a few of the very different ways things have
been done.

References, unfortunately, are a bit hard to share, since they're
mostly dead-tree books, plus a small number of IPF documents (a format
kinda like man pages, but they get compiled) which have probably been
lost by now. Oh, plus a lot of "My dad told me", which is a bit hard
to point anyone else to :)

But if you want to delve into things today, I would recommend using
Wikipedia or whatever the almighty Google shows up, neither of which
was available back then, but both of which have vast information
available to you. Some useful topics:

* Single (or Synchronous) Input Queue
* CORBA (the system for cross-language subclassing of PM classes)
* The OS/2 Presentation Manager
* 80386 Protected Mode
* DBCS (early multilanguage support - appallingly inferior to Unicode,
but better than nothing)
* REXX, VX-REXX, VPREXX, VREXX
* DB2 (IBM's flagship database both then and now; spectacular even
back then, although slow at times)

Python *was* available on OS/2 back then, but not heavily supported.
It might be interesting to compare the early versions of Python to the
other tools available, but probably more useful to compare the 1990s
tools to modern Python on modern OSes and see how far the world has
come.

ChrisA