J Horacio MG wrote:
As I commented earlier, my only source for Pascal programming information for a beginner is a short course of Borland Turbo Pascal in windoze. I too have installed the Gnu Pascal Compiler in Linux, so I thought it would be possible to learn with the former to use latest.
Is there any document that explains (from scratch) the very basic differences between one and another? I hope you will excuse my lack of knowledge, but as I said these are my very first attempts to learning programming at all.
The GPC documentation contains a chapter about most of the differences and the degree of compatibility to BP. You can type info -f gpc -n "Borland Pascal" to read it (or an equivalent in your favourite info reader, e.g. `(gpc)Borland Pascal' in the RHIDE help).
Now, from the very first basic program (I guess sort of C's "hello world"):
Program saludo; Uses WinCrt; Begin
{1} WriteLn ('Hola Mundo');
End.
Ken Linder (KC7RAD) replied:
The WinCrt unit in Turbo Pascal is just a set of functions that allow a turbo Pascal for Windows program to work in a console (DOS) type window under Windows. In Linux/GPC this is not necessary.
That's correct, but since there are some misconceptions about the (Win)Crt unit in the BP world, let me say a few words to clarify the situation:
The Dos version of Borland Pascal contains a Crt unit which provides things like text colors, cursor positioning, text windows, reading of single keys (not only whole lines), etc. To accomplish that, it takes over control of Input and Output (i.e., of Read[ln], Write[ln] statements that are not explicitly applied to other files), while in programs without Crt, Input and Output go to the standard input/output of the process, which are connected to the terminal, unless redirected, e.g. `program < inputfile > outputfile'.
Unfortunately, many BP programmers have the habit of using Crt in each and every program, whether or not it needs its features. However, using Crt unnecessarily has some disadvantages, e.g. that input/output of such programs can't easily be redirected, the program gets bigger -- and BP's Crt unit contains a famous bug...
Now, under windoze, AFAIK, there is no terminal, and therefore standard input/output are not connected by default. That's why the windoze version of BP provides this `WinCrt' unit which emulates a terminal and provides some (but by far not all) routines of the Crt unit (e.g., no colors).
Now, for GPC:
Since the last release (19990118), GPC contains a CRT unit which contains all the functionality from BP's Crt unit (and more). Like BP's unit, it has to take over Input and Output to do its job. It works on all Unix systems (and especially well on Linux/x86 :-), and on DJGPP. It probably will also work on windoze (mingw) and OS/2 (EMX), but someone would have to compile the PDCurses library (which it uses internally on these platforms), and perhaps make a few little adaptions in the CRT unit, but this shouldn't be hard. (BTW, if a mingw or EMX user could do this, and forward the library binary and any changes necessary in CRT to us, we could include them in the official distribution.) Therefore, GPC will not need a `WinCrt' unit, since its CRT unit will simply work on those systems...
What I said above for BP, that using Crt unnecessarily has some disadvantages, holds for GPC as well (actually even more so, since the ability to redirect input/output is more valued under Unix than under Dos).
So, when porting from BP/windoze to GPC, one can simply replace `WinCrt' by `CRT'. But one should think twice if CRT is really needed at all -- one can just remove the `uses WinCrt', and if this leads to undefined identifiers, insert `uses CRT'.
In principle, we could provide a WinCrt unit for GPC which is identical to CRT, but apart from the fact that that's wasted space (at least on Dos where there are no symbolic or hard links), this would often lead to unnecessary uses of CRT which should be avoided. Therefore, I'd prefer to intentionally not provide a WinCrt unit for GPC. But we should probably include a section in the documentation about this issue...
Frank