Zac Bowling’s Blog

I just don’t know what to make of this video… I guess Microsoft is trying to break the stigma around Vista as best they can (I don’t think this video is helping their case much).

Texas Instruments, my company, will not support upgrading to Vista across the entire corporation as was leaked to the inquirer back in late 06 to early 07. No Vista machines in sight here still (except in the testing labs). Everyone is running XP if they are using Windows, but you do see a lot of Mac’s running Leopard, or and few laptops running the latest Fedora, Ubuntu, SuSE, and OpenSolaris desktops for those of using in various development and engineering roles.

I’m sure TI would probably use Vista if Windows 7 isn’t out by the time that XP goes into legacy support status, but XP works and we don’t have any problems with it. We already bought our huge corporate level volume licenses for XP so I can see the logic into why really IT doesn’t want to upgrade more then 10,000 users machines here when there isn’t a significant gain (and more of a loss really) by doing so even still. Nothing in Vista (even in SP1) is really worth upgrading for.

The developer program is turning out to be bunch of hype for something stupid. The restrictions on what your application is allowed to do is total, laugh-out-loud, crap.

I was initially excited about the SDK and developer program for the iPhone. I was willing to live with Apple being only distributor of Apps and getting a cut of the profits. I was willing to live with an entrance criteria to get into the App Store.

But then I heard about the other restrictions, and if you haven’t heard yet about the restrictions placed on your applications, here are gritty details:

• “Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.” (section 3.3.1 in the SDK license agreement) That means currently no access to IOKit
• “An Application may write data on a device only to the Application’s designated container area, except as otherwise specified by Apple.” (section 3.3.4 in the SDK license agreement). No full file system access basically.
• Your application is completely closed when the user leaves it like when they get a call or any of a number of actions happen. (specified in the Human Interface Guidelines). Only one application can run at a time basically so no background applications. (Something you can do in the current Open SDK)
• “An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and builtin interpreter(s).” (section 3.3.2 in the SDK Agreement)
• “If Your Application includes any FOSS, You agree to comply with all applicable FOSS licensing terms. You also agree not to use any FOSS in the development of Your Application in such a way that would cause the non-FOSS portions of the SDK to be subject
  to any FOSS licensing terms or obligations.” (section 3.3.14 in the SDK license agreement)
• No way to write plugins for the apps that exist on the phone right now, even for apps that openly support it plugins like Safari.
• Applications can be rejected for not meeting the Human Interface Guidelines
• No VoIP apps that work over cell network (that is acceptable, VoIP is a bandwidth hog and with unlimited data, it hurts the carrier)

Porting Firefox would be impossible because it supports downloading and running “interpreted code” with its Javascript engine. Things like Mono could only be used if you included a version Mono with your application, so basically no system wide install. No way to write a usable IM or IRC client on it, since apps can’t run in the background. Since we won’t be able to write plugins for existing apps like Safari, it means no Silverlight/Moonlight and no third party Flash support. IOKit isn’t in the list of document APIs even though its on the iPhone today, so no way to access the dock port to get to the PC or access the Bluetooth hardware. No way to tie into the data sync integration as well, so you can have it sync data with other things on your PC when docked.

What we get is so much more limited then what you can get natively in the unofficial Open SDK that is out there for the jail broke iPhones today. What annoys me is that Apple only played it off like their was only restrictions around application acceptance criteria for the application if was porn or a bandwidth hog. Not all this crap.

I think its idiotic of Apple to think this is what we were looking for. It’s pretty much a giant joke. I hope the public out cry about this is enough to knock Steve out of his black sweat-shirt and blue jeans, and have another wake up call.

Yesterday, I attended the first day of my company’s huge T³ conference. It was something else and a little different then the software conferences that I’m used to attending. Nearly 3000 people there. So many teachers from around the world. It made me appreciated the reach our software and hardware has a bit more getting to see how large our customer base is. As a software developer, I think we sometimes get separated from our customers through so many layers, and for me it was great to get to meet so many of them. One part thing I love about our company is that we try to get everyone in just about every role out there to interact and listen to our customers. Everyone from software developers, QA testers, project managers, distribution, sales, marketing, customer service, product managers, HR, configuration management, hardware/electrical engineers, and just about everyone else in our division came out to help with the conference.

