Foo Infusion

A periodic infusion of foo from the world of a junior developer

Saturday, April 29, 2006

Getting Serious About Testing

I had a brief discussion with the guy who's sort of in charge of my project this week. The basics of the beef center around the support network the my company has [not] set up for my development team. Among other things, I am upset because our QA team isn't doing enough automated testing.

Here's a message to all you project/product/development/team managers out there. Your developers find it insulting when you don't take their work seriously, and choosing not to perform proper QA is one of the surest ways to get them to feel this way.

The rationale goes a little something like this:

"I do good work. If my company recognizes that I do good work, they will ask me to do important work (important as in 'important to the business'). If the work that I'm doing is important, my company will support me (with QA, among other thigns), so that the products I produce are the best products they can be. If the work that I'm doing is not important enough to do proper QA on, get me working on something that IS important - I want to be working on something that IS important. If I'm not doing important work, my comapny must not feel that I do work that's as good as I think it is, and they don't want me to do important work. If I'm not doing important work, I don't know why I'm doing anything."

We do automated unit testing (although we recently broke that part of our build process and are in the midst of redoing that stuff - it is there though) but it's no excuse for automated acceptance testing. I suspect many mangers don't realise the difference.

Thursday, April 27, 2006

The Truth About Darwine

So I've discovered a few things about WINE that I was didn't understand before.

In my last post I was all gunned up about how WINE should be able to use the actual Windows DLLs right off the Windows CD to provide it's functionality.

As it turns out, you CAN use the original Windows DLLs, which I would have known if I had actually read the introductory paragraph on the WineHQ homepage. Obviously, Wine's goal is to create a 100% MS-free solution, but in order to make their product usable in the interim (while this 100% MS-free thing is implemented) they have also provided the facilites to use the Windows DLLs. Smart.

The process for doing this is described here.

Still, I think my original idea was/is on the right track.

I think that something that would really make Darwine successful on Mac OS X/x86 is a Windows CD DLL extractor/wizard. I think it would greatly speed up the adoption rate of Darwine, by making more things work sooner.

The extractor would work by running either along with the Darwine installer or after Darwine's already been installed, sucking all the DLLs it can out of a Windows install CD, and replacing the equivalent Wine DLLs with the 'native' Windows versions. Maybe it would present you with the option of sucking the DLLs off the CD, but still trying to use the Wine DLLs first, and then if you experience problems you can flip on the Windows ones. I don't know.

If I had a machine to do some playing around on, this is something I would be working on.

Tuesday, April 25, 2006

Darwine, Parallels, BootCamp, when will it END?

I've been thinking a lot lately about this whole "Windows on Macintosh Hardware" thing lately.
Really I guess I've been thinking about how terrible the current solutions are.
I think I have a better solution but I have no idea how one would go about implementing it, or even if it would be legal. But I think it's doable, at any rate.

Right now there a few things going on in this space:
  • Apple is obviously thinking about people who want to use Windows software on their Mac hardware. BootCamp, I think, is only one piece of Apple's game plan. Lots of people have been discussing Apple's possible moves in this regard, so I won't go through everything. Here's some pointers though: Cringely;Shute;Gartenberg;Daring Fireball-#1;Daring Fireball-#2;among many others.
  • Parallels has released their products to allow virtualization, specifically aimed at Mac users that want to use Windows on their machine.
  • There are other virtualization options, like QEmu and VirtualPC - maybe VMWare will get into the fray as well.
  • Darwine has been gaining steam - attempting to utilize the Wine project's attempt to re-implement the entire Win32 API (in a portable way so that any OS can run applications that rely upon it), adding some Mac OS X specific stuff to make it look better and work better/more cleanly.
  • Mono has also had some great advances over the past few years, attempting to re-implement the .NET runtime in a more portable way, so that any OS can run applications that rely upon it.
While all of these are pretty great ideas/products, none of them really get at the heart of the matter (running applications that were developed for Windows to run on Mac OS X) with quite the right mix of performance and ease of use.

Apple's got a neat solution of providing a neat dynamic disk partition tool, and a fancy bootloader. Neat as in 'intersting', not neat as in "tidy". Anyone who really needs to use a Windows app will quickly tire of rebooting, and being stuck using a crappy FAT32 partition in order to share files between the two OSes (not to mention the indiosyncracies that have already been reported with respect to the partition tool and the bootloader). While it's probably a good move for Apple, it's probably not the best long term solution for users. Again, I think Apple's really just testing the water with this one, and it will be interesting to see exactly where they're willing to take this in the future, but for now we can file this away in the "good, but not quite right category".

Virtualization is also a pretty nifty solution, and I think there will always be a market for real machine virtualization technology - it's been employed by many an enterprise for years to do server virtualization, for example. (Beneficial, as when the VM goes down, but the hardware stays up, and can even safely restart VMs for you, plus it runs in its own address space like any other process, and can't mess other things on the machine up).

Still, for regular users who don't need to have virtual machines for this type of enterprise separation and protection, the idea of having Mac OS X, all your own apps, PLUS a full Windows install, PLUS whatever app you're running in windows, seems terribly inefficient to me. There is no need to have ALL of windows running, hogging disk space and memory and sweet sweet processor cycles and precious little video card resources. (PS, if you think XP is a hog in this regard, just wait till you see what Vista can do to a machine's resources). Not to mention that issue of dealing with partitioning hard drives, filesystems' respective pros and cons, space limitations, security, etc)

