DOS/V: The Soft(ware) Solution to Hard(ware) Problems
In recent months, there has been much speculation in the Japanese media about the future of the various PC operating systems, with most of the attention centered on Windows NT 3.5J, OS/2 Warp, Windows 95 (whose release has been delayed until autumn). As more and more corporations move to these newer platforms or use products such as Win/V to handle their Japanese applications, a question that remains is: What will become of DOS/V?by Steven Myers
DOS/V is the operating system that revolutionized the Japanese PC industry. Until the release of DOS/V, the major Japanese PC makers ó such as NEC, Fujitsu, and Toshiba ó each used their own version of DOS along with their own proprietary hardware. The result was a lack of software compatibility among platforms. Software developers had to create separate versions of their programs for each platform, which slowed development time, and owners of two brands of machines had to have two sets of programs. All of the brands of computers used hardware solutions to handle the display of Japanese characters, storing the data for all of the characters on special chips known as kanji ROMs. This method required the double-byte code for each character of keyboard input to be sent to the CPU, which in turn fetched the corresponding character from the kanji ROM and sent it to the screen via text-mode VRAM. The use of kanji ROM meant that the shape of each character was fixed, while the use of text-mode VRAM set a standard 16x16 dot size for each character.
A software solution
Meanwhile, serious research had been going on at IBM Japan since the early 1980s to produce a software solution to the problem of displaying Japanese characters. With the advent of high-resolution VGA monitors, faster processors, and larger memories and hard drives, designers at IBM's Fujisawa and Yamato research laboratories realized that information about the shape and size of kanji characters could be stored on disk, loaded into extended memory, and displayed through graphics-mode VRAM. (The "V" in DOS/V, by the way, comes from the VGA monitor necessary to display the Japanese characters via software.)Although the technology required for DOS/V was in place and widely available as far back as 1987, development efforts were reportedly hampered by strong opposition within IBM Japan. The introduction of the DOS/V software solution at that time would have rendered some of the just-released IBM hardware products obsolete ó systems that were selling well, and that had required a heavy investment of time, labor, and development costs.
While IBM Japan was holding back on the release of a software solution for Japanese input and display, other companies were taking a completely different approach. These companies opted instead to develop a computer that was AT-compatible, but which still used the kanji ROM. This system ó dubbed the AXó never caught on. It was doomed to failure, as it soon became apparent that the display of Japanese could be handled much more flexibly through software, and the subsequent release of DOS/V was the final nail in the AX coffin.
It is widely believed that with a little more foresight on the part of certain resource-abundant developers, a Japanese "open systems" version of DOS could have been brought to market as much as five years earlier than was actually achieved. Foresight has never been the strong point of Japanese computer firms, though; maintaining the status quo has always had priority for the successful firms. So it was not until 1990, when IBM Japan sales entered a period of doldrums, that DOS/V finally hit the market.
Enter DOS/V
The release of DOS/V was announced by IBM Japan in October 1990. Initial acceptance of this new "Japanese DOS" was not widespread, however. This was due in part to the fact that the system was based on the unpopular version 4.0 of DOS. In addition, initial support was provided for only the 106-key keyboard (which, while popular in Japan, is considered difficult to use by many non-Japanese) and a limited range of Japanese printers.It was not long, though, before independent Japanese programmers were writing patch files to support the "American" 101 keyboard (widely used on IBM-PC/AT-compatible computers). At the same time, DOS/V system disks became available at various computer shops in Akihabara, and other types of workaround patch files were soon being written and distributed through local BBSes.
In June 1991, a huge press conference was held in Otemachi to announce the formation of the OADG (PC Open Architecture Development Group), which included all the giants of the Japanese PC industry (with the notable exception of NEC). This group established a set of standards for developers that, if adhered to, guaranteed that applications could be used in any DOS/V environment (Korean, Chinese, etc.).
Although several foreign makers, such as AST, Acer, and Mitac, sold DOS/V machines at increasingly competitive prices in the early days, it was not until Compaq entered the market with drastically reduced prices that the DOS/V revolution really took off ó sparked by the so-called "Compaq shock" of 1992. Compaq took Microsoft's still-under-development MS-DOS/V and modified it to create its own DOS 5/V, then marketed its machines sharply and, most importantly, provided strong user support. In early 1992, Compaq was reportedly selling more copies of DOS/V than it was computers. By the end of the year, however, machine sales had begun to take off. While the IBM version (which was bundled with 90% of the DOS/V machines sold at the time) was considered the "official DOS/V," many potential users found the features, packaging, and support of the Compaq systems to be superior.
An interesting question that arises at this point is: What was Microsoft doing during all of this? A software giant like Microsoft should have been able to come out with a generic retail MS-DOS/V early on in the game. Why, then, was the company so slow to climb aboard the DOS/V bandwagon? Although no one can say for sure, it appears that a variety of factors came together to greatly slow the development of Microsoft's MS-DOS/V. To begin with, this kind of development ran counter to Microsoft's philosophy of producing only OEM products that manufacturers then modify to fit their own machines. At the same time, however, Microsoft engineers were attempting to make their version of DOS/V compatible with the AX machines (which, as has been mentioned, used kanji ROM) ó an endeavor that turned out to be an exercise in futility. Other, more cynical observers, have cited the cozy relationship between Microsoft and certain large Japanese computer makers as the real reason for the delay. Whatever the case, Microsoft's MS-DOS 6.0/V was not released until well after the shift of the Japanese market to the DOS/V standard had already taken place.
The present state of DOS/V
In the past two years, virtually all foreign and Japanese makers have moved to the DOS/V standard, solidifying the place of DOS/V and the AT architecture in the Japanese marketplace. Even Epson, long a producer of NEC 98 clones, has joined the DOS/V world. Currently, NEC appears to be left out in the cold ó completely isolated as the only maker of non-DOS/V PCs in Japan. With a market share still over 40%, NEC can still afford to go its own way, but the company may have noticed t here is no light at the end of the tunnel. Unconfirmed rumor has it that NEC is in the initial stages of phasing out its 98 series of computers in favor of the DOS/V platform.There are several versions of DOS/V available today, with the two biggest being Microsoft and IBM. Microsoft now has its own MS-DOS 6.2V, which comes with all of the same features and utilities that are included in the standard MS-DOS 6.2. IBM, meanwhile, markets the "official" OADG PC-DOS 6.3/V. The differences lie mainly in the utilities that are included and in features such as IBM's bilingual installation program and PCMCIA support, which are not included in the Microsoft version.
DOS/V in 95
In spite of the huge impact that DOS/V has had on the Japanese PC industry, recent attention has been focused on the "next generation" of Japanese operating systems ó namely, Windows NT and OS/2 Warp 3J. DOS/V and Windows 3.1J, a notoriously difficult platform for which to design applications, appear to be getting phased out of many larger corporations in favor of Windows NT. The appearance of Win/V on the Japanese software market has further reduced the need for DOS/V among foreign firms, as these companies can now run their Japanese applications (with reportedly fewer problems) on English-language Windows. (See the January and February Windows Help Desks.óEd.)Although popularity of the DOS/V-Windows 3.1J standard may be waning, its impact on the Japanese PC industry has been tremendous. DOS/V has served to firmly establish the IBM AT architecture in the Japanese market, bringing Japanese users compatibility with the rest of the world. Sales of DOS/V PCs remain strong, and these systems appear to be in wide use among small and mid-size firms throughout the country. (Many of the more "traditional" Japanese firms, however, are clinging steadfastly to the proprietary NEC systems).
DOS/V has created quite a stir in the four-and-a-half years since it first appeared. And from all indications, it will continue to maintain a strong presence in Japanese homes and offices in the coming years.
Special thanks to Greg Smith for his assistance in preparing this article. Well known in Japan as an expert authority on DOS/V and Windows, Greg is the founder of Fast River Systems Y K, and has been providing bilingual computing solutions for over eight years.
Among the books (in Japanese) written about DOS/V are: Adachi, Tsuyoshi. DOS/V Technical Reference Manual. Softbank Books, 1994. Tsuchiya, Masaru. PC DOS 6/V Handbook. Natsumesha, Inc., 1994. Compaq Seran Kikaku Division. DOS/V Pasokon. Seitousha, Inc., 1993.
Inside DOS/V ó a general overview
To make an operating system capable of providing a Japanese environment, the developers of DOS/V took the existing (North American) IBM DOS and added a variety of extensions. Specifically, the following four device drivers (programs that extend the capabilities of DOS) were added: Font driver: $FONT.SYS Display driver: $DISP.SYS FEP support driver: $IAS.SYS Printer driver: $PRNESCP.SYS As the figure shows, the display and printer drivers act as a direct interface between the application and the BIOS, and these programs in turn can call the font driver programs to get the information that they need for screen or printer output.DOS/V device drivers
Font support
The information needed to display Japanese characters is included in font files, which are loaded into extended memory and accessed via a font driver. Current DOS/V versions are able to use two different methods for loading fonts into memory. One option is to have the VDISK program load the fonts through the INT 15 interrupt, which handles the transfer of data to and from extended memory. (See the sidebar on page 18 for an explanation of software interrupts.) The problem with this method is that INT 15 provides no mechanism by which applications can share extended memory.With DOS 6.2/V, fonts can also be loaded using an XMS (eXtended Memory Specification) driver, such as HIMEM.SYS or QEMM. This method is better because it allows other applications to share extended memory. As shown in the figure, the font driver routines are called by both the display driver and printer driver routines.
Display support
Japanese text screens are displayed under DOS/V by using VGA graphics memory. The computer, however, thinks it is operating in English text mode 03. The $DISP.SYS driver extends the INT 10 interrupt routines (which include all of the functions for controlling the display ó screen writes, cursor positioning, scrolling, etc.) to correctly display text output by Japanese applications and to reroute calls to the BIOS for text display from non-Japanese programs.In order to increase program speed, however, many applications developers design their programs to write directly to text screen memory. In this case, English DOS applications that are run in Japanese mode will operate, but nothing will appear on the screen.
FEP and keyboard support
The IAS (Input Assist Subsystem) provides a generic, keyboard-independent interface for FEPs (Front End Processors), which are used to enter Japanese text. The FEP will take the input typed by the user, in either romaji or kana, and produce the desired kanji, hiragana, or katakana. The FEP then passes this information to the IAS driver, where it is can by processed by the system and finally displayed by the display and font drivers. The most important aspect of this support interface is created by extending the functions of the INT 16 vector (used to handle keyboard input) to handle the generation of the double-byte codes necessary for processing Japanese characters.Printer support
Depending upon the program used ($PRN or $PRNUSER.SYS), DOS/V is able to use several different standards for printing. The most common in Japan is probably the Epson "ESC/P J84" standard. It is the job of the printer drivers to ensure that the Japanese output conforms to this standard being used. ESC/P, for example, uses JIS encoding, so the printer driver routines must first convert all of the Shift-JIS encoded data into JIS codes before sending the information to the printer. Specifically, this process involves extensions to the INT 05 and INT 17 vector routines, which handle printer input/output. DOS/V applications developmentMany applications developers have reported extreme difficulty in trying to port software to the DOS/V platform. Although few firms design straight DOS/V applications anymore, this kind of software ó both commercial and proprietary ó is still used widely in Japan. Many DOS applications are still in use due to the relatively limited power of the average Japanese user's PC. However, the move from DOS to Windows has been aided by the traditional lack of support from Japanese software makers. Once a Windows version has been released, users of the DOS version can find support extremely hard to come by. Some of the issues that can create problems for DOS/V programmers include the following.
DBCS processing
Processing Japanese characters requires the use of a double-byte code system (DBCS), such as Shift-JIS. If the first byte of a character has a code value that falls within the hexadecimal ranges 81H to 9FH (129 to 159 decimal) or E0H to FCH (224 to 252 decimal), then Shift-JIS treats the byte as the first byte of a double-byte character. One problem that arises involves the assignment of code values that are below 81H. The characters that Japanese PC manufacturers have assigned to these code values differ from the characters used by AT-compatible makers for the same values. This discrepancy makes it virtually impossible to run English-language applications in DOS/V Japanese mode.A second problem involves the editing of Japanese characters. To delete a single Japanese kanji character, it is necessary to erase two bytes. Deleting an alphabetic character, on the other hand, requires only a one-byte change. With Shift-JIS code, unfortunately, there is no way of telling whether the previously stored byte represents a single-byte character or the second byte of a double-byte character. (The only way to check is to start at the beginning of the line and check each character up to the point of deletion.)
Display
A major problem in displaying double-byte Japanese characters involves the video mode. The standard DOS/V video mode is an emulation of the CGA text mode 03 used by English DOS, but the emulation is by no means exact. Hence, there are differences between the two in issues such as character dot size and location of the video buffer. Application developers need to be sure to check and save the current video mode setting when an application is started, set the mode to the DOS/V standard (CGA text mode 03), and then return to the previous mode when the application finishes.Another consideration that designers must keep in mind is that the bottom line of the display screen (which differs depending on the video mode) is reserved by the system for use by the FEP. When using DOS/V, application designers must refrain from using this space.
Extending the functions of the interrupt routines
Japanese display and processing was made possible in DOS/V essentially by taking the interrupt routines of the original IBM DOS and adding new functions to them. A software interrupt is an instruction to the operating system that some request for a service, such as a disk read or screen write, needs to be fulfilled. Services that are related (those involving screen output, for example) generally share the same interrupt vector (the place in memory that contains the starting address of a particular service routine).The first 1,024 bytes of memory are used to store 256 of these 4-byte vectors. If you want to request one of the many DOS services, for example, you would use an INT 21 instruction, which tells DOS to look at the 33rd (21H (hexadecimal) equals 33 in decimal notation) interrupt vector position, find the memory address stored there, and branch to that address to begin the service routine. Exactly which DOS routine is executed depends on the service requested ó as specified by the programmer in the instruction immediately preceding the INT 21.
As an example of just one of the extensions made to this set of interrupt function routines in the development of DOS/V, consider the situation of processing a single character keystroke of input. Whenever a key is entered from the keyboard, an INT 09 is generated. (See figure.) This interrupt causes control to be transferred to a routine that returns the code value for the key, and this value is then stored in the BIOS key buffer. In English-mode DOS, the character is then ready to be read by the application (by issuing INT 16).
With Japanese DOS/V, however, the FEP (front end processor) support driver must jump in and issue an INT 16 that initiates one of its own routines, to store the code value in a separate buffer. As more keystrokes are entered, code values accumulate in this buffer until the user confirms through the FEP that the input line has been properly converted to the desired kanji and kana. At this point, a different INT 16 interrupt function is called to find the correct Shift-JIS codes for the characters and send them to the application.
