I am using the latest released version from http://www.freepascal.org/ version 1.04 to port some Borland Pascal for DOS programs to Win32 console apps. I have noticed two annoying bugs in the CRT unit:

(1) ClrEOL does not respect TextBackground

In the Borland Pascal for DOS version, ClrEOL sets the background color of an entire line according to the most recent TextBackground call. However, in Free Pascal for Win 32, it sets the background color to black, regardless. Here is a sample program:

  uses CRT;
  begin
    TextBackground(cyan);
    ClrEol;
    WriteLn('hi');
  end.

This should produce a full-width cyan line, with the letters "hi" occupying the first two spaces. Indeed, in Borland Pascal it does. However in Free Pascal, the only the "hi" have the cyan background.

(2) Keystrokes not registered until upstroke

Not only does this give the user poor visual feedback, it also has the by-product that typematic doesn't work. Try holding down the "x" key while running this program, first compiled in BP for DOS, then in FP for Win32:

  uses
    CRT;
  var
    k: char;
  begin
    WriteLn('Type a few words.  Hit Enter to quit:');
    repeat
      k := ReadKey;
      if k=#0 then Readkey (* discard second half of function keys *)
      else write(K) (* but echo ASCII to screen *)
    until k=#$0D;   (* terminate with ENTER key *)
  end.

My compliler switches include -Sgico for what it's worth.

- Rich

Quite some time ago I reported that clreol didn't clear the last character of a line. I wonder if the two items are related...

Jim

The "sound" procedure does not produce a sound of the required Hertz, instead is imply "dings the bell."

Try this program under Borland Pascal and under Free Pascal 1.04

uses CRT;
begin
  sound(1000);
  delay(1000);
  sound(500);
  delay(1000);
  nosound;
end.
     - Rich

At 15:58 04/03/2002 , vous avez écrit:

This is a known missing feature.
(The RTL source only uses MessageBeep(0) call)

You are very welcome to propose a
patch for adding support for this feautre, but
don't forget tat there are still
(even if it becomes very rare)
win32 systems that don't have any sound systems
Moreover, I suspect that
that code will need to be different for win9X/Me
and for winNT/2000/XP....

One can't use the sound system anyway, since it might be locked by another app.

Well, that would explain why it doesn't work!

I would prefer that it would just use the PC speaker, just like the 16-bit Borland Pascal does.

Moreover, I suspect that that code will need to be different for win9X/Me and for winNT/2000/XP....

The binary output of Borland Pascal works on all these OS's without modification--through the PC speaker.

- Rich

Well, the binary output of the Dos (go32v2) FPC version will also work under WinNT etc. However, that's because Windows includes a Dos compatibility/emulation layer. From a win32 program, it's not possible to write directly to the PC speaker ports like under Dos, so you either have to use win32 api calls (and it seems there aren't any which allow you to specify the tone/duration), or you have to write a VxD (since that one runs with kernel privileges and as such it should be able to access the hardware directly which in) which in turn can be called from FPC programs.

Jonas

Yikes, now I understand the problem.

Here's an idea: How about code that would generate a waveform "on the fly" (in this case, a square wave would do) and then play it through the Windows API (as if it were a WAV file)? Or maybe a (very short) MIDI sequence through the MIDI device? I know these are through the Windows sound system, not the PC speaker, but at least ported apps would sound about like they were supposed to.

- Rich

That is dangerous, since it could disrupt already running audio using apps. (the beep would simply be not audible, or other porgs might even crash.)

Don't forget that non-Dos oses are often multitasking!

It could be done like that if needed for special purposes, but it isn't fit as a general solution for the above reasons.

*********** REPLY SEPARATOR ***********

In Delphi, the Windows function Beep(Frequency, Duration) will beep the PC speaker. The normal Delphi beep does not take parameters and uses one of the sound system .wav files. You have to use the one located in Windows.pas and that calls Kernal32.dll. It does block during execution though.

Jeff.

Marco van de Voort wrote

That is dangerous, since it could disrupt already running audio using apps. (the beep would simply be not audible, or other porgs might even crash.) Don't forget that non-Dos oses are often multitasking!

I think it would be acceptable to make the sound from a Sound() statement contingent on the audio system being available at that moment.

If an attempt to use the audio system caused another program to crash, then somebody is not following the OS's rules.

- Rich

Here's a beeping program that compiles under Borland Pascal for DOS and Free Pascal for Win32 and sounds the same on both. What eludes me is how to code a unit that implements sound() and delay() by calling windows.beep().

- Rich

{$ifdef WIN32}
  uses Windows;
{$else}
  uses CRT;
{$endif}
begin
{$ifdef WIN32}
  beep(1000,1000);
  beep(500,1000);
{$else}
  sound(1000);
  delay(1000);
  sound(500);
  delay(1000);
  nosound;
{$endif}
end.

From: "Rich Pasco"

Maybe making a loop in another thread or hooking an int (if it's possible in Win32),
this loop calls beep(freq_x, 1) when sound is called and not when nosound is called.
But anyway I think it's more simple to just drop a compile warning when using this
function in Win32.

I am pleased to report that both of the bugs referenced below seem to have been fixed in the 1.0.6 prerelease announced on Wednesday.