Tue, Aug 10, 2004

Check out the trailer for Peasant's Quest! You are Rather Dashing, a peasant whose life is destroyed when Trogdor, the Burinator, destroys your thatched hut.  How much would you pay for this game?  $100? $50? $0.50?  Don't spend any money because it is free. See if you can complete it with all 150 points!  I was able to finish the game on my own but couldn't get all of the points without finding a walkthrough.

Sun, Aug 8, 2004

A couple of buddies of mine (Avi and Ken) both have Lomo cameras that they shoot with.  For the uninitiated, these are super low tech cameras that are mass produced in Russia.  There is no autofocus but instead a choice of 4 (count 'em -- four) focus settings.  These cameras are so simple and bulletproof, that using them is more of a philosophy than a tool.  The whole idea is to experiment and play.  On top of that, the lens isn't sharp corner to corner and it has quite a bit if vignetting.  That's okay -- it adds to the Lomo look.  If I still shot film, I would pick one of these up right away.  I may pick one up anyway.  In essence, these cameras are the anti-digital camera.

If you aren't willing to go that far, there is the lensbaby.  I have one of these on order.  This is a super simple lens for you SLR.  It is a single lens attached to some flexible tubing.  You focus by using your fingertips to move the lens in and out.  You can also tilt the focus plane.  This lens also has quite a bit of blur and vignetting.  And it works on digital SLRs?  This thing is so old school that you have to manually take it apart to change the aperture.  Sure, you could get the Canon EF 50mm f/1.8 lens cheaper -- and it has autofocus and an adjustable apature.  But there is something cool about the look and feel of the images form this lens.  Check out some of the photos here.  (I want to post photos but I don't want to steal anybody's images.)

Sun, Aug 8, 2004 Yesterday Rachel and I went over to the Scoble estate for a BBQ.  It was great to see Robert and Maryam.  The food and company was excellent.  The conversation drifted between geeky things (cameras, HDTV, Tivo/Media Center) and other non geeky things (jokes, BBQ technique, etc.)  I also finially met Mr. Winer -- an interesting experience.

Wed, Jul 14, 2004

If you haven't seen it yet, you should read the sad and scary story of Ian and his run-in with homeland security at the Ballard Locks here in Seattle.

Well, I was driving past the locks yesterday and telling my wife this story.  I floated the idea that it would be cool to organize a photoshoot in support of Ian.  Well -- I'm behind the curve.  Mykoleary has already organized one of these on August 1st.  I have to check but I think I may be out of town.  I'll be there in spirit at least!

Thu, Jul 8, 2004

I recently went to New Zealand.  Since it is an outdoorsy type of place I put my camelback water bladder/backpack in my big duffle bag and had a great time.  Since I'm a responsible hiker, I have a standard emergency kit in my backpack that contains things like a compass, foil space blanket, ace bandage, banana powerbars (these are so gross I'll only eat them in an emergency), etc.

Cut to me going on a hike last Monday and grab my trusty back with the kit already put together.  I wanted to put something in my emergency pack and noticed a slip of paper from the TSA informing me that they had confiscated my pack of 25 windproof matches.  If I had a scanner I would post an image of the notice.  The rule apparently is that knives must go in your checked baggage and matches must be in your carryon baggage.  Don't ask me to explain this.  Also don't ask me to explain why I can't use my PocketPC to read books during takeoff and landing.  These things cannot be explained.

So, imagine that I had gotten lost in the mountains last Monday and it started to get cold.  Normal people would have dispaired and rolled over and died.  But not me!  I was a boy scout and was prepared ("Be prepared, its the motto of the Boy Scouts!").  I'd reach in to my emergency kit to get my matches to start a fire.  Instead of finding life saving matches I would instead find a very official looking notice from the TSA letting me know that I'm screwed.

Wed, Jun 30, 2004

It's (a)live!  Look here (up on ms.com) for the 3D Graph demo that shows off the 3D demo from WinHEC that I talked about quite a while ago.  Here it is again:

I apologize that this took so long to get out here.  I've been busy and it has been interesting to get this hosted on MS.com.  I have some other similar samples coming and I think that I'll just host them here directly.  I mostly took the demo code that Nathan and Robert had and cleaned it up for public consumption.

Take a look at it and let me know what you think.  As Avalon moves forward, I'd like to keep this example up to date and add to it.

