some problems for an introductory python test

[Hope Rouselle]

Chris Angelico <rosuav at gmail.com> writes:

> 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.

Speaking of which, NTFS supports something called file streams.  That's
essentially a way to have files inside files.  Streams are not shown by
tools such as file explorer.  Applications could definitely use that as
metadata.  (End of tangent.)

I think UNIX people would say and I'd agree --- we have that already.
But instead of hiding the stream, which is obscurantism, we let the user
see.  (Just create two files in a directory, one with the extension
.metadata.  And, oh, if you don't like that extension, you can change it
to whatever you like.  Lol.)  I like that.

>> > 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.)

I like that kind of simpler GUI interface.  Cleaner.  Fast!  You know,
the so-called ``modern world'' is totally overrated.

>> > 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.

Lol.  Really?  I mean a certain panic button.  You know the GNU Emacs.
It has this queue with the implications you mentioned --- as much as it
can.  (It must of course get the messages from the system, otherwise it
can't do anything about it.)  And it has the panic button C-g.  The
keyboard has one the highest precedences in hardware interrupts, doesn't
it not?  A certain very important system could have a panic button that
invokes a certain debugger, say, for a crisis-moment.

But then this could be a lousy engineering strategy.  I am not an expert
at all in any of this.  But I'm surprised with your quick dismissal. :-)

> 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.)

Why not?  Misuse of hardware?  Too precious of a resource?

> 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

You know your pins!  That's impressive.  I thought the OS itself could
use something like that.  The fact that they never do... Says something,
doesn't it?  But it's not too obvious to me.

> 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.

Lol.  I feel you're saying you would. :-)

>> 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.

I just pressed M-PrtSc on my keyboard.  Windows 10.  Nothing happened.
(I'm not aware of any synchronous input queue liked you said either.)

>> > 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.

I am in my early fourties.  I can clearly see how kids look at me as
old.  It's really not so bad.  Some are born earlier. :-) And it turns
out life a few decades ago was really not so bad.  Things seem to be
getting rougher now.  I feel sorry for kids.

What we should do, though, is preserve our health.  Older people in good
health seem sometimes even happier than the youngsters.

> 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)

Thank you so much.  That's good enough.  

> 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.

I heard of Python for the first time in the 90s.  I worked at an ISP.
Only one guy was really programming there, Allaire ColdFusion.  But, odd
enough, we used to say we would ``write a script in Python'' when we
meant to say we were going out for a smoke.  I think that was precisely
because nobody knew that ``Python'' really was.  I never expected it to
be a great language.  I imagined it was something like Tcl.  (Lol, no
offense at all towards Tcl.)