[fpc-pascal]CRT unit

[Thomas Schatzl]

From: "Andreas K. Foerster" <AKFoerster at nikocity.de>
Subject: Re: [fpc-pascal]CRT unit


> > > - 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)
> [ ... ]
> > Since Borland only reserved a byte for
> > width and height inside this variable your app will have serious
problems
> > with that.
>
> And how does the "window" command handle this?

The coordinate params have been expanded to DWords =) (although negative
values could be reasonable as well, e.g. for expanding the window above the
current cursor position the program has started)
Internally it uses four seperate DWord variables called WindMinX, WindMaxX,
WindMinY and WindMaxY. They're exported to the interface section of the unit
atm.
Note that they are meant for read-only purposes only but the Win32 crt
should work when they are written to too.
The problem with publishing global vars is that this is hell to make those
threading safe - someday (if someone cares to update the crt in that
respect). It's not compatible to the other platforms. And you are free to
write bogus values into them (e.g. by accident).

The WindMax variable is there for .... umm .... historical reasons.
(compatibility).

> > 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.
>
> Oh, I have a slow machine and it is definitly slow under Windows. Not
> only in a window, but also in fullscreen-mode!

Yes, it might be (also gfx driver dependant). Otoh I can't feel the
difference on a PII/366 notebook with crappy gfx card and W2k for all
applications so far. [If they're not written like benchmarks, e.g. redrawing
the whole screen because one character changed]
Text output speed is imo one of the lesser problems when trying to create
platform compatible console programs. Other things are usually much more a
problem.... (with or without the crt unit)

> > > - There are many procedures wich are simply empty. What about putting
> > > something like this into them:
> > >   "If DEBUG then RunError(DebugError);" ???
>
> Yes, I know the reason, but...
> I meant it as help for people, who want to port programs from TurboPascal
to
> FreePascal. When something is not working, then this could help to
> figure out why.

I do agree with you here. Though I can't find the 'many empty functions' in
the current (1.1) crt (exactly two: nosound() and textmode() where the first
is intentionally empty, the second is known to be only implemented in the
DOS platform; see the docs). It contained lots of unused functions which
were never used anywhere....
Probably looking at the docs, sources or asking here will help you find the
answers too.
Porting from TP to FPC / GO32V2 is usually done with recompiling
(considering it's pascal code) - I don't think that porting to another OS
from TP is possible as easily at all. The TP RTL is too much DOS dependant
for this task imo. You'll notice that there are already some changes for
each OS (e.g. the screenwidth/height issue).

Regards,
    Thomas