2011/5/6 Henrique Peron <hpe...@terra.com.br>:
> The number refers to the hex code (Unicode). Naturally, every dot would
> be a "0" and every "@" would be a "1"; with a little math, we have pixel
> data for any printer.
> The following step would be to create association files. I would prepare
> them.
> Let's say that we would have a file called "CP858.TXT", which would be
> checked by, let's say, "PRINTER.EXE". There would be a line which would
> read:
> D5, 20AC
> Then, I would run
> C:\> PRINTER 858
> Now, PRINTER.EXE knows that it would have to check CP858.TXT. If, when
> intercepting data being sent to a printer, it receives byte D5h, it
> would send the glyph code 20AC from the text file I have here.

Be careful here. You're breaking the NLS system here. The way to make
everything in a consistent way is that any character-device (such as a
printer  LPT1, or the console CON) must be a DOS device driver that
accepts certain ioctl commands to change codepage. Thus, when you

CHCP 858

all devices (console, printer, ...) change their codepage by the
kernel (the NLSFUNC extension).

The goodpoint by the CONSOLE is that there's an alternate way to
change the codepage via interrupts, thus you don't need to write a
device driver, but to have a TSR to do that (I guess that FreeDOS
NLSFUNC does use this interface for FreeDOS DISPLAY, which is
unstandard, but helps having a DISPLAY.EXE instead of a DISPLAY.SYS).

Unfortunately, no other character devices have such interrupt
interface that I know of. In order words, such software must be a true
DOS device driver (such as MS-DOS DISPLAY.SYS) and not a TSR (such as

Thus Henrique, the way you suggest breaks NLS compatibility in two points:
- By not being a true device driver, issuing CHCP 858 would change
codepages of all devices to 858, except for the printer: kernel
doesn't have a way to reach such PRINTER.EXE
- Even if there was that interrupt interface, it must be a resident
program: thus, if a program (other than COMMAND) issues a codepage
change command, it would work.

Of course, would be usefeul for a number of scenarios. But unlike on
MS-DOS, the way to change to 858 wouldn't be a plain CHCP 858, but
CHCP 858

(MODE CON CP SELECT 858 is the NOT recommended way)


All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
Freedos-user mailing list

Reply via email to