Re: [fd-dev] codepage IDs
X-Comment-To: Axel C. Frinke Hi! 26-îÏÑ-2002 02:18 [EMAIL PROTECTED] (Axel C. Frinke) wrote to [EMAIL PROTECTED]: AF Well, with the assumption that all codepage IDs would not take more AF than 10 bits, there would be 6 remaining bits to denote variations of AB Please, don't make such silly suggestions and implementations. Making ACF Really, I would not call this suggestion 'silly'. But results of such decisions often are silly. B-\ Probably, most clear example of such decisions is an BIOS limits for disk sizes: first 512M, then 2Gb, then 4Gb, then 8Gb, then 32Gb, then 127Gb... ACF Maybe I've gone too ACF far with 'nightmare', but it's still handy to save address space. This is matter of taste, how call such desicions: silly, nightmare, etc. AB full featured lookup table may be _slightly_ more complicated, but then AB later this will not crash your (and our) head when limits will be exhausted. ACF Yes, but whenever new codepages are introduced, such lookup tables ACF must be maintained, this can become a cumbersome work. Why? -- 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
X-Comment-To: tom ehlert Hi! 26-îÏÑ-2002 16:25 [EMAIL PROTECTED] (tom ehlert) wrote to [EMAIL PROTECTED]: ACF Maybe I've gone too ACF far with 'nightmare', but it's still handy to save address space. This is matter of taste, how call such desicions: silly, nightmare, etc. te I often disagree with arkady, :( te like this time: :) te trouble to save 4 bits isn't 'silly'. it's outright 'dull' ;-) Let me clarify the situation: there is no trouble with saving four bits, but I was try to dissuade Axel to make such decision, when he tries to use part of regular enumeration space for its own needs. We already have much of troubles with FIDO communication software and FoxPro DBMS, which uses some positions in upper half of ASCII8 for their own needings. -- 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
Rösberg, Tue 26.11.02 Hi Arkady, On Tue, 26 Nov 2002 18:54:43 +0300 (MSK), Arkady V.Belousov wrote: AB 26-îÏÑ-2002 16:25 [EMAIL PROTECTED] (tom ehlert) wrote to [EMAIL PROTECTED]: AF Maybe I've gone too AF far with 'nightmare', but it's still handy to save address space. AB This is matter of taste, how call such desicions: silly, nightmare, AB etc. TE trouble to save 4 bits isn't 'silly'. it's outright 'dull' ;-) Tom, why so polite? Why not slightly saying 'crack-brained'? After all, you always omit infinitive truth and wisdom, so you do need to take care of other people's opinion AB Please, don't make such silly suggestions and implementations. Making AF Really, I would not call this suggestion 'silly'. AB AB But results of such decisions often are silly. B-\ Probably, AB most clear example of such decisions is an BIOS limits for disk AB sizes: first 512M, then 2Gb, then 4Gb, then 8Gb, then 32Gb, then AB 127Gb... Hmmm... the number of codepage IDs does not grow with the same speed than hard disks do. But I go for that. And I want to repeat: my previous statement is more a wish than a demand. I would likely have the number of existing codepages limited to 4096 or 16384. But if there would be new codepages introduced with higher ID's, I would not ignore them. Of course, because of the possibility of such high codepage IDs my idea is somewhat questionable. AB full featured lookup table may be _slightly_ more complicated, but then AB later this will not crash your (and our) head when limits will be exhausted. AF Yes, but whenever new codepages are introduced, such lookup tables AF must be maintained, this can become a cumbersome work. AB Why? Actually, I starting to ask this question to myself. At meanwhile, it seems to be less effort for me to implement lookup tables than constisting on my idea. ;-) Regards, Axel. -- 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 Tue, 26 Nov 2002, Axel C. Frinke wrote: On Sat, 23 Nov 2002 01:39:39 -0500 (EST), Bart Oldeman wrote: BO This is what the Linux console does: its console driver first translates BO from the used character set to Unicode, and then maps the Unicode to BO the font used. How does this work in full screen text mode? At the end, this requires to display more than 256 different chars at the same time! (Tell me if I'm completely wrong with this.) This is full screen text mode what I was talking about. You see funny little square boxes for each unicode character for which the font has no equivalent. I saw these square boxes for instance in Matthias mails because he used 264 180 B4 ´ ACUTE ACCENT instead of the ASCII ' and I was using cp437 on the console. 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 ==^^===
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] 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 ==^
RE: [fd-dev] Codepage IDs
On Fri, 22 Nov 2002, Matthias Paul wrote: On 2002-11-20, Arkady V.Belousov wrote: 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. Well FreeDOS doesn't have a DOS BIOS as such. There's kernel.sys which consists (presently) of a) PGROUP 256 bytes at 60:0, used for startup and the init code's PSP b) TGROUP ~1500 bytes at 70:0: small device drivers (CON, AUX, PRN), assembly interface code, intxx trampolines, XMS callers to enable and disable the HMA. c) DGROUP ~5000 bytes now at 00eb:0. The DOS DS: LOL, SDA and so on, COUNTRY tables, constant strings and the low deblock BUFFER (this buffer is actually part of our SDA). d) HGROUP ~4-43000 bytes: main DOS code + block and clock device drivers. e) I_GROUP: ~18000 bytes init code and data: config.sys parser, block device driver init, main init. I_GROUP feels much like a normal .COM DOS program: after setting int vectors it simply calls int21 to open and read config.sys. Discarded after init. But I guess you mean the roughly same thing when I say that once nlsload.c gets fixed up it will be part of I_GROUP. 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 ==^
Re: [fd-dev] codepage IDs
Rösberg, Thu 21.11.02 Hi Arkady, On Thu, 21 Nov 2002 02:37:51 +0300 (MSK), Arkady V.Belousov wrote: RQ ( my wish: below 4000 RQ my second wish: below 8000 RQ my last wish: below 16000 :-((() AF I agree completely! AF Let me express it more precisely: it would be handy to have all AF codepage number below 4098. AB As stated by Matthias, DR-DOS assigns for code pages with euro sign AB some very big values. I think I heard about this, too. But is there an official DR-DOS release with such codepages? AF Codepage numbers above 16383 would be nightmare! AB Why? Well, with the assumption that all codepage IDs would not take more than 10 bits, there would be 6 remaining bits to denote variations of the existing codepages. If I remember correct, the DR-DOS method denotes codepage 858 as 20850. For automatted processing it is much easier to subtract 2 than looking up in an additional lookup table for variants of codepages. With 'regular' codepage IDs above 16383, there would only one bit remain for variations - this could become painful for system programmers. AF lot of codepages without any official IDs. The most important of them AF is KOI8-R, which should be supported as well. (Arkady, do you agree?) AB No. What a pity. AB See the difference: under Windows you have one system codepage (to be AB precise: two with so called OEM) and may use any fonts simultaneously. AB This is how was added support for KOI8-R in Netscape Navigator before it AB begins a _real_ internationalized program. Well, as it goes for me, I would likely have support for ISO-Latin-1 under DOS, this would spare me much conversion work for my emails. I thought you would feel similar. AB Under DOS you have one system codepage and you _can't_ have other AB simultaneous fonts [for different code pages]. This is nature of text modes, AB only some _applications_ may support in graphics mode some different fonts. I don't understand this. Can't you use CHCP to switch between codepages? AB On the other side, KOI8-R never used in DOS as base codepage, although This is no reason against. You know, there was a time where Internet was never used before. Nowadays many people use it in spite. ;-) AB beside ALT (CP866) codepage there was three other - MAIN, BULGAR and GOST. AB KOI8-R used only as commincation base, so under DOS you should only have AB translation tables in communication programs. Well, I don't know whether these codepages contain important characters which are not contained in KOI8-R. AB Conclusion: under DOS may/should used only CP866. Adding support for AB other codepages (even for Windows CP1251) have no sense - at least, because AB they not contain pseudographic characters. Well, I confess: you have more knowledge about this topic as I have. AB BTW, to complicate case the more, there is another KOI8 - KOI8-U AB (Ukrainian KOI8). You may see the differences with KOI8-R in RFC2319. I will take a look at it by chance. Thanks. Regards, Axel. -- 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 ==^^===
