Marco, There are a lot of considerations that people don't think about. The system uses different video space so that some drivers don't work. Far east fonts are different. They are center line rather than base line. You need different video resolution and roman (Latin) text looks awful. Normally we use and odd number of pixels to form characters. Far East characters use and Even number of Pixels. At low resolution it make Latin look cruddy. The far east is also aligned from the center of the character not the base line so underlining is weird. Often you will work on a system and find that you are 80% done and hit a snag that requires a major rewrite to shoe horn it in. Yes you can make it work. NEVER fix price bid a DOS project. You will always hit snags. The other problem that we encounter is that the client will often use third party drivers that won't port. Often they won't even know. Some times they will get most of the code converted but this one program will use a special driver that they forgot about. Most DOS code has 3rd party code. I had a had time letting go. I go back to the time when you looked at each instruction to see how long it executed to see which way was best to write you program. The first operating system that I wrote used less than 600 bytes of core (storage) and I wrote it in machine language first and than converted it to assembler to get it to compile. The code was so tight that it actually fetched pieces of machine instructions in different overlays. The first network was on a mainframe that was a powerful as the original IBM PC and it supported 300 users with under 3 second response time. I have worked on 8041s and done some micro coding. So as you can imagine it was difficult for me as a bit twiddler to give up squeezing every last drop out of the system and stand back and look at the big picture and ask "Is it worth it?". If you keep running into problems over and over again then it is time to ask the question is it better to move from DOS to Windows CE, or Unix or whatever. The hardware costs are dropping and it is the software and support that is becoming a larger factor. You are no longer buying processors with 64 bytes of RAM like the 8041 for embedded systems. When you go to Far East systems you need more memory anyway. It is a good time to ask the question "is it time to change?" Carl -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 19, 2000 10:34 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: query Carl W. Brown wrote: > Double byte enabling DOS is no minor feat. It is not a > driver but a new > operating system. If you are tight on memory your > applications may not run > because the DBCS support adds overhead. About 5 years ago we > gave up on > DBCS DOS projects because they were too much grief. Hardware > is not that > expensive any more. The excuse no longer holds up. > Considering that a good > Chinese font is 3-10Mb, using DOS just does not make sense. Carl, a lot of special devices and embedded stuff are still in DOS, and there is little one can do (although I would expect that solutions based on newer palmtop OS's also exist on the market). I think I know the kind of hardware Joshua is talking about, as we use them a lot in retail systems: they are not PC's, but rather special hand held devices, used for making inventories in shops. They have an integrated barcode reader and a small keyboard (sometimes only numeric; sometimes with also QWERTY... or ABCDE... alphanumeric keys). I don't understand why you say that double-byte enabling DOS is such a nightmare. Before Windows 3.x became the standard, there used to be lots of Chinese and Japanese software for DOS. There are editors, word processors, libraries, and add-ons (well, TSR's) to make the whole operationg system double-byte. Of course, these solutions did not use Unicode or TrueType fonts, but rather GB or JIS and monospaced bitmapped fonts. But if the solution has to be Unicode, it is not such a big deal to bang out a minimal Unicode library implementing, say: 1) UTF-8 handling, and maybe also UTF-16; 2) Unicode to DBCS (GB or JIS) conversion for the display. The only problem I see is that this old software is not on shops shelves anymore, so getting all the needed pieces requires some digging on Internet or bargain shops. _ Marco
