Re: Porting perl to (traditional) Mac OS via Genie

On Jul 19, 2005, at 5:43 AM, Dominic Dunlop wrote:

> On 19/07/2005, at 10:27 AM, Joshua Juran wrote:
>> I'm porting perl to a platform called Genie, which is a Unix-like 
>> subsystem that runs in Mac OS.  The purpose of this exercise is to 
>> have a command-line perl tool available for Mac OS, in a stdio 
>> environment with polymorphic file descriptors, without the 
>> limitations of MPW.
>
> Good to hear. You don't say whether this is PPC or 68k Mac OS. I guess 
> the former, though the FAQs on your site make me wonder.

I wonder too.  I haven't looked at them in years.  :-)

Genie requires CFM -- Genie programs are built as CFM drop-ins, or 
plugins.  CFM-68K Runtime Enabler 4.0 requires System 7.6.1, which 
requires a 32-bit clean ROM (and perhaps a 68020 or better).  This 
leaves out the Mac II, IIx, IIcx, SE/30, and 68000-based machines 
(unless an earlier version of the CFM-68K Runtime Enabler with an 
earlier system works, which I don't plan to test any time soon).  While 
it might be possible to use code resources (with Genie fiddling the A4 
register for plugin globals) I don't see the value, since much faster 
Macs are readily available on the cheap.  Genie does actually build and 
run on 68K, although you have to patch a bug in Threads.h if you want 
to use Thread Manager callbacks without crashing.

Genie's sockets support requires Open Transport -- MacTCP is not 
supported.  I don't think this will upset anyone.

One caveat is that Open Transport only supports CFM-68K as of version 
1.3, which requires Mac OS 8.1, which in addition to ruling out 
anything less than a 68040 nails you to a specific OS version.  
Fortunately, the OTCFM68KGlue library hacks around this by calling OT 
from a 68K code resource and should make it possible to support System 
7.5.5 and 7.6.1.  I haven't tried this yet.

> Back in the day, I worked on keeping Perl running on PPC MachTen, a 
> commercial UNIX-under-Mac OS product from Tenon Intersystems 
> (http://www.tenon.com). The product, though still apparently 
> available, is, as far as I know, unsupported, and suffers from a 
> number of long-standing bugs and security issues. Vague requests from 
> some users that the code be open-sourced after support ended were 
> rebuffed.

Apple phrased it this way:  "Open source is not a dumping ground for 
dead products."[1]

Most unfortunate, since I'm sure I could have found *something* useful 
in the source code.  ;-)  Other closed Unix-on-Mac products include 
Mac06 and (though this is a stretch) Apple's own MPW.  Open-source 
projects include MacMiNT and PATMOS.

> MachTen was delivered with gcc, so I didn't use MPW or CodeWarrior in 
> porting perl. If you search in old perl5-

Genie requires a real C++ compiler to build, which rules out MrC/SC.  
Plugins shouldn't require C++ at all, but I haven't investigated using 
anything other than MW C.  Perhaps I should -- I ran into some curious 
MW linker issues that prevent me from linking Genie plugins against my 
own shared libraries, and had to link in the standard library 
statically.

> porters archives, you'll find mail about various issues I tripped 
> over, including malloc() (once tweaked to work, Perl's own malloc was 
> much faster than Mac OS' own); and fork() (MachTen, thanks to deep and 
> probably dark magic, has both fork() and vfork(), but the latter is 
> MUCH faster, as Mac OS does not support Copy on Write). You'll also 
> find clues in hints/machten.sh.

One of the problems is returning twice.  Matthias got the idea to 
provide vfork() as a macro that calls setjmp(), which he implemented in 
his Natty project.[2]  I opted against this for now, since what you'd 
have to do with the return value of setjmp() to implement proper 
vfork() semantics and what the standard says you're allowed to do with 
it are not compatible.  AFAICT you're not even allowed to assign the 
return value to a variable.  It might work anyway, but I didn't wish to 
go there.

My interim solution requires as a compromise that code be written thus:

	#ifndef macintosh
	#define is_child_pid( pid )  ((pid) == 0)
	#endif
	
	pid_t pid;
	
	while ( (pid = vfork()) == -1 )  sleep(5);
	
	if ( is_child_pid( pid ) )
	{
		/* We're the child */
		/* setenv, dup2, etc. */
		
		execve( ... );
		
		_exit( EXIT_FOO );
	}
	
	/* We're the parent */
	
	waitpid( ... );

The trick here is that for a Genie plugin, vfork() saves the caller's 
process context and returns the child pid (once), is_child_pid() is the 
identity function (always true for a pid), and either execve() (unless 
it fails) or _exit() restores the original process context AND RETURNS. 
  (Unless you call without forking, in which case it terminates the 
caller's thread.)

Hey -- it works, doesn't it?

The third way is to decide you're not just an application but really 
part of the operating system and actually implement  per-process 
address spaces, a la MachTen.  This has been left as an exercise for 
the reader.

For implementing qx// and system, vfork() is sufficient.  For fork, we 
should be able to use the same perl_clone()-based emulation that 
Windows uses.  See perlfork.  It may even be possible to clone into a 
'real' Genie process (which is really a kind of pseudo-process) without 
resorting to pseudo-(pseudo-)processes, such that 'fork and exit' would 
work.

Josh

[1] ...When asked to open-source HyperCard, at the 'Apple Handshake' 
session of MacHack 2000.

[2] http://www.sourceforge.net/projects/natty/

-- 
Joshua Juran
Metamage Software Creations - Mac Software and Consulting
http://www.metamage.com/

                * Creation at the highest state of the art *

• Porting perl to (traditional) Mac OS via Genie by Joshua Juran
• Re: Porting perl to (traditional) Mac OS via Genie by Dominic Dunlop
• Re: Porting perl to (traditional) Mac OS via Genie by Joshua Juran
• Re: Porting perl to (traditional) Mac OS via Genie by Joshua Juran