I was browsing some TP pages, and found this Pascal-compiler poll:

http://pub.alxnet.com/poll?id=1250146

FPC is already second, after TP :-)

(and third is Bloodshed........)

Marco van de Voort ( or )

Hello
I found a little free time and tried to rewrite my linklib patch. Now compiler understands {$linklib alibrary.dll} for win32 dlls and, unlike my previous version, works fast. Are notes of Peter Vreman are used. But my patch is based on very old CVS of fixes branch. What branch must I use now to port my patch and where I could download it?

Pavel

The funny part is how -bad- GNU pascal is. I havn't gotten any remotely serious project to comile in GNU pascal, and yet they claim borland pascal compatibility. Their "compatibility" is so easily broken just by declaring a variable with a name that is reserved in C (since it apparently still reserves those in pascal), and that's just the start. It's amazing how broken it is, when I can get most of my programs to compile under Borland TP 7 for DOS, Pure Pascal for Atari, Free Pascal for Linux, and even Delphi on windows (which lacks CRT, etc.). Consider also that Virtual Pascal has only 2%, but that's for OS/2, and I'm sure it has most of the OS/2 pascal people (just that that's a smaller group). GNU pascal works on a lot more platforms than even Free Pascal. Obviously it is pretty bad if it still can't gain support. I myself would like to use it because I use Linux on Sparc, and there is no Free Pascal yet for Sparc, so I have really tried to get GPC to be usefull, I am not just bashing it here, but I challenge anyone else to port a large borland pascal type program to it. The [most recent] program I was trying to port was my matchup CGI, which can be found (as source) on atari-source.com, and also actually running ; The CGI
portion compiles only on Free Pascal at the moment, but the rest of it will compile on VP in OS/2, BP7 on DOS, Delphi, and Pure Pascal on Atari. The delphi took the most work (to fake out a CRT unit), and was still easy compared to trying to get anything to work under GNU Pascal.

- noah

Hello I found a little free time and tried to rewrite my linklib patch. Now compiler understands {$linklib alibrary.dll} for win32 dlls and, unlike my previous

version, works fast.

Are notes of Peter Vreman are used. But my patch is based on very old CVS of fixes

branch.
What branch

must I use now to port my patch and where I could download it?

You should use the main branch. You can download daily the whole source from

ftp://ftp.freepascal.org/fpc/source/fpc.zip (8 Mb)

or only the compiler and rtl

ftp://ftp.freepascal.org/fpc/source/compiler.zip (1,7 Mb) ftp://ftp.freepascal.org/fpc/source/rtl.zip (1,5 Mb)

This may be to some extent true, but they claim it to be borland compatible, and not only that, but in the Man page they take a egotistic attitude about it and say that those who would disagree to it's compatibility are "pendants" - as if fancy words and put-downs can make up for the physical lack of compatibility. Also they bluntly state that you shouldn't use the other compilers because gpc is "better". Seems a bit concieted to me.

some advantages, which I like: - it's no problem to use C code

To me this isn't a theoretical advantage, but it can be an advantage in the real world where so much is done in C. The problem here is that people will put off porting things to pascal that should be. One example is that I recently ported a C API for a TCP stack over into Pascal so I could write an AIM clone using it. Obviously if I could use C code, this would have been easier, but I definatly prefer to have the Pascal unit I have today.

I do have respect for the ease that might come if you were writing a primarily C application and you had a bunch oc code that was in pascal that you wanted to include into it.

- they provide a better Regular Expression unit

that's probably true ;)

- operator overloading

that's definatly more of a C thing than a Pascal thing.

- scheme types

I don't know anything about that.

- a better CRT unit with extensions, in my experience the CRT unit of Free Pascal has several problems on linux, and I don't like the new ocrt, which also had problems.

I have noticed some minor problems with the CRT unit also, but I am sure they will be fixed eventually. I havn't used the new unit.

If you don't use a tool like Delphi, then the extensions of the Pascal language with properties and so on makes no sense,

Properties make sense to me, but I typically don't use delphi style objects, but TP7 style ones, because I compile a lot on TP7 and Pure Pascal on Atari, so I don't use properties often, though I would if the compilers I use all supported them.

in my opinion. Also I don't like classes, because I want to bee all pointer usage explicit.

With turbo 7 style objects, I always use the pointers explicitly. I think some compilers can mask this (like delphi and VP), but I think FPK doesn't by default.

I am not saying GPC isn't usefull for anything. But to me, in this day and age, a pascal compiler is only usefull if it is basically borland compatible. If you only claim ISO, fine (but what is that usefull for, other than teaching some of those pascals don't even have Units). If you claim borland compatibility, you should be able to compile basic TP7 designed programs fine. Like I said, I challenge anyone to get my matchup program to compile in GPC. IF someone does, note how many changes you have to make to the source to get it to work.

Johan Blok

thanks,
Noah Silva

Neither is FPC. Except you have to translate some macro's or headers.

- they provide a better Regular Expression unit

I don't know about that. But for something like that is not a criterium to switch compilers.

- operator overloading

Supported by FPC for a while.

- scheme types

Never saw a usefull usage, except for

a) ansistrings substitutes, which FPC fully implements. b) something which can be done easier within the Delphi classes model, or even dynamical arrays (which aren't my favourite, but schemes are hardly better)

- a better CRT unit with extensions, in my experience the CRT unit of Free Pascal has several problems on linux, and I don't like the new ocrt, which also had problems.

Still a library thing. And if you wanted, that specific unit itself would be portable across compilers.

This is a Major issue to me, basically there are two major issues to get things to compile:
a.) The compiler iteself
b.) The libraries

FreePascal works well with TP code because it has the TP style compiler and libs.

Pure Pascal works well for the same reason.

Delphi has problems with some turbo code because they retracted some of their own libs ;(

Free Pascal also has some other usefull units like Sysutils, and I have ported the most important parts of those to other compilers like pure.

To claim borland compatibility, not only should you be able to compile 99% of borland pascal code, but you should have the standard libraries available as well.

The problem with the GPC is that not only doesn't it have the libs, it is too broken to even port them properly ;(.

thanks,
Noah Silva

1) Now I cannot connect to this FTP server: I get message that it is shut down. Are mirrors available?
2) My current patch is more "hard": it makes changes in 6 units:
    implib.pas (formerly impdef.pas);
    pmodules.pas;
    cobjects.pas;
    psub.pas;
    pdecl.pas;
    t_win32.pas;
    files.pas.

I tried to make some things which must allow porting this patch also to OS/2 target (but I did not write OS/2 support because I have no OS/2 on my computer). Therefore I have several questions about OS/2 target:
1) does loading OS/2 dlls work now?
2) Is the "unbinding" from EMX planned? BTW, Watcom C is preparing to become an open source. I don't know, but may be, its linker can support OS/2 target?

Also an next idea about compiler directives. May be, that would be useful, to make the possibilty to change default calling conventions: {$CALLING CDECL | STDCALL | REGISTER | etc.}?

Pavel

mirrors available?

ftp://ftp.no.freepascal.org/pub/fpc/source/fpc.zip ftp://ftp.no.freepascal.org/pub/fpc/source/compiler.zip ftp://ftp.no.freepascal.org/pub/fpc/source/rtl.zip

2) My current patch is more "hard": it makes changes in 6 units: implib.pas (formerly impdef.pas);

should be easy. The version in the compiler can be replaced

pmodules.pas;

should not be that hard as there aren't much changes in this unit

cobjects.pas;

for 1.1 this unit will be replaced by cclasses. Only tdictionary is still used from cobjects, but will also be remove in favor of cclasses soon.

psub.pas;

This unit has been split in psub.pas and pdecsub.pas guess you need to patch pdecsub.pas for the changes.

pdecl.pas;

could be hard as pdecvar has been split off

t_win32.pas;

should not be that hard

files.pas.

has been split in finput and fmodule. guess you'll need the fmodule.pas

Also an next idea about compiler directives. May be, that would be useful, to make the

possibilty to change default

calling conventions: {$CALLING CDECL | STDCALL | REGISTER | etc.}?

Should not be that hard to implement, but needs some discussion if we want to support this.

El Mi� 28 Feb 2001 18:40, escribiste:

I think fpc must be included in the linux distributions. Can you do something about it?

> This may be to some extent true, but they claim it to be borland > compatible, and not only that, but in the Man page they take a

egotisti> c

> attitude about it and say that those who would disagree to it's > compatibility are "pendants" - as if fancy words and put-downs can

make> up

> for the physical lack of compatibility. Also they bluntly state that

y> ou

> shouldn't use the other compilers because gpc is "better". Seems a bit > concieted to me. I think fpc must be included in the linux distributions. Can you do

somet> hing

about it?

fpc already is included in Suse and Debian. And for redhat in the contrib

Not really.
It's included in SUSE and Debian, I don't know about RedHat and the others. We have no control over what they put in their distributions.

Michael.

The delphi took the most work (to fake out a CRT unit), and was still easy compared to trying to get anything to work under GNU Pascal.

I used Free Pascal for some time for a new project, and I'm now using GNU Pascal. I believe Free Pascal is better if you want's to port code from TP/Delphi or when you want to use it there also. But GNU pascal has some advantages, which I like:
- it's no problem to use C code
- they provide a better Regular Expression unit
- operator overloading
- scheme types
- a better CRT unit with extensions, in my experience the CRT unit of Free Pascal has several problems on linux, and I don't like the new ocrt, which also had problems.

If you don't use a tool like Delphi, then the extensions of the Pascal language with properties and so on makes no sense, in my opinion. Also I don't like classes, because I want to bee all pointer usage explicit.

Johan Blok

I think fpc must be included in the linux distributions. Can you do something about it?

I agree with this also (although I heard here SUSE includes it now)

I'm proud to anounce the first FPC based version of 3D_Mec:

A program for the Numerical, Symbolical and Graphical work with Mathematical Expresions in Mechanics

IT IS RELEASED UNDER THE TERMS OF THE GNU GPL,

You can get linux and windows binaries,
nevertheless you will have to wait to have the code on line cause I still
haven't placed the needed copyright notices within the code files.

The page is AT http://www.imem.unavarra.es/3d_mec

My natural language is spanish and most information there is now in spanish, although the
source code is close to be fully commented in english. Nevertheless I'm planing to translate the
user docs..., and the core aplication (3d_mec instruction set) is ready to be internationalized.

Regarding the poll, I can say:

FPC has allowed me to:

1.- Port my old DELPHI code (quiting the interface part, 40.000 lines, may more) to Windows and Linux 386,
2.- Use OpenGL, from pascal
3.- Use ImageMagick, ""
4.- Use GTK as interface,(No lazarous here)
5.- Use GTKGlArea (as a GTK to OpenGL bridge)
6.-...

Sharing a single source code for both platforms...

I'm pretty sure this (or a piece of this) would be imposible to do with any other compiler (no more coments)...

I can also say that I'm experiencing some velocity increase related to the previous delphi2 version,...

So THANKS, THANKS, many THANKS to all of you that every day are here to answer, and develop such a dream compiler.

For if there is some interest on have I've don to get the full story working i can give some explanations,...

Of couse, I have some ideas about things that can be done regarding souce code sharing between windows and linux,
if this will help I can post them here also. I mean taking away ifdef win32 and non dll library isues in
the win32 side, and issues related to mingw vs cygwin. Nevertheless I'm not aquainted with FPC internals
as to make any code contributions in this direction.

Finally, I would like to thank the people in this list that in several times has given advice to me.
In special to Sebastian, who worked out the opengl headers that quite transparently aply to the above
mentioned platforms.

To:
Organization: Sechenov Institute of Evolutionary Physiology and Biochemistry, Russian Academy of Science
From: (Pavel V. Ozerski)
Date sent: Thu, 1 Mar 2001 12:11:04 +0300 (MSK) Subject: Re: [fpc-devel]My Linklib again
Send reply to:

I tried to make some things which must allow porting this patch also to OS/2 target (but I did not write OS/2 support because I have no OS/2 on my computer).

I'll be glad to test it for you.

Therefore I have several questions about OS/2 target: 1) does loading OS/2 dlls work now?

Yes, of course - we couldn't access the OS libraries otherwise, i.e. we could do nothing.

2) Is the "unbinding" from EMX planned?

Yes, it is, definitely. There are two stages involved:
1) Get things linked without the EMX linker.
2) Change the RTL to not use EMX any more.

Fortunately, this doesn't have to occur at the same time, because the EMX runtime support is a regular DLL under OS/2, so it can be used with any linker. For 2), we'd need to have support for 16-bit far Pascal calling convention (with automatic thunking like VP/2 does), because the text mode support only has 16-bit interface libraries (compatible to OS/2 1.x; the real code is 32-bit of course).

BTW, Watcom C is preparing to become an open source. I don't know, but may be, its linker can support OS/2 target?

Yes, it can. The main trouble is that GNU AS creates AT&T object files, whereas most linkers except GNU need Intel OMF. OS/2 ships with its own linker (LINK386) - although this one is quite slow, it's still pretty usable. That one of Watcom would be better though, because it's cross-platform.

There are at three ways to get Intel OMFs. First, get a binary writer for this format in the compiler. This would be the best, but impossible for me, because I know nothing about such things. Second, assemble with GNU AS as it's done now, but convert the created object files with emxomf conversion tool. I didn't succeed with this yet - I converted all object files (including loaders), but LINK386 didn't want to link them. Third, get it assembled with NASM or some other assembler with OMF output. I didn't try this yet.

Anyway, my main problem is to find free time for experimenting with this. :-(

Tomas