Doing Windows, Part 1: MS-DOS and Its Discontents
filfre.net
filfre.net
You boot your 80286 with 1MB RAM and a 20MB (RLL) HDD. This was my second PC and I'd forked out over £100 to get a 287 Maths Co-pro. so I could run a dodgy copy of AutoCAD. I had it all on this box: WordPerfect with the multi colour cardboard Fn key strip. Harvard Graphics and Super Calc and a flirtation with WordStar (I still prefer joe for a terminal editor). GW BASIC and some other games rounded out the collection.
Printing was a right laugh because each app, including your own, had its own printing system. Getting our Epsom RX80 working with all of the above was a major feat and my efforts with C (Borland? Can't remember) nearly drove me mad.
Ahhh, I can still see the faded (partial) Mandelbrot set crossing over the perfs. on the tractor fed paper because I'd screwed up my co-ordinate transformations.
I think we had an EGA monitor and I collected 5.25" floppies like crazy. I had WordPerfect and SuperCacl.
My first computer was a T1-99-4a with basic and audio cassettes.
Basically we defined the columns to be printer operations, bold, italic, subscript, ...., then went through the manuals copying the escape codes while creating a row for each printer model being supported.
Adding new printer support was releasing an updated version of the printers.dbf file.
It was really "fun" making it work and testing printouts.
Obviously i also wanted to make sure that it had a manual since all professional programs have a manual. Months before that, the owner of a local computer shop had given me some stacks of old continuous paper that was around A6 in size (although it was squareish, so not really A6) that he was about to throw away, so i decided to use that since it had a nice "booklet" feeling. To write the actual manual, i wrote a program in Turbo Pascal that allowed me to write the text in a quasi-WYSIWYG way: i was editing each page in a full screen view (the paper could hold around 40x20 or so characters with the normal font) and each character could be "styled" with bold, underline, italic and big flags (this used a double sized font, i had to take into account the letter size) which was displayed as different colors.
The program was thedefinition of being purpose built: it only supported that particular printer (well, that particular printer line, i also got an LC-10 at some point and it worked there too) and only that particular paper size. One of the most interesting bits i remember was that the printer didn't really had a concept of paper sizes (it was a continuous paper printer only) and the paper size i used wasn't fitting exactly the (default font) line height, so after printing every page, i was sending commands to change the line heights and move the paper back and forward with different line heights to reposition the header at the same spot for each page.
After printing the pages i had to cut the perforated sides and since i didn't had a big stapler to hold all of them together, i opened the holes where the staple would be with a needle and put and bent a staple with a screwdriver (or something like that, i do not remember exactly) and then putting some tape over the side. That process wasn't as fun as writing the software and printing it, which ensured i only made a single copy of the manual which i gave to my father. He eventually gave it back to me some years later when he upgraded the computer he used at his shop, but that was almost 20 years ago and since then we moved a few times and i moved a few times myself and it was either lost or hidden in some long forgotten corner of my attic here (where the few things i still have from my childhood/teen days are stored).
I do not remember printing stuff being particularly hard though, but i might have been lucky and ended up with a very simple printer.
Man, that wasn't minimalism, _the computers really were small._
Like, 'cascading' windows (e.g. in Program Manager) made sense in a world where a 12-14" 640x480 monitor was normal, users still wanted to ability to multitask, and skeuomorphic design (everything is a 'window') was the most intuitive analogy for users.
Nowadays you would just tile your two main windows on your widescreen monitor.
Rarely do I really need/want two windows. Worse, since most of what I do is data entry, copying out of a browser is not something I will do by transcribing text, which means I'm likely reaching for the mouse. Which means I don't really care about the wins of a tiling window.
Granted, I do tend to side towards training of a more tiling like experience is far superior to just diving through. However, I no longer subscribe to the idea that knowing the shortcuts and other fancy management tricks of advanced window managers is necessary. I do it nowdays solely because it makes me happy. And this is perhaps why I find the phone so non-compelling of a platform to use.
I sometimes wonder if I'd have gotten into programming sooner had I had exposure more than just Oregon Trail or Number Munchers.
Yes, they were. But it was more than that. The machines were very diverse. Several very different video card options were all in wide use and to make them work efficiently meant low level frame buffer work. Pointers were rare and weird, and again, diverse; bus mice, serial mice and other stuff. Writing a GUI compatible with all the permutations of PC hardware while being simultaneously efficient enough to run from floppies was possible with difficulty, but what value would it have provided? These were 16 bit machines with either no or extremely limited (286) MMUs; just how many processes were you going to be multitasking with your 512K of MMU-less RAM?
DOS was just a program loader, and being just a program loader it was perfectly suited to the PC market. You bought a system with the 'adapter' cards you needed, booted DOS and let some program take over the system, be that Word Perfect, Paradox, Lotus 123 or whatever. That was the real, day to day use case for the PC. An advanced user with a 'fast' disk could bounce between programs in a few seconds and that was entirely sufficient for the vast bulk of PC users. It's also not dissimilar to the contemporary phone/tablet use case.
And I don't remember anyone getting too hung up on the C:> prompt. They either acquired the clues needed to run a few commands or had someone make a .BAT file to kick off their program.
There were certainly contemporaries with compelling UIs, but they invariably cost more and had a vastly smaller catalog of software.
Commodore also had the PC Colt series PC compatible systems cheaper than IBM and Compaq etc.
The Commodore name and reputation of selling C64s in toy stores made businesses not see the Amiga seriously.
There also was that Amax Mac emulator for the Amiga as it used the same CPU as the Mac.
But all people could see was the AV part not the other parts.
Computer stores blackballed Commodore products because the VIC20 and C64 sold in toy stores.
A 286 was not as powerful as a 68000 with the coprocessors.
68000 w/coprocessors "felt" on par with a low end 386... though clearly it still lacked in raw computational performance.
The Amiga ran games better than even a 486 thanks to coprocessors multitasking events.
And people were paying for the big heavy cases, expansion slots, full keyboards and etc. Amiga didn't look the part. (And neither did Apple until the Mac IIs came out.)
noooo, why did you make me remember real mode[1]!?
[1]: https://en.wikipedia.org/wiki/Far_pointer#In_16-bit_x86
DOS also provided a little bit of an abstraction layer with its system calls, and some utilities. I just wanted to make the distinction in case any readers took you literally
https://en.wikipedia.org/wiki/Terminate_and_stay_resident_pr...
It's frankly amazing that Microsoft ever managed to get Windows to run on 5150-class machines (which were allowed to have as little as 256 KiB of RAM per the minimum requirements). While the Macintosh had half that much RAM (128 KiB) it had the luxury of storing most of its system and graphics code in ROM. On the PC all the code for Windows had to reside in memory, with an elaborate system to swap code in and out of RAM as needed with absolutely no hardware memory management support. Raymond Chen's Old New Thing blog has some interesting reading on the topic of 16-bit Windows memory management:
1. GlobalAlloc vs LocalAlloc: https://blogs.msdn.microsoft.com/oldnewthing/20041101-00/?p=...
1a. 4-part series on the history of GlobalAlloc: https://blogs.msdn.microsoft.com/oldnewthing/20041104-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20041105-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20041108-00/?p=... https://blogs.msdn.microsoft.com/oldnewthing/20041109-00/?p=...
2. Walking the stack in Win16: https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=...
3. Fixing up pointers to discarded code segments: https://blogs.msdn.microsoft.com/oldnewthing/20120622-00/?p=...
4. MakeProcInstance: https://blogs.msdn.microsoft.com/oldnewthing/20080207-00/?p=...
5. 16-bit x86 calling conventions: https://blogs.msdn.microsoft.com/oldnewthing/20040102-00/?p=... (Note that 16-bit Windows used the Pascal calling convention to save 3 bytes per function call, which according to a comment on that blog post allowed it to be shipped on one fewer floppy disk compared to the C calling convention.)
That's the L2 cache of an Ivy Bridge CPU.
I remember finding an old laptop that I somehow ended up with in some box: Windows 3.1 with a TCP stack in 8 MiB of RAM.
That's the L3 cache of an Ivy Bridge CPU.
It might not sound impressive today. But back then, playing full screen video on a PC usually required an "MPEG accelerator card"
(Excuse the awful recording quality, all I had was a mediocre phone at the time)
That's the total of the data+instruction L1 cache on each core.
I've used WordStar on a machine with 64 KB addressable, which was as WSIWYG word processor as possible on the text monitor with 80x25 characters. It showed you all the possible actions in each step too -- what even today so many programs don't manage to do. If I remember it didn't keep the whole program in the RAM at once, but had its own swapping mechanism.
I've also used a Turbo Pascal there, which was even on such a machine amazingly fast. By default the compilation was directly to memory, no waiting on any disk.
It's always sad to read histories of computing during the 80s. It was a lost decade in many ways. Much more powerful and competent paradigms were alive and vital at the start, but by the end, they were all collapsing. A few different choices, a little bit better business sense, and we'd have a computer world profoundly alien to the one we have now.
It's still possible, of course. But it'd be wearing the hair shirt and being a lone hacker as you built up your system.
I refer, of course, to both Lisp and Unix machines, along with the various developments in parallel architectures. The Unix machines as sources of power and use lay quiescent for many years, until maybe the early 00s, and IMO the Lisp machines path has never been genuinely walked.
There's an elegy to be written for the loss of the operator of the computer being turned into a consumer rather than a producer (unix) or symbiont (lisp). Maybe rpg will write it one day.
Turbo Pascal, in particular, more or less introduced an entire generation to programming, especially since it had no copy protection.
I owe everything to DOS and GWBASIC.
I remember phoning up AT&T's lawyer to ask him if I could get permission to implement a C++ compiler, and call it C++. He laughed, and thanked me for asking, saying nobody else had bothered :-) I've always had warm feelings towards AT&T based on that experience.
Of course these weren't standardized and had slight differences in their syntax, but at the time C++ wasn't standardized either and - again - not all compilers were compatible.
I think the main reason that C++ got its hold was that it was compatible with C which itself got its hold over other similar languages because the popular OSes of the time used it and provided headers in C, all documentation was about the C interface and most third party stuff hooked up with C. Borland initially tried to Pascal-ize the C bits of Windows (f.e. they converted the function declarations from C to Pascal in the Windows SDK docs they distributed up until and including Delphi 1) but eventually gave up (Delphi 2's Windows API docs use C syntax).
Of course that was up to early-90s. After that it was mainly Borland who used Pascal and they succumbed to Enterprise Envy, constantly and it wouldn't be until Free Pascal released version 1.0 years later (in 2000) that a competent 3rd party implementation would exist - and even that was mostly ignored until people started noticing Lazarus in very recent years. Of course now is too late to change the tide as no matter what a Pascal compiler may provide, most people have a ton of preconceived notions about the language.
Since ZTC++ was not a proprietary language, people felt confident to use it on DOS and use cfront elsewhere (and the nascent g++).
The success of ZTC++ directly caused Borland to do Turbo C++, followed by Microsoft C++, and other languages were simply left in the dust.
Sure, DOS was solving useful problems that Unix didn't. But there was no reason why an OS for computers with 20Mhz processors that whopping 640kB of RAM had to be as bad as it was.
Everyone knew DOS was awful, but it had all the software, and the alternatives (e.g. OS/2) were worse. Once Windows matured, adoption was immediate.
I believe that eventually happened in the 80s for some form LISP machine as an expansion card for the mac. Not sure about that though...
I think in many ways, PC architecture--especially the bus--was IBM's attempt at poisoning the well to give their mainframe lines a little more runway. Part of why Gates parted ways with IBM over OS/2 was how busted memory management was on the 286 along with IBM's relative indifference to that.
As for Intel, their problem was that they were physics/chemistry guys, not architecture ones. So many of their architecture adventures have been disasters.
I didn't know about Lisp machines until the early part of this decade. But everything I've read about them generates the same excitement I had about Linux and BSD coming from Windows. In some ways Lisp machines are even more powerful than the Unix environment is. Unfortunately, there is no Linux/BSD analogue of the Genera operating system. Genera was never open-sourced, and I have not heard of any Linux or BSD analogues to Genera. The source code to some earlier Lisp machine operating systems have been released, but these operating systems lack the complete feature set of Genera.
Also, it would be difficult to develop a clone of Genera and have it gain traction in the broader community today. Linux not only benefitted from the already-existing work on the GNU toolkit, but it also emerged at a time when PC users were mainly using MS-DOS and Windows 3.0. The GNU toolkit and X11 is a dramatic upgrade from MS-DOS and Windows 3.0 unless you need access to proprietary software packages that could only run on DOS or Windows. But what if Linux had come of age during the days of Windows 2000? The story regarding Linux's adoption among PC enthusiasts might have been very different. In the case of a Genera clone, all work would have to be done from scratch, and it would have to compete against full-featured, readily-available operating systems like Linux, the BSDs, and Windows 10. It would also take a lot of time to write: the period of time between the founding of the GNU Project (1984) and the release of the first Linux kernel (1991) was seven years.
The closest thing we have to anything like Genera is Pharo, a modern derivative of Smalltalk. But even with Pharo it will take a lot of work to develop a suite of utilities that could make Pharo an environment that can be used as a daily-driver operating system.
Even so, I'd love to use a FOSS clone of Genera that's updated for the needs of the next decade or two of computing.
I would also agree regarding market conditions.
One other thing, since this textbox is here and you're contemplating similar thoughts: the Modula-2/Oberon OS system in the 90s deserves some serious re-analysis and recognition of what it did do. My memory of a paper - and I haven't found this source when I went looking for it - is that it had a full networked productivity suite suitable for all users of the CS department? University? hosting Oberon's development. And it was used heavily in that place. It was a hardware-software-language codesign project, if I remember right. Maybe the last of its kind in the wild outside of the Linux/DOS projects with C and Intel processors.
I do agree that someone who dropped a reasonably decent starting point for the Next Lisp OS in a fashion that multiple people could contribute to could get some traction and power. A lot of water has passed under the bridge since Lisp machines went away, and the model users and environments are substantially different. My reckoning is that a genuinely next-gen system would wind up with a trusted-compute base, maybe even a trusted-compute kernel, using Rust or other forward-looking technology, with the lisp system sitting on top. Broadly: rust would provide syscalls & drivers, then boot sbcl for the init and then the main user.
It would be a fascinating exercise in modern OS & userland redesign. I think there's probably a PhD in it; as far as I know, that world has lain fallow for a few decades now in academia.
http://www.progtools.org/article.php?name=oberon§ion=com...
Unlike that previous era, we have big advantages today that make me think the world is ready for reconsider all of this. The first is that we have more universally adopted standards for exchanging data (we don't bitch as much about compatibility across systems). The second, and somewhat related point, is that we can assume high network connectivity most of the time (itself a kind of universal standard). As I've said before: all a new system needs in order to be "viable" to the existing world is a web browser. Everything else can be rethought.
Today I will be doing yet again another project for a client who simply needs to have data pulled in from a bank as CSV and inserted into their existing Excel template. This is in theory a very simple programming task. But the ecosystem and our environments make it tremendously and unnecessarily difficult. If we had "real" personal computing, they wouldn't even need someone like me.
I'd like to stop the argument there though and ask, first, why bother for a research project? Not that it's useless, but if you're trying with a few other hackers to reconceptualize OS layout and write the relevant tools for your system, you've got enough on your back.
Arguably in this hypothetical next-gen system, if you can provide an interface that looks like a Linux container, you can run a Linux application like Chrome and be done with it.
(and even more to my point original point of things could have been very different: web browsers are essentially reimplementing a cross-platform GUI without a toolkit and with a custom language (JS). Maybe it's time we just had plain old network applications without a web browser..... but that's a different discussion, a different musing).
> why bother for a research project?
We'll never get anything new if we don't. Linux and containers are band-aids. They are not original solutions. We shouldn't be squeamish about re-implementing everything from the ground up. The big problems in personal computing have not yet been solved. If anything, we've been regressing — in the wrong way.
Even with special "Lisp-optimised" hardware they were still extremely slow compared to other contemporary machines.
Commercial Lisp Machines (LMI, Symbolics, TI) were basically as fast as contemporary machines 1981-90. Especially for running Lisp. The first systems appeared end 70s and there basically almost no machines like them. LMI and Symbolics machines were basically the first or at least among the first GUI-based workstations in the early 80s. In the mid 80s a Lisp Machine was as fast as the then contemporary machine, but much more extensive in capabilities - which made the hardware very expensive.
In 84 Apple released a Mac with tiny b/w screen, an 8 Mhz 68000, 128kbytes memory, no virtual memory, a floppy drive, no extension cards, no development environment, ...
At that time the Lisp Machine from Symbolics used a 68000 as a frontend processor for its megapixel console, had ethernet, supported several megabytes of RAM, had a dozen of extension slots, had disk drives, tape drives, color graphics options, and an object-oriented OS running with 100+ virtual memory with garbage collection.
At the end of the 80s machines catched up - especially the Unix machines - but they were not dramatically faster for running Lisp. But they allowed machines with less RAM running C code/applications - while RAM was really expensive. Real faster machines appeared in the early 90s, when Lisp Machines were already abandoned and newer Lisp architectures based on Lisp RISC chips were not brought to the market - due to lack of customers interested in expensive niche technologies...
In the end 80s a 68030 wasn't running Lisp faster than a Lisp Machine - basically the same for the usual (micro-) benchmarks. The 68040 in the early 90s was slightly faster, then. Generally the during its lifetime 75-92 the Lisp Machine architectures were not designed for speed, but for other capabilities - they were basically enablers for the first development workstations with able to run large (at that time) software/datasets. A single Macsyma could thrash a timesharing mainframe end 70s, but on a Lisp Machine the user had Macsyma on his 'personal computer' with his/her own 1MB-4MB RAM and his/her own virtual memory.
SGI Machines in the mid-80s used Motorola processors - thus weren't 'extremely' faster either. The early MIPS processors weren't much faster either - around 1990 SGI introduced cheaper SGI machines with good graphics - but still not with 'extremely' fast CPUs...
A Lisp Machine new in 1984 would be around 80k$. Prices were then coming down a bit for delivery systems and also for embedded boards. But you could think that end of 80s a large Lisp Workstation was three times as expensive as a high-end PC or Mac. But for PCs RAM was still expensive and the 32bit Intel processor wasn't really that good running Lisp. RISC systems (SPARC, MIPS, ALPHA, ...) were better at that and their Lisp systems were better than the ones for PCs. But the real good Lisp systems (Allegro CL, LispWorks, Lucid CL) for RISC appeared or matured only end 80s/early 90s. 64bit Intel is okay nowadays, too.
Some Lisp systems were also stretching PC/Workstation capabilities, since they were large memory-hungry applications - they triggered specific bugs in larger configurations. Imagine in the early 90s a CAD system written in Lisp running in hundreds of MBs of RAM, where each CAD workplace cost 1-2 million... stuff like that used by FORD for example to design cars...
If I have to pay 3-5-10x of an already expensive PC for the average person, that thing'd better be life changing amazing.
Symbolics then was also developing a virtual Lisp Machine - an emulator running on 64bit DEC Alpha machines - the software did cost around $5k later.
But keep in mind when PCs became viable for Lisp development on a comparable level, it was already end 80s. Something like a Mac IIx from end 88 was not faster and came with a 40MB Disk. I got a used Lisp Machine from 1986 which had a 600MB disk drive - the drive alone was more expensive than 2 Mac IIx machines. When research labs bought machines like such a Lisp Machine in 1982 for 100k$, they were basically ten years ahead of the market. When budget for these projects were shrinking and the competition was catching up (first RISC Unix workstations and then high-end PCs) it was already endgame time.
Additionally companies moved some Lisp software away to C++ - because C++ applications were usually thought to use less system resources at application runtime.
It is very interesting to piece together these history pieces from the various books :-)
No, they did not. Off the top of my head:
- No cursor keys. You had to reach for the mouse every time you wanted to move the cursor. Rectified later, yes, but not the right choice from the beginning.
- Menus across the top of the screen, inherited from Xerox Alto whose portrait format monitor made vertical space most plentiful, did not make so much sense on the Macintosh landscape monitor, still less so on today's letterbox monitors.
- One-button mouse leading to a workaround where to perform the most common operation of running a program or opening a file required clicking twice in rapid succession. Windows fixed the first problem immediately, but the second problem only years later.
- Copy-pasted text bringing attributes from the source document where it should take them from the destination document. This problem still has not been fixed to this day.
Like other artifacts, the Lisa and Macintosh had their good points and their bad points. Let's not let appreciation of one blind us to the other.
And how did windows fix it? Maybe I'm too young to remember. I've always been double clicking.
That being said, as a power-user I have no problem with double clicking and find that it works pretty well for me.
If an icon is on the desktop, then it requires a double click. If it is added to the task bar, then it is a single click. I understand the reasoning for the distinction, but it is not intuitive at all.
- The double-click isn't ideal but way less prone to accidentally triggering the slow, painful operation of opening files and programs on ancient floppy disks and CPUs.
- Cutting and pasting ideally should consistently work exactly like that operation in real life; randomly changing what you've tried to move over and dropping information would be surprising and confusing.
Anyway, "almost all" doesn't mean "all". The number of correct decisions Apple made back then is astonishing and vastly outnumbers the mistakes. Fire up an emulation of the original Macintosh sometime and it feels surprisingly modern and intuitive - far moreso than its contemporaries (Windows 1.0, AmigaOS...)
That sounds intuitively reasonable, until you look at the current situation where every time you copy paste text between programs that support formatting, you have to cleanse it by pasting and copying through Notepad, or it will do the wrong thing. Note that fixing this would have negative cost: just don't bring any formatting information with copied text.
> Fire up an emulation of the original Macintosh sometime and it feels surprisingly modern and intuitive - far moreso than its contemporaries (Windows 1.0, AmigaOS...)
I used AmigaOS in the late eighties, and found it better than the contemporary Macintosh, though admittedly I don't remember the details well enough to be sure to what extent that was because of the operating system versus the hardware.
> That sounds intuitively reasonable, until you look at the current situation where every time you copy paste text between programs that support formatting, you have to cleanse it by pasting and copying through Notepad, or it will do the wrong thing.
Most programs which support rich text copy-pasting have "paste with formatting" versus "paste text only" options, with the ability to change the default. If an application doesn't, that's the fault of that developer, not the OS semantics.
> Note that fixing this would have negative cost: just don't bring any formatting information with copied text.
I like having source formatting with my pastebins, and most non-technical people do as well. For example, when emailing a code snippet to somebody, I love keeping the syntax highlighting from my editor. And the option to keep the text only is always right there if I need it.
OP started a conversation based on the premise that there are right and wrong ways to design a user interface. If you're going to say it's really just a matter of personal preference, that's fine, but that's not an argument for one side of the original debate, it's a choice to pass up on that debate and have a different conversation altogether.
> Most programs which support rich text copy-pasting have "paste with formatting" versus "paste text only" options, with the ability to change the default.
Does Google Docs have these features? If so, how do you change the default?
> If an application doesn't, that's the fault of that developer, not the OS semantics.
If we accept that argument (which as it happens I don't), it's not an argument in favor of current OS semantics, it's an argument that OS semantics doesn't matter and we shouldn't be debating it in the first place.
This shortcut is common in many applications I use.
Yes, that can be horrible. But there's Ctrl+Shift+V for plain text pasting.
Are you proposing a NeXT-style floating vertical menu? I'm trying to envision one that either wouldn't take up more usable screen real estate than a thin strip at the top of the screen or would have to constantly be re-arranged and am coming up short.
> required clicking twice in rapid succession
To open a file you could always select the file then choose "Open" from the File menu (or press Cmd-O). Double-click was just a shortcut. Same thing with the oft-maligned "dragging floppy disks to the trash to eject" - the standard method was selecting "Put Away" from the menu.
Just as some people have trouble double-clicking, others have trouble mistaking the left and right mouse buttons. The solution isn't so clear-cut.
> Copy-pasted text bringing attributes from the source document where it should take them from the destination document. This problem still has not been fixed to this day.
Every Mac app I use has a "paste and match style" option, including the system ones.
- Do you move the mouse cursor with the keyboard? The cursor is designed to be used with the mouse, controlling the mouse cursor with the keyboard is slow.
- Every modern OS have menus across the top of the screen. If you think it's a bad choice, you're alone.
- Double click may sound bad, but right-click is worse. Look at non-tech people using a computer, they will double click instead of right-click and run.
- To paste without formatting, you use Ctrl+Shift+V in most programs.
Menus on top waste less screen real state and are easier to hit (just slam the mouse against the border). Perhaps you mean on the sides? But then their read awkwardly.
The double click is a silly anti-pattern, I agree. But in those times you needed to be really sure you wanted to open an app, that was a very expensive operation taking many seconds. With today's SSDs we tend to forget that.
Attributes from the source document vs destination is something that needs to be left for the user to decide (Outlook does this). Sometimes I want to copy and paste an HTML table or excel rows, and I want them to look like the source. Other times I am pasting text and I want it to assume the same format as the existing document. Outlook lets me do both, even after the fact.
EDIT: typo
I've at least heard of the latter two, unlike the former ones, or VisiOn. IIRC,they were mentioned in the documentation of some program or game or another I had found and tried to run on my assembled-or-modified-from-scrap computers back in the mid-90s. I assume they had achieved some measure of success and presence in the marketplace (however small or brief that may have been), had they managed to be worth mention in an old DOS or Windows application's documentation.
I'm curious if they'll be covered in subsequent articles in this series.
I also usued a grey import IBM Pc before it was sold in the UK we had out electronics shop build a custom 240-110 v power supply
I don't know about that - people have adapted to the GUI because it's the most dominant thing. Microsoft shipped Solitaire to get people used to the mouse and I'm sure I've heard of people who were extremely reluctant to give up TUI or DOS programs that they were extremely efficient in.
In the end, both are very useful.