Re: RE: [fd-dev] Codepage IDs
Hi, = Actually, Michal and I are working on creating new .CPI files from scratch (to be used under *any* system supporting .CPI files, including DR-DOS, PTS-DOS, MS-DOS OEM issues, Arabic/Hebrew issues of MS-DOS, OS/2 and Windows NT/2000/XP), so you can include and exclude codepages as you like. Switching between the various .CPI file formats will also be just a matter of setting a different conditional define. = This is good, one of my goals is to introduce soon CPI parsing routines in DISPLAY, so that such project can also be used for FreeDOS with DISPLAY. But in order to have SOMETHING, I decided to release DISPLAY with the easier approach of the RAW files (simply a concatenation of the x8,x14 and x16 fonts). == There's something that I would need to know for KEYB to handle this easily: which is the highest codepage number known? May I refer you to the huge KBD.LST file containing all the keyboard related news for the forthcoming issue of RBIL? I already sent you a copy... For your convenience, here's one of the tables to be found under INT 21h/AX=AD80h: == Sorry, I always forgot that there's codepage info over there too! :-) === ( my wish: below 4000 my second wish: below 8000 my last wish: below 16000 :-((() Country codes, Code Page IDs, and Keyboard Layout IDs are 16-bit values and should be treated as such. Although far not all of them were or are used by Microsoft and IBM, the highest assignable Code Page number is 65533. 0, 65534 and 65535 are reserved as they have special meanings for the OS itself (see below). == So I was out of luck! Well, it can be patched more or less easily. == CHCP is an internal program that calls kernel, which calls NLSFUNC. Indirectly, yes. It calls the DOS kernel, which will usually call down to NLSFUNC, which will then call back into DOS to retrieve the info (for file I/O only). Once the info has been looked up, NLSFUNC will return it to the DOS kernel, which will then again call NLSFUNC in order to switch the codepage. NLSFUNC will then ask any character device driver in the system if it supports codepage switching. Any driver supporting codepage switching (like DISPLAY.SYS or PRINTER.SYS, for example), will then be advised to switch the codepage. If they return an error, NLSFUNC will return an error as well. DISPLAY.SYS internally will also communicate with ANSI.SYS and KEYB in order to switch display and keyboard codepages (ANSI.SYS is not called for codepage switching as is, only for communicating display properties). = Very interesting topic. Well, some more issues here: (1) The way of doing that is via int2Fh/MUX=1Ah or is it possible to call the next driver in the chain somehow? (2) In fact, I was expecting to reflect ALL the calls except the change codepage (generic IOCTL) to the next driver in the chain, how can I do it? (3) Suppose someone install DISPLAY.SYS before ANSI.SYS. Can I expect that ANSI (or other CON driver loaded later) will reflect to me any call? == (*) There is a case which, in my opinion, leads to inconsistency. DISPLAY.SYS is responsible for changing keyboard codepage too. Microsoft's implementation will switch the screen codepage regardless if KEYB managed to change codepage or not, which means that it would leave screen and keyboard with different codepages if KEYB failed. In my opinion, this is a bug. In my opinion, too, but I would simply implement an option into DISPLAY to control the behaviour - so the decision is up to the user. I suggest to use /E for this purpose because it would somewhat correlate with an option supported by my internal issue of DR-DOS NLSFUNC: = Ok, annotated in the TODO list ;-)) = This program is not required. It required only if you wish to switch codepages on the fly, but if you work only with one codepage, you may (should) initialize it with COUNTR= statement. Of course, in MS-DOS MODE and KEYB without NLSFUNC loaded will fail to load fonts/layouts other than pointed in COUNTRY=. This is correct, but still, a COUNTRY.SYS file parser is needed not only for NLSFUNC, but also for FreeDOS' DOS BIOS. In older issues of DR DOS, NLSFUNC has been an integral part of the kernel, and the disk file was only a dummy for programs expecting it to be there. But then the code moved into the DOS BIOS, where it will get discarded after init (the driver is temporarily linked in during the processing of the COUNTRY directive), and into the file parsing portion of the external NLSFUNC driver for later use. = We could have at least a very basic parser that would simply read the information in the formats defined by Steffen as chunks in a single file. If someone manages to cut on 1 half the Earth spinning rate, so that a day has 48 hours, I'd compromise to do that myself. ((I have removed it when you mentioned that older currencies are not longer in use)) There seems to be a symbol (I think in CP437) for Spanish PESETA, that I have seen
Re: [fd-dev] Dosemu
Eric Auer wrote: Hi, well, you really ARE a pessimist. Au Contraire, I think some distro programmers will figure it out, and realize that: Linux comes from Unix, which is a multi-user networked operating system. As such it sux for the single user desktop. I dont think it would be that big a deal to design a distro for the single user, and some have made some modifications to that end, but.. they've got a long ways to go before reaching the convenience of dos, which was always built for the single user, and tweaked over the years for that purpose. Some Linux lovers have told me how to change the boot so it comes right up to my personal xwin kde, or do, as you have suggest ways to install software or whatever, but I dont do windoz, and I sure as shit dont build them. Start talking about building kernels and makefiles and compiling binaries to most people who just want to sit and do email, and their eyes glaze over looking out the window and thinking they awta go outside. If Nettamer would do my email anymore, I'd be using it; writing ascii in a gui screen is fundamentaly oxymoronic. But my new local ISP will not log me in with any of the dos ppp drivers, and I have other things to do besides debug that problem. There must be someone who knows more about it. But in both cases, dos and linux, I look at the computer skill of most users, and dont see reasonable solutions. For example, you dont turn off net servers. But I dont like the idea of my computer in my quiet rural home running all the damn time. As people realize that they can telecommute from the boondocks, this will become a more obvious problem, you can hear the damn blowers in the kitchen while you get another cuppa java. So, with dos, I close the app, and hit the power button. [that's a period] I find it a p*** in the a** to havta go thru so many clicks to close the browser, kde, and wait for the shutdown to close all the open files [which are there for a network which does not exist]. I'm not ragging on Linux, cause it is a great operating system for sysads, networks, and servers. But the newbie so commonly sees the message to 'consult with your system administrator', that he knows he will be scrod if he tries to fix the problem himself. The only 'system administrator' I have is behind my navel. FWI: SCROD- pluperfect subjunctive case. -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
Re: [fd-dev] codepage IDs
On Thu, 21 Nov 2002, Axel C. Frinke wrote: BO with cp850 vs. cp437 you already lose the mixed double/single box drawing BO characters, but these aren't used as often as the non-mixed ones. I don't think so! Consider a programm which displays a table with different box styles for 'inner' and 'outer' lines. Under cp850, the 'junctions' will already look weird. Sure, that's exactly what I said. Let me rephrase: cp850 does not have the mixed double/single box drawing characters, but cp437 has them. On the other hand there are many DOS programs who avoid those characters and only use the single-only or double-only boxes. And all of the DOS style codepages have at least those characters, at the expected places. BO So it is not so much the nature of text mode, but more an artifact of the BO direct-video approach. If all text mode apps would write using, say, ANSI I don't think this has to do with direct-video approach, but with the assumption that cp437 ist active instead. BO sequences (fast enough with NANSI.SYS) then the ANSI driver could do the BO translation. But the MSDOS ANSI.SYS was slow and not loaded by default so I don't think so. In text mode, every display of characters ends up in a direct-video approach, regardless whether a program does this by itself or uses INT 21h function calls. In text mode there is no way to display mixed box chars under cp850! Sure, NANSI itself uses direct video access, but (N)ANSI.SYS could do a translation. This is what the Linux console does: its console driver first translates from the used character set to Unicode, and then maps the Unicode to the font used. So if you boot Linux using the codepage 437 font, then you can still use iso8859-1 as the character set without changing the font in the video hardware -- as long as there is an equivalent position of the iso8859-1 character in cp437. Boxes can also be drawn using VT100 sequences. This is impractical under DOS *because* so many programs use direct video access instead of the console driver. Bart -- list options/archives/etc.: http://www.topica.com/lists/fd-dev unsubscribe: send blank email to: [EMAIL PROTECTED] ==^ This email was sent to: archive@mail-archive.com EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^