If you are interested in Avalon 3D and you haven't found his site yet, DanLehen has some great samples up and running.

Fri, Jun 25, 2004

Update: 8/29/04 -- There is an updated version of this tool described here.

If you've been a regular reader, you know that I've been having a blast playing with making digital panoramas.  The problem that I've been hitting is twofold:

1. When I want to use enblend to do the blending, I don't get the component layers in photoshop.  I get a flat blended tiff file that usually looks great.  However, if I want to tweak it I have to manually find the tiff file and import that to a layer so that I can paint the original over the endblended result.
2. PanoTools can work with 16bit files just fine but it doesn't know how to create a Photoshop PSD file.  (16 bit layers were only added in Photoshop CS.

Both of these require the fairly manual process of loading up a bunch of tif files and copying them in to one composite file with masks.

Being a dork, I wrote a program to automate this from the outside.  This is a command line utility that drives photoshop from the outside.  It would be cool if this were a plugin that would go in the "Automate" menu but I didn't have time to figure that out. It just grabs a bunch of files, opens them up one by one and puts them in to a new PS file.   This works well with the individual .tif files that PanoTools creates.  If you have feature suggestions let me know and I'll see what I can do.

In any case, here is the binary, source and license.  Please be aware that this requires the version 1.1 .Net runtime.  You can get this from windows update if you don't already.  Here is more info on getting the runtime.

Interesting notes on programming to Photoshop:

There are two ways to automate photoshop (that I've found).  The first is using "Actions".  This is the built in way to record a bunch of steps and replay them.  There is a bunch of UI for this and it is good for simple things.  Actions are to limiting for this problem as anything that iterates over multiple files or has "if" statements is super hard to do with Actions.

The second way to program is via a set of COM interfaces.  Adobe installs a type library that provides some nice object model to do quite a few things.  My understanding is that this is exposed via a built in javascript engine and via applescript on Macs.  Since COM is language neutral, you can drive it (for example) via the scripting host (JavaScript, VBScript),  perl, VB or C#.  I choose to use C#.

The programmable interface has some pretty glaring holes in its support.  For example, you can't do anything with the tools such as the magic wand.  There is also no easy programmatic access to creation of layer masks.  You can get around this by installing a plugin called the "ScriptListener."  This essentially creates funky unreadable code that (I'm thinking) uses the same hooks as the Actions code.  On windows this is written out as VB or JavaScript.  Here is an example from "c:\ScriptingListenerJS.log" to create a layer mask on the current layer.

// =======================================================
var id375 = charIDToTypeID( "Mk  " );
    var desc84 = new ActionDescriptor();
    var id376 = charIDToTypeID( "Nw  " );
    var id377 = charIDToTypeID( "Chnl" );
    desc84.putClass( id376, id377 );
    var id378 = charIDToTypeID( "At  " );
        var ref66 = new ActionReference();
        var id379 = charIDToTypeID( "Chnl" );
        var id380 = charIDToTypeID( "Chnl" );
        var id381 = charIDToTypeID( "Msk " );
        ref66.putEnumerated( id379, id380, id381 );
    desc84.putReference( id378, ref66 );
    var id382 = charIDToTypeID( "Usng" );
    var id383 = charIDToTypeID( "UsrM" );
    var id384 = charIDToTypeID( "RvlA" );
    desc84.putEnumerated( id382, id383, id384 );
executeAction( id375, desc84, DialogModes.NO );

As you can see, this isn't the easiest code to read. The solution is to wrap it in functions that you can call at will. Here is how I created a C# function out of this:

void CreateLayerMask()
{
    int id375 = app.CharIDToTypeID( "Mk  " );
    PS.ActionDescriptor desc84 = new PS.ActionDescriptor();
    int id376 = app.CharIDToTypeID( "Nw  " );
    int id377 = app.CharIDToTypeID( "Chnl" );
    desc84.PutClass( id376, id377 );
    int id378 = app.CharIDToTypeID( "At  " );
    PS.ActionReference ref66 = new PS.ActionReference();
    int id379 = app.CharIDToTypeID( "Chnl" );
    int id380 = app.CharIDToTypeID( "Chnl" );
    int id381 = app.CharIDToTypeID( "Msk " );
    ref66.PutEnumerated( id379, id380, id381 );
    desc84.PutReference( id378, ref66 );
    int id382 = app.CharIDToTypeID( "Usng" );
    int id383 = app.CharIDToTypeID( "UsrM" );
    int id384 = app.CharIDToTypeID( "RvlA" );
    desc84.PutEnumerated( id382, id383, id384 );
    app.ExecuteAction( id375, desc84, PS.PsDialogModes.psDisplayNoDialogs );
}

This is a little bit of a pain but at least you can get stuff done.  It would be cool if we could build a library of these things.  If anyone else is interested in driving photoshop let me know and I'll help bring this stuff together.

Mon, Jun 21, 2004

Vince has responded to my "Defending the Rich Client" post.

He works on writing games for Midway and has a unique perspective.  He says that the type of games that he writes are the ultimate rich client.  To a certain degree I agree, but I'd like to dodge some of that as this is a market where Avalon definately isn't targeted.

However, Vince does talk about internal authoring tools for games such as level editors and he has some concerns with how plausible it would be for someone to start taking advantage of the CLR and Avalon.  I'm not an interop expert, but here are some thoughts: 

• Add-ins for other packages.  If those packages are DLL based, you can always use MC++ to write add-ins.  With both WinForms (I think) and Avalon, you should be able to write UI that can be hosted via hwnds.  If the package is COM based, you can either use MC++ or CLR COM interop support. 
• Writing a new tool. You shouldn't have to start from scratch.  You can host windows that are written in unmanaged code in both WinForms and Avalon.  Beyond this, you can manage internal intefaces via P/Invoke, COM interop or MC++ (if you aren't happy with the current managed C++ implementation, all I can say is that the team has heard you and changes are in the works).

The next question: Is it worth it?  We definately hope so, but there is nothing stopping you from continuing to use the technologies that you are currently using.  Managed code and garbage collection aren't the solution to every problem.  There are certainly places where it does make sense to drop down in to unmanaged code, just like there are places where it make sense to drop down in to assembly.

So, if you do decide to jump, will it do everything that you want?  Vince gives an example where he can't get a specific behavior out of WinForms without dropping down and P/Invoking.  I'm not sure what is going on here, but the reality is that there are going to be things that we don't wrap or don't think of.  That is just the challenge of writing a platform -- we try to expose as much functionality as possible in as easy to program a way as possible while leaving as much room for extensibility as possible.  This is a complicated equation and we are sure to miss stuff.  To complicate things, when we move forward with something that is more than just evolutionary (WinForms and Avalon, for example) there are going to be regressions in functionality.  We may have decided to change the equation from one framework to another.  All I can really say is that we try our best and please let us know if there is something we missed.

Next, Vince looks at my 3 reasons to write rich client apps: presentation, local storage and network connectivity.  How important these are to different developers and users depends on specific circumstances.  While local storage may not be that big a deal for networking, it would be huge for an online image gallery application with a smart client interface (it looks like the guys at nGallery are eventually headed in this direction). 

One area where the web model has been ahead of the traditional Windows APIs is the ease of connecting to the network.  But it was the case where there were things you could do with Win32 (raw network access) that you can't do with a typical browser and there are things that you can do with the browser (talk http to load and display an image asynchronously) that are super hard in Win32.  Making the smart client better is all about removing these "either-or" choices and giving you the best of both worlds.

Lastly, Steve rails on the fact that it looks like MSBuild isn't going to support VC++ out of the box.  I have no clue what is going on here but stay tuned to AKipman's blog for news.

Overall, I really think that this is a healty debate and I thank Joel for getting it started.  Hopefully this gives everyone a little insight in to why we are doing what we are doing in Avalon and Longhorn.

Fri, Jun 18, 2004

It probably goes without saying, but these comments are my own and don't represent any official position by Microsoft.

There has been an interesting discussion started by Jon Udell and continued by Joel Spolsky (discussed on Slashdot). In both of their articles/postings they have referenced the interview that I gave quite a while back for Scoble for Channel 9. Dare and Robert McLaws have also responded.  My buddy from high school, Vince Anichini, wants in on the action too.

Go ahead and read them if you haven't already and then come back.

Here is my summary so that Jon, Joel and everyone else can make sure that I'm reading them right. First, Jon is asking why anyone (and the "enterprise" specifically) would want to write a rich client (probably for any platform) above and beyond a web application. Joel takes this and runs with it -- saying essentially that the rich client is dead and that the Windows API is dying with a whimper. He also says that there are two camps of developers inside of Windows: those that want to keep on the same track and those who are for all the new technologies.

IE history

Being on the Windows team, and Avalon specifically, my job is to help write a product that is compelling enough to overcome the very valid concerns that these guys have. I started out on the IE team (now you know where at least a little bit of the IE team went, Joel) back in 1997 -- toward the tail end of IE4 development. I firmly believe that we had the better product starting with IE4 and we really turned up the heat with IE5. IE was, in a lot of ways, a rear guard action against Netscape. Netscape was trying to replace the Windows API with a cross platform "Netscape" API.

IE was, buy many metrics, very successful. First, we gained significant adoption. I personally think that this was mostly due to a superior product.

Second, we also, by making the browser market a 2 horse race, drove baseline interoperability in the web space. Where would the world be without IE? Do you think that we would have an interoperable browser space now? Based on pure psychic reasoning, my guess is that without the healthy competition from MS, Netscape would have owned the client space completely. At this point I don't think that anyone owns the web client platform. Despite IE's market share, the network addressable platform pieces that anyone uses are largely restricted to the W3C blessed parts. So, taking a look at the IE4 and IE5 timeframe, in some ways you can thank Microsoft for enabling a mostly standards based web by making the browser a two horse race.

Where IE wasn't successful was in bringing the Web model in as a fundamental part of the Windows API. Sure, you had the reusable browser control and the Trident (mshtml.dll) engine. But you were either writing a web-like application (HTAs included) or you were writing a Win32 application. There were certain things that were easy to do with traditional Win32 that you couldn't do with IE and things that you could do easily with IE that you couldn't do with Win32.

The best of windows and the best of the web

Avalon, and Longhorn in general, is our attempt to reenergize the rich client at Microsoft. Is it, as Joel says, too late? I don't think so. I think that the combination of features we are putting together will be compelling enough to start turning the tide. Are we ever going to see a world where the web is history and all development is focused on writing Longhorn applications? Of course not. Longhorn is a long term investment to start laying the ground work for a rich client that takes advantage of the web in a way that we have never been able to before. This is what we mean when we say that we want to make Avalon the best of Windows and the best of the Web. We want to take some of the advantages of the web and build them in to the windows API.

Why do people write web based client/server apps over writing rich client apps for Windows?

1. Frictionless deployment story
2. Cross platform interoperability
3. More fun to code -- you can set up your own API system and abstract HTML to a large extent
4. Built in network/server awareness

You put all of these together and you have a pretty darn compelling story for many scenarios. How can the Windows client compete with this? The key is to take the good things of the web that we can (1, 3 and 4) and combine that with all of the goodness from having stuff run on the client. Don't get me wrong -- I still believe in the web as a way to interoperate and exchange content and as a lowest common denominator for UI interaction. But we can do so much better than HTML with the horsepower that is sitting on our desk when it makes sense to do so.

For example, Joel says that he can "install" GMail by hitting Ctrl-D, gmail, Ctrl-Enter. My understanding (and I haven't had time to really play with GMail yet) is that Google has written browser specific code to enhance the user experience.

With Avalon you should be able to implement a GMail like application that takes advantage of the rich client in some very significant ways:

1. Rich user experience.  No page refreshes on simple actions.  Smooth animation and graphical composition.  The ability to do rich real time data visualization.
2. Local Storage. Cache the mail data locally for faster access and more integration with other desktop services.  You could also support reading and responding to mail while offline.
3. Easy network connectivity.  Using web services, the ability to use widely interoperable protocols to talk with a server.

Will this be possible in Longhorn? YES. This is the direction that we want to go and what I mean when I say "network connected rich client applications." We aren't replacing the web or the web paradigm. We are instead providing the platform so that it is easy -- and worthwhile -- for developers to differentiate when their applications are running on Windows.

But what about the enterprise?

Now, to get to some specific points brought up in the articles. Jon brings up some good points around the enterprise space. I can only say that we are working hard to build a package of features on the client that will either make enterprise developers willing to standardize on Longhorn or take the extra cost to provide a rich client solution in addition to a web based solution. There are some applications where this will never make sense.

However, there are a set of applications that are currently being implemented on against today's web clients that could be vastly improved by rich client capabilities. I can definitely see a need for a rich expense reporting application with a good offline mode and rich display and reporting. Anything that involves charting or graphing can also be enhanced by using some rich client technologies. I use Outlook every day to do email. There is a web solution for Exchange called "Outlook Web Access" (OWA) that uses DHTML and all of the other web goodies to provide as good an experience as possible through the web client. While I think that OWA is great and I'm a huge fan of what those guys are doing, I'd still much rather use the real Outlook.

With Avalon we are hoping to make it vastly easier to write rich data connected applications like Outlook. However, we don't want stop there. We also want developers to be able to get the best of the web. These applications can run in the browser for the browser experience or can be "one click" installed and run on the desktop.  Even when they are "installed" they can be managed from the server and be kept up to date as easily as copying a new version on to the server. Think of how many enterprise LOB apps could benefit from that? Expense reporting (with offline mode), "Digital Dashboard" data aggregation and visualization, integrated content creation, new network connected collaboration applications and more. 

Backward compatibility

Now, talking to some of Joel's points: He says that we have fundamentally changed our view of backward compatibility. I totally disagree. As one Slashdot poster put it: "Joel confuses binary compatibility with API compatibility." From the end users point of view we are still completely committed to making apps that run on Windows continue to run on Windows. At the PDC, Jim Allchin showed off Lotus 123 Visicalc running on Longhorn. The developer experience, however, will have a gap -- it is necessary as part of the transition to managed code. He states that VB.Net not being source compatible with VB6 is a first. I would argue that the switch from 16 bit to 32 bit is very similar to the switch from unmanaged code to managed code. Old apps will continue to run and new apps are written to the new technology.

In Avalon we are working very hard to provide rich ways for application developers to tie their old code in with new code that takes advantage of our new technologies. You can host a Win32 hwnd -- WinForms based or not -- in with Avalon content. You can also host Avalon content in a Win32 hwnd. You can nest these completely. While it is true that you have to write new code to get the new features -- and that the new code is part of a completely new framework -- we don't want to force application developers to rewrite everything to start using our stuff.

Above and beyond what Avalon has been doing, the C++ team has heard what the community has been saying and is doing some great work in Whidbey to make the managed version of C++ better than ever.  It will be the best solution for those who have the C++ code and skills and want to start taking advantage of the the CLR.

What's a $300B (market cap) company to do?

The real question is: What are we to do? Without arguing about the fine points, we are stuck with a choice. We can either continue adding doodad on top of doodad to Win32 (and maintain backward compat from an API and binary perspective) or we can try and make a fresh start with WinFX and set ourselves up for the future. Look at the timelines: Windows 1.0 with the start of Win16 came out in 1985. Windows 95, with the mainstream advent of Win32 came out in 1995. It is now 2004.

Now is the time for Microsoft to either watch the Windows rich client sail in to the sunset or to do its best to reinvigorate it. The only way to make this happen is to go "all-in" and think big. We want to empower developers by making a much richer, network connected and modern API for programming on windows. WinFX is all about taking what we've learned over the last 20 years and creating a solid platform for the next 20 years. We will provide the right API, backward compat for old applications and a great bridge between the two for developers. If we really want developers to write code that only runs on windows, we have to provide features and enticements that they can't get anywhere else. While I don't think that it is too late, I do think that we have our work cut out for us.

Mon, Jun 14, 2004

Since writing the article in the Luminous Landscape, I've run across Max Lyon's forums covering all things pano.  Cool stuff I've discovered or been alerted to:

• A really sweet cheap DIY pano tripod head using 8020 aluminum extrusion stock.  I built one of these last week and it works great!
• Autopano -- a helper to automatically find the control points for panotools.  PTAssembler can be set up to call this directly.
• Enblend -- a tool to automatically do the blending between images based on the spatial frequency of the image at the seam.
• Hugin -- a free (as in speech) appliaction for driving PanoTools.  There is also an experimental replacement for PanoTools called nona.  I haven't played with this yet but it is interesting to see this stuff develop.  If this weren't GPL'd and similar to my real job, I'd love to get involved and write some code.
• nGallery -- I installed this on an ASP.Net server and I'll be posting some new pictures soon.  It was super easy to get up and running and looks configurable.  This is something that I could get involved in and write some code.

Hopefully I'll have some example panos put together using the new setup soon.