Hello all,

Inside an XPsp3 CMD.EXE console window :

I've just used 'GetVolumeInformation' function to retrieve a drives volume
name and noticed that it looks differently from when I did a "dir" for the
same drive.

The "dir" command returns an intended 0xFA (a small vertically-centered
dot), the GetVolumeInformation function returns a 0XB7 (single border left, double border down).

I'm /guessing/ that some kind of characterset translation is performed
by/for the "dir" command. How can I have the same done to (the output of)
the GetVolumeInformation function ?

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 31 Jan 2022 13:31:34 +0100, R.Wieser wrote:

Hello all,

Inside an XPsp3 CMD.EXE console window :

I've just used 'GetVolumeInformation' function to retrieve a drives volume name and noticed that it looks differently from when I did a "dir" for the same drive.

The "dir" command returns an intended 0xFA (a small vertically-centered
dot), the GetVolumeInformation function returns a 0XB7 (single border left, double border down).

I'm /guessing/ that some kind of characterset translation is performed
by/for the "dir" command. How can I have the same done to (the output of) the GetVolumeInformation function ?

Regards,
Rudy Wieser

The Middle Dot character's Unicode Codepoint is 0xB7 which is the same character code for Windows (ANSI) code page. DIR generates character code translated to OEM US code page 437, which is 0xFA.

If you switch to code page 1252 in CMD using `chcp 1252` then capture the
DIR output, it'll generate character code 0xB7 instead of 0xFA.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

The Middle Dot character's Unicode Codepoint is 0xB7 which is the same character code for Windows (ANSI) code page. DIR generates character
code translated to OEM US code page 437, which is 0xFA.

Thanks for confirming my guess. :-)

If you switch to code page 1252 in CMD using `chcp 1252` then capture
the DIR output, it'll generate character code 0xB7 instead of 0xFA.

I just wrote a "thanks, I'm going to try that", but realized that that
ofcourse affects all other console-based programs too, and only on my
current machine - neither of which is positive.

IOW, I'm going to see if I can find something that will either only change
the codepage for a single program (emulating what the DIR command seems to
be doing), or perhaps even a codepage translation for just that string. Google/DDG, here I come :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 1 Feb 2022 10:49:33 +0100, R.Wieser wrote:

IOW, I'm going to see if I can find something that will either only change the codepage for a single program (emulating what the DIR command seems to
be doing), or perhaps even a codepage translation for just that string. Google/DDG, here I come :-)

I use Microsoft AppLocale for that.

https://en.wikipedia.org/wiki/AppLocale

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

IOW, I'm going to see if I can find something that will either only change the codepage for a single program

I found and tried SetConsoleOutputCP as well as SetConsoleCP, but neither
seems to affect the output I'm writing (to the STD_OUTPUT_HANDLE file).
And both seem to remain after my program terminates. :-|

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

I use Microsoft AppLocale for that.

Thanks. But I need my program set it for itself, and just for the 32...255 range.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

R.Wieser wrote:

IOW, I'm going to see if I can find something that will either only change >> the codepage for a single program

I found and tried SetConsoleOutputCP as well as SetConsoleCP, but neither seems to affect the output I'm writing (to the STD_OUTPUT_HANDLE file).
And both seem to remain after my program terminates. :-|

Just make a unicode application and write the output by means of WriteConsoleW(), which performs the translation to the console's
codepage which works without any losses if it is UTF-8 and no
bitmap font is used.

But if the output is redirected then WriteConsole fails and WriteFile
must be used. Here you write raw data and are reponsible to translate
the text to the desired format. I use GetACP() for WideCharToMultiByte.

m_OutputRedirected = ( GetFileType(GetStdHandle(STD_OUTPUT_HANDLE)) != FILE_TYPE_CHAR );
m_ErrorRedirected = ( GetFileType(GetStdHandle(STD_ERROR_HANDLE )) != FILE_TYPE_CHAR );

Or just assume redirection if WriteConsole fails ;-)


Uwe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Uwe,

Just make a unicode application

Thanks, but no. I like ASCII too much to ditch it for a problem like this.

and write the output by means of WriteConsoleW()

The last time I looked that needed a console screen buffer. And while
playing with that I had to experience that those do not really work nicely alongside of STD_OUTPUT_HANDLE file output (strange stuff happened).

m_OutputRedirected = ( GetFileType(GetStdHandle(STD_OUTPUT_HANDLE))
!= FILE_TYPE_CHAR );

(Named) Pipes are also character devices ...

