Marlon of Macedonia implemented GDI+ C++ API on top of AGG2 (Antigrain Geometry, a high performance portable anti-aliased 2D graphics library).  Announcement and discussions about the wrapper can be found at Antigrain mailing list.  ZIPed source code is available here.

Note that it's not a full implementation of GDI+, just the parts Marlon uses.  Still, I think the chances are good that most of the API you need is covered by Marlon's implementation.  If not, you can join hand with Marlon to fill in the parts you need.  The result will be better and faster graphics for your GDI+ application.  I hope others will port this to .NET soon.

Egad.  Thanks to Michael Champion, I am reminded of the fact that it's been five years since I took a joke seriously and started a riot that lasted years and produced a couple of XML subsets and launched other XML simplification projects like YML.

Why did the riot called SML-DEV eventually die off?  Well, we got sick of XML too early.  It took five years for complaints from the general developer community to gather enough mass.  Five years ago, it was just us (so called XML gurus) worried about ease of use and complexities.  Now it's real world practitioners, people we were worried about, complaining about their bruises.

I have no regrets about diverting hundreds of XML gurus, loving called Simpletons, off W3C's official XML bandwagon.  I met great bunch of smart folks and I had fun.  Also, our simpleton memes spread far and wide, affecting many XML formats created since then.  Besides, I am a born troublemaker and I was doing what I was born to do.  Fishes swim.  Rabbits hop.  And skunks…well…I think you know what I mean.

What I do have regrets about is the DOM API.  Although I participated in the W3C DOM activities and implemented the DOM several times to make sure people had some chance to bang on the API before it went final, it wasn't until much later that I realized how lame the API really is.  It's practically unusable without a thick coat of helper functions.  The fact that I took part in building of that lemon makes me feel really really sorry.  I must have been blind and stupid to not see how ugly and useless it is.

To the geekdom, I offer my sincerest apology for the mess I helped create, the DOM API.

The preview of one of my ideas, which I mentioned recently, will have to be delayed.  Instead of a preview, I am going to flesh it out with the help of a team of developers and launch it as a beta quality service a few months down the line.  Sorry about that.  I do have another idea I might make public soon, hopefully in a few weeks, called dropfeed.  So stay tuned.

This is what is going on in the P2P world this moment.  BitTorrent is the king of P2P world.  BitTorrent download rate is one to two order of magnitude faster using BitTorrent than other P2P technologies.  For example, what typically takes a couple of weeks to download via eDonkey2000 takes only half a day to download via BitTorrent.

Unfortunately, torrents are not easy to find as other P2P technologies.  So if you want to download something in particular, you have to google around or find some BitTorrent search site.  Since BitTorrent is most effective at the very edge of what is hot and Google is not so hot in that space, you are out of luck unless you are a member of a hot BitTorrent site.

The ideal solution would be to distribute BitTorrent seed files on other P2P services such as eDonkey or Gnutella but those services currently don't handle indirections too well.  Once they do, the flood gate will open and it won't be just RIAA screaming but the Hollywood itself.

If you are a Win32 developer, this article on the scarcely undocumented firewall hook might interest you.  Unlike the network filter hook which supports only one system wide hook, multiple firewall hooks can be installed to monitor network packets.  Neato.

Looks like Microsoft's battleplan for Passport is in full retreat.

Several years ago, I integrated Passport with 3D-Secure so online credit card users can use Passport to approve online credit card transactions.  It worked well and some banks expressed interest but nothing came of the project because of all the bad press surrounding Passport.  Of course, Passport guys didn't help much either other than complaining about their cost and getting pushy with .NET adoption.

I also designed a P2P payment system on top of it but, thankfully, never got around to building it.  Otherwise, I would have been pretty upset by now.

The good news is that a class of vulnerabilities in Passport prompted Microsoft to add HTTP-only cookie support to IE.  Hopefully, support for HTTP-only cookie will become ubiquitous in the near future.

Tim Bray equates phishing websites to crooks in plain sight which makes no sense and asks what he is missing.  Well, Tim.  They are not crooks in plain sight but stolen getaway cars.  Those websites are either zombies*, parasites*, or simply setup with stolen credit cards by crooks.

Phishers populate phishing websites with pages that mimic financial websites and a CGI that forwards submitted passwords and credit card numbers to a public channel such as newsgroups where crooks can recover the goods without leaving traces pointing back to them.  To prevent others from stealing the goods in transit, they either encrypt them or hide them inside multimedia files.

Fortunately, there are no efficient market infrastructures for stolen authentication devices yet.  So phishing currently impacts customer support most severely with each phishing attack generating high number of calls and emails for the targeted financial service.  But spear phishing** is expected to change that in the near future.

If you are interested in anti-phishing technologies, take a look at PassMark Security which offers a simple yet elegant solution.

Disclaimer: PassMark is a client of mine.

* I prefer to differentiate zombies from parasites by defining zombies as compromised home computers with broadband connection and parasites as hidden webapps running inside compromised public websites.

** Spear phishing is where, instead of targetting millions with generic attacks, phishers target just a handful of rich individuals with designer attacks based on target-specific information.

I installed Google Desktop Search (GDS) yesterday morning.  First thing I was impressed with was the size of the thing: 400K.  As a developer, I know how difficult it is to pack that much functionality into just 400K these days.  Of course, if it was 20 years ago, I would have howled about the 'huge' footprint.

I uninstalled GDS 8 hours later when my laptop reved up like a car with stuck accelerator.  I was using Eclipse at the time so this version of GDS must have faulty idle detection algorithm.  Since I don't enjoy writing code inside a jet engine (my laptop's two fans make a lot of noise when they are going at full speed), I uninstalled GDS to wait for a better version.

The problem with desktop search is that, while the file system, email archives, and browser cache offers extra metadata, there are no hyperlinks among desktop documents.  Without hyperlinks, you can't do page ranking Google is famous for.

The only advantage Google has over other desktop search is tight integration with their website.  While some people seem to be impressed with seeing the word 'Desktop' added to the Google homepage, I think the tight integration and blurring of the line between the Web and the desktop will result in confusion and concerns with little gain for Google.

The core problem here is that search engines like Google throws everything into one pot.  For web search, all the web pages on the Net gets thrown into that pot.  Thankfully, hyperlink-based pageranking pulls the good stuff to surface with minimal hassle.  With desktop search, all of your documents gets thrown into the pot without an equivalent of page ranking to measure relevance.  IMHO, there aren't enough metadata on the desktop to achieve the same level of utility Google web search offers.

Also, there is a problem that will surface in the future as desktop search over browser cache becomes ubiquitous: desktop spam.  Websites will begin loading up their webpages so links to their websites will appear in desktop searches and, without page ranking, they will find it easier to catch the desktop searcher's eyes than web searchers.

Whether desktop search is a killer-app for the user or not, I have doubts whether it is a killer-app for Google.  If they start showing ads on desktop search result pages, many users won't like it.  If those ads are context-sensitive, meaning they are based on words in YOUR documents, even more users will howl.

I have other issues and possible solutions but I want to think them through before sharing them.

I just wasted a couple hours fiddling with IIS 6's HTTP compression to fix my feed.  The trouble originally started when I noticed static files being served compressed by IIS 6 when the file size grew beyond 30K or so although I didn't turn on compression.  Since some news aggregators can't read compressed feeds, I looked for ways to disable it.

Googling led me a set of tags inside the metabase.xml file and I set all compression related parameters to FALSE and restarted IIS.  Initially, this seemed to fix the problem but after a few minutes, the background compression service kicks in and I am back to where I started.

The annoying part is that IIS serves up gzip or deflate encoded content even when HTTP header Accept-Encoding is missing or empty.  I'll have to pore over the HTTP specs to see what the behavior is supposed to be but this doesn't make sense.  My guess is that HTTP.SYS's memory cache code is not bothering to check the header.  Another crazy symtom is that the involuntarily compressed feed sometimes appear as blank pages on IE.

I am just going to let this problem drop for now because I got work to do.