Hello,

long time I didn't know how to get a sound under Windows. Sending a #7 doesn't work anymore, when the CRT unit is used.

Solution:
The filehandle "stdout" is still assigned. So sending the #7 to stdout still works:

procedure Beep;
begin write(stdout, #7) end;

should do it on any system.

long time I didn't know how to get a sound under Windows. Sending a #7 doesn't work anymore, when the CRT unit is used.

What version of Windows are you referring to? I don't have that problem with NT4 or 2000.

Jim

Surely there's a windows API call!! MessageBeep iirc. Wouldn't that make more sense??? You can therefore use the default Windows Alert, error warning sounds etc.

Matt

Matt Emson wrote

Surely there's a windows API call!! MessageBeep iirc. Wouldn't that make more sense??? You can therefore use the default Windows Alert, error warning sounds etc.

No, I try hold my programs portable between Linux and Windows and perhaps other systems later on.
I don't like to use (and learn) too much system-secific commands! That's why I still stick to console programming. <sight>

The problem seems not to be in the Windows-Version but more in the version of FPC. I took a brief look into the souce code of the CRT unit - version 1.0.4: the code for handling #7 is explicitly commented out - I don't understand why.

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)

- 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)

- 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.

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

If you have Delphi or the Win32.hlp file, take a look at the following:

TCharInfo - This holds the equivalent of the old screen buffer's combination of a character/attribute pair. I found a bug when working with this, probably due to alignment issues, such that I needed to define a dummy version of this structure called TFixedCharInfo, like so:

 TFixCharInfo   = Record
                   AsciiChar  : Char;
                   Dummy      : Byte;
                   Attributes : Word;
                  End;

I used this to define these structures:

VirtualScreen  : Array[0..24, 0..79] of TFixCharInfo; // Screen
Buff           : Array[0..79] of TFixCharInfo;		// Line

TConsoleCursorInfo, GetConsoleCursorInfo, SetConsoleCursorInfo - You can use these to turn on and off the cursor

ReadConsoleOutputAttribute, WriteConsoleOutputAttribute, WriteConsoleOutputCharacter, WriteConsoleOutput, ReadConsoleOutput - Uses these in place of the direct memory reads and writes to the screen buffer.

GetStdHandle - Used to get the handle to the screen

Using these I converted a BP7 windowing unit to Win32 Console, with little loss of speed.

Jeff.

- 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)

I have problems with clreol clearing an entire line -- it leaves a character in the last column. It has something to do with perhaps the last line of the window, or what windmax is set for, but I haven't quite figured it out yet.

Are you referring to write and writeln being slow? If so, I can send you a function that does pretty fast screen writes for Win32 binaries.

Jim

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

Hi,

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.

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

At least in the 1.1 snapshots. Please try that snapshot first, because it contains a big update of the Crt unit donated by Tomas.

With current CRT you mean the version in the 1.1 development branch. The version in 1.0.x is not adapted yet. When the 1.1 version is better tested then it can also be moved into the 1.0.x

Peter

[James Wilson wrote]

I have problems with clreol clearing an entire line -- it leaves a character in the last column. It has something to do with perhaps the last line of the window, or what windmax is set for, but I haven't quite figured it out yet.

Can't reproduce that problem (with the 1.1 snapshots). Do you have some code showing that behaviour ?

[Peter Vreman wrote]

This is also fixed in the 1.0.5 snapshots since it was already done by you at the point I changed the stuff afair.

Yes.

Regards,
Thomas

Oh, I didn't know.

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?

Apart from that problem: what do you do when the window dimensions change because the user resized the console window ? (both NT + Linux/X)

Actualy nothing.
I just have an unusual resolution in the textmode - so I need it.

What someone could do under Linux is to create a procedure for to call when signal 28 (SIGWINCH) occurs, then recalculate the screensize and redraw the screen.

I don't know that much about Windows.

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, 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.

From: "Andreas K. Foerster"
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)

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 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

hey Jeff,

If i remember correctly, the main performance penalty is actually setting the cursor position on the screen.
The updating of the screen itself shouldn't be too slow and using ReadConsole(), WriteConsole() has some issues.

Another way to do it would be maintaining an own array of chars/attr pairs (like DOS's screen buffer), and writing to this, then running another thread copying the screenbuffer to the screen upon certain events (using the routine to write a whole buffer to the screen, can't remember its name at the moment).
I do think this will cause some other issues though.

groeten, Maarten.

AM Maarten Bekers wrote

If i remember correctly, the main performance penalty is actually setting the cursor position on the screen. The updating of the screen itself shouldn't be too slow and using ReadConsole(), WriteConsole() has some issues.

I never had a problem with updating the cursor position, but then again, with the windowing unit I wrote, the cursor was off most of the time. It was only on when a user was expected to enter data, which wasn't often. As far as positioning text on the screen, it worked very well. Like I said, this was a text based windowing system that would read the screen contents and save them when a window opened, and restore them when a window closed. However, it didn't have any niceties like allowing the user to move/resize the window, so it may have suffered in that respect. Fortunately, this app didn't need any of that level of complexity.

I moved away from CRT level programming early, and writing directly to the video memory was par for the course in my BP days. Doing the same in Win32 didn't turn out to be hard, as long as certain assumptions could be made. The "larger than physical screen" of Windows NT didn't bother me, because my apps were always pure console and I didn't care if the user made the console 80x50 (or 255x255) when the app was written for 80x25. So what if it didn't fill the screen, as long as it was consistent within the screen size it was designed for. The installation process built a shortcut that forced the screen resolution to what I wanted it to be (full screen 80x25), and if the user decided to change it, then that was their problem. After seeing it didn't do any good to make the screen bigger, they would quickly change it back. Sometimes you have to make these kinds of trade offs.

Anyway, the apps I wrote were designed to be the sole app running on the computer. I took advantage of the helpful bits of Windows like networking and such, but forcing screen size wasn't a problem. I had the luxury of not having to worry about it, but many of the techniques involved in what I did could be used for the generic case. If I get a chance, I may look at the Win32 version of CRT and see what can be done, but I doubt it will happen soon.

Jeff.

"Andreas K. Foerster" wrote:,

please give us some information. I think there is no other way then using the API to access the Console Screen.

Thomas Schatzl wrote

WindMinY and WindMaxY. They're exported to the interface section of the unit atm.

ATM?

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

I try to write progs, which are portable between Linux and Windows. Under Linux the screensize isn't always the same.

I meant, it's much slower under Windows compared to Linux. But okay, you are right, that's not that important.

[help for porting from TP to FPC]

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

Okay, I also looked into some other source codes.
The most extreme is - of course - the DOS unit for Linux. The suggestion was just meant as an additional aid.

I don't think so. Except of the DOS unit and perhaps the Graph unit.

From: "Andreas K. Foerster"
Subject: Re: [fpc-pascal]CRT unit

> WindMinY and WindMaxY. They're exported to the interface section of the

unit

> atm. ATM?

Don't know. Probably the developers will keep it, just for compatibility [if you want to express the concern that someday the vars will be removed]. But imo there are reasons to not keep it and to do it in a better way, some of them I mentioned to you earlier. It's Borland-crt incompatible anyway. Not that I have much to say in this issue, that's just my two cents.

Btw, a small question: why do you need the screenheight/width vars in Linux then ? Wouldn't it be better to use the WindMax stuff there too (since it's 'portable').

Under Windows [NT and other supported non-DOS OSes] it isn't as well..... it may even change during program execution, what a progress since '92... ;-)

> 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. Oh, I was surprised how easy it is to port console progs to Linux.

Depends on the complexity of the program (and with what constraints you are satisfied, see another mail in that thread).

I personally don't have the need to port from TP to Linux; if I am coding in this OS I'm not porting from DOS but trying to get Win32 stuff running (somehow) or vice versa (somehow).
[A TP based RTL doesn't help much here. Porting a Win32 app via DOS to Linux or so.... *lol*]

> The TP RTL is too much DOS dependant for this task imo. I don't think so. Except of the DOS unit and perhaps the Graph unit.

*g* So we're talking about all TP units which deal with some kind of OS or user interaction..... [the latter can be considered as kind of the former too].

[Left from the TP RTL is the strings unit, not counting overlay (obsolete), printer (dos dependant; isn't stated as 100% Linux compatible in the fpc docs) and the turbo3 and graph3 (n/a with FPC, obsolete) unit. You save one unit. Please correct me if I'm mistaken]

Regards,
Thomas

Thomas Schatzl wrote

I personally don't have the need to port from TP to Linux;

These different needs explain our different views.

There is just additional functionality in Linux.

and the turbo3 and graph3 (n/a with FPC, obsolete) unit. You save one unit. Please correct me if I'm mistaken]

I meant the whole big SYSTEM unit, the CRT unit, the PRINTER unit, the STRINGS unit, the OBJECT unit, and don't forget TurboVision - okay, it's not yet in FPC, but that's not, what we're talking about.

ATM?

ATM is "At The Moment"

Are you referring to write and writeln being slow? If so, I can send you a function that does pretty fast screen writes for Win32 binaries.

Isn't that what the CRT unit was supposed to do?

With Borland Pascal on a DOS platform, using CRT would greatly speed up Write and WriteLn.

- Rich

Thomas Schatzl wrote

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.

Umm, I thought that when a program using the CRT unit was active, the NT console buffer was out of the picture, and the CRT unit used the physical window size (which would be less than 255 lines to fit on the screen, unless a very tiny font were used on a very high-res display).

What am I missing here?

- Rich

Isn't that what the CRT unit was supposed to do? With Borland Pascal on a DOS platform, using CRT would greatly speed up Write and WriteLn.

But his concern was using FPC on Win32, not BP on DOS. The function I was alluding to uses the WriteConsoleOutput API call from Win32, and not write/writeln at all (or CRT for that matter).

Jim

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

Thomas Schatzl wrote: > 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. Umm, I thought that when a program using the CRT unit was active, the NT console buffer was out of the picture, and the CRT unit used

No.

the physical window size (which would be less than 255 lines to fit

No.

on the screen, unless a very tiny font were used on a very high-res display).

But it does have to be considered. You can reach that resolution with an 8x8 font 'already' at 2048x1536 which modern graphics cards already support (256 columns), e.g. ATI's Radeon graphics card series.
That's not the main problem. The problem is that the windmax variable just represents the "screen dimensions" at a certain point in time, e.g. the moment the crt unit is initializing. Three miliseconds after that event it is not guaranteed to be true anymore. So it does not really matter whether the variable contents were actually true at crt initialization time. Even if they were updated by the crt unit, there's no way your TP program gets to know that change (in the Borland CRT interface). You could poll those vars, but this not only is a
waste of cpu resources it is also expected that your legacy TP app you want to port simply does not take such changes into consideration during runtime.

Regards,
Thomas