cpython/Mac/MPW

Python and MPW
==============

There is conditional code in Python for MPW.  This has been used with
different compilers at various points in time.  Right now it is being
used to turn the entire interpreter into a shared library on 68K Macs,
so we can build "applets".  I have used MPW 3.2 and the OpenDoc
development environment from an OpenDoc CD released in 1984.  This
contains the Symantec C compiler for MPW, version 7.XXX, the
Universal Headers version 2.0a1 (XXX), and early versions of CFM-68K
(the Code Fragment Manager ported back to the 68K Mac) and
MixedModeInit, which are required to use shared libraries.

I've created a Makefile that does everything, plus a three-line Build
script that calls Make and runs its output.  The Makefile assumes that
it lives in a 1-deep subdirectory of the root, so e.g. the Python
Include directory can be referenced through "::Include".  All object
files are collected in the subsubdirectory Objcode.

I use these feature test macros:

MPW		for all MPW compilers (e.g. long double in <math.h>)
__SC__		for things specific to the Symantec C compiler
		(e.g. doesn't like static forward)
__CFM68K__	for things specific to CFM-68K
		(e.g. it requires the use of #pragma lib_export on|off)
HAVE_UNIVERSAL_HEADERS	for things not yet in Think's headers (e.g. UPPs)
GENERATINGCFM	for both PPC and 68K Code Fragment Manager

MPW is defined in config.h (if it finds that applec is defined);
HAVE_UNIVERSAL_HEADERS is defined in macglue.h depending on whether it
thinks we are using Universal Headers.  The others are defined by the
compiler or by the system headers.

Compiler switches were a nightmare until I found I had to use -b.
This wasn't mentioned in the CFM-68K docs that came on the OpenDoc
CD-ROM.


Applets
=======

(XXX This text file is on my Mac)


Warning: Mixing Think C and MPW
===============================

(XXX Need to check what convention SC uses -- I hope it uses Think's.)

If you are mixing Think C and MPW, you may experience weird errors in
previously correct modules.  These disappear when you throw away the
module's .pyc file.  The errors usually have to do with string
literals containing '\n' or '\r'.  The reason is an incompatibility
between their handling of '\n' and '\r' -- in MPW C, '\n' actually is
ASCII CR while '\r' is ASCII LF, which is the reverse situation from
any other ASCII based C implementation.  This behaviour is inherited
by Python compiled with MPW C.  This is normally not a problem, but
*binary* files written by one system will be mis-interpreted by the
other, and this is what happens to the .pyc files.  There is no easy
way to fix this in the source.  (This is a real shame, since the
format of .pyc files was carefully designed to be independent of byte
order and integer size -- deviations in the ASCII character codes were
never anticipated.)