• Console : volume name displayed by "dir" is different than returned by

    From R.Wieser@21:1/5 to All on Mon Jan 31 13:31:34 2022
    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)
  • From JJ@21:1/5 to R.Wieser on Tue Feb 1 09:41:17 2022
    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)
  • From R.Wieser@21:1/5 to All on Tue Feb 1 10:49:33 2022
    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)
  • From JJ@21:1/5 to R.Wieser on Tue Feb 1 21:25:16 2022
    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)
  • From R.Wieser@21:1/5 to All on Tue Feb 1 15:51:19 2022
    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)
  • From R.Wieser@21:1/5 to All on Tue Feb 1 15:55:10 2022
    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)
  • From Uwe Sieber@21:1/5 to R.Wieser on Wed Feb 2 11:56:31 2022
    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)
  • From R.Wieser@21:1/5 to All on Wed Feb 2 17:33:50 2022
    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)
  • From Uwe Sieber@21:1/5 to R.Wieser on Thu Feb 3 09:14:54 2022
    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)
  • From R.Wieser@21:1/5 to All on Thu Feb 3 11:50:44 2022
    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)
  • From Uwe Sieber@21:1/5 to R.Wieser on Fri Feb 4 09:09:14 2022
    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)
  • From R.Wieser@21:1/5 to All on Fri Feb 4 11:35:19 2022
    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)
  • From R.Wieser@21:1/5 to All on Fri Feb 4 14:51:18 2022
    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)