I also met up with the Vernier guys there, one of the members of the GNOME Mobile community, and I got to play with their new GNOME based LabQuest. The Vernier guys are awesome. I’ve enjoyed working with them in the past to make sure that our TI-Nspire product works with their Vernier EasyTemp®/Go!® Temp/Go!® Motion probes and sensors, so they can power the data collection features of our product. The Vernier guys are big Linux supporters which is nice to see.

I’ve come across some really bad unit tests in a number of projects recently. I’m assuming that were written in the past only because someone said to the developers something like “Writing more unit tests improves code quality, so everyone write more unit tests!”. That was all the direction they got it seems (I’m assuming that from reading the code), and unfortunately, the developer and the leader wanting the developer to write unit tests wasn’t exactly sure why unit tests are important or how to write effective unit tests.

There are a few common goals that writing units help solve.

1. Unit tests provide an excellent facility for regression testing, in that help they allow programmers to easily refactor a piece code at a later date, and make sure that each module still works correctly.
2. Unit tests can be written to help simplify integration if you are working from the bottom-up in many cases. This goes well with really good planning around integration points. In a large project you may need to separate everything out into smaller units or modules. All the pieces are probably going to developed concurrently by different developers and teams. If you write unit tests around your integration interfaces, you can flush out any issues before hand and move on to develop other pieces of the project, and that lessens the strain on your integration phases later.
3. Unit tests can also offer a form living document for others to understand how the code works and how they can use it or call it by providing a bunch of working examples. Since the unit tests are constantly being updated as code gets refactored they are usually more reliable then any static documentation which can drift and get out of date.

Another overlooked piece is when should you write unit tests. I know that in a lot of projects that I’ve worked on, the time developers would take to write their unit tests is usually delegated to the end or when they have any extra time. The unit tests usually end up the victim of procrastination and a lack of coverage usually causes more headaches later.

I believe unit tests should almost drive your development, especially when you are developing in an agile environment, defining features as you go and you are constantly refactoring your code.

Unit tests are great way of showing you where you have spaghetti code and complex environmental dependencies right away.

If you enforce unit tests on all business logic, you pretty much can enforce a clean separation of interface and implementation, and drive you code towards using better coding standards and patterns out of necessity to just be able to test your own code (like moving your code to a basic model/view/controllers pattern). It’s a great practice to get into for writing maintainable code.

You have to be smart about your unit tests though. More is not always better. You have to be practical and not walk about until you feel you have sufficiently covered everything. Anything that preforms any custom logic based on a specific input is a big candidate for a unit test. Sanity check unit tests are not usually necessary (such as writing a unit test around a property/setter-getter method that simply reads or writes to a field in a class).

One of my pet peeves is a test that knows the internals of a particular unit, not the function of that unit provides. You should pretend you don’t know how your code works internally, and write tests how other code is going to interact with it. The exception to that rule is if you know of ways that unit could easily break with specific inputs but stay within the confines of what that unit provides you. Do not write units tests that simply reconfirm that your code works exactly the way that you wrote it and would probably break if someone refactored the internals of that code.

For example, lets say I have a function called “SaveCustomer(String id, Customer customer)” that I know saves to a database underneath and another function called “LoadCustomer(String id)” that loads from that database underneath (the underlying database is not intended to be accessed directly except by the customer abstraction in this case). It would not be an effective test to write a test that calls the SaveCustomer function and then connects to the database to see if its written, or similarly, write a test that calls the LoadCustomer function and checks to see if the data returned is the same as in the database. Rather a more effective test would be write a test creates a customer and attempts to store it using the SaveCustomer function and then tries to load it back out using the LoadCustomer function and verify the data in the customer objects survived round trip.

Another example that I ran into was a function called “getOffset” which was meant to return the internal position of where to read off an array returned by that same class. The previous programmer that wrote the function knew that the value would always return 16 at that time but made the function so that he didn’t have any magic numbers running his code and that he could change the value it returned to something different someday (or possibly even dynamically figuring its position at some point). However the programmer wrote a unit test to make sure it always returned 16 and sure enough when I went in and changed what the offset would was, the unit tests broke although no code did that called that function. Effectively, the test was broke and not the code.

It comes down to being smart and practical about your unit tests. There is no perfect setup. I try to shoot for a test around each public function and protected function (if intended to be inherited by other classes), and if applicable how the class is used as a whole (thinking of it as almost writing examples and documentation for the code).

