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/
_____________________________________________________________________

Dr. Rolf Jansen wrote

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.

One problem with this may be that it seems that diff (the version distributed with Mac OS X in any case) is not able to cope with Mac line breaks. It thinks the whole file is one long line. We can of course create a script that uses "tr" to change the Mac line breaks to unix linebreaks before patching (or a Pascal program that simply reads the orignal and writes it out elsewhere, that will have the same effect).

Jonas

Many thanks for the hint. I will try the following:

1. I will make a command line Pascal program which converts CR to LF
2. I will make a shell script which applies the diff
3. I write a double-clickable AppleScript application which calls both with the correct arguments in the correct order and which in its later incarnation might install other stuff.

Rolf

04-08-16 11.58, skrev Dr. Rolf Jansen följande:

Many thanks for the hint. I will try the following: 1. I will make a command line Pascal program which converts CR to LF

You might use the tr utility, like this:

tr "\r" "\n" | diff ... | tr "\n" "\r"

2. I will make a shell script which applies the diff 3. I write a double-clickable AppleScript application which calls both with the correct arguments in the correct order and which in its later incarnation might install other stuff.

Nice.

But I still think it vould be easier for our users if we got the permission from Apple to redistribute our modified UI. I'll try to contact them.

Olle

Olle Raab wrote

You might use the tr utility, like this: tr "\r" "\n" | diff ... | tr "\n" "\r"

I will give it a try.

I aggree that would be best. I would appreciate if you would contact Apple. I think you might want to start here:

http://developer.apple.com/faq/softwarelicensing.html

Rolf

04-08-16 10.31, skrev Dr. Rolf Jansen följande:

I do not either want to accomodate for bugs.

My idea is to make fpc in mode macpas emulate Metrowerks Pascal, since this is the most modern commercial pascal compiler for mac. And the compiler today's active pascal programmers uses. Mode macpas should accomodate for Think Pascal features.

And the Delphi mode of fpc sometimes support things in Delphi which is not so nice, but not neccesarily bugs, because it should be possible to share code between FPC and Delphi.

That said, we should of course not support all bad things in Metrowerks.

And perhaps it is good to be conservative and not implement everything right now, at least not today :)

Sorry, you are right.

IT IS the policy of the UI to activate/deactivate not used parts for different platforms/targets - by this way the interfaces became universal.

But this one:

{
* ScrollWindowRect()
*
* Availability:
* Non-Carbon CFM: not available
* CarbonLib: in CarbonLib 1.0 and later
* Mac OS X: in version 10.0 or later
}

is not deactivated for Non-Carbon CFM. I guess non-carbon calls is deactivated, but not everything is properly deactivated, it is instead left to the linker to complain about.

But ok, at least non carbon code should be deactivated under carbon.

OK.

But I will anyway add LongDouble for non Mac OS X. Because it is defined by Metrowerks.

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.

Metrowerks do not treat object as an reserved word, thats why this bug is not discovered. But I agree it is not nice. So rename.

OK, its added to the cvs. Its recognized but does nothing.

OK.

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.

In any case it is nice to have a diff file as a document of the changes.

Olle

BTW If you write in the wiki, consider to register as a user, it is then
easier to see who has written what, and to discuss that.

Nothing more to say about it, since I see we are in total agreement.

- I will produce a diff file or the changes in the Universal PInterfaces.
- If I ever submit any change to the MacPas wiki page, I will do it as a registered user.
- I will update the Xcode-FreePascal site soon with the latest development.

Thank you very much Olle and Jonas.

Best regards

Rolf

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

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