Hello,

i am interesting, what do you think about redirecting text streams not to windows console, but creating free pascal's own gui console (for example implementing it under -WX switch)? I mean to do something like graph unit is done now or unit wincrt in Virtual Pascal's rtl. Windows console looks like some relict derived from dos. We have problems with keybord drivers and text encoding in it (text prepared with windows editor needs to be encoder to dos cp when outputing if you want to see national characters properly). Different it's implementation in win9x and win2000,xp systems makes these problems deeper.

Regards,
Rimgaudas Laucius

Things like redirection doesn't work anymore.

Nobody will stop you from creating a faster console under Windows. At least don't expect anything to be written by the current fpc developpers.

Peter

You can simply create a wingui unit which is e.g. graph based and which redirects input/output.

have you tried using virtual pascals wincrt unit with freepascal?

and if so does it compile and work?

have you tried using virtual pascals wincrt unit with freepascal?

and if so does it compile and work?

Hello,

i am interesting, what do you think about redirecting text streams not to windows console, but creating free pascal's own gui console (for example implementing it under -WX switch)? I mean to do something like graph unit is done now or unit wincrt in Virtual Pascal's rtl. Windows console looks like some relict derived from dos. We have problems with keybord drivers and text encoding in it (text prepared with windows editor needs to be encoder to dos cp when outputing if you want to see national characters properly). Different it's implementation in win9x and win2000,xp systems makes these problems deeper.

Regards,
Rimgaudas Laucius

Hello,

No. I know that you are very busy and do not expect from you anything to be written. But maybe you can help me with some hints how to do this if it is posible. You are experts in this case.
I ported VP wincrt unit but it is not very usefull. It just redirects input/output but that is not enouth. I am thinking about creation console where windows console related functions (getconsolehandle, setconsolemode) could work. So standard crt and other console based units could work without additional efforts. Do you think it is posible to create and integrate into FPC such windows console replacement?

you wrote

We have problems with keybord drivers and text encoding in it (text prepared with windows editor needs to be encoder to dos cp when outputing if you want to see national characters properly).

just change the console's output codepage ("chcp" command at the prompt or SetConsoleOutputCP to do it programmatically). It defaults to the system's OEM codepage, for consistence with full-screen mode, but it can be set to any valid codepage, including UTF-7 and UTF-8. Also, if you write Unicode text there is no problem

you wrote

Things like redirection doesn't work anymore.

no, this isn't an issue. This is about the CRT unit, which could really use its own console, not just a display window. It would be a real improvement, considering what the CRT unit is used for. I tried playing some old Turbo Pascal programs with it, but it's nearly impossible because you see the graphics in the CRT window, but you still have to enter keyboard input in the console window. Rimgaudas has a case, here

Hi,
Maybe i am wrong, but it seems to me that SetConsoleOutputCP function works only on WinNT systems.

On Sun, 7 Nov 2004 22:59:08 +0300, Rimgaudas Laucius wrote

Hello,

I might be wrong, but it seems to me that you're basically talking about creating an alternative implementation of Win32 console windows. Whereas this might be possible in theory, it would be probably a very complex task to implement it... Integration on the FPC level only (like creating replacement/wrapper functions for the appropriate console related Win32 API calls in unit windows) would have severe limitations (including incompatibility to any external libraries using these calls), anything else would depend on availability of all required hooks from Win32 or lower-level APIs (which I somewhat doubt).

Tomas