Hello all,

I've severe problems with text output of FPC programs on W2k consoles. Depending on the current time (well, I don't know exactly why) one of the following oddities show up here (on 2 completely different computers btw):

- text output is limited to a window to, say, around 10 lines
- text output starts _above_ the line I entered the command to start the program or at the top
- text is written black in black
- it works fine (sometimes, usually when the cursor is at the top of the window when starting the program, e.g. after a "cls" on the command prompt followed by the program start)

Note that the programs I use only issue a series of writeln(); no multithreading involved.

I already thought that the problem is that the console uses a line buffer larger than the display window, but changing that doesn't problems show up in any FPC Win32 programs - for example also in the FPC - IDE: When I start it up (without params), the only things I can see is the top menu bar and the FPC - logo. There's no bottom status bar at all (when in windowed mode). If I switch to fullscreen the bottom status bar is there (but not at the bottom of the text screen but four lines above it - the compiler messages window is cut at the status bar). When switch back to windowed mode the bottom status bar is gone again.

If I happen to open a new window (in windowed mode; File->New) then the edit window is limited to 42 lines, making a total of 46 lines with the border and top and bottom status bar (yes, the bottom status bar appears mysteriously). The command window is set to 39 lines though, so I'd have to scroll around all the time while programming. Again in fullscreen mode (80x50 characters) the
last four lines are empty.
After switching the window to 50 lines, in windowed mode everything is ok, the whole edit window shows up. But when switching to fullscreen, the bottom four lines are still empty (black, unused).
If I open a message window (F12), the height of the text area is cut to two lines,
because it's upper edge is placed 3 lines above the bottom status bar (probably this is intentionally done, but it wasn't the case in the BP IDE by default).
When exiting (pressing Alt-X) the new command prompt is at around line 10. The upper lines are filled with colored text garbage (always the same), the others are mostly black. Probably this might be some ansi - drawing though;
could someone acknowledge that ?

[Here's the text which is shown btw:
x;WTs3bPE.;EAC.;ESSW. CORTUxPEREF=
i6d6en0entPERV6OSRS=aome:omPPPSeiCymt\NECOEAN
\A1mM:K~DILL\pEM=TUN=itoSRL:knuEtunmstwi:N

÷ xx

]<-- end of text

I tried on a fresh installed FPC 1.04 setup.

What buggers me most is that only FPC programs show that behaviour. Win32 console mode programs compiled in any other language I tried (java, vc++, Delphi) don't show similar graphics hardware
acceleration doesn't change a thing either.

Regards,
Thomas

This happends also with only writeln() used in your program? And what about go32v2 compiled programs?

I've seen this too, but only with certain builds, and not always The current 1.0.4 win32 release doesn't seem to suffer from this.

Hi,

> > What buggers me most is that only FPC programs show that behaviour.

Win32

> > console mode programs compiled in any other language I tried (java,

vc++,

> > Delphi) don't show similar graphics

hardware

> > acceleration doesn't change a thing either. > > This happends also with only writeln() used in your program? And what

about go32v2

> compiled programs?

Here's a sample program:
----------
uses
crt;

var
 i : Integer;
begin
 for i := 0 to 100 do
  writeln('Hello ', i);
end.

--- guess that one is simple enough. Just compile and run it a few times and you'll notice. Btw, I think it's connected to the crt unit because when it's not used it seems to work (quick tests show that at least; FPC 1.1 from 2001/06/01)

Go32V2 programs are fine as far as I can tell. But don't count on that too much since it has been a while since I last did any serious go32v2 programming. The go32v2 IDE from the 1.0.4 release doesn't show text output related problems.

I've seen this too, but only with certain builds, and not always The

current

1.0.4 win32 release doesn't seem to suffer from this.

I am not downloading and trying 'new' 1.0.4 releases just for fun of it. The version still shows 1.0.4 afair so I don't see a
reason to upgrade - I have the one from 2000/12/30 btw. I am usually using 1.1 snapshots - only if something doesn't work I get a new snapshot which usually fixes the problem anyway (usually some internal error at compile time).
But I am certain that I can not remember any 1.1 snapshot which handles W2k text output correctly. And today I tested with 1.0.4 too and finally reported it.
[A certain graphics card manufacturer "convinced" me somewhat to only update if something really doesn't work and not always getting the latest stuff - 'cause reinstalling OSes takes a lot of time :)]

Regards,
Thomas

But this is with Crt unit. What does it without the crt unit? because that makes a big difference. If it works without crt unit the the problem is the crt unit. Also you can't compare it with Delphi since delphi has no Crt unit. If it works with an 3rd party crt unit you can check the differences between the units to find the problem.

Peter

Subject: Re: [fpc-pascal]Text output oddities with W2k

and

>you'll notice. Btw, I think it's connected to the crt unit because when

it's

>not used it seems to work (quick tests show that at least; FPC 1.1 from >2001/06/01) But this is with Crt unit. What does it without the crt unit? because that

I said I _think_ it _might_ be caused by the Crt unit. Just running the sample program three times with and three times without using crt is no proof of anything.

makes a big difference. If it works without crt unit the the problem is

the

crt unit. Also you can't compare it with Delphi since delphi has no Crt

Obviously.

I'm not comparing the CRT unit with Delphi but the final program output. Else my comparisons with C / Java console output would have been even more ridiculous (they don't have a CRT either). Apart from that the CRT unit is part of the FPC rtl nevertheless. Just saying "it's the big bad CRT which never works anywhere as expected" doesn't make my FPC program run better imo.

Always assuming that it is not the purpose of the crt unit to mess everything up.

unit. If it works with an 3rd party crt unit you can check the differences between the units to find the problem.

I'll have a look at it.

Peter

Btw, what's API 2 ?

Regards,
Thomas

Hi,

> unit. If it works with an 3rd party crt unit you can check the

differences

> between the units to find the problem. I'll have a can download a patched and verified (with W2k only !) version of the CRT

unit at http://members.yline.com/~tom_at_work/crt010609.zip (will be there at least for a week)

It now works fine with W2k and virtual screens greater than visual screens.

Some notes about the patches:
- I added a "//ts" mark everywhere I changed something, partially with some comments. It would be great if the one who's adding this to the RTL source tree removes them before checking them in (if you actually add it)
- I was forced to change the interface of some functions: wherey(), wherex(), gotoxy(), window() due to the fact that bytes are too small to hold probable input / output values (because virtual windows can easily be > 255 lines with W2k; usually they are). They're DWords now.
- the crt unit only operates on the screen area which was visible at the time it was initialized, e.g. it never touches any areas beyond it (the virtual screen area before and after the visual window). I don't know how this is handled with the Linux CRT unit, but I thought this was the most BP compatible way. This can be partially undone by calling the window() function.
- I removed loads of global vars and useless internal functions to make it a bit more multithreading safe. But it's still far away from that.
- only worked on the output; didn't do a thing regarding the input stuff.

Feedback appreciated, especially reports about Win9x compatibility.

Regards,
Thomas

Hi,

Subject: Re: [fpc-pascal]Text output oddities with W2k

Some notes about the patches: [...]

- forgot to mention that it doesn't automatically adapt to visual screen resizing events. Although this is possible, it would require the installation of some user callback. I skipped this because it would not be cross-platform compatible and anyway it is far beyond the capabilities of the original BP CRT unit. (Since TP compatibility has to be kept, doesn't it ? ^__.)

Regards,
Thomas