Some good candidates for unit tests are around that code that does logic in loops, contains switch statements (especially in languages that all statements to can fall through), any goto/jump statements, any regular expressions usage, any “auto-magical” features that can possibly fail at runtime, non generic collection usage, null pointers, static position access on non-rigged arrays, primitives based by reference, and code that calls reflection features of your language.

In scripting/interpreted/dynamically typed languages, lots of sanity check tests are also more useful to attempt to test each code path possible. I wish you luck if you are writing a large application in one of these languages if you don’t have a strict coding standard and a whole bunch of tests.

Whatever you do, you can’t trust unit tests to be your only type of testing. Unit tests are not well suited for GUI testing and they can almost never do functional testing. Unit tests can only tell you if an error occurs in one particular case but not that couldn’t foresee to happen in many cases. Automated testing solutions depending on your project are really important as well in many cases.

What the hell is the world coming too. I found this in my local grocery store tonight. $1.50 + credit card interest is totally worth the convenience of not having to handle a dollar bill.

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*

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.

When I read Andreia Gaita’s latest post, I started to tear up and laugh a little as it brought back a lot of painful memories with my experience with fighting it. Andreia, you know all to well my pains and my struggles I had with that code (trying to embed Mozilla externally). I’m so overwhelmed with joy that you got it going. Awesome work that you have done taking my pretty hobbled and badly broken code the rest of the way and making it actually work!

My biggest hurdle in the beginning was trying to figure out how to make this all work given all the requirements. Some of the requirements where more self imposed in what I though it would take to get the web browser control accepted, and others requirements came from other monoers (especially Miguel ). Going through the options, it came came down to forking off a version of the entire mozilla tree and embedding the entire mozilla engine into my wrapper, or calling it Mozilla dynamically. (You can read more about that in previous post). I knew that forking the mozilla tree would be horrible because no body would want to build it and use it (it takes an extra 7mb, about 3 hours to build on most average machines, and you have to manually maintain it). Also there were concerns about littering the source control with that massive beast. That left the only other solution, externally calling the local Mozilla environment on the users machine dynamically, although it was the FAR more complicated solution to make it work (it shouldn’t be and perhaps this project will help that).

In beginning, I was still going through the mozilla code and documentation trying to understand it better. I have written a bunch of patches for GtkMozEmbed, so thats the angle I started attacking it. The Mozilla documentation on embedding is helpful but it was written around the idea of forking the Mozilla tree. I was still trying to understand how to make it work so I went ahead and wrote a version of the embedding control in that fashion (internal wrapper) by forking the gtkembedmoz code and removing almost all the GTK+ references (you can see older bits and peices of that here). I though I could take that version and move it to build externally, however I didn’t realize how many private functions and interfaces are inside Mozilla that gtkmozembed actually used. There was almost no way it was going to work, so I started from scratch.

I was pretty much forced to dive deep into internals of XPCOM. In the process I had to learn the evolution of the Mozilla codebase to understand why things where done the way they are done. This took way to long (I could almost write a small book on the topic now). When I got done, I figured that no body in their right mind (I guess that includes me) is going to want to go through this to just embed Mozilla. Thats when I came up with the goal of making sure that the backend library that I was going to write to bridge Mono and Mozilla would be reusable outside of just Mono if at all possible (a simple embedding interface that exposes basic C exports for people to use).

Then it came down to the build environment. I have experience with witting libraries in the open source/Linux world, and at first I though it was going to be easy. Heck, even my distro even had package config files to save me a bunch of trouble (later I found out that my distro added those and there is no standard package config for developer packages or XPCOM). I got started with an environment that I though would work for everyone and got going writing code. I got it working for while, but half way through development I updated to a new release of my distro. Suddenly nothing would compile anymore. I found out that my distro was including IDL files it wasn’t supposed to in the older version. I was missing IDLs I needed. I did some investigation of other distro setups and found everyone did it differently (vastly different in many cases). This shut any new code development down while I re-evaluated what to do and what code would I be able to saved. I went back and looked at what was frozen and I trimmed down the interfaces I was going to use to as few as possible. After that I went back to the code and started trimming out code that called those interfaces I couldn’t/shouldn’t use anymore and looked for a work around to each one. This put the code in an unstable state where it wouldn’t build again. I hacked and hacked, trying to get it to compile again. I wasn’t even sure when I was done if it was going to work since I didn’t get to test it as I went along. I spent a good month’s worth of free time on it. I finally got it to compile but I was cheating in a few places. My build environment still needed work to stop cheating. I remember only one time that I seen that come up and show something after that after hacking it for a while.