Or just assume redirection if WriteConsole fails ;-)

That sounds like something I would do. Its too damn hard to figure out if
a handle is redirected or not. Although MSDN mentiones GetConsoleMode I do
not see how (also, it has side effects when used on a pipe).

Thanks for the suggestion though.


I'm currently thinking of trying to use a MultiByteToWideChar, WideCharToMultiByte pair to do the translation. Not elegant, but with (seemingly) the absense of anything else it will have to do. :-\

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

R.Wieser wrote:

Just make a unicode application

Thanks, but no. I like ASCII too much to ditch it for a problem like this.

Then just use W functions here and there...

and write the output by means of WriteConsoleW()

The last time I looked that needed a console screen buffer. And while playing with that I had to experience that those do not really work nicely alongside of STD_OUTPUT_HANDLE file output (strange stuff happened).

No, WriteConsoleOutput needs console buffer, WriteConsole just a string buffer.

m_OutputRedirected = ( GetFileType(GetStdHandle(STD_OUTPUT_HANDLE))
!= FILE_TYPE_CHAR );

(Named) Pipes are also character devices ...

Nope, they are FILE_TYPE_PIPE.

I'm currently thinking of trying to use a MultiByteToWideChar, WideCharToMultiByte pair to do the translation. Not elegant, but with (seemingly) the absense of anything else it will have to do. :-\

W function plus WriteConsoleW plus non-bitmap font plus codepage 65001 (UTF-8) is the only way to avoid character translation losses.
Until you hit a FAT drive with non-ASCII charcters in the volume label (which is OEM-CP on disk) written under a dfferent OEM-CP than the current one :-)

Uwe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Uwe,

No, WriteConsoleOutput needs console buffer, WriteConsole just a string buffer.

I'm afraid MS begs to differ :

https://docs.microsoft.com/en-us/windows/console/writeconsole

"hConsoleOutput [in]
A handle to the console screen buffer."

m_OutputRedirected = ( GetFileType(GetStdHandle(STD_OUTPUT_HANDLE))
!= FILE_TYPE_CHAR );

(Named) Pipes are also character devices ...

Nope, they are FILE_TYPE_PIPE.

My apologies, I was (somehow) looking at GetConsoleMode.

And although I wondered about a redirected-to-another-programs StdIn, a
quick test showed that that also returns the "pipe" type.

W function plus WriteConsoleW plus non-bitmap font plus codepage 65001 (UTF-8) is the only way to avoid character translation losses.

That does limit my options a bit. :-|

Until you hit a FAT drive with non-ASCII charcters in the volume label
(which is OEM-CP on disk) written under a dfferent OEM-CP than the current one :-)

At the time I created that volume label (first letter of my christian name, vertically centered dot, family name - on an USB stick) I already wondered
how long it would take before some kind of a problem with it would pop up
...

Although it didn't for a decade or so I think I should re-think the wisdom
of it. :-)

Thanks for the information.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

R.Wieser wrote:

No, WriteConsoleOutput needs console buffer, WriteConsole just a string
buffer.

I'm afraid MS begs to differ :

https://docs.microsoft.com/en-us/windows/console/writeconsole

"hConsoleOutput [in]
A handle to the console screen buffer."

I thought you talk about the buffer with the characters to write...

About the handle:
GetStdHandle(STD_OUTPUT_HANDLE) is the handle to the current console
screen buffer and can be used with WriteConsole and WriteConsoleOutput.


Uwe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Uwe,

I'm afraid MS begs to differ :

https://docs.microsoft.com/en-us/windows/console/writeconsole

"hConsoleOutput [in]
A handle to the console screen buffer."

I thought "what the heck, the program can only crash" and just now tried providing it the StdOut handle. Unexpected (by me) I got output on the
screen *and* I could use WriteFile to the same StdOut handle without it becoming a mess.

And oh yeah, it gave me the output I needed too (regardless of using the W
or A version).

IOW, I owe you another thanks.

As for MS, I guess its another example of how hard it is to write good documentation. :-\

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Uwe,

I thought you talk about the buffer with the characters to write...

:-) And I was thinking that that is normally referred to as "a string" ...

I on my side did not recognise that "the console screen buffer" is not just
an array of bytes.

About the handle:
GetStdHandle(STD_OUTPUT_HANDLE) is the handle to the current console
screen buffer and can be used with WriteConsole and WriteConsoleOutput.

Thanks. Having to rely on the MS docs for most of what I do I surely miss
(in more than one sense of the word) details like that. :-\

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)