Which nicely brings us to Wine/Darwine, and Mono. This is also a neat idea - probably the best idea we've looked at yet - and I give both projects' founders and contributers the hugest props both for taking this on and for being unbelievably successful at it. This approach achieves much better performance than VM style stuff, allows for neat applications-sharing-resources stuff to work that couldn't possibly with the bootloader approach Apple has taken so far, and can probably overcome most of the ease-of-use stuff with a nifty installer and some diligence.

The problem I have with the re-implementors (Wine/Mono) is that they are re-implementing. They're redoing something that's already done. And this approach doesn't stand a chance at keeping up with what Microsoft is doing with Windows and it's APIs.

I really don't understand why, from a technical standpoint, it isn't possible to simply create an environment for applications to run, that actually USE the DLLs from the Win32 API and the .NET runtime, right off the Windows CD. Rather than re-implement it, why not actually use THE reference architecture, and just get on with it.

I'm suggesting something along the lines of an application that could find all the files it needs on the Windows install CD, and pull them out, and place them somewhere sane in the host OS, which could then allow apps to call directly into the Windows DLLs, and either provide some kind of abstraction layer between the Windows DLLs and the hardware, or allow the DLLs to run in some type of sandbox that would grant them direct hardware access. This approach would be very fast as it could run directly on the new Intel hardware, and it would be a reliable implementation as it would be using the reference architecture that the apps were created for/with.

This is essentially what Apple did with the Carbon API, to allow 'classic' applications to run (in a slightly retooled fashion) directly in Mac OS X. It was a little slower due to the abstraction, but it was fine for most things. And it was MUCH faster than running something using the "Classic" virtual machine environment.

Now, admittedly, from a technical standpoint it may be doable, but I really have no idea how this would be accomplished. I, personally, wouldn't have a clue where to start.

Legally, I think there could be a number of pitfalls to this idea, and that is perhaps why it hasn't been attempted (to my knowledge). Apple would never be able to take this on. The open source community could probably take this on though.

Wil Shipley did a piece a while ago about how Darwine is the future for this stuff, attempting to incite young developers who feel like they have something to prove (*ahem!*) to get on board and help out. And I think I'm there. I would like to have a discussion about this with someone knowledgeable about all of this first though.

UPDATE: Some reading on the WINE site revealed to me that they CAN in fact use the Windows DLLs directly, though I haven't found the prescription for actually getting this done yet.

All of this ignores that fact that people don't buy Macs to run Windows programs, nor should they. It's a bonus for some people, but it won't make a difference to many users.

I for one wouldn't want Windows apps, with all their bizzare registry expectations, individual file management conventions, individual UI behaviour, completely path based file access, user permissions model, etc, etc, etc, to get in and bugger up my nice Mac OS X install.

Sunday, April 23, 2006

Daring Fireball wieghs in on the Great Kernel Debate

In the post I made about Mac OS X's kernel and Cringely's first mention of it, I basically said that eventhough the monolithic guys (Linux, esp) are all about getting down on Apple (XNU & Mach specifically) for being different, and slow, Apple should still consider themselves in a good position for innovation and technical acclaim. Plus I'm all for microkernels anyway.

Tech writer (newly full time!!) Daring Fireball has just published a few of his ideas on this topic as well. While I mainly avoided Cringely's article in particular, DF goes straight for the meat and makes a lot of the points that I hinted at, and many I didn't even see. For some great commentary on this subject, (plus a sweet geeky ink to a Linux kernel development forum thread that discusses this very thing from a slightly higher level), check out his article.

Look for much more from Daring Fireball, as he's recently taken up producing his blog as his full time job.

Friday, April 21, 2006

Ben Goodger on Fighting With Windows (Foo #1!!!)

The great Ben Goodger has run a series of short posts recently about his fight with his development laptop, and the Windows installation on it.

I found these articles particularly relevant, as I've spent these last days rebuilding the Windows install on my machine here at work.

As I see it there are a few issues at play here.

  • Removing software from Windows SUCKS.
  • Installing Windows SUCKS.
  • Companies are building hardware that SUCKS.
The biggest issue for me, while rebuilding my machine, has been the installer.

First of all, an OS should most certainly not simply degrade to (as Ben says) "useless"-ness after time. Any amount of time, really. Maybe it needs repairing sometimes, maybe that's even often if you're a heavy user - but this attitude of rebuilding the machine everytime the OS gets too foobar-ed to continue serving usefully has got to go. (For the record, OS X has a ways to go in this regard as well, but it's certainly better than XP)

The Windows XP installer is the biggest piece of crap I have ever used. It looks terrible (640x480 display with 256 color graphics, monospaced fonts), it behaves badly (it does things that take hours to complete with nothing but a small green progress bar to tell you what's going on, and it reboots without telling you it's going to do it or why MULTIPLE TIMES), it makes you feel stupid by expecting you to know what's going on and what options you want to choose, and it doesn't give you the functionality you need in an OS installer (disk partitioning, reformatting, etc).

Actually it does let you do some of that stuff, and even lets you do some nifty 'repair' things too, but it does it in a 'curses' interface that looks even worse and it even harder to use than the XP installer described above.

I could go on forever about my own problems and the shortcomings I see in the hardware and software I use from day to day, but Ben does a good job with his gripes too, so go check him out.