On 9 Mar 00, at 14:50, Marco van de Voort wrote:
I have been having discussions with Leon de Boer who is writing most of the FreeVision (FV) stuff. The project is being done to dispense with all copyright issues, and it seems that this has largely been achieved. I have ported the Objects unit to GPC, along with a few other units. The sticking point now is a number of the base units (drivers.pas, dialogs.pas and views.pas), which contain some assembler code. Some of these are in x86 assembler and some (determined by some IFDEFs) are in FPC assembler (which looks to me like the AT&T syntax).
There is no FPC syntax. FPC uses an modified NASM based internal assembler (which can do both AT&T and Intel), and also a pass through mode (DIRECT) which copies the code to the back-end file.
Well, the FPC asm stuff that I can see looks different from the AT&T syntax in the sense that I can't see any single quotation marks there.
Since I understand neither of these, I can't proceed with the porting.
Send me the relevant pieces, and I'll try to pascal'ize them.
I will do that in a private email.
Could you elaborate on the GPC modifications? Are they huge?
No, they are not. Actually the changes that I have had to make are quite minimal (at least when compared to the size of the code).
One possible problem are the strings. We are touching the 255 character TP limit in the IDE, and converted it to Delphi style dynamical AnsiStrings.
I know GPC has some dynamical string, but I don't know how it works. Are they source compatible with ansistrings (auto allocate, auto deallocate?)?
Not yet. But GPC does not have a 255 character limit for strings. You can give a string any capacity that you want, but you have to specify the capacity otherwise it defaults to 255 characters.
Length(s) should return length of string, and a setlength(s,len) should be defined that sets the length of string s to "len".
All that works okay under GPC.
If you would like to help with porting these units, then do please get in touch. It would seem better to recode these assembler routines in Pascal than to convert the FPC assembler to something that GPC can understand (if it isn't already in that form).
In my opinion, if we can port these three units to GPC, then a working class library for GPC (which also supports several other Pascal compilers) is within reach.
Try to implement the FPC-API .
Hmmm ... I am not too sure that that is the way to proceed ...
Best regards, The Chief ----- Dr Abimbola A Olowofoyeku (The African Chief) Email: African_Chief@bigfoot.com Author of Chief's Installer Pro v5.22 for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm