[fpc-pascal]Windows console

[Noah silva]

Yes, it can be done to some extent, but my point is,
You can hardly compile a TP program that uses the  CRT unit.  You can
compile these in FPC (in linux anyhow) with no problem, and in VPC, and in
Pure Pascal with no problem.  But delphi is another story, no textcolor,
etc.  Perhaps this is more of an oversight in delphi itself, than in the
Win32 API, but 3rd party developers making CRT units for the win console
have run into problems with the Win console API.  There is even a quote on
the Lazarus pages from a database developer who was trying to port a unix
application (with a console interface) to windows, and had spent quit e a
lot of effort, with little outcome.  I have my own solution: I have a CRT
unit which dummies out almost every function, just so I can compile things
on Delphi 4, without having to change the source.  Of course, I loce the
colors, etc. this way, and some things (like gotoXY) will be very broken,
but hey, it compiles ;).  I hate to load up a program I did in FPC/Linux
or PPC/TOS, and have it not even compile because of a few textcolor()'s I
have in my source.  

More to the point - Is there is a Proper CRT unit for FPK for the Win32
console that I could be using?  If there isn't, I can offer my dummied out
one, or one I have that uses ANSI/VT codes to do the color changes and
repositioning. (that one is designed for Atari, but... may have some use
on PC...).

While I'm on the subject, I have recently started to run some apps from
said Atari, compiled with Said CRT unit, over telnet, from other machines,
and the display gets very messed up (as the telnet client is normally not
using the same emulation).  Is there a better way to do this?  Does anyone
know how the FPC Linux CRT unit works?  Perhaps I should have a look at it
if nobody does.  I designed my VT-CRT unit to work only locally for the
standard (on that machine!) "ST52" emulation.

thanks,
   noah silva


On Wed, 7 Mar 2001, Jeff Wormsley wrote:

> On 03/07/2001 at 1:19 PM Noah silva wrote:
> 
> >he he he
> >I think you are going to be rather disappointed with the Windows Console
> >API.  It seems as if they purposely made it crappy.  Just look atround for
> >the better delphi 4 console libraries.  You will see frustrations of
> >authors, as well as what options are/aren't available.
> 
> It's not -that- bad, but it can be tedious.  I ported some 16-bit BP code to a Delphi console app that used a homebrew windowing library that was based on direct screen writes.  There is a windows console equivalent to direct screen writes that allows you access to the screen buffer.  The important routines are:
> 
>   ReadConsoleOutputAttribute
>   WriteConsoleOutputAttribute
>   ReadConsoleOutputCharacter
>   WriteConsoleOutputCharacter
>   ReadConsoleOutput
>   WriteConsoleOutput
>   GetConsoleCursorInfo
>   SetConsoleCursorInfo
> 
> AFAIK, all of these functions have been implemented in FPC.  I did find a quirk in the Delphi implementation.  The TCharInfo structure wouldn't work correctly for some of the calls, and I had to declare the following type to make it work:
> 
>  TFixCharInfo   = Record
>                    AsciiChar  : Char;
>                    Dummy      : Byte;
>                    Attributes : Word;
>                   End;
> 
> I don't know if that's the case for FPC or not.
> 
> Combined with one of the free WinCRT's out there it worked fairly well.  I also had to write a translator for the keyboard scancodes, but that was fairly simple.  
> 
> Unfortunately, that code is owned by my employer, so I can't release it.
> 
> HTH,
>  Jeff.
> 
> 
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>