Shortly afterward, I started working for TI and at the same time my laptop decided to take a sabbatical and go off to laptop hospital at Dell, who after replacing my motherboard, happened to wipe my drive and image with Windows (thank you every much Dell! Of course it “wouldn’t boot into Windows”, its called LINUX! Thank god I backed everything up.) I decided to give up working on it and wait until the interfaces changes and patches I submitted to mozilla would make it into the next release version (basically by 2.0).

I haven’t been able to spend the time to get back into it with work taking more of day. I did take some time and finished some work on getting a reusable build environment last month but haven’t been able to dedicate the time to it I wanted to.

Thats where Andreia has stepped up and taken over getting it done and she has done an awesome job doing so. I’m so happy to see it going somewhere with all that time I dumped on it.

Omar snapped this photo of all of us Mono guys (Joseph Hill, “Wasabi”, and me) at the Dallas Code Camp this year. It turned out to be a really good showing. Can’t wait till next year!

Yet more proof of Firefox’s growing dominance. Microsoft’s Windows Media guys have just released a Windows Media add-on for Firefox.

Now it only needs to run on Linux and Mac…

read more | digg story

I’ve been making some progress on the web control I started some time ago for System.Windows.Forms. I took a little break to wait for the 2.0 release to stabilize the API and make it easier to link an existing build of Mozilla rather then do the pre-mozilla 1.8 method of embedding by forking the entire tree and building everything in you need into your build. In theory it should be possible to link the libxpcom from any Mozilla product based on 1.8 or newer. In practice its not as easy as it sounds.

In order to use the components in Mozilla (using C++) you need to have an interface that represents that class that you use to cast to the instance you get back from XPCOM’s CreateInstance function. (Whats neat is that what it returns you could be anything, including your own instance, a proxied instance from where else, or even reference to a common singleton instance of that class.)

The problem is getting the interfaces on a clean build against the flavor of xpcom you are using with whatever Mozilla product you want to use to develop off of. You can do that by using the IDL tool in Mozilla (xpidl) against the IDL file of the component you want to use. Unfortunately that usually requires you first build the source of the Mozilla product to get the IDL files and the xpidl tool. Some Linux distros package a weird “devel” package which contains the xpidl tool and the IDL files generated when they build the Mozilla product. There is nothing in any Mozilla documentation that I know of that says thats ok or even recommended thing to do. All I’m aware of that is recommend is the Gecko SDK which contains all the headers and IDL files you need as well as standalone xpidl tool. However that tool was stopped after Mozilla 1.7/Firefox 1.0. It wasn’t until recently a new version of the Gecko SDK began to get built again but as part of the XulRunner project. Right now the Windows and Mac versions are broken however because they missing dependencies for their tools (libidl 6.x and glib 1.x)

The other downside is that there are also lots of unfrozen APIs in Mozilla and they change from product to product a lot. That means a lot of #ifdefs and testing on my part to work out all the kinks. For now I’m sticking to Firefox 2.0/Seamonkey 1.0/XulRunner 1.8 api only for now (they all are based of the same branch of the tree).

What I’m thinking about doing is generating the headers with the xpidl tool and including them in the source with instructions on how to rebuild them yourself if you wish not use the included (or in case they change or are different in your case). At least until the new Gecko SDK stabilizes, I think its an ok work around for now then having everyone download and build mozilla just to get the headers to build this library (thats a lot to ask since a Mozilla build can take a few hours doing it from scratch).

The reason why gtkembedmoz is so nice is that its a standard part of every linux build of mozilla and firefox built the normal build process. For that reason it can access internal classes that are not exposed to external developers that link into XPCOM (at least not without hacking). All the public apis are frozen and there are no dependencies to any mozilla headers in the gtkmozedmoz headers. It’s nice and portable and makes it very easy to embed with GTK+. Unfortunately it doesn’t make it easy to just simply copy gtkembedmoz code and make a version that can run dynamically linked against Mozilla. Not to say it wouldn’t be impossible to make standalone gtkembedmoz.

There is a lot of code to go through in order to make it work right in every respect. DOM support is possible as well (the Mozilla activex control guys pull off mimicking Microsoft’s IHTMLDocument interfaces in COM since they work as a drop in replacement for Microsoft’s IE Active Control so I might be able to leverage some of their work).

The great part is that little to none of the actual backend binding library is not tided directly to Mono. It simply just exposes a simple basic C api to embed Mozilla that I p/invoke. For that reason it might be useful in the future for other projects doing similar things to share the same backend that I’m using, like, for example, WxMozilla or Epiphany/Galeon (if they wanted to move off of gtkembedmoz so they could things like use the editing interface). It would be nice since we could all maintain a single library that could keep up with the breaking changes of Mozilla to maintain the same basic API to the backend. That’s just a though I had (that probably might not ever be realized) but I might was well not limit the code to preclude the possibility. Its unlikely but maybe someday down the road, Mozilla could embed the library I’m developing into their normal build. Who knows

You can see the planning and research I did before here on the Mono wiki.

I’ve done a lot since I first got interested in computers. It’s my hobby, my carrier, and basically my life. I got started back in the early 90s in the Windows 3.1 days. I wasn’t even out of elementary school before I was programming. In the 4th grade I wrote my first C program, and I knew immediately what I wanted to do. Since that time, I progressed pretty dang far, pretty dang quick. Reflecting on my life, I really hit every goal that I ever wanted to hit. I have to say that while I’m happy as I ever wanted to be, I’m just not that satisfied.

I’m setting a new goal that by 2010, on my 25th birthday, I’m doing something internationally recognizable. I want to manage other developers by then and help them get to the same status that I’m was at, at this point I’m at right now in my life. That means I don’t have much time either. I have to get started now and make it happen. Time to get started!

More to come later….

One thing I known for in my office is my wacky t-shirts. We don’t really have a standardized dress code anymore. There was one years ago (the up until the early 90s) at Texas Instruments. The rules are relaxed a bit at TI over the years from what I hear and it really depends on the division and area of TI you work for I guess more then anything (over 35,500 employees worldwide and thats not including students, interns, and contractors, every part of the company is like its own little company altogether).

Our QA is staff is know for being pretty lax on their own dress (sometimes even flip flops). Maybe thats why the have they work in the basement? Out of all the developers, I’m the only one that dares to ware a t-shirt more then once a month.

At Match.com, the dress code was extremely lax (I don’t even think the CEO even wore a tie). At Nortel is was mandatory for slacks and a collared shirt and a tie was recommended. When I interviewed for Mary Kay, it was required to ware more then just a tie, but everyone was heavily encouraged to ware only the best looking designer clothing.

Funny stuff…

The PS3 supporting Linux is an awesome thing. It runs under a hypervisor (similar to a client OS runs in Xen).

Well some eager folks got Myth TV working on the PS3. It’s wonderful for viewing stuff recorded on other MythTV boxes but what about recording? Well thats taken care with the use of a USB TV Tunner. You have a fully functioning DVR! How cool is that? It wasn’t for the fact I like to play movies and games, I could record constantly.

After getting of Mono on the PS3, and all the little projects that are starting up exposing people to Linux for the first time, I’m starting to think that Sony might of started something by opening this up the way they did.

Monoport.com, the mono flavored paste-bin, is back online.

Note: monoport is not powered by Mono (rather PHP), but it doesn’t have any ads like many of the other pastebins, it defaults to C# syntax highlighting, and it supports a few other neat tricks that I have added that I have found to be useful. I have some other little features coming soon when I get a few minutes to commit everything (including password protecting your posts).

ENJOY!

Second Life’s viewer is now open! Linden Labs has decided to release the Second Life client under a GPL v2 license. I’m guessing it won’t be long before the viewer gets some much needed Linux client love and speed enhancements.

Going through source, it’s amazing how clean and structured it is. I was honestly expecting that the code would of complicated it self beyond understanding by any mere mortal programmer because of the massive evolution of the product and its need to stay working with past versions over the years. Personally, C++ is not my favorite language in the whole world, but for this project it was probably the best choice because of the complexity, and the Linden Lab guys did a really great job bringing it together the way they have.

Now I’m wondering if their OpenGL based UI is portable enough to make a standalone library?

I came across this which I’m sure that many of you have seen, but it’s still worth posting:
http://blogs.msdn.com/jasonmatusow/archive/2006/11/11/your-input-requested.aspx

“I think it important for the community to know that Nat Friedman and Miguel de Icaza from Novell have been extremely clear with us that the existing covenant is not good enough - they are being excellent advocates for OSS developers. Nat, I’d like to thank you publicly for your cogent arguments and for the cooporative approch you have taken on this so far.”

GO Nat and Miguel!!!