some problems for an introductory python test

[Hope Rouselle]

Chris Angelico <rosuav at gmail.com> writes:

[...]

>> > [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
>> > had a wealth of power available. Good times, sad that's history now.
>>
>> I know OS/2 only by name.  I never had the pleasure of using it.  In
>> fact, I don't even know how it looks.  I must be a little younger than
>> you are.  But not too younger because I kinda remember its name.  Was it
>> a system that might have thought of competing against Microsoft Windows?
>> :-) That's what my memory tells me about it.
>
> 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?

> (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?

> In the latter half of the 1990s, Windows came in three broad flavours:
> the 16-bit Windows 3.x line, which ran purely on top of DOS; the
> 32-bit Windows 95 line, which was the "home" OS and had to be heavily
> compatible with Windows 3, but still doing more things; and the
> Windows NT line, which was aimed at businesses. OS/2 was a viable
> option for businesses, but almost nobody took it seriously as a home
> OS. And Microsoft was using its marketing machine to push Windows
> fairly hard, so most people went that way.
>
> OS/2 had all kinds of amazing features (for its time). The default
> file system, HPFS ("High Performance File System"... IBM was good at
> many things, but imaginative naming wasn't one of them), did a
> spectacular job of maintaining reliability and performance on the
> ever-growing hard disks of the time. Yes, it coped remarkably well,
> even on *gigantic* drives that could carry, ooh, an entire gigabyte of
> data! I'm not kidding! We even had a drive that had TWO gigabytes of
> space, and HPFS managed it beautifully! 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.)

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?

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

> It had features that we'd consider fairly normal or even primitive by
> Python's standards, but back then, Python was extremely new and didn't
> really have very much mindshare.  REXX offered arbitrary-precision
> arithmetic, good databasing support, a solid C API that made it easy
> to extend, integrations with a variety of other systems... this was
> good stuff for its day. (REXX is still around, but these days, I'd
> rather use Python.)

Yeah, REXX looks horrible at first.  But arbitrary-precision is
definitely very attractive.  I never liked to deal with floating-point.

> I mentioned the Presentation Manager, because it was one of the best
> parts of running OS/2. The kernel was decent, but it was the graphical
> shell that was the real pleasure to work with. Probably the most
> notable feature, by today's standards, was that it had a single input
> queue. If you press a series of keys, they'd go into a global queue,
> and the application that has focus would get the first one. When that
> key has been handled, the application that has focus would get the
> next key from the 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.)  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.

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