Update -
Found the company’s product docs. “Bright, flashing blue LEDs to attract customers.”
This is the best thing that I have seen all day! http://www.conservapedia.com/Special:Statistics. Not gay at all.
I blogged earlier about getting Phalanger running on Mono and the missing feature missing being the native extension support because the bridge was written in Managed C++.
Well I came up with an all C# solution. It’s not close to being done, more just a proof concept. I’m not sure the willingness of the upstream with supporting this method because it probably means a lot more work to maintain this method then the managed C++ version. With the managed C++ version, its less complicated because at least you can reuse the headers from PHP to help out with all the function declarations, typedefs, macros, and structs (that sometimes break ABI compatibility on rare occasion in PHP from version to version which everyone who has ever used the Zend optimizer knows about when they upgrade their PHP version the old version of Zend’s optimizer breaks). With the all C# solution, it means reversing all those headers and duplicating their function in C#.
There are also a few typedefs in the headers that compile to two different sizes between 32bit and 64bit platforms so I have to declare two versions of the same p/invoke calls on some occasions and use one or the other if the code is running on 32bit or 64bit.
The way the code works on the managed C++ side is that the code will iterate through all the php extension dynamic libraries. All the extensions in PHP are required to expose a standardized set of function exports. The managed C++ code will dlopen them (I’m using Unix terminology here, LoadLibrary on windows), use dlsym to get the function pointers for that extension, store them in to a struct, and stick the struct on to an array where it holds references to all the extensions. (I’m way over simplifying what it does, as phalanger also does some neat isolation tricks by loading the extensions into a different memory spaces/processes to keep buggy extensions from crashing the process phalanger is running in and remotes into them).
This same kind of operation using dlopen and dlsym like this can be done from Mono/.NET natively in a cross platform safe manner using just plain old P/Invoke and some really cute System.Reflection.Emit code. (Cecil maybe able to help me here for what I’m doing later). Basically, it means I emit an class for each extension on the native side, with all the emited classes inheriting from a interface that matches the same method signatures of the exports I’m P/invoking in on with each lib. It’s not possible to declare an extern in an interface, so I emit both a private pinvoke call and a public function with the same signature and name that just calls it which is in the interface. The class I emit each time is almost identical except for the given library name each of the p/invoke calls call out to. Poor mans dynamic p/invoke. This entire process can be at runtime, or done before hand, where I can generate assemblies or even exes that remote into a parent process for poor mans process isolation (which is really easy since I’m using a well known interface for each of the extensions so remoting to it is simple).
After the extension is loaded up, the managed C++ code will then do some System.Reflection.Emit operations to generate a wrapper assembly around the functions provided by the php extension library. This is done using the reflection like information provided by the extension to emit a similar call in the .NET side that proxies down to the extension. PHP has setter and getter methods, overloading, purely dynamic functions, well known functions, etc. Thankfully this managed C++ code converts to C# without to much trouble. There is still a lot of structs to rebuild though.
In all, its about a 6 to 8 week project if I had the time. (which I don’t) 
In my free time, I’ve been trying to get Phalanger working better on top of Mono. Phalanger is a PHP implementation for the CLI and ASP.NET. It runs like a champ with the basic features on top of Mono.
One of the greatest features, and also biggest missing feature with running Phalanger on Mono, is native support for PHP extensions. The extensions in PHP are basic dynamic libraries, exposing a common set of standard C exports. In Phalanager, they have written a wonderful bridge between them, but unfortunately for me though, this bridge is written in Managed C++ (icky) and does a lot of Win32 specific things. They are also doing a lot with named pipes and running things in separate memory spaces, and worst of all, a good portion of the managed C++ code is doing Reflection.Emit. No easy way to get around this it looks like. *sigh*
Apple seems to have given up with supporting Java on the desktop. They have really been pulling back hard on any desktop Java related technology.
It’s only on the desktop. Apple’s J2EE based WebObjects technology doesn’t look like its going anywhere for now (Apple’s store and .Mac server are still powered by it) but that is a server side technology that was created back in Job’s NeXT days which is included in Mac OS X Server.
Apple slipped and didn’t ship Java 6 with Leopard like they implied they would. They also pulled the developer previews of Java 6 from the Apple developer site. What is left for Java 5 support in Leopard is sadly broken around everything AWT and Swing related. Not that I’m horribly sad to see it going but years ago, Apple was excited about supporting Java. I remember claims that Mac OS X would become the platform for Java on the Desktop a few years ago at an Apple Developer Conference.
About a year and a half ago, Apple still supported Java bindings to Cocoa and Java was treated as a first class citizen in Xcode for developing Cocoa apps. That was depreciated, and Apple’s solution was to tell people to migrate to Swing instead and publish articles on the ADC on how to embed the JRE and use JNI with Cocoa and Objective-C code. Long ago, Apple had bindings for Quicktime that fell into depreciation in Jaguar. They also had bindings for other libraries but they are long since gone. Before Leopard, there was almost as many references to Java on the Xcode and OSX pages as there was to Objective-C. Now you can’t find anything. Old links all redirect to developer.apple.com/java.
You also don’t see Java on the iPhone, which isn’t a huge surprise. Jobs was quoted as saying right before the iPhone’s release, “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”
There has been a lot of talk about porting OpenJDK to the Mac, but I don’t really believe its worth the effort to take on that beast. Why not instead take the opportunity to embrace something already supported on Mac like Mono (or maybe Python) ?
It’s a sad fact of life.
1. You can have it Fast and Cheap but it won’t be Good.
2. You can have it Fast and Good but it won’t be Cheap.
3. You can have it Good and Cheap but it won’t be Fast.
It also works for project schedules, resources, and scope.
1. The project can be done with that many people and that deadline if you allow us to change the scope.
2. The project can be done with that many people and that scope if you allow us to change the deadline.
3. The project can be done with that scope and that deadline if you allow us to change how many people.
Monologue My iTunes