Hello,
I normally do my programming with Free Pascal. But I wanted to give GNU Pascal a try again.
Well I don't have any problems under GNU/Linux anymore, but the version for MinGW makes trouble with the CRT unit. I have installed PDCurses 2.6-2 for MinGW.
Programs using the CRT unit do compile and the output stuff is all okay, but the input doesn't work as it should.
On most keypresses ReadKey just returns #0+#255, just occasionly it returns the correct keycode.
ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end.
Is GPC for MSYS better? Why is there a separate version anyway? I mean, MSYS belongs to MinGW, isn't it?
I've seen, that GPC still doesn't support "{$AppType GUI}" or "{$AppType Console}". That's an extension comming from Delphi. Free Pascal supports it on the Windows and the Amiga platform. I found out, that in GPC they correspond to the linker-parameters "-mwindows" or "-mconsole". But it would be nicer to have it in the source code.
On 14 Sep 2005 at 11:02, Andres K. Foerster wrote:
Hello,
I normally do my programming with Free Pascal. But I wanted to give GNU Pascal a try again.
Well I don't have any problems under GNU/Linux anymore, but the version for MinGW makes trouble with the CRT unit. I have installed PDCurses 2.6-2 for MinGW.
Programs using the CRT unit do compile and the output stuff is all okay, but the input doesn't work as it should.
On most keypresses ReadKey just returns #0+#255, just occasionly it returns the correct keycode.
ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end.
Can you please send a test program? I have not encountered any of these problems. Also, what is your GPC version? (run "gpc -v").
Is GPC for MSYS better?
Better in what way?
Why is there a separate version anyway?
Because they are different environments.
I mean, MSYS belongs to MinGW, isn't it?
MSYS is a fork from Cygwin, the purpose of which is to provide a minimalist *nix environment so that shell scripts can be run. It allows you to build native Win32 GNU tools without using a cross compiler or installing Cygwin. It is not a native Win32 environment and I am not sure what "belongs to MingW" means!
I've seen, that GPC still doesn't support "{$AppType GUI}" or "{$AppType Console}". That's an extension comming from Delphi. Free Pascal supports it on the Windows and the Amiga platform. I found out, that in GPC they correspond to the linker-parameters "-mwindows" or "-mconsole". But it would be nicer to have it in the source code.
And then the source code would not be portable. Those switches may well mean nothing under anything other than Windows.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Am Wednesday, dem 14. Sep 2005 schrieb Prof A Olowofoyeku (The African Chief):
Programs using the CRT unit do compile and the output stuff is all okay, but the input doesn't work as it should.
On most keypresses ReadKey just returns #0+#255, just occasionly it returns the correct keycode.
ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end.
BTW. the same happens with the Backspace key...
Can you please send a test program? I have not encountered any of these problems.
On my system it happens with any simple program which uses CRT.
Program readtest; uses CRT;
var s: String(80);
begin CRTInit; ReadLn(s); WriteLn(s) end.
Program keytest; uses CRT;
var c: char;
begin CrtInit; repeat c := ReadKey; WriteLn(c:2, ord(c):4); until false; end.
Also, what is your GPC version? (run "gpc -v").
Reading specs from c:\progra~1\mingw\bin..\lib\gcc-lib\mingw32\3.2.3\specs Configured with: ../configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=pascal --disable-win32-registry --disable-shared --enable-sjlj-exceptions --without-x --enable-interpreter --enable-hash-synchronization Thread model: win32 gpc version 20041218, based on gcc-3.2.3 (mingw special 20030504-1)
It's the binary from your website.
Is GPC for MSYS better?
Better in what way?
I mean, why should I prefer one over the other? I'm using the mingw compilers with the MSYS environment.
I've seen, that GPC still doesn't support "{$AppType GUI}" or "{$AppType Console}". That's an extension comming from Delphi. Free Pascal supports it on the Windows and the Amiga platform. I found out, that in GPC they correspond to the linker-parameters "-mwindows" or "-mconsole". But it would be nicer to have it in the source code.
And then the source code would not be portable. Those switches may well mean nothing under anything other than Windows.
Okay, that's a point. But I'm using lots of {$IfDef _Win32} anyway.
On 14 Sep 2005 at 15:33, Andres K. Foerster wrote:
[....]
ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end.
Looks like something broken in your curses library, or some weird setting on your terminal.
BTW. the same happens with the Backspace key...
Can you please send a test program? I have not encountered any of these problems.
On my system it happens with any simple program which uses CRT.
Program readtest; uses CRT;
var s: String(80);
begin CRTInit; ReadLn(s); WriteLn(s) end.
Program keytest; uses CRT;
var c: char;
begin CrtInit; repeat c := ReadKey; WriteLn(c:2, ord(c):4); until false; end.
Well, I don't have any problems running either of these programs, and I do not experience what you are experiencing.
BTW: I don't think there is any need to call CrtInit directly.
Also, what is your GPC version? (run "gpc -v").
Reading specs from c:\progra~1\mingw\bin..\lib\gcc-lib\mingw32\3.2.3\specs Configured with: ../configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=pascal --disable-win32-registry --disable-shared --enable-sjlj-exceptions --without-x --enable-interpreter --enable-hash-synchronization Thread model: win32 gpc version 20041218, based on gcc-3.2.3 (mingw special 20030504-1)
An old version. But I am not sure if that is the cause of your problem. Looks like a pdcurses thing - but Frank might be able to tell.
It's the binary from your website.
Is GPC for MSYS better?
Better in what way?
I mean, why should I prefer one over the other?
Depends on whether you need to use *nix pathnames, etc., and whether you are trying to produce native Win32 binaries with no external dependencies, or ones that require the MSYS runtime DLL (to provide some posix support).
I'm using the mingw compilers with the MSYS environment.
Then you should probably stick with the Mingw version. If you are using Mingw and not Cygwin, then you clearly are trying to produce native Mingw binaries.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Am Wednesday, dem 14. Sep 2005 schrieb Prof A Olowofoyeku (The African Chief):
On 14 Sep 2005 at 15:33, Andres K. Foerster wrote:
[....]
ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end.
Looks like something broken in your curses library,
I've already replaced PDcurses with the newest version. Same problem in both versions.
or some weird setting on your terminal.
Or could it be a problem with my old Windows version? Have you tested it with the 95/98/ME series?
BTW: I don't think there is any need to call CrtInit directly.
If I leave it away, I even have problems under GNU/Linux with the second program...
On 16 Sep 2005 at 13:42, Andres K. Foerster wrote:
Am Wednesday, dem 14. Sep 2005 schrieb Prof A Olowofoyeku (The African Chief):
On 14 Sep 2005 at 15:33, Andres K. Foerster wrote:
[....]
ReadLn also behaves strange: It takes and displays the entered text correctly, but when I press the Enter-key, it just displays a musical note (the character of #13). When I repeat typing the Enter key, then at some point it is accepted. But the input string still has all the other #13's at its end.
Looks like something broken in your curses library,
I've already replaced PDcurses with the newest version. Same problem in both versions.
Perhaps you might want to try the latest GPC snapshot: http://gnu-pascal.de/contrib/chief/win32/mingw32/gpc-20050331.i386-pc- mingw32.tar.gz
Although I doubt it will help you.
or some weird setting on your terminal.
Or could it be a problem with my old Windows version?
Possibly. Anything is possible under Windows.
Have you tested it with the 95/98/ME series?
Not in recent times. In the past, yes - and then, I didn't experience these problems.
BTW: I don't think there is any need to call CrtInit directly.
If I leave it away, I even have problems under GNU/Linux with the second program...
Well - that is a problem. As far as I know, you should not need to call CrtInit directly.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
or some weird setting on your terminal.
Or could it be a problem with my old Windows version?
Possibly. Anything is possible under Windows.
Have you tested it with the 95/98/ME series?
Not in recent times. In the past, yes - and then, I didn't experience these problems.
All I could easily try is PDCurses for DJGPP under Linux DosEmu. I'm not sure it's worth the effort, if the problem is between various Windows versions.
BTW: I don't think there is any need to call CrtInit directly.
If I leave it away, I even have problems under GNU/Linux with the second program...
Well - that is a problem. As far as I know, you should not need to call CrtInit directly.
Depends on what kind of "problems" (you didn't really explain that). Without CRTInit, CRT behaves more BP compatible (some might actually consider this a problem ;-), perhaps that's what you're seeing. But I think it's all explained in the comments in crt.pas.
Frank
Am Friday, dem 16. Sep 2005 schrieb Frank Heckenbach:
All I could easily try is PDCurses for DJGPP under Linux DosEmu. I'm not sure it's worth the effort, if the problem is between various Windows versions.
My DOS version works fine using FreeDOS booted directly. It's just the MinGW version which has the problem.
BTW: I don't think there is any need to call CrtInit directly.
If I leave it away, I even have problems under GNU/Linux with the second program...
Well - that is a problem. As far as I know, you should not need to call CrtInit directly.
Depends on what kind of "problems" (you didn't really explain that). Without CRTInit, CRT behaves more BP compatible (some might actually consider this a problem ;-), perhaps that's what you're seeing. But I think it's all explained in the comments in crt.pas.
Under GNU/Linux the second program without CRTInit outputs strange characters, even with some normal ascii-letter keys like l, k, j. There are even strange characters in the nummerical output. That's surely not just BP compatible. ;-) Using CRTInit helps.
My version: gpc 20040516, based on gcc-3.3.5 (Debian 1:3.3.5-13)
Andres K. Foerster wrote:
BTW: I don't think there is any need to call CrtInit directly.
If I leave it away, I even have problems under GNU/Linux with the second program...
Well - that is a problem. As far as I know, you should not need to call CrtInit directly.
Depends on what kind of "problems" (you didn't really explain that). Without CRTInit, CRT behaves more BP compatible (some might actually consider this a problem ;-), perhaps that's what you're seeing. But I think it's all explained in the comments in crt.pas.
Under GNU/Linux the second program without CRTInit outputs strange characters, even with some normal ascii-letter keys like l, k, j. There are even strange characters in the nummerical output. That's surely not just BP compatible. ;-) Using CRTInit helps.
Then something is really strange ...
CRTInit basically does two things, the equivalents (almost) of:
SetCRTUpdate (UpdateRegularly); SetPCCharSet (True);
Can you check if adding either or both of them instead of CRTInit makes a difference?
Frank
Am Sunday, dem 18. Sep 2005 schrieb Frank Heckenbach:
Under GNU/Linux the second program without CRTInit outputs strange characters, even with some normal ascii-letter keys like l, k, j. There are even strange characters in the nummerical output. That's surely not just BP compatible. ;-) Using CRTInit helps.
Then something is really strange ...
CRTInit basically does two things, the equivalents (almost) of:
SetCRTUpdate (UpdateRegularly);
no change
SetPCCharSet (True);
also no change. But with SetPCCharset(False) it works correctly.
Can you check if adding either or both of them instead of CRTInit makes a difference?
Seems to be a bug with SetPCCharset (true) ?
I'm going to chack this also with mingw...
Andres K. Foerster wrote:
Am Sunday, dem 18. Sep 2005 schrieb Frank Heckenbach:
Under GNU/Linux the second program without CRTInit outputs strange characters, even with some normal ascii-letter keys like l, k, j. There are even strange characters in the nummerical output. That's surely not just BP compatible. ;-) Using CRTInit helps.
Then something is really strange ...
CRTInit basically does two things, the equivalents (almost) of:
SetCRTUpdate (UpdateRegularly);
no change
SetPCCharSet (True);
also no change. But with SetPCCharset(False) it works correctly.
Sorry, I got it the wrong way. What I wrote are the settings without CRTInit.
Can you check if adding either or both of them instead of CRTInit makes a difference?
Seems to be a bug with SetPCCharset (true) ?
Oh yeah. I suppose it's this change, necessary with newer ncurses versions. (Afftects only Linux, so your mingw problems are probably unrelated.)
Touch crt.pas after applying to force recompilation.
Frank
Am Monday, dem 19. Sep 2005 schrieb Frank Heckenbach:
Seems to be a bug with SetPCCharset (true) ?
Oh yeah. I suppose it's this change, necessary with newer ncurses versions.
A known bug?
Touch crt.pas after applying to force recompilation.
Please more info.
(Afftects only Linux, so your mingw problems are probably unrelated.)
I know. I had no luck with mingw so far.
P.S.: The new version of AKFQuiz should be fully compatible with GPC again. http://freshmeat.net/projects/akfquiz/
Andres K. Foerster wrote:
Am Monday, dem 19. Sep 2005 schrieb Frank Heckenbach:
Seems to be a bug with SetPCCharset (true) ?
Oh yeah. I suppose it's this change, necessary with newer ncurses versions.
A known bug?
Yes, but discovered after the last release. I had to look in the list archives myself.
Touch crt.pas after applying to force recompilation.
Please more info.
Just `touch .../crt.pas', or make sure crt.pas is seen as modified, or previously created crt.gpi/crt.o are removed. Otherwise gpc will not notice that it has to recompile CRT. If you use the gp utility for compiling, this should not be necessary, as gp detects if a C file used was modified.
Frank
-
Andres K. Foerster -
Frank Heckenbach -
Prof A Olowofoyeku (The African Chief)