[fpc-devel]Compilation of Apples Universal Interfaces

[Dr. Rolf Jansen]

There is an ongoing fruitful private discussion between Olle Raab, 
Jonas Maebe and me (Rolf Jansen) about the compilation of Apples 
Universal PInterfaces with Free Pascal.

The actual state is, that with relatively minor tweaks the UI´s can be 
compiled for Classic Mac OS (Olle) and also for Mac OS X (Rolf). After 
Jonas made some changes to the compiler with respect to the resolution 
of external names, I was able to produce a running NIB based Carbon 
application completely with Free Pascal within Xcode. NIB means that 
the user interface is built by Interface Builder and not with ResEdit.

Olle suggested to continue the discussion at the fpc-devel list, so 
after giving to you (the group) this short summary, I continue with the 
discussion.


Olle,

I am with you to keep the number of changes to the PInterfaces as small 
as possible. However, I would like to make a distinction between buggy 
or misleading parts of the PInterfaces and those parts which simply 
belong to another flavour (presumably the Mac one).

A.  I advocate for debugging the UI´s and not to accommodate
     for bugs in the Free Pascal mode -Mmacpas.

B.  I advocate for improving the Free Pascal mode -Mmacpas in order
     to allow all Pascal Mac developers a smooth transition.

C.  I advocate for maintaining and improving the PInterfaces
     as time goes by since Apple will not do it anymore.


Examples for A:

IMHO the active LongDouble routines in fp.p and the use of the term 
"object" at several places belong definitely to category A. In fact, 
your example "SetDeskCPat" is deactivated with the {$IFC 
CALL_NOT_IN_CARBON} directive. IT IS the policy of the UI to 
activate/deactivate not used parts for different platforms/targets - by 
this way the interfaces became universal.

I doubt that the term LongDouble was ever used by Mac Pascal 
Programmers. LongDouble was known as extended. So, I suggest not to 
care about the LongDouble routines, but simply deactivate them for Mac 
OS X by encapsulating them with the conditional directive {$IFC 
TARGET_CPU_PPC AND NOT TARGET_API_MAC_OSX}.

I consider "object" to be a reserved word for Mac Pascal. So it is a 
bug to use it as record field names or in routine declarations as 
parameter names. There is no other way, "object" must be renamed in the 
UI´s.

In CFStrings.p compared to CFStrings.h the declaration of CFSTR is 
simply missing, but many other parts of the UI´s rely on it. So, there 
is no other way, the following declaration should be added at line 158:

function CFSTR(cStr: ConstCStringPtr): CFStringRef; external name 
'___CFStringMakeConstantString';


Example for B:

{$LibExport+} belongs definitely to category B. It might be a good idea 
to let Free Pascal accept this directive in -Mmacpas in the future, 
even if it does nothing special but simply ignor it.


Example for C:

The changes to the type declaration of CStringPtr/ConstCStringPtr from 
Ptr to PChar belong to category C. After thinking about it, I aggree 
with you that this more specific change is better compared to the more 
general change of Ptr from ^SInt8 to PChar.

It might be a good idea to surround changes of category C with the 
conditional compiler directive {$IFC NOT UNDEFINED FPC}.

This would mean in the given case that in MacTypes.p:

	CStringPtr            = Ptr;
	CStringPtrPtr         = ^CStringPtr;
	ConstCStringPtr       = Ptr;
	ConstCStringPtrPtr    = ^ConstCStringPtr;

should be changed to:

{$IFC UNDEFINED FPC}
	CStringPtr            = Ptr;
{$ELSEC}
	CStringPtr            = PChar;
{$ENDC}
	CStringPtrPtr         = ^CStringPtr;
	ConstCStringPtr       = CStringPtr;
	ConstCStringPtrPtr    = ^ConstCStringPtr;


If we follow these rules then no change of either category will break 
compatibility to old Mac compilers or different targets.

I aggree with you that it would be great if Apple would allow us to 
distribute a patched version of the PInterfaces. In the meantime we 
have to go the diff and patch way.

Best regards

Rolf

__ InstantWare ______________________________________________________
  Dr. Rolf Jansen * Stephanienstraße 19 * D-76133 Karlsruhe * Germany

  http://InstantWare.bei.t-online.de/
_____________________________________________________________________