Console Encoding in Windows (Local VS. UTF8)

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Console Encoding in Windows (Local VS. UTF8)

shiruba2012
Hi,

I deal with in Japanese (and sometimes other languages) in a lot of my programs, and nothing I do seems to work consistently on Windows systems.  (OS X is no problem).

I have followed steps in the Wiki, etc., but to little avail, so I have some questions for anyone who knows more than me:
1. What encoding "should" I be writing to the terminal?  from experimenting with text files using the cat command in powershell, it seems that local ("ANSI") encoding should be used.  This makes sense since older versions of windows only supported local encodings.
2. Is there any reason why writing out data in the local encoding (with write statements, etc.) should get corrupted?  For example is some level of the RTL assuming something about the encoding? (I don't think so, but...)
3. Is there a way to set the output to UTF8 so I can just write out UTF8 and be done with it?

Just to give an example:
1. I read in an SJIS CSV file, and display it on the screen, and it's corrupted.  
2. I convert it to UTF8 before displaying it, and it's still corrupted. 
3.I cat the file to the screen and it's ok.  
4. I write the output to a file instead of the console, and it's ok.

Something seems odd.

Does anyone else have these issues?

Thank you,
    Noah Silva

p.s.: I know that the actual data in my programs isn't broken, because if I write it to a file or database, there is no problem with corruption.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Jonas Maebe-2

On 09 Jul 2013, at 11:02, Noah Silva wrote:

> 1. What encoding "should" I be writing to the terminal?

The console code page. You can get it using the following function:
   function GetConsoleOutputCP : UINT; stdcall; external 'kernel32'  
name 'GetConsoleOutputCP';

> from experimenting
> with text files using the cat command in powershell, it seems that  
> local
> ("ANSI") encoding should be used.  This makes sense since older  
> versions of
> windows only supported local encodings.

The ansi code page is (or at least can be) different, that's the the  
result of
   function GetACP:UINT; stdcall; external 'kernel32' name 'GetACP';

> 2. Is there any reason why writing out data in the local encoding  
> (with
> write statements, etc.) should get corrupted?  For example is some  
> level of
> the RTL assuming something about the encoding? (I don't think so,  
> but...)

Not in 2.6.x. In 2.7.x, every ansistring is tagged with a code page  
(the ansi code page by default) and the RTL will convert it to the  
console code page before writing it.

> 3. Is there a way to set the output to UTF8 so I can just write out  
> UTF8
> and be done with it?

I don't know.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Reinier Olislagers
In reply to this post by shiruba2012
On 9-7-2013 11:02, Noah Silva wrote:

> I have followed steps in the Wiki, etc., but to little avail, so I have
> some questions for anyone who knows more than me:
> 1. What encoding "should" I be writing to the terminal?  from
> experimenting with text files using the cat command in powershell, it
> seems that local ("ANSI") encoding should be used.  This makes sense
> since older versions of windows only supported local encodings.
> 2. Is there any reason why writing out data in the local encoding (with
> write statements, etc.) should get corrupted?  For example is some level
> of the RTL assuming something about the encoding? (I don't think so, but...)
> 3. Is there a way to set the output to UTF8 so I can just write out UTF8
> and be done with it?
>
> Just to give an example:
> 1. I read in an SJIS CSV file, and display it on the screen, and it's
> corrupted.  
> 2. I convert it to UTF8 before displaying it, and it's still corrupted.
> 3.I cat the file to the screen and it's ok.  
> 4. I write the output to a file instead of the console, and it's ok.
>
> Something seems odd.
>
> Does anyone else have these issues?
Yes.

See:
http://bugs.freepascal.org/view.php?id=22461
for info on the situation in FPC trunk.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Tomas Hajny-2
In reply to this post by Jonas Maebe-2
On Tue, July 9, 2013 11:13, Jonas Maebe wrote:
> On 09 Jul 2013, at 11:02, Noah Silva wrote:
 .
 .
>> 3. Is there a way to set the output to UTF8 so I can just write out
>> UTF8
>> and be done with it?
>
> I don't know.

There is code page 65001 for UTF-8, however I don't know since which
version of MS Windows it is supported (and to which extent - e.g.
including the console output). You may change the output code page for
console using the Windows API call SetConsoleOutputCP, but e.g. our unit
Crt currently resets the code page used for output to console to the
"main" process code page (as returned by GetACP) on each write and thus
ignores the user selection - this will probably change in trunk in the
future as part of the Unicode support activities, but the current state is
like this.

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Marco van de Voort
In our previous episode, Tomas Hajny said:
> >> and be done with it?
> >
> > I don't know.
>
> There is code page 65001 for UTF-8, however I don't know since which
> version of MS Windows it is supported (and to which extent - e.g.
> including the console output).

Afaik Windows XP, but there might be font problems on console.

> console using the Windows API call SetConsoleOutputCP, but e.g. our unit
> Crt currently resets the code page used for output to console to the
> "main" process code page (as returned by GetACP) on each write and thus
> ignores the user selection - this will probably change in trunk in the
> future as part of the Unicode support activities, but the current state is
> like this.

Keep in mind he is talking powershell, not cmd.exe
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Michael Schnell
In reply to this post by shiruba2012
On 07/09/2013 11:02 AM, Noah Silva wrote:
>
> I convert it to UTF8 before displaying it....
>
Not a good idea.

The FPC developers are right now busy implementing the new Delphi
Strings. This _could_ mean that the application programmer can  use any
encoding (such as multiple different ANSI byte-codes, UTF-8, UTF-16,
...), but in fact to be 100% Delphi compatible ("nothing less, nothing
more"), it seems that only UTF-16 will gain full decent support (e.g.
class inheritance, in TStringList, the Lazarus user API etc.)

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Marco van de Voort
In our previous episode, Michael Schnell said:
> Not a good idea.
>
> The FPC developers are right now busy implementing the new Delphi
> Strings. This _could_ mean that the application programmer can  use any
> encoding (such as multiple different ANSI byte-codes, UTF-8, UTF-16,
> ...), but in fact to be 100% Delphi compatible ("nothing less, nothing
> more"), it seems that only UTF-16 will gain full decent support (e.g.
> class inheritance, in TStringList, the Lazarus user API etc.)

Well, the main reason is not FPC, but Windows. UTF8 in Windows on _API_
level is simply not a good idea.

I have tried some programs/batchfiles that do chcp 65001  in  a cmd.exe, but
that doesn't really work nice. E.g. the "dir" command might simply fail
afterwards, and some foreign chars don't work properly either (some do
though!?!?)

I mostly rewrote them to delphi console apps (the delphi RTL does everything
over -W functions).

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Dennis Poon
In reply to this post by shiruba2012

> I have followed steps in the Wiki, etc., but to little avail, so I
> have some questions for anyone who knows more than me:
> 1. What encoding "should" I be writing to the terminal?  from
> experimenting with text files using the cat command in powershell, it
> seems that local ("ANSI") encoding should be used.  This makes sense
> since older versions of windows only supported local encodings.
> 2. Is there any reason why writing out data in the local encoding
> (with write statements, etc.) should get corrupted?  For example is
> some level of the RTL assuming something about the encoding? (I don't
> think so, but...)
> 3. Is there a way to set the output to UTF8 so I can just write out
> UTF8 and be done with it?
>
> Just to give an example:
> 1. I read in an SJIS CSV file, and display it on the screen, and it's
> corrupted.
> 2. I convert it to UTF8 before displaying it, and it's still corrupted.
> 3.I cat the file to the screen and it's ok.
> 4. I write the output to a file instead of the console, and it's ok.
>

Please state the windows version you are using. XP or Windows 7?  I deal
with chinese in my programs so I know your problems. The same delphi 5
program works differently on XP and Windows 7.  Looks like Windows 7 has
removed support for non unicode (I am not sure whether the Unicode it
uses is UTF8, UTF16 or UTF32).

Seems that all filenames in XP are treated as unicode code. If you type
a non unicode file name in Explorer, it will be auto converted to unicode.
Also, in XP, when text is copied to MS Office from other programs and
vice versa, XP seems to do an automatic conversion to UTF-8 and vice versa.
That is if you copy some text in your program which is encoding in SJIS
and paste it to Word, the text seems to be auto converted to unicode.

As for file handling, it seems some programs will read the first 2 bytes
of the text file to determine the the encoding of the file. Google about it.

Sorry, I don't have exact answers to your questions. Just share some of
my experience.

Dennis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Michael Schnell
In reply to this post by Marco van de Voort
On 07/09/2013 12:55 PM, Marco van de Voort wrote:
> Well, the main reason is not FPC, but Windows. UTF8 in Windows on
> _API_ level is simply not a good idea

You are absolutely right.

Here, in theory the Lazarus LCL and the FPC RTL could help by by
providing an application programmer API that does not force a dedicated
encoding. But to do so without the necessity to provide multiple OS
depending versions of the LCL and RTL interface definition, it would
need the compiler to provide support this.

In a perfect world the application programmer could use the encoding he
thinks is appropriate for the internals of his busyness logic and the
programming system does the correct things do use the API of the OS the
program is compiled for (while for optimum performance do code
conversions only when necessary).

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Marco van de Voort
In reply to this post by Dennis Poon
In our previous episode, Dennis Poon said:
> Please state the windows version you are using. XP or Windows 7?

In XP there were separate Far East versions of Windows.  In Vista+ this
was wholly integrated and there is only one Vista base system with various
language packs.

It might be that some of the Far East apis were deprecated later, but I
would expect them to run if you configure the backwards compatibility
options on the shortcut.

> I deal with chinese in my programs so I know your problems.  The same
> delphi 5 program works differently on XP and Windows 7.  Looks like
> Windows 7 has removed support for non unicode (I am not sure whether the
> Unicode it uses is UTF8, UTF16 or UTF32).

UTF16 and a bit of UTF8. (e.g. notepad groks utf8 now).

> Seems that all filenames in XP are treated as unicode code.

All NT derived systems are Unicode (UCS2, later UTF16) in the heart. The
whole ansi support is a win32 compatibility layer.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Tomas Hajny-2
In reply to this post by Marco van de Voort
On Tue, July 9, 2013 12:40, Marco van de Voort wrote:

> In our previous episode, Tomas Hajny said:
>> >> and be done with it?
>> >
>> > I don't know.
>>
>> There is code page 65001 for UTF-8, however I don't know since which
>> version of MS Windows it is supported (and to which extent - e.g.
>> including the console output).
>
> Afaik Windows XP, but there might be font problems on console.

I also thought about mentioning True Type fonts (like Lucida) being a
better option in this case, but then I assumed that with Japanese, this
might be necessary anyway.


>> console using the Windows API call SetConsoleOutputCP, but e.g. our unit
>> Crt currently resets the code page used for output to console to the
>> "main" process code page (as returned by GetACP) on each write and thus
>> ignores the user selection - this will probably change in trunk in the
>> future as part of the Unicode support activities, but the current state
>> is
>> like this.
>
> Keep in mind he is talking powershell, not cmd.exe

I have no experience with powershell yet, but as long as it uses a console
window (albeit designed differently), the launched applications should
behave the same way, shouldn't they?

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Marco van de Voort
In our previous episode, Tomas Hajny said:
> >> is
> >> like this.
> >
> > Keep in mind he is talking powershell, not cmd.exe
>
> I have no experience with powershell yet, but as long as it uses a console
> window (albeit designed differently), the launched applications should
> behave the same way, shouldn't they?

Dos compatibility has waned somewhat. I would assume a new console type
wouldn't be OEM.  And probably even the 8-bit api would be a compatibility
layer over the underlaying 16-bit api.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Tomas Hajny-2
On Tue, July 9, 2013 14:38, Marco van de Voort wrote:

> In our previous episode, Tomas Hajny said:
>> >> is
>> >> like this.
>> >
>> > Keep in mind he is talking powershell, not cmd.exe
>>
>> I have no experience with powershell yet, but as long as it uses a
>> console
>> window (albeit designed differently), the launched applications should
>> behave the same way, shouldn't they?
>
> Dos compatibility has waned somewhat. I would assume a new console type
> wouldn't be OEM.

True. However, this probably changes the default value of console output
CP, but whopefully should not change the principle.


> And probably even the 8-bit api would be a compatibility
> layer over the underlaying 16-bit api.

Isn't this already the case of the original console anyway?

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Graeme Geldenhuys-3
In reply to this post by Tomas Hajny-2
On 2013-07-09 13:08, Tomas Hajny wrote:
>> Afaik Windows XP, but there might be font problems on console.
> I also thought about mentioning True Type fonts (like Lucida) being a


It's not so much about True Type fonts, but about enabling a Unicode
font in the console. There are many True Type fonts that only support
the ASCII character-set.


Regards,
  G.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Tomas Hajny-2
On Wed, July 10, 2013 10:30, Graeme Geldenhuys wrote:
> On 2013-07-09 13:08, Tomas Hajny wrote:
>>> Afaik Windows XP, but there might be font problems on console.
>> I also thought about mentioning True Type fonts (like Lucida) being a
>
>
> It's not so much about True Type fonts, but about enabling a Unicode
> font in the console. There are many True Type fonts that only support
> the ASCII character-set.

Sure, but you can't select just any True Type fonts for console windows
(only Lucida is offered in WinXP; I just don't know if the same font is
offered if the main locale is Japanese or if it isn't another font in
later MS Windows versions).

Regarding True Type fonts only supporting ASCII (and disregarding the fact
that those wouldn't support Japanese mentioned in the original post
anyway) - I meant using an appropriate True Type font as a minimum
condition (i.e. not necessarily sufficient per se).

Tomas


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

Graeme Geldenhuys-3
On 2013-07-10 11:19, Tomas Hajny wrote:
>
> Sure, but you can't select just any True Type fonts for console windows
> (only Lucida is offered in WinXP;

And is so since Win95. Just amazing that Windows Console is so far
behind other platforms - it's rather ridiculous if you think about it.

If I used Windows, I would install a different console application —
there must be better after-market ones out there. But yes, this probably
doesn't solve your or your clients problems.

Anyway, here is some background information on Microsoft's terrible
Console Window.


Why are console windows limited to Lucida Console and raster fonts?

 http://blogs.msdn.com/b/oldnewthing/archive/2007/05/16/2659903.aspx

Here is how you can add more fonts — but you are on your own (the words
from Microsoft):

  http://support.microsoft.com/kb/247815


Regards,
  G.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

el_es
On 10/07/2013 13:38, Graeme Geldenhuys wrote:

> On 2013-07-10 11:19, Tomas Hajny wrote:
>>
>> Sure, but you can't select just any True Type fonts for console windows
>> (only Lucida is offered in WinXP;
>
> And is so since Win95. Just amazing that Windows Console is so far
> behind other platforms - it's rather ridiculous if you think about it.
>
> If I used Windows, I would install a different console application —
> there must be better after-market ones out there. But yes, this probably
> doesn't solve your or your clients problems.
>

I seriously doubt it...

I mean, in the olden days, the cmd program was actually a fully/partially [delete inappropriate]
DOS compatible virtual machine, starting with : being able to run real x86 mode programs...
It wasn't a shell as *nix has, never was meant to be...

You'd have more luck using DosBOX emulator these days...

> Anyway, here is some background information on Microsoft's terrible
> Console Window.
>
>
> Why are console windows limited to Lucida Console and raster fonts?
>
>  http://blogs.msdn.com/b/oldnewthing/archive/2007/05/16/2659903.aspx
>
> Here is how you can add more fonts — but you are on your own (the words
> from Microsoft):
>
>   http://support.microsoft.com/kb/247815
>
>
> Regards,
>   G.
>

-L;)


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

shiruba2012
In reply to this post by Jonas Maebe-2
Hi,

First, I want thank everyone for taking the time to answer!

2013/7/9 Jonas Maebe <[hidden email]>

On 09 Jul 2013, at 11:02, Noah Silva wrote:

1. What encoding "should" I be writing to the terminal?

The console code page. You can get it using the following function:
  function GetConsoleOutputCP : UINT; stdcall; external 'kernel32' name 'GetConsoleOutputCP';

I will certainly check this out.   On the other hand, it seems that on a Japanese system, it has to either be some form of Unicode or SJIS.  (And it almost has to be SJIS since older windows versions didn't support Unicode!).

from experimenting
with text files using the cat command in powershell, it seems that local
("ANSI") encoding should be used.  This makes sense since older versions of
windows only supported local encodings.

The ansi code page is (or at least can be) different, that's the the result of
  function GetACP:UINT; stdcall; external 'kernel32' name 'GetACP';


Again I will check this today, but see above. 

2. Is there any reason why writing out data in the local encoding (with
write statements, etc.) should get corrupted?  For example is some level of
the RTL assuming something about the encoding? (I don't think so, but...)

Not in 2.6.x. In 2.7.x, every ansistring is tagged with a code page (the ansi code page by default) and the RTL will convert it to the console code page before writing it.

Hmm, so at any rate, I need to support two code paths:
1. Convert it myself if on 2.6
2. Don't convert it if on 2.7

I use UTF8String for everything - I know that it is still just an ANSIString on FPC - but is the codepage set to UTF8 automatically? 


3. Is there a way to set the output to UTF8 so I can just write out UTF8
and be done with it?

I don't know.

There is a function to set the output codepage, which someone on this list told me before.  Unfortunately, it didn't work, and had bad side-effects (the output window flickers and gets very slow).

Jonas

Thank you,
    Noah Silva 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

shiruba2012
In reply to this post by Reinier Olislagers
Hi,

Thank you very much for the link.

I think it will take some experimenting to get everything to work how it should on my systems.

I am not using the {$codepage utf8} in my files, but I don't usually have any non-ASCII text in the programs.  (The source files are in UTF8 though).  The data I am loading is loaded from database, text files, etc.  I am sure it(s not corrupted in memory, because I can write it back out to text files, store it in the database, or even view it in the debugger.

The SetColsoleOutputCP is probably what I tried before that caused the Windows Console to act strange.

What's worse, adding UTF8ToANSI not only didn't fix the problem on Windows, it broke MacOS (because console on OS X is always UTF8, but ANSI encoding still exists, so it(s not a noop).

thank you,
    Noah Silva




2013/7/9 Reinier Olislagers <[hidden email]>
On 9-7-2013 11:02, Noah Silva wrote:
> I have followed steps in the Wiki, etc., but to little avail, so I have
> some questions for anyone who knows more than me:
> 1. What encoding "should" I be writing to the terminal?  from
> experimenting with text files using the cat command in powershell, it
> seems that local ("ANSI") encoding should be used.  This makes sense
> since older versions of windows only supported local encodings.
> 2. Is there any reason why writing out data in the local encoding (with
> write statements, etc.) should get corrupted?  For example is some level
> of the RTL assuming something about the encoding? (I don't think so, but...)
> 3. Is there a way to set the output to UTF8 so I can just write out UTF8
> and be done with it?
>
> Just to give an example:
> 1. I read in an SJIS CSV file, and display it on the screen, and it's
> corrupted.
> 2. I convert it to UTF8 before displaying it, and it's still corrupted.
> 3.I cat the file to the screen and it's ok.
> 4. I write the output to a file instead of the console, and it's ok.
>
> Something seems odd.
>
> Does anyone else have these issues?
Yes.

See:
http://bugs.freepascal.org/view.php?id=22461
for info on the situation in FPC trunk.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Console Encoding in Windows (Local VS. UTF8)

shiruba2012
In reply to this post by Marco van de Voort
Hi,

Some comments...

2013/7/9 Marco van de Voort <[hidden email]>
In our previous episode, Tomas Hajny said:
> There is code page 65001 for UTF-8, however I don't know since which
> version of MS Windows it is supported (and to which extent - e.g.
> including the console output).

Afaik Windows XP, but there might be font problems on console.

I have been testing with Windows 7.
 
> console using the Windows API call SetConsoleOutputCP, but e.g. our unit
> Crt currently resets the code page used for output to console to the
> "main" process code page (as returned by GetACP) on each write and thus
> ignores the user selection - this will probably change in trunk in the
> future as part of the Unicode support activities, but the current state is
> like this.

Keep in mind he is talking powershell, not cmd.exe

I have tried in both.  I tend to use PowerShell more often because I have this habit that goes like this:

cmd.exe
>cd SourceCode
>ls
>Err: Command Not Found
(Swear words)
>dir

Using powershell saves me a little sanity since I am used to Unix Systems and I can't install Cygwin everywhere.

At any rate, I assume that since the console is a separate thing from the program running in it that powershell and cmd would be the same from the point of view of a program executed from them.  Does powershell use a different console?

 Thank you,
     Noah Silva
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12