Chris Angelico <ros...@gmail.com> writes: > On Fri, Aug 13, 2021 at 2:15 AM Hope Rouselle <hrouse...@jevedi.com> wrote: >> >> Chris Angelico <ros...@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.) -- https://mail.python.org/mailman/listinfo/python-list