Extended ASC

[ed_crumbpacker]

When I use SCREEN 19 command and CHR(1??) I get an extended ascii character (I'm trying to display the pipe and double pipe type borders). This is great - just what I want. But when I take out the SCREEN 19 and go to console (in Linux and I assume in Windows also) I end up with some other character completely. I would like to be able to run in both console and windows mode. I would like to know why this happens, and if there is a workaround.

I maybe wrong about this happening in cmd.exe but I can't test it because my wife is playing some rpg at the moment.

Also, I know the extended characters ARE available in Linux because Midnight Commander uses them in console mode.

thankx

[counting_pine]

There's no single definition for ASCII codes above 127.
The DOS console (and DOS graphics modes) use character sets called codepages (the US defaults to CP437) while the Windows GUI and Linux use a very different character set. I think Windows-1252 tends to be standard.
You could look up the unicode character values for things like line drawing characters, but they won't work in graphics modes or the DOS console, which aren't unicode.

[Bob the Hamster]

I think that the Curses library might be a way to accomplish this:

ExtLibcurses

[marcov]

There's no single definition for ASCII codes above 127.
The DOS console (and DOS graphics modes) use character sets called codepages (the US defaults to CP437) while the Windows GUI and Linux use a very different character set. I think Windows-1252 tends to be standard.

Non embedded Linux is generally UTF8 nowadays (check LANG env variable).

Windows has a so called OEM encoding for the textmode console, which is afaik equal to the old cp437/850 codepages etc. While the Windows API uses the so called "ansi" encodings (Windows-125?), or UTF16. (UCS2 in Windows 2000)

You could look up the unicode character values for things like line drawing characters, but they won't work in graphics modes or the DOS console, which aren't unicode.

It could be that the NT console can be unicode (if you use -W functions to write), but I never got that entirely confirmed. Besides that, there must be font support for that.

[MichaelW]

Running on my Windows XP system, where the default code page is 437, whether I select Raster Fonts or Lucida Console, this displays the familiar extended ASCII characters:

Code: Select all

#include "windows.bi"

print GetConsoleOutputCP
print

for i as integer = 127 to 255
    print chr(i);
next
print

sleep

[marcov]

Running on my Windows XP system, where the default code page is 437, whether I select Raster Fonts or Lucida Console, this displays the familiar extended ASCII characters:

Here it is 850 (UK Win pro with dutch locale selected). You can view the OEM codepage with the chcp command.

Code: Select all

C:\Users\marcov>chcp
Active code page: 850

[counting_pine]

There's no single definition for ASCII codes above 127.
The DOS console (and DOS graphics modes) use character sets called codepages (the US defaults to CP437) while the Windows GUI and Linux use a very different character set. I think Windows-1252 tends to be standard.

Non embedded Linux is generally UTF8 nowadays (check LANG env variable).

Yeah, that sounds right. I think what I meant to say is that (at least in my experience) it uses the 1252 character set to choose the glyphs for chars between 128 and 255.