Marco wrote: > James Kass wrote: > > > [...] but would it really take *millions* of dollars for > > > implementing Unicode on DOS or Windows 3.1? > > > > It could be done with, say, Ramon Czyborra's Unifont and QBasic. > > Why not? Or, even better, with a Unifont-derived BDF font and GNU C++. Reason #1 Those are end-of-lifed, unsupported OS's. Sure there are plenty of machines still running applications on them, but the handwriting is on the wall for those machines -- even in impoverished countries, schools, organizations, whatever -- simply because there is no way forward if they want to change and update whatever it is that they are doing on those machines. Reason #2 The *tools* that run on those OS's are end-of-lifed and obsolete. That makes them difficult to get a hold of and makes them unsupported, too. Sure you can work in QBasic to do something, or in whatever other tool you might happen to have, but QBasic is a sorry excuse for a development tool, and you have no guarantees that you can share the burden with the next guy over who may have a different obsolete level of the OS and a different obsolete and unsupported tool. Reason #3 OS's like DOS and Windows 3.1 don't scale well to the demands of Unicode application support -- over and above the fact that there is not and never will be any OS support. The 16-bit segmented memory models, the incompatible memory driver extensions for DOS in particular (anybody else recall the config.sys hell for dealing with expanded memory and extended memory drivers to get access past 640K base memory in DOS?), the file size limitations, the limitations on disk size supported, and so on, all constrain what you can do. Trying to program with tables in DOS, in particular, hits up against all kinds of limits very quickly. What seems like a *small* table in a 32-bit world quickly turns into a *large* table in a 16-bit world, and then becomes a programming problem. It isn't impossible, of course -- in point of fact, the Unicode library I write for Sybase was ported to Windows 3.1 up until about a year ago, but even when it was running, I don't know of anyone who actually tried to use it to support Unicode on Windows 3.1. And that was just a backend library -- the frontend support is where the real problems would be. Reason #4 Lack of marketing and distribution support. Anything you develop on DOS or Windows 3.1 is going to be a total anachronism, developed by a true believer and a small group of acolytes, but with no obvious channel for promotion and distribution. There can always be a small group that knows about and promotes it for particular niche usage, but that, too, doesn't scale well. If you are trying to create a "Unicode solution" for people who are stuck with backlevel computer equipment, how do you get your solution to them? Many a startup company that *was* well-funded with millions of dollars has foundered on this rock simply because even after they had a clever solution in hand they couldn't find their customers and their customers couldn't find them. Reason #5 Creating anachronistic Unicode applications to run on DOS or Windows 3.1 isn't really doing the intended beneficiaries much of a favor. If I am still using an 80286 AT class 6 MHz machine running MSDOS 5.0, I can't run a browser and access the internet. That is a far more crippling limitation on my IT enablement today than the fact that I don't have any Unicode applications running on the machine. Nobody is going to reengineer IE 5.5 (or even IE 4.0 or IE 3.0) in QBasic to run on DOS 5.0. Personally, I still own a working vintage 1983 Osborne Executive CP/M computer beefed up to 512K memory. Turbo Pascal 2.0 still runs on that machine, and I know enough about WordStar patch hacking, RAM character generator programming, and printer driver hacking that I could probably upgrade that system to a limited form of Unicode support, given enough time. But in the end, what would I have accomplished except to show I was a macho programmer of anachronistic equipment? Who would even be able to read the 180K 5-1/4" floppy disks to use my Unicode data? Aside on hacking -- James Kass objected to the negative connotations of the term that Peter was using. But there are at least two distinct uses. One is to hack *into* systems, i.e. the kind of illegal security breaching associated with "hackers" in the media. The other, widespread practice is just hacking software, akin to the concept of the "hack up". This generally just means to take software or a specification that somebody else wrote and to tweak and twist it to do things it was never designed to do in the first place. As a limited, quick fix for some problem, this is often the most cost-effective thing to do, but as a longterm approach, "hacking" is almost always bad, since it introduces maintenance problems, is almost never extensible, is often bug-ridden if patched further, and is less effective than a redesign that addresses the new problem head-on. Peter is talking about the second kind of hacking, which has both good connotations (as clever, quick, cost-effective fixes to immediate problems) and bad connotations (as unmaintainable, expensive hairballs when the hacking programmer moves on). Hacking up fonts or applications to provide Unicode support on backlevel OS's may indeed be a good idea to meet some immediate pressing need, but people who are doing this ought at the same time to be aware that what they are doing has a built-in, inescapable obsolescence factor (think androids in Bladerunner), and it would only be prudent to also be planning for technology jumps to whatever is in the mainstream of software (and hardware) development when possible. --Ken
