PowerPup, run it on Tiger if you can -- there's a widget bug that affects Leopard that I'll have fixed in beta 2.
The NSPR bit: Chromium has a system abstraction layer in it that Chrome/Chromium use to abstract functions between Windows, Mac and POSIXy Un*x. Mozilla has had such a glue library for a lot longer, as evidenced by the name: the "Netscape Portable Runtime." NSPR is much more comprehensive, and at one particular point in the past it simultaneously had support for Mac OS 8/9, Windows, early OS X, BeOS, OS/2, a wide variety of Unices including Linux, *BSD, Solaris, AIX, etc., and even VMS and some other exotics. NSPR was as the name implies a holdover from the Netscape Classic days, where it handed System 7, Windows 16/32 and numerous Unix ports. My ANS even has Netscape on AIX 4. If you want Mozilla code to run on your system, you must port NSPR, which was the first thing Timberwolf had to do to get it on AmigaOS 4. Classilla is also based on NSPR, just an earlier version that still supports OS 9 with of course my patches stuck in it, and TenFourFox uses a tweaked NSPR that still runs on 10.4.
So the question was why Mozilla chose Chromium to handle their IPC instead of rolling their own, and I guess it was just the path of least resistance. But they didn't do (just) that; rather than port Chromium IPC to talk to NSPR and just have it use NSPR for the system guts, they decided to bring its entire system abstraction layer with it. Chromium IPC in TenFourFox is super-gutted; most of it doesn't even work. It's only there to provide stubs to make Mozilla happy, because there are other pieces of code I wrote to route around it. This will only work for so long because 10.4 lacks posix_spawn and Chromium IPC absolutely requires it, which is why plugins will never run out of process in 10.4Fx. When Firefox goes fully multiprocess, which fortunately is at least several versions away, we're going to have another fish or cut bait moment.
The NSPR bit: Chromium has a system abstraction layer in it that Chrome/Chromium use to abstract functions between Windows, Mac and POSIXy Un*x. Mozilla has had such a glue library for a lot longer, as evidenced by the name: the "Netscape Portable Runtime." NSPR is much more comprehensive, and at one particular point in the past it simultaneously had support for Mac OS 8/9, Windows, early OS X, BeOS, OS/2, a wide variety of Unices including Linux, *BSD, Solaris, AIX, etc., and even VMS and some other exotics. NSPR was as the name implies a holdover from the Netscape Classic days, where it handed System 7, Windows 16/32 and numerous Unix ports. My ANS even has Netscape on AIX 4. If you want Mozilla code to run on your system, you must port NSPR, which was the first thing Timberwolf had to do to get it on AmigaOS 4. Classilla is also based on NSPR, just an earlier version that still supports OS 9 with of course my patches stuck in it, and TenFourFox uses a tweaked NSPR that still runs on 10.4.
So the question was why Mozilla chose Chromium to handle their IPC instead of rolling their own, and I guess it was just the path of least resistance. But they didn't do (just) that; rather than port Chromium IPC to talk to NSPR and just have it use NSPR for the system guts, they decided to bring its entire system abstraction layer with it. Chromium IPC in TenFourFox is super-gutted; most of it doesn't even work. It's only there to provide stubs to make Mozilla happy, because there are other pieces of code I wrote to route around it. This will only work for so long because 10.4 lacks posix_spawn and Chromium IPC absolutely requires it, which is why plugins will never run out of process in 10.4Fx. When Firefox goes fully multiprocess, which fortunately is at least several versions away, we're going to have another fish or cut bait moment.