[fpc-pascal]CRT unit (was: Beep in Windows)

[Thomas Schatzl]

Subject: Re: [fpc-pascal]CRT unit (was: Beep in Windows)

Hi,

> On Wed, Aug 01, 2001 at 02:29:01PM -0400, James_Wilson at i2.com wrote:
>
> some other comments to the code of the CRT unit (Win32, 1.0.4):
>
> - The variables "ScreenHeight" and "ScreenWidth" are calculated, but not
> exported. That's a pity for they'd be very usefull - In the Linux version
> they are exported. (I always recreate them from WindMax at startup)

WindMax contains garbage on NT consoles because the height of the console
window is > 255 lines by default. Since Borland only reserved a byte for
width and height inside this variable your app will have serious problems
with that.
Apart from that problem: what do you do when the window dimensions change
because the user resized the console window ? (both NT + Linux/X)

> - The command "clreol" doesn't work correctly. It clears the rest of the
> line as it should, but it doesn't set the color. (That's what I need
> this command mostly for)

This has been fixed with the snapshots afaik.

> - Anything is done by calling API codes. That's why it is so slow!
> As far as I understand it, Windows uses a buffer that's built up equal to
> the screenbuffer as it is directly used under DOS, so that you can write
> directly to that buffer as in Dos. Just with the difference, that you have
> to fetch the starting point and size from the API.

If there were such a way it would have been implemented.

But imo this way to access the screen does not cause the main performance
hit (if there's any for the usual purposes) - rather the difference between
graphics output and text mode output.
Try with the Linux' VBE framebuffer console mode and you'll see.

The current CRT should be faster now too since it doesn't scroll around the
whole screen buffer anymore when inserting / removing lines but only the
actually visible screen (well, only really interesting for NT people since
W9x consoles can't be bigger than the visual screen).

> - There are many procedures wich are simply empty. What about putting
> something like this into them:
>   "If DEBUG then RunError(DebugError);" ???

Because these procedures are obsolete ? Some stuff isn't supported or can't
be implemented the same way it was done in DOS times in Win32 at all....

Regards,
    Thomas