tbray@watsol.uwaterloo.ca (Tim Bray) (05/06/91)
I'm a software vendor, selling Unix text database software. Recently we have been engaged in creating a Windows-3 front end for the products - the idea is you drop a unix server into a DOS LAN and use the PC's as front end boxes, something for which they ought to be suited. In the progress of doing this, I've received an unpleasant education in a situation which I believe has the potential of turning into a pretty substantial catastrophe for end-users out there. Since the problem is architectural, I thought it might be interesting to the folks here. As you're probably aware, the default desktop box, "the computer" in the eyes of Joe End User (JEU) ain't Unix. It's a PC running DOS. If JEU is working for a technically backward organization, that's all: a PC running DOS. If JEU is lucky, his PC is sitting on a LAN, perhaps accessing a "mainframe" of some sort, and has, for the last few months, been running Windows 3.0. Here's the problem: You have Np kinds of PC's to choose from (Np is big), Nn kinds of LANs to choose from (typically Nn <= 3: Novell, Banyan, LAN Manager - but really this is Nns kinds of software + Nnh kinds of hardware), Na different applications (Na is a a big number), and Nm kinds of "mainframes" (typically Nm = 4: Unix, OS/2, VMS, or MVS). Here's where it gets ugly. If you were in Unix, everyone would use TCP/IP for networking, rely on Unix for VM, and use X for windowing. So the job of getting things to work together, while non-trivial, is problem of size O(Na); making sure each talks to the standard interfaces properly. On DOS, I'm not sure what the number is, but it's closer to ((Np + Nn + Na + Nm)!), or maybe just (Np * Nn * Na * Nm). As far as I can tell, *every one* of these links in the chain has the potential to screw up its interface to any of the others, and *lots do*. The ugliness starts at the core - in DOS. This operating system was designed from the start to do a good job of running one program at a time in a moderate amount of memory. The addition of client-server networking, while very cleverly done, amounts to kludge. The addition of extended memory handling, also. The addition of fake multitasking, also. What's the effect? There are now a lot of consultants make a very fat living, thank you, helping big biz, and especially government, make this tower of kludge upon kludge limp along and work. And it's a constant struggle, and the problem keeps growing, and I think there are some real brick walls out there that are going to cause a lot of blood to be shed. That's the worst case. The best case is that all these programmers and consultants spend more and more of their time pasting these fragile structures together and less and less actually improving the applications. And the problem isn't going to go away, because it's application-driven. MS Word is a wonderful, easy-to-use, get-it-done-quick application. So is Lotus. So is DBase. So are a lot of low end CAD and graphics packages. And that's just a few. They really help people get what they need to done, quickly and easily. The effect of a LAN is easy for people to understand, and essential in a large enterprise once you've seen it - try to imagine life without file sharing, printer sharing, e-mail, and so on. The effect of Windows is easy to understand and hard to do without. The effect of access to the central "mainframe" data resources from your desktop windowed enviroment, likewise. And when it works, more and more people want to use it. The effort in setting up Novell + DOS + Windows + Oracle/SQLnet + VMS + Excelan + WordPerfect + Excel for a group of 12 is ugly but do-able. Then when it works, the other 134 people on the floor want in, only they also want to use Harvard Graphics, CADmaster, and Macintoshes. This is not just a matter of running some more thinwire and maybe dropping in an FDDI backbone. I don't know what the answer is. But I think for the overwhelming majority of computer users out there, the above is the central architectural problem they have to deal with; not CISC/RISC, or SIMD/MIMD, or superscalar/VLIW, or stateful/stateless remote file access. Maybe this problem isn't an appropriate topic for this group. But it's architectural, that's for damn sure, and anybody who figures out how to beat it is going to make a lot of money. Cheers, Tim Bray, Open Text Systems