the truth is the truth, and debian is against ease of use.
You are so wrong.
The Debian project is not just one person; it is thousands of people, all working together in a loose organization. I'm sure that if you interviewed everyone, you could find a few who actually want Debian to be hard to use. But most of the people working on Debian want it to be easy to use. We want it to be the best it can be.
The excellent Stormix installer, and the excellent Corel Linux installer, are excellent non-free installers. They are not available to the Debian project.
Also, Debian is very serious about supporting Linux on multiple architectures: Sparc, PowerPC, even Motorola 68K... and the current text-based installer runs everywhere. The Progeny Installer is not only available to Debian, but it was built in a modular way, and it leverages XFree86 instead of using some x86-specific video mode; so it should be possible to get PGI running on all the architectures Debian supports.
Debian isn't stuck in 1996. It is true that it takes the Debian project longer to get some things done than other versions of Linux take... but everyone is a volunteer (the Debian project doesn't have money to pay people) and when things do finally get done they really work right.
Why hasn't Debian project adopted the Corel Linux (nowadays Xandros Linux) installer? [...] Is the installer non-free software or what is the reason?
It is non-free. I have not heard or read anything, anywhere, about Xandros being willing to donate it. It is one of the things Xandros was paying for when it bought Corel Linux, so perhaps they are not in a hurry to give it away.
But I have to say that PGI is actually better than the Corel Linux installer (call it CI for short).
CI has no text-based install. It only installs in GUI mode, so there is nothing you can do if it cannot handle your graphics card. And since it is non-free software, you have no chance of fixing the installer on your own.
If CI cannot handle your graphics card, the officially recommended workaround is: pull out your graphics card, put in one it understands, install, pull out the card it understands, put back your original graphics card, and then tweak XFree86 to deal with your card. (Corel Linux 1.0 could not deal with my GeForce2; I know all this from experience.)
PGI on the other hand does its GUI stuff with XFree86, so as XFree86 adds video cards, PGI gets them too. If your system will be able to use the card when the install is done, you should be able to run the GUI installer.
I read the review. From the way the features were described, this doesn't sound like a product in the same league as Office XP; it's more of a Microsoft Works level product.
If it truly has 100% compatible document import/export, then people might feel comfortable using it as a replacement for Office on some desktops (much as StarOffice is being used now in many companies).
I especially like the licensing. I hope that they sell many copies to families with new computers.
On Linux, I don't think they have much chance of making money. The word processor sounds like it is pretty similar to AbiWord in available features. The spreadsheet sounds like it is not quite up to Gnumeric's level yet. Graphics are not up to the GIMP yet (although they might be a bit more newbie-friendly; I couldn't really tell from the review). In short, there is very little functionality here that is not available already in the free software. Most of the people interested in using Linux probably won't be interested in paying for software that offers little beyond what is already free on Linux.
The integration features are sort of interesting. When you do a Save As on a document with a spreadsheet, several pictures, and some text, I wonder what happens?) Microsoft Office has had features like this since forever, though: you can pick one document to be a shell and drop other documents into it, or else you can run the "binder" and make a metadocument with several other documents bound up inside. (I think most people just do the shell document thing; MS has mostly retired the binder. You can still install it if you like but it is no longer installed by default.) The clean "sheets" interface is nice, but I think you could get that in Office by using an Excel spreadsheet as the shell doc.
A few years back, my Mom wanted to buy a computer. She asked my older brother what to get. "Don't buy an IBM AT, buy a compatible with a 386." She in turn asked my other brother, and me, and we all gave the same answer: get a 386.
So she bought an IBM PC AT with a 286 and 512 KB of RAM. "Why?!?!?" I asked.
"Well, the salesman told me it was the fastest computer they made." Okay, the AT he sold her was an 8 MHz 286, not the usual 6 MHz 286, and that did in fact make it the fastest PC AT that IBM ever made. But any 386 would have smoked it, and been able to run real software as well.
Not a vendor lie story, but still interesting, is the postscript to this story. After a year or so, the power supply in her AT died. As it died, it fried her motherboard too. We contacted IBM, and they informed us that we would have to ship the computer to them, then wait 6 to 8 weeks, for a repair; there would be no guarantee of any sort on the repair; and it would cost $X00 (I don't remember exactly how much but it was a lot). And of course after all this she would still have a 286 running at 8 MHz.
We went down to a friendly local computer shop. They installed a new power supply, a new motherboard with a 386SX and 2 MB of RAM, and a new VGA-compatible display adapter. They burned it in overnight to make sure all was working, and we picked it up the next day. Total cost was less than IBM had wanted to repair the AT.
I like to tell this story when people don't understand why I like my computers to be made from standard, easily-replaceable parts. (Apple's new iMac is cute, but I don't want one.)
My mom still has that computer, by the way, and it still works.
Well, to be precise, the worst-case value "degraded". And I'm not sure "degraded" is the correct word. With a huge torture load put on the kernel, during a 15-hour interval, at least once the latency value was 215.2 msec. This could mean that there is a possible latency condition that happens under torture load approximately once every 15 hours. It could also mean that after 15 hours, your chance goes up so it could happen much more often than that, but we don't know that. It could even mean that there is a possible 215 msec latency condition that happens under torture load approximately once every 30 hours, and it happened to occur during the first 15 hours.
Embedded systems must have a very high uptime, it's not acceptable to reboot the machine every day to maintain performance.
True that. Which is why the author of that article made the point that combining the two patches is the best way to go, since he ran the torture test for 15 hours and it didn't go over 1.5 msec even once.
Note that for many purposes, a worst-case latency of 1.5 msec is ample. I don't think there is any version of Windows that goes that low; I don't even think BeOS (legendary for low latency) goes that low. As the author noted, if you are driving a chemical processing factory or something like that, you need hard realtime and you should use something other than Linux kernel 2.4.x!
If you want to use a parallel-port based gadget with one of these, you will either need to use one of the PCI slots to get a parallel port, or else use a 1394-to-parallel adapter. Or a USB-to-parallel adapter, if you don't mind the speed hit (USB isn't quite as fast as a parallel port running in 1284 mode).
But all the new stuff is either USB or 1394 anyway, so I doubt that many people will care.
P.S. It has two serial ports! Two serial ports and no parallel. I guess it was just a question of what they could fit in there...
That's not a floppy disk bay, that's a 3.5" device bay.
You can put a tape drive there, a Zip drive, and Orb drive... many possibilities.
Even a floppy comes in handy sometimes, too!
But I think I would like one of these better if they made it with two 5.25" device bays, one of which came with a bracket for 3.5" devices. Then you would have even more options, and the case need not be much larger.
Although you said several times "there were no standards" you also said several times "Alt was used for something". I have programmed PCs for 20 years and I worked with Lotus and early MSWord and many other programs. Ctrl was rarely used for anything other than Emacs emulation,
I'm still not sure what you are talking about. Look at WordStar -- it did everything with Ctrl keys, didn't use Alt keys at all. PC Write used Ctrl keys and Alt keys and function keys, with only function keys used to bring up menus. Lotus 1-2-3 used its "slash key" system for bringing up menus. I can't remember any rhyme or reason anywhere to DOS apps and keys, but I definitely remember Ctrl keys being used all over the place.
And emacs emulation!? I don't remember anything with emacs emulation. WordStar emulation was extremely common, but the average PC user didn't know what emacs was.
By the way, I've programmed PCs for nearly 20 years. My first PC programming was with Borland Turbo Pascal 2.0.
the problem is that for some reason they said "Ctrl+key" selects menu items, rather than "Alt+Key".
Look, I never used Windows before 1989, so I suppose that this could have been true for Windows 1.x or something. But I have never, ever seen any windowed software from Microsoft that did not use Alt+key for choosing menus and dialog stuff. I include OS/2 PM, Windows 2.x and newer, and character-oriented Windows (COW) apps like Word for DOS 5.5 and 6.0.
Are you talking about Windows 1.x?
I agree that Ctrl+letter should be a shortcut for cutting and pasting text. However the MicroSoft design means that these letters must also be used for cutting and pasting anything and this has seriously hurt GUI design because you cannot have a text field on the same window as any other selectable objects.
I will only make one comment: I do like having universal behaviors... if you can copy text to the clipboard, or copy an object, I like only having to remember one key to do it. But I'm sure that MS could make some improvments to their UI.
Please take a look at the history. Yes there were many programs where neither ctrl+x or alt+x did menu shortcuts. But there were 3 or 4 years of alt+letter doing menu shortcuts before ctrl+letter was used for this.
What do you mean "menu shortcuts"? In DOS apps, you never knew what Ctrl or Alt might do until you read the manual. Some apps used both keys. With Windows, Microsoft put forth a standard where Alt plus a letter or number would be used only for pulling down a menu or doing something in a dialog: Alt+S would only do something if there was a menu or dialog active that uses S as a shortcut, but Ctrl+S is outside the menu/dialog structure completely.
Do you at least agree with me that Microsoft was consistent from Windows 2.x onward?
I also get disgusted with all the people complaining "Linux is inconsistent, do I use Alt+X or Ctrl+X to cut text" when this is entirely MicroSoft's fault for changing standards right in the middle.
As I said, I don't remember MS changing standards, but I won't rehash that here. I will point out that GNOME apps are all consistent, and KDE apps should all be consistent. It's only older apps (like Motif-based Netscape Navigator) that vary.
Apps expected to use ctrl keys to do stuff, and apps were not as complicated as they are these days, so you saw a lot of Ctrl+P for print and Ctrl+S for save. (And in those days they wrote them as ^P and ^S; it was only in the PC days, with Ctrl and Alt and Shift being used with wild abandon that the "Ctrl+" notation became common.)
Microsoft's original Windows standard was mnemonic Ctrl keys. Microsoft went from Ctrl+S to Shift+F12 back to Ctrl+S. The Mac keyboard had nothing to do with this. As I said, IBM had their CUA (Common User Access, if memory serves) which called for weird shortcuts like F12 == Save As, Shift+F12 == Save, and Ctrl+Shift+F12 == Print (or whatever it was).
The Mac was responsible for Microsoft adopting Ctrl+V for paste, and Ctrl+X for cut. Paste used to be the Insert key, and cut used to be Shift+Del.
most logical people would take that to mean that MicroSoft wanted Alt+letter to mean "shortcuts" and that it should cause menu items to *execute*, to match the buttons. Instead the &x in menu items "navigated" to that menu item, completely different from what it did in buttons!
No, Windows was always, always consistent about how this worked. Hitting Alt+ would always do the same thing as clicking with the mouse on the thing that showed underlined. If a menu item said "Save _A_s..." and you hit Alt+A, it would open the "Save As..." dialog. If a menu item said "_P_rint!" and you hit Alt+P, it would immediately print (items with a '!' would happen immediately without a menu... MS has walked away from that particular idiom though).
Every program up to then used Alt+letters as "shortcuts" whether that caused a menu item to be picked, a button to be pushed, or something to happen that you could not do with a GUI.
DOS apps also used Alt keys, and Ctrl+Alt, and so on. There was no standard. When Windows appeared, Microsoft put out a standard, and even DOS apps started following it (when they mimiced Windows in character mode): Ctrl+key does something immediately, Alt+key does something in a menu or dialog, and Alt+Fkey does window-related stuff. (Alt+F4 quits the app, Alt+spacebar brings up the "window menu", Alt+Tab jumps to next window, etc.)
This screw up has greatly hurt the ability to have fast editing (with Emacs or similar control functions in text fields) and screwed up GUI design by requiring that the "focus" be able to move to non-text objects so that Ctrl+X can cut a non-text object (more practically it has required that all text entry fields be on pop-up windows so that average users are not confused by the need to move the focus).
I really have no idea what you are talking about here. Text-entry fields are by no means always in pop-up windows. Text fields have always had Ctrl keys for editing: Ctrl+X cuts to clipboard, Ctrl+V pastes, etc. (Back in the IBM CUA days it was of course Shift+Del to cut to clipboard, Shift+Insert to copy to clipboard, and Insert to paste.) Ctrl+Tab jumps to the next field, Ctrl+Z undoes the editing, and so on. I'm sure you would love an emacs mode, and I would love a vi mode, but Windows will never offer either.
I am pretty certain that ctrl+P dates back to command.com. That program was incapable of detecting the PrtSc or any other function key if written in "portable MSDOS" that did not use the IBM PC Bios, thus all functions had to be on control keys.
Every app always used Ctrl keys since before PCs. If you were using a dumb terminal like an ADM3A, control keys were what you had, and there were some standards (under UNIX at least): Ctrl+S pauses the flow of text, Ctrl+Q restarts it, etc. The very first DOS apps used Ctrl keys as well as function keys. Yes, Ctrl+P special meaning in the DOS days, but that was mostly in the command shell; DOS apps would override it and there wasn't any real confusion. DOS apps also used Alt keys, and Ctrl+Alt, and so on. There really were no standards.
I'm curious to know why Novell was using this trick, anyway. Why did they need to be able to run real-mode code on a Netware server? I would have thought they could just recompile all their server software for protect mode. Were there plug-in modules for Netware, with which they needed to preserve binary compatibility?
There were always compatibility libs. Microsoft never made a true OS/2 version of Word; they compiled Windows Word with a library called WLO (pronounced "willow", acronym for Windows Libraries for OS/2).
But the 286 was marginal at best for a GUI, and memory was expensive in those days, and the added bloat and inefficiency of compatibility libs meant that they were a last resort.
I think you probably meant 1986 and 1987, not 1996 and 1997. Otherwise of course I agree with you (agreeing with me).
There were even new UI standards and APIs for interoperability with character-mode 3278 terminals!
Is that where IBM came up with their CUI stuff? I remember: F12 was save, Ctrl+Shift+F12 (or something like that) was Print, etc. etc.
Originally, Microsoft apps used Ctrl+S for Save, Ctrl+P for Print, and so on. While Microsoft was trying to be friends with IBM, apps like Word adopted IBM's standard. Later, after the divorce, Microsoft went back to Ctrl+S and Ctrl+P.
I always wondered where IBM got the idea that function key combinations were better than Ctrl+P.
I didn't say Microsoft discovered this trick; I said they used this trick in OS/2.
And I couldn't forget that Novell had done it first, since I never knew Novell had done it in the first place. I would thank you for the information, but your abrasive tone makes me feel somewhat less grateful. Don't you feel good knowing you made my day a little less cheerful?
Pardon me--I have to go jump off a cliff into the ocean now.
What exactly in the in the 286 architecture prevents the use of a multitasking operating system?
That was not the problem. The problem was writing a multiasking operating system that would run all the DOS apps (which were important at the time).
When the 286 was in protect mode, some of the instructions worked differently than when it was in "real" mode (8086 compatibility mode). Result: you could not execute DOS apps; they wouldn't work.
So, how about making a DOS virtual machine? Well, the 386 has features that make it easy to spin up multiple real mode virtual machines, but the 286 didn't have those features. A purely software virtual machine would be very slow.
So, how about switching out of protect mode and running real mode code in the 286's real mode? That was the only option, so Microsoft took it. However, Intel had not designed the 286 to do this. There was an instruction to start up protect mode, but no instruction to leave it and go back to real mode! Microsoft wound up programming the keyboard controller chip to actually reset the CPU, many times per second, to switch to real mode.
Because DOS apps ran in real mode, they owned the whole machine: all memory, all devices, etc. So if a DOS app crashed, it would take the whole machine down with it; a crashing DOS app could trash OS/2, and there was no way to prevent it.
Even worse, the 286 did not have features that would let you virtualize the hardware, and DOS apps liked to talk directly to the hardware. All DOS apps liked to write directly to the video card, rather than going through the BIOS, and the 286 didn't really help you solve that problem.
So the OS/2 1.x "compatibility box" could only run a single DOS app at a time.
Meanwhile, Microsoft sold Xenix 286, which worked perfectly well. Alas your Xenix 286 programs either had to be less than 64KB each, or else they had to deal with near/far pointers (yuck), but Xenix 286 worked. Microsoft never tried to do a GUI desktop for Xenix, but it would have been possible.
It appears to me that the article writer is trying to excuse Microsoft's lack of skill by pretending that the task was impossible.
No, it really was impossible to write an OS that would run decently fast on the 286 hardware of the day, would multiask old DOS apps, and would be reliable. The 286 was just too broken.
I read through the article, and it was full of weird conclusions. I am very familiar with what was going on in the computer industry during the time period discussed, and I disagree with much of the article.
The story of OS/2 is what taught me that in the computer industry, revolution is not what the customers want; they want evolution. You can sometimes pull off a revolution (Macintosh) but it is much easier to offer a smooth upgrade path.
OS/2 was not killed by some weird conspiracy by Microsoft. Some of the other causes of death listed were not doubt contributing factors, but the major cause of death was: incompatible APIs.
It was not possible to take a Windows application and compile it for OS/2; you had to substantially re-write your app. It wouldn't be quite as much work as re-writing your app from scratch, but it was close. Microsoft didn't want this. Microsoft wanted to make OS/2's windowing API compatible with Windows, but IBM had some other API they thought was better, and they insisted it be used.
This had the effect of forcing companies to decide whether they wanted to write for Windows, or write for OS/2. That was totally dumb of IBM. If people could have just recompiled for OS/2 and offered an OS/2 version of their app, they would have done so. IBM was asking developers for a revolution, not evolution.
But let's go back to the first version of OS/2. Because it was written for the 286, its compatibility with DOS apps was poor. OS/2 1.x offered a "compatibility box" for running a single DOS app at a time; it worked poorly, and it was often called the "Chernobyl Box" because it would often crash (and it would take the whole OS down with it). So, any company that wanted to adopt OS/2 had to plan on getting new versions of all their applications.
But in 1990, Windows 3.0 shipped. It sold like hotcakes. The article makes some bizarre statements about Win 3.0, but the reality was that it would multitask your DOS applications very well. DOS applications were preemptively multitasked, not cooperatively, and DOS apps could very well crash but usually Windows would not crash with them. In other words, Win 3.0 allowed companies an evolutionary upgrade path: they could keep running the same DOS apps they were using, and then phase in Windows apps over time. The same companies that were unwilling to commit to OS/2 were willing to commit to Win 3.0.
Win 3.0 was what made Microsoft decide to walk away from OS/2. The customers were voting with their dollars, and what they were voting for was Windows. It didn't hurt that Microsoft had covered all bets: they had applications for DOS, Windows, OS/2, and Macintosh. (They even flirted with a few other platforms: my favorite word processor for the Atari ST was Microsoft Write.) When Win 3.0 took off, Microsoft was ready, and sold lots of Word and Excel.
So, to review: IBM forced developers to choose whether to develop for OS/2 or Windows, and Windows became a runaway hit. That's it right there. That's what killed OS/2.
It would actually work: use a thermal probe to actually hook up the temperature guage, hook the voltage guage up to the +12V on the power supply (but it would be very boring on a good power supply, so maybe you should hook it up to a drive light or something). Not sure what to do with oil pressure. Maybe sound volume to speakers?
I think this would be a good use for those "Tokyo-by-night" guages, with LEDs instead of moving needles. That way you wouldn't hear the sound of needles beating against the stop post when the values fluctuated...
Back in my Apple ][ days, there was a gadget that I lusted after. It was an array of LEDs, 16x16 (256 in all), and it was connected to the 8-bit memory bus on the Apple ][. Since you only had 64KB of memory space, each of the 256 LEDs mapped onto a 256-byte chunk of address space. The lights would light up for each access to that chunk.
It would have been very interesting to watch the lights during, say, garbage collection in BASIC.
It would still be fun to have something like that on a grander scale, perhaps docked near my CPU meter in my GNOME desktop.
While I never got the LEDs gadget, I did take an AM radio and set it up on top of my computer, volume turned down low. The RF interference made a distinct sound, which changed pitch when something different happened. If the computer went into an infinite loop, you could hear it. I got tired of the noise, though, so I don't do this anymore.
Libertarianism, the general philosophy, is based on the idea that you own yourself and the fruits of your labor, and that you have the right to decide what is best for yourself. A libertarian government would be very small and do very little: it would enforce the laws against fraud and force, and it would enforce contracts, and it would handle national defense. "Victimless" crimes (such as using drugs, or paying for sex) would not be crimes. If you had cancer and wanted to take an experimental drug, there would be no FDA to forbid you to do it. It would still be illegal to hurt people or steal their stuff, or fool people into giving their money to you. Pollution would still be regulated but the mechanisms used might be different from what you see today.
Sadly, while most people would love to live in a libertarian society, almost everyone has some pet feature of government that they like, or else they don't want other people to be fully free, or both. (For example, some people who disapprove of drugs want drugs to be illegal.) Take the union of all the things people want government to do, and you have a large, complex government.
As this is off the main topic, I won't make this much longer, but will close with two final points:
0) libertarians don't, as a rule, want poor people to suffer and die; rather they think private charities would do a better job of helping the poor.
1) Not only do libertarians want to end things like welfare, but they also want tax burdens to be remarkably lower. Right now charities get lots of donations, even though the tax rate is over 50% for most people (add up state and federal income tax, sales and restaurant taxes, car and gas tax, etc. etc. and include things like Social Security "contributions" and you will go over 50% quickly). If the overall tax rate for people went down to 10% or less, charitable contributions would increase.
If I remember right the keyboard interface could report the state of the shift keys, the problem was that certain key combinations produced nothing, ie you could not tell if they had been typed by using the BIOS.
Right. You would call the "get a key" interrupt, and it would return one byte for the key. If the one byte was a certain escape byte, then the key was an "extended" key and you had to check another byte for its value. 256+256 = 512, so there were less than 512 possible keys under this system. I don't remember anymore whether you had to make a second BIOS call to get the extended key value, or just look in a different register.
In any event, it would only return keys in its list. So if the number pad was in Num Lock mode, and you hit the 5 key, you would get a 5, but if the Num Lock was not set and you hit the 5 key, you got no key back. If you wanted to do anything with that key, you could not go through the BIOS.
I just did a web search to check. You are right and I was wrong. I am sure that I remember that there was some lack in the BIOS that made it annoying to print strings, but now I'm not sure what it was. Maybe it was just the speed thing; if you do your own MOVS you will be faster than if you make the BIOS call. I do note that if you are doing color text, the BIOS call can only do one color (well, character attribute byte, to be precise) per string. So if you have a string and parts of it should display in different attributes (to make your word processor more interesting) then you would need to make lots of calls to the display string interrupt.
And come to think of it, the situation with graphics was worse than the situation with text. Back in the day, Microsoft Flight Simulator was used as a compatibility test for PC compatible computers; if you couldn't run Flight Simulator, you weren't compatible enough. Graphics was already slow on those machines, and the additional overhead of doing pixels through the BIOS was a non-starter. So it was probably graphics more than text that locked down the 640k limit.
- MDA text was at $b000 (as well as hercules graphics), CGA was at $b800, only the latter EGA used $a000.
But by the time the 640KB limit really started to hurt, EGA graphics were important.
The bios was more like the drivers (basic io, right?).
That's what I meant when I said the BIOS abstracted the hardware.
Nothing prevented Microsoft to implement a usable hardware abstraction (that's what an OS if for, right?). They didn't.
It's true, MS could have fixed the holes in the BIOS by adding more stuff to DOS. I wonder why they didn't.
I used to work at MS, and I would guess that the MS-DOS guys and the application guys simply didn't talk that much. They may also have wanted to keep DOS small. Probably also DOS was viewed as a dead end, and all the serious development was going on for Windows and OS/2.
Back in the day, I remember people saying that Windows would never go anywhere because doing everything in graphics mode was too slow. I figured that Moore's Law would fix things, and that the much better hardware abstraction would be a huge improvement. (I never want to return to the days where you needed a new driver for each of your applications if you had an unusual video card!)
Guys, I can't believe no one has yet posted the true reason why the 640K limit was a problem. Well, I'll explain it.
The IBM PC BIOS was designed to abstract the hardware. These days Linux or Windows do that for us, but in those days the BIOS was what you had. Your DOS programs were never supposed to talk to the hardware, they were supposed to go through the BIOS.
The problem was that the BIOS sucked. Want to draw a character on the screen? Fine; there is a BIOS call for that. (BIOS calls were called "interrupts" because you used an interrupt to call them, but I'll just call them "BIOS calls".) Want to draw a whole string of characters on the screen? You would think there would be a BIOS call for that too, right? But there wasn't. You would have to do one interrupt per character, and poke your string onto the screen one character at a time! And interrupts were really expensive; remember that we are talking a 4.7 MHz chip with slo-o-o-o-w memory.
And suppose you wanted to read the keyboard? Not a problem; there was a BIOS call for that. Of course, it had a few limitations: it could only recognize a little more than 500 distinct keypresses. If your app wanted to recognize Alt+F1, no problem, that was one of the recognized keys. But if you wanted to recognize Ctrl+Alt+Shift+F1, too bad. The obvious and correct way to read the keyboard is to return the scan code for which key was pressed, coupled with a chord of which shift keys were down (e.g. Ctrl and Alt were down, shift wasn't, or whatever). With two bytes of data, you could handle any combination of Alt+Shift+Ctrl+whatever. But the BIOS didn't do it that way.
There are other examples, but I think those two are enough. Given this broken a BIOS, the application writers all decided to go around the BIOS and talk directly to the hardware. Get the address of the keyboard controller, find out what keys the user hit, and support any combination of keys you want. Get the address of the video card's character buffer, and use MOVS to blast a string into it with zero overhead. Now your copy of Microsoft Word 1.0 runs much faster than if it used the BIOS.
Guess what address the video card was at? That's right, 640K. By the time people began seriously hurting for more address space, there was way too much software out there writing directly into the character buffer of the video card, so it was now too late to move the buffer somewhere else. The 640K limit was set in stone.
Even if everyone had used the BIOS, there would have still been a 1024K limit, since that's all you could address on an 8088. But that would have been much better, and it would have been much easier to write environments like DesqView. (You could have done something like DesqView on an 8088 if it only had to run well-behaved apps, i.e. apps that never went to the hardware but always went through the BIOS.)
P.S. Slightly offtopic, but I have fond memories of using a multitasking environment called OmniView. It did much the same thing as DesqView, except that it didn't try to do the overlapping windows thing with the apps; it ran your apps full-screen. You could use function key combos to switch your full screen among app sessions, almost exactly like using Ctrl+Alt+Fn in Linux to switch full-screen among virtual ttys. DesqView got the fame and fortune, but OmniView was a little bit more efficient and I got some real work done using it on my 33 MHz 386 system. I used to run compiles in parallel: one compile would cause the disk to load the source, and the other compiles that used the same source file would find the data already buffered. I could finish four compiles in only a little more time than a single compile took on its own; the compiles were fairly disk-bound.
I like putting computers together. I always try to keep the RF shielding intact. This computer has no RF shielding at all.
How much of a problem is that, anyway? If his next-door-neighbor is an amateur radio enthusiast, will the clear computer mess up the airwaves? If he wants to watch TV, will the computer ruin the picture? Can he stop pacemakers at 50 yards or something?
I don't have any clear idea how serious the emissions from computer hardware really are.
He removed the metal case so the guts of the power supply are visible. He took the face off his DVD drive so you can see inside. Even his hard disk has been modded with a window showing the platter and the read/write head.
My favorite quotes:
"Needle files are a modder's secret weapon."
"Yes, I did polish the heads on the fasteners. Thanks for noticing."
What about a UI that learns from the user and configures itself?
In the article, Jef Raskin said that your subconscious learns its way around an interface, and customization is bad because it changes what you have to learn. Here are his words:
When you use an interface for a given amount of time, your subconscious mind records its intricate UI elements, allowing you to focus on the task at hand rather than on navigating the interface.
When that interface is inconsistent, however, your conscious mind must work harder to accomplish the same task that a consistent UI would have allowed you to complete far more efficiently.
I think he would hate auto-configuring interfaces even more than he hates configurable ones.
In this interview, Jef Raskin comes off as rather arrogant. He seems absolutely convinced that there is an objective, scientific, Best Way for everything about interfaces.
I'm not convinced. One person might actually work better with white text on a deep blue background, or whatever. I can think of other examples.
With Mr. Raskin it is all-or-nothing: if you work for him, you don't get to customize anything, unless you convince him that you really have a better idea (in which case he switches too, and everyone else who works for him has to switch too.
His supporting arguments didn't impress me much either. A "Preferences" dialog makes an app consume more resources? Not enough to matter, I'd say. That's like saying that putting foam cushions on a car seat makes the car heavier.
The absolute gem of a quote, though, was this one:
Of course, there are no really well-designed interfaces out there good enough to prove the point that you don't need preferences. Any programmers who want to help build one with me, drop me an e-mail.
Maybe he can actually create an interface so amazing, so perfect, so right that no one would ever be able to improve upon it. I won't hold my breath, though.
Slashdot Mirror
the truth is the truth, and debian is against ease of use.
You are so wrong.
The Debian project is not just one person; it is thousands of people, all working together in a loose organization. I'm sure that if you interviewed everyone, you could find a few who actually want Debian to be hard to use. But most of the people working on Debian want it to be easy to use. We want it to be the best it can be.
The excellent Stormix installer, and the excellent Corel Linux installer, are excellent non-free installers. They are not available to the Debian project.
Also, Debian is very serious about supporting Linux on multiple architectures: Sparc, PowerPC, even Motorola 68K... and the current text-based installer runs everywhere. The Progeny Installer is not only available to Debian, but it was built in a modular way, and it leverages XFree86 instead of using some x86-specific video mode; so it should be possible to get PGI running on all the architectures Debian supports.
Debian isn't stuck in 1996. It is true that it takes the Debian project longer to get some things done than other versions of Linux take... but everyone is a volunteer (the Debian project doesn't have money to pay people) and when things do finally get done they really work right.
steveha
Why hasn't Debian project adopted the Corel Linux (nowadays Xandros Linux) installer? [...] Is the installer non-free software or what is the reason?
It is non-free. I have not heard or read anything, anywhere, about Xandros being willing to donate it. It is one of the things Xandros was paying for when it bought Corel Linux, so perhaps they are not in a hurry to give it away.
But I have to say that PGI is actually better than the Corel Linux installer (call it CI for short).
CI has no text-based install. It only installs in GUI mode, so there is nothing you can do if it cannot handle your graphics card. And since it is non-free software, you have no chance of fixing the installer on your own.
If CI cannot handle your graphics card, the officially recommended workaround is: pull out your graphics card, put in one it understands, install, pull out the card it understands, put back your original graphics card, and then tweak XFree86 to deal with your card. (Corel Linux 1.0 could not deal with my GeForce2; I know all this from experience.)
PGI on the other hand does its GUI stuff with XFree86, so as XFree86 adds video cards, PGI gets them too. If your system will be able to use the card when the install is done, you should be able to run the GUI installer.
steveha
I read the review. From the way the features were described, this doesn't sound like a product in the same league as Office XP; it's more of a Microsoft Works level product.
If it truly has 100% compatible document import/export, then people might feel comfortable using it as a replacement for Office on some desktops (much as StarOffice is being used now in many companies).
I especially like the licensing. I hope that they sell many copies to families with new computers.
On Linux, I don't think they have much chance of making money. The word processor sounds like it is pretty similar to AbiWord in available features. The spreadsheet sounds like it is not quite up to Gnumeric's level yet. Graphics are not up to the GIMP yet (although they might be a bit more newbie-friendly; I couldn't really tell from the review). In short, there is very little functionality here that is not available already in the free software. Most of the people interested in using Linux probably won't be interested in paying for software that offers little beyond what is already free on Linux.
The integration features are sort of interesting. When you do a Save As on a document with a spreadsheet, several pictures, and some text, I wonder what happens?) Microsoft Office has had features like this since forever, though: you can pick one document to be a shell and drop other documents into it, or else you can run the "binder" and make a metadocument with several other documents bound up inside. (I think most people just do the shell document thing; MS has mostly retired the binder. You can still install it if you like but it is no longer installed by default.) The clean "sheets" interface is nice, but I think you could get that in Office by using an Excel spreadsheet as the shell doc.
steveha
A few years back, my Mom wanted to buy a computer. She asked my older brother what to get. "Don't buy an IBM AT, buy a compatible with a 386." She in turn asked my other brother, and me, and we all gave the same answer: get a 386.
So she bought an IBM PC AT with a 286 and 512 KB of RAM. "Why?!?!?" I asked.
"Well, the salesman told me it was the fastest computer they made." Okay, the AT he sold her was an 8 MHz 286, not the usual 6 MHz 286, and that did in fact make it the fastest PC AT that IBM ever made. But any 386 would have smoked it, and been able to run real software as well.
Not a vendor lie story, but still interesting, is the postscript to this story. After a year or so, the power supply in her AT died. As it died, it fried her motherboard too. We contacted IBM, and they informed us that we would have to ship the computer to them, then wait 6 to 8 weeks, for a repair; there would be no guarantee of any sort on the repair; and it would cost $X00 (I don't remember exactly how much but it was a lot). And of course after all this she would still have a 286 running at 8 MHz.
We went down to a friendly local computer shop. They installed a new power supply, a new motherboard with a 386SX and 2 MB of RAM, and a new VGA-compatible display adapter. They burned it in overnight to make sure all was working, and we picked it up the next day. Total cost was less than IBM had wanted to repair the AT.
I like to tell this story when people don't understand why I like my computers to be made from standard, easily-replaceable parts. (Apple's new iMac is cute, but I don't want one.)
My mom still has that computer, by the way, and it still works.
steveha
Well, to be precise, the worst-case value "degraded". And I'm not sure "degraded" is the correct word. With a huge torture load put on the kernel, during a 15-hour interval, at least once the latency value was 215.2 msec. This could mean that there is a possible latency condition that happens under torture load approximately once every 15 hours. It could also mean that after 15 hours, your chance goes up so it could happen much more often than that, but we don't know that. It could even mean that there is a possible 215 msec latency condition that happens under torture load approximately once every 30 hours, and it happened to occur during the first 15 hours.
Embedded systems must have a very high uptime, it's not acceptable to reboot the machine every day to maintain performance.
True that. Which is why the author of that article made the point that combining the two patches is the best way to go, since he ran the torture test for 15 hours and it didn't go over 1.5 msec even once.
Note that for many purposes, a worst-case latency of 1.5 msec is ample. I don't think there is any version of Windows that goes that low; I don't even think BeOS (legendary for low latency) goes that low. As the author noted, if you are driving a chemical processing factory or something like that, you need hard realtime and you should use something other than Linux kernel 2.4.x!
steveha
If you want to use a parallel-port based gadget with one of these, you will either need to use one of the PCI slots to get a parallel port, or else use a 1394-to-parallel adapter. Or a USB-to-parallel adapter, if you don't mind the speed hit (USB isn't quite as fast as a parallel port running in 1284 mode).
But all the new stuff is either USB or 1394 anyway, so I doubt that many people will care.
P.S. It has two serial ports! Two serial ports and no parallel. I guess it was just a question of what they could fit in there...
steveha
That's not a floppy disk bay, that's a 3.5" device bay.
You can put a tape drive there, a Zip drive, and Orb drive... many possibilities.
Even a floppy comes in handy sometimes, too!
But I think I would like one of these better if they made it with two 5.25" device bays, one of which came with a bracket for 3.5" devices. Then you would have even more options, and the case need not be much larger.
steveha
Although you said several times "there were no standards" you also said several times "Alt was used for something". I have programmed PCs for 20 years and I worked with Lotus and early MSWord and many other programs. Ctrl was rarely used for anything other than Emacs emulation,
I'm still not sure what you are talking about. Look at WordStar -- it did everything with Ctrl keys, didn't use Alt keys at all. PC Write used Ctrl keys and Alt keys and function keys, with only function keys used to bring up menus. Lotus 1-2-3 used its "slash key" system for bringing up menus. I can't remember any rhyme or reason anywhere to DOS apps and keys, but I definitely remember Ctrl keys being used all over the place.
And emacs emulation!? I don't remember anything with emacs emulation. WordStar emulation was extremely common, but the average PC user didn't know what emacs was.
By the way, I've programmed PCs for nearly 20 years. My first PC programming was with Borland Turbo Pascal 2.0.
the problem is that for some reason they said "Ctrl+key" selects menu items, rather than "Alt+Key".
Look, I never used Windows before 1989, so I suppose that this could have been true for Windows 1.x or something. But I have never, ever seen any windowed software from Microsoft that did not use Alt+key for choosing menus and dialog stuff. I include OS/2 PM, Windows 2.x and newer, and character-oriented Windows (COW) apps like Word for DOS 5.5 and 6.0.
Are you talking about Windows 1.x?
I agree that Ctrl+letter should be a shortcut for cutting and pasting text. However the MicroSoft design means that these letters must also be used for cutting and pasting anything and this has seriously hurt GUI design because you cannot have a text field on the same window as any other selectable objects.
I will only make one comment: I do like having universal behaviors... if you can copy text to the clipboard, or copy an object, I like only having to remember one key to do it. But I'm sure that MS could make some improvments to their UI.
Please take a look at the history. Yes there were many programs where neither ctrl+x or alt+x did menu shortcuts. But there were 3 or 4 years of alt+letter doing menu shortcuts before ctrl+letter was used for this.
What do you mean "menu shortcuts"? In DOS apps, you never knew what Ctrl or Alt might do until you read the manual. Some apps used both keys. With Windows, Microsoft put forth a standard where Alt plus a letter or number would be used only for pulling down a menu or doing something in a dialog: Alt+S would only do something if there was a menu or dialog active that uses S as a shortcut, but Ctrl+S is outside the menu/dialog structure completely.
Do you at least agree with me that Microsoft was consistent from Windows 2.x onward?
I also get disgusted with all the people complaining "Linux is inconsistent, do I use Alt+X or Ctrl+X to cut text" when this is entirely MicroSoft's fault for changing standards right in the middle.
As I said, I don't remember MS changing standards, but I won't rehash that here. I will point out that GNOME apps are all consistent, and KDE apps should all be consistent. It's only older apps (like Motif-based Netscape Navigator) that vary.
steveha
Sorry, I can't agree with a lot of what you said.
Apps expected to use ctrl keys to do stuff, and apps were not as complicated as they are these days, so you saw a lot of Ctrl+P for print and Ctrl+S for save. (And in those days they wrote them as ^P and ^S; it was only in the PC days, with Ctrl and Alt and Shift being used with wild abandon that the "Ctrl+" notation became common.)
Microsoft's original Windows standard was mnemonic Ctrl keys. Microsoft went from Ctrl+S to Shift+F12 back to Ctrl+S. The Mac keyboard had nothing to do with this. As I said, IBM had their CUA (Common User Access, if memory serves) which called for weird shortcuts like F12 == Save As, Shift+F12 == Save, and Ctrl+Shift+F12 == Print (or whatever it was).
The Mac was responsible for Microsoft adopting Ctrl+V for paste, and Ctrl+X for cut. Paste used to be the Insert key, and cut used to be Shift+Del.
most logical people would take that to mean that MicroSoft wanted Alt+letter to mean "shortcuts" and that it should cause menu items to *execute*, to match the buttons. Instead the &x in menu items "navigated" to that menu item, completely different from what it did in buttons!
No, Windows was always, always consistent about how this worked. Hitting Alt+ would always do the same thing as clicking with the mouse on the thing that showed underlined. If a menu item said "Save _A_s..." and you hit Alt+A, it would open the "Save As..." dialog. If a menu item said "_P_rint!" and you hit Alt+P, it would immediately print (items with a '!' would happen immediately without a menu... MS has walked away from that particular idiom though).
Every program up to then used Alt+letters as "shortcuts" whether that caused a menu item to be picked, a button to be pushed, or something to happen that you could not do with a GUI.
DOS apps also used Alt keys, and Ctrl+Alt, and so on. There was no standard. When Windows appeared, Microsoft put out a standard, and even DOS apps started following it (when they mimiced Windows in character mode): Ctrl+key does something immediately, Alt+key does something in a menu or dialog, and Alt+Fkey does window-related stuff. (Alt+F4 quits the app, Alt+spacebar brings up the "window menu", Alt+Tab jumps to next window, etc.)
This screw up has greatly hurt the ability to have fast editing (with Emacs or similar control functions in text fields) and screwed up GUI design by requiring that the "focus" be able to move to non-text objects so that Ctrl+X can cut a non-text object (more practically it has required that all text entry fields be on pop-up windows so that average users are not confused by the need to move the focus).
I really have no idea what you are talking about here. Text-entry fields are by no means always in pop-up windows. Text fields have always had Ctrl keys for editing: Ctrl+X cuts to clipboard, Ctrl+V pastes, etc. (Back in the IBM CUA days it was of course Shift+Del to cut to clipboard, Shift+Insert to copy to clipboard, and Insert to paste.) Ctrl+Tab jumps to the next field, Ctrl+Z undoes the editing, and so on. I'm sure you would love an emacs mode, and I would love a vi mode, but Windows will never offer either.
I am pretty certain that ctrl+P dates back to command.com. That program was incapable of detecting the PrtSc or any other function key if written in "portable MSDOS" that did not use the IBM PC Bios, thus all functions had to be on control keys.
Every app always used Ctrl keys since before PCs. If you were using a dumb terminal like an ADM3A, control keys were what you had, and there were some standards (under UNIX at least): Ctrl+S pauses the flow of text, Ctrl+Q restarts it, etc. The very first DOS apps used Ctrl keys as well as function keys. Yes, Ctrl+P special meaning in the DOS days, but that was mostly in the command shell; DOS apps would override it and there wasn't any real confusion. DOS apps also used Alt keys, and Ctrl+Alt, and so on. There really were no standards.
steveha
I'm curious to know why Novell was using this trick, anyway. Why did they need to be able to run real-mode code on a Netware server? I would have thought they could just recompile all their server software for protect mode. Were there plug-in modules for Netware, with which they needed to preserve binary compatibility?
steveha
There were always compatibility libs. Microsoft never made a true OS/2 version of Word; they compiled Windows Word with a library called WLO (pronounced "willow", acronym for Windows Libraries for OS/2).
But the 286 was marginal at best for a GUI, and memory was expensive in those days, and the added bloat and inefficiency of compatibility libs meant that they were a last resort.
steveha
I think you probably meant 1986 and 1987, not 1996 and 1997. Otherwise of course I agree with you (agreeing with me).
There were even new UI standards and APIs for interoperability with character-mode 3278 terminals!
Is that where IBM came up with their CUI stuff? I remember: F12 was save, Ctrl+Shift+F12 (or something like that) was Print, etc. etc.
Originally, Microsoft apps used Ctrl+S for Save, Ctrl+P for Print, and so on. While Microsoft was trying to be friends with IBM, apps like Word adopted IBM's standard. Later, after the divorce, Microsoft went back to Ctrl+S and Ctrl+P.
I always wondered where IBM got the idea that function key combinations were better than Ctrl+P.
steveha
I didn't say Microsoft discovered this trick; I said they used this trick in OS/2.
And I couldn't forget that Novell had done it first, since I never knew Novell had done it in the first place. I would thank you for the information, but your abrasive tone makes me feel somewhat less grateful. Don't you feel good knowing you made my day a little less cheerful?
Pardon me--I have to go jump off a cliff into the ocean now.
steveha
What exactly in the in the 286 architecture prevents the use of a multitasking operating system?
That was not the problem. The problem was writing a multiasking operating system that would run all the DOS apps (which were important at the time).
When the 286 was in protect mode, some of the instructions worked differently than when it was in "real" mode (8086 compatibility mode). Result: you could not execute DOS apps; they wouldn't work.
So, how about making a DOS virtual machine? Well, the 386 has features that make it easy to spin up multiple real mode virtual machines, but the 286 didn't have those features. A purely software virtual machine would be very slow.
So, how about switching out of protect mode and running real mode code in the 286's real mode? That was the only option, so Microsoft took it. However, Intel had not designed the 286 to do this. There was an instruction to start up protect mode, but no instruction to leave it and go back to real mode! Microsoft wound up programming the keyboard controller chip to actually reset the CPU, many times per second, to switch to real mode.
Because DOS apps ran in real mode, they owned the whole machine: all memory, all devices, etc. So if a DOS app crashed, it would take the whole machine down with it; a crashing DOS app could trash OS/2, and there was no way to prevent it.
Even worse, the 286 did not have features that would let you virtualize the hardware, and DOS apps liked to talk directly to the hardware. All DOS apps liked to write directly to the video card, rather than going through the BIOS, and the 286 didn't really help you solve that problem.
So the OS/2 1.x "compatibility box" could only run a single DOS app at a time.
Meanwhile, Microsoft sold Xenix 286, which worked perfectly well. Alas your Xenix 286 programs either had to be less than 64KB each, or else they had to deal with near/far pointers (yuck), but Xenix 286 worked. Microsoft never tried to do a GUI desktop for Xenix, but it would have been possible.
It appears to me that the article writer is trying to excuse Microsoft's lack of skill by pretending that the task was impossible.
No, it really was impossible to write an OS that would run decently fast on the 286 hardware of the day, would multiask old DOS apps, and would be reliable. The 286 was just too broken.
steveha
I read through the article, and it was full of weird conclusions. I am very familiar with what was going on in the computer industry during the time period discussed, and I disagree with much of the article.
The story of OS/2 is what taught me that in the computer industry, revolution is not what the customers want; they want evolution. You can sometimes pull off a revolution (Macintosh) but it is much easier to offer a smooth upgrade path.
OS/2 was not killed by some weird conspiracy by Microsoft. Some of the other causes of death listed were not doubt contributing factors, but the major cause of death was: incompatible APIs.
It was not possible to take a Windows application and compile it for OS/2; you had to substantially re-write your app. It wouldn't be quite as much work as re-writing your app from scratch, but it was close. Microsoft didn't want this. Microsoft wanted to make OS/2's windowing API compatible with Windows, but IBM had some other API they thought was better, and they insisted it be used.
This had the effect of forcing companies to decide whether they wanted to write for Windows, or write for OS/2. That was totally dumb of IBM. If people could have just recompiled for OS/2 and offered an OS/2 version of their app, they would have done so. IBM was asking developers for a revolution, not evolution.
But let's go back to the first version of OS/2. Because it was written for the 286, its compatibility with DOS apps was poor. OS/2 1.x offered a "compatibility box" for running a single DOS app at a time; it worked poorly, and it was often called the "Chernobyl Box" because it would often crash (and it would take the whole OS down with it). So, any company that wanted to adopt OS/2 had to plan on getting new versions of all their applications.
But in 1990, Windows 3.0 shipped. It sold like hotcakes. The article makes some bizarre statements about Win 3.0, but the reality was that it would multitask your DOS applications very well. DOS applications were preemptively multitasked, not cooperatively, and DOS apps could very well crash but usually Windows would not crash with them. In other words, Win 3.0 allowed companies an evolutionary upgrade path: they could keep running the same DOS apps they were using, and then phase in Windows apps over time. The same companies that were unwilling to commit to OS/2 were willing to commit to Win 3.0.
Win 3.0 was what made Microsoft decide to walk away from OS/2. The customers were voting with their dollars, and what they were voting for was Windows. It didn't hurt that Microsoft had covered all bets: they had applications for DOS, Windows, OS/2, and Macintosh. (They even flirted with a few other platforms: my favorite word processor for the Atari ST was Microsoft Write.) When Win 3.0 took off, Microsoft was ready, and sold lots of Word and Excel.
So, to review: IBM forced developers to choose whether to develop for OS/2 or Windows, and Windows became a runaway hit. That's it right there. That's what killed OS/2.
steveha
It would actually work: use a thermal probe to actually hook up the temperature guage, hook the voltage guage up to the +12V on the power supply (but it would be very boring on a good power supply, so maybe you should hook it up to a drive light or something). Not sure what to do with oil pressure. Maybe sound volume to speakers?
I think this would be a good use for those "Tokyo-by-night" guages, with LEDs instead of moving needles. That way you wouldn't hear the sound of needles beating against the stop post when the values fluctuated...
steveha
Back in my Apple ][ days, there was a gadget that I lusted after. It was an array of LEDs, 16x16 (256 in all), and it was connected to the 8-bit memory bus on the Apple ][. Since you only had 64KB of memory space, each of the 256 LEDs mapped onto a 256-byte chunk of address space. The lights would light up for each access to that chunk.
It would have been very interesting to watch the lights during, say, garbage collection in BASIC.
It would still be fun to have something like that on a grander scale, perhaps docked near my CPU meter in my GNOME desktop.
While I never got the LEDs gadget, I did take an AM radio and set it up on top of my computer, volume turned down low. The RF interference made a distinct sound, which changed pitch when something different happened. If the computer went into an infinite loop, you could hear it. I got tired of the noise, though, so I don't do this anymore.
steveha
Libertarianism, the general philosophy, is based on the idea that you own yourself and the fruits of your labor, and that you have the right to decide what is best for yourself. A libertarian government would be very small and do very little: it would enforce the laws against fraud and force, and it would enforce contracts, and it would handle national defense. "Victimless" crimes (such as using drugs, or paying for sex) would not be crimes. If you had cancer and wanted to take an experimental drug, there would be no FDA to forbid you to do it. It would still be illegal to hurt people or steal their stuff, or fool people into giving their money to you. Pollution would still be regulated but the mechanisms used might be different from what you see today.
Sadly, while most people would love to live in a libertarian society, almost everyone has some pet feature of government that they like, or else they don't want other people to be fully free, or both. (For example, some people who disapprove of drugs want drugs to be illegal.) Take the union of all the things people want government to do, and you have a large, complex government.
As this is off the main topic, I won't make this much longer, but will close with two final points:
0) libertarians don't, as a rule, want poor people to suffer and die; rather they think private charities would do a better job of helping the poor.
1) Not only do libertarians want to end things like welfare, but they also want tax burdens to be remarkably lower. Right now charities get lots of donations, even though the tax rate is over 50% for most people (add up state and federal income tax, sales and restaurant taxes, car and gas tax, etc. etc. and include things like Social Security "contributions" and you will go over 50% quickly). If the overall tax rate for people went down to 10% or less, charitable contributions would increase.
If I remember right the keyboard interface could report the state of the shift keys, the problem was that certain key combinations produced nothing, ie you could not tell if they had been typed by using the BIOS.
Right. You would call the "get a key" interrupt, and it would return one byte for the key. If the one byte was a certain escape byte, then the key was an "extended" key and you had to check another byte for its value. 256+256 = 512, so there were less than 512 possible keys under this system. I don't remember anymore whether you had to make a second BIOS call to get the extended key value, or just look in a different register.
In any event, it would only return keys in its list. So if the number pad was in Num Lock mode, and you hit the 5 key, you would get a 5, but if the Num Lock was not set and you hit the 5 key, you got no key back. If you wanted to do anything with that key, you could not go through the BIOS.
steveha
- there was a print string (int 10, ah=9)
I just did a web search to check. You are right and I was wrong. I am sure that I remember that there was some lack in the BIOS that made it annoying to print strings, but now I'm not sure what it was. Maybe it was just the speed thing; if you do your own MOVS you will be faster than if you make the BIOS call. I do note that if you are doing color text, the BIOS call can only do one color (well, character attribute byte, to be precise) per string. So if you have a string and parts of it should display in different attributes (to make your word processor more interesting) then you would need to make lots of calls to the display string interrupt.
And come to think of it, the situation with graphics was worse than the situation with text. Back in the day, Microsoft Flight Simulator was used as a compatibility test for PC compatible computers; if you couldn't run Flight Simulator, you weren't compatible enough. Graphics was already slow on those machines, and the additional overhead of doing pixels through the BIOS was a non-starter. So it was probably graphics more than text that locked down the 640k limit.
- MDA text was at $b000 (as well as hercules graphics), CGA was at $b800, only the latter EGA used $a000.
But by the time the 640KB limit really started to hurt, EGA graphics were important.
The bios was more like the drivers (basic io, right?).
That's what I meant when I said the BIOS abstracted the hardware.
Nothing prevented Microsoft to implement a usable hardware abstraction (that's what an OS if for, right?). They didn't.
It's true, MS could have fixed the holes in the BIOS by adding more stuff to DOS. I wonder why they didn't.
I used to work at MS, and I would guess that the MS-DOS guys and the application guys simply didn't talk that much. They may also have wanted to keep DOS small. Probably also DOS was viewed as a dead end, and all the serious development was going on for Windows and OS/2.
Back in the day, I remember people saying that Windows would never go anywhere because doing everything in graphics mode was too slow. I figured that Moore's Law would fix things, and that the much better hardware abstraction would be a huge improvement. (I never want to return to the days where you needed a new driver for each of your applications if you had an unusual video card!)
steveha
Guys, I can't believe no one has yet posted the true reason why the 640K limit was a problem. Well, I'll explain it.
The IBM PC BIOS was designed to abstract the hardware. These days Linux or Windows do that for us, but in those days the BIOS was what you had. Your DOS programs were never supposed to talk to the hardware, they were supposed to go through the BIOS.
The problem was that the BIOS sucked. Want to draw a character on the screen? Fine; there is a BIOS call for that. (BIOS calls were called "interrupts" because you used an interrupt to call them, but I'll just call them "BIOS calls".) Want to draw a whole string of characters on the screen? You would think there would be a BIOS call for that too, right? But there wasn't. You would have to do one interrupt per character, and poke your string onto the screen one character at a time! And interrupts were really expensive; remember that we are talking a 4.7 MHz chip with slo-o-o-o-w memory.
And suppose you wanted to read the keyboard? Not a problem; there was a BIOS call for that. Of course, it had a few limitations: it could only recognize a little more than 500 distinct keypresses. If your app wanted to recognize Alt+F1, no problem, that was one of the recognized keys. But if you wanted to recognize Ctrl+Alt+Shift+F1, too bad. The obvious and correct way to read the keyboard is to return the scan code for which key was pressed, coupled with a chord of which shift keys were down (e.g. Ctrl and Alt were down, shift wasn't, or whatever). With two bytes of data, you could handle any combination of Alt+Shift+Ctrl+whatever. But the BIOS didn't do it that way.
There are other examples, but I think those two are enough. Given this broken a BIOS, the application writers all decided to go around the BIOS and talk directly to the hardware. Get the address of the keyboard controller, find out what keys the user hit, and support any combination of keys you want. Get the address of the video card's character buffer, and use MOVS to blast a string into it with zero overhead. Now your copy of Microsoft Word 1.0 runs much faster than if it used the BIOS.
Guess what address the video card was at? That's right, 640K. By the time people began seriously hurting for more address space, there was way too much software out there writing directly into the character buffer of the video card, so it was now too late to move the buffer somewhere else. The 640K limit was set in stone.
Even if everyone had used the BIOS, there would have still been a 1024K limit, since that's all you could address on an 8088. But that would have been much better, and it would have been much easier to write environments like DesqView. (You could have done something like DesqView on an 8088 if it only had to run well-behaved apps, i.e. apps that never went to the hardware but always went through the BIOS.)
P.S. Slightly offtopic, but I have fond memories of using a multitasking environment called OmniView. It did much the same thing as DesqView, except that it didn't try to do the overlapping windows thing with the apps; it ran your apps full-screen. You could use function key combos to switch your full screen among app sessions, almost exactly like using Ctrl+Alt+Fn in Linux to switch full-screen among virtual ttys. DesqView got the fame and fortune, but OmniView was a little bit more efficient and I got some real work done using it on my 33 MHz 386 system. I used to run compiles in parallel: one compile would cause the disk to load the source, and the other compiles that used the same source file would find the data already buffered. I could finish four compiles in only a little more time than a single compile took on its own; the compiles were fairly disk-bound.
steveha
I like putting computers together. I always try to keep the RF shielding intact. This computer has no RF shielding at all.
How much of a problem is that, anyway? If his next-door-neighbor is an amateur radio enthusiast, will the clear computer mess up the airwaves? If he wants to watch TV, will the computer ruin the picture? Can he stop pacemakers at 50 yards or something?
I don't have any clear idea how serious the emissions from computer hardware really are.
steveha
The craftsmanship is incredible.
He removed the metal case so the guts of the power supply are visible. He took the face off his DVD drive so you can see inside. Even his hard disk has been modded with a window showing the platter and the read/write head.
My favorite quotes:
"Needle files are a modder's secret weapon."
"Yes, I did polish the heads on the fasteners. Thanks for noticing."
Very impressive.
steveha
In the article, Jef Raskin said that your subconscious learns its way around an interface, and customization is bad because it changes what you have to learn. Here are his words:
I think he would hate auto-configuring interfaces even more than he hates configurable ones.
steveha
"No customizations for you!"
In this interview, Jef Raskin comes off as rather arrogant. He seems absolutely convinced that there is an objective, scientific, Best Way for everything about interfaces.
I'm not convinced. One person might actually work better with white text on a deep blue background, or whatever. I can think of other examples.
With Mr. Raskin it is all-or-nothing: if you work for him, you don't get to customize anything, unless you convince him that you really have a better idea (in which case he switches too, and everyone else who works for him has to switch too.
His supporting arguments didn't impress me much either. A "Preferences" dialog makes an app consume more resources? Not enough to matter, I'd say. That's like saying that putting foam cushions on a car seat makes the car heavier.
The absolute gem of a quote, though, was this one:
Of course, there are no really well-designed interfaces out there good enough to prove the point that you don't need preferences. Any programmers who want to help build one with me, drop me an e-mail.
Maybe he can actually create an interface so amazing, so perfect, so right that no one would ever be able to improve upon it. I won't hold my breath, though.
steveha