Archives / 2007 / June
  • ScriptDoc 1.0 available

    ScriptDoc is a tool that extracts documentation from JavaScript files and packages it into XML files that can be consumed by documentation building tools such as Sandcastle. The 1.0 version is now able to extract documentation from doc comments as well as from the structure of the code itself. It generates a documentation file that uses the same format as C# doc comment files and a reflection file that describes the structure of the object model and that follows the same schema that Sandcastle is using.

    It is available under a Microsoft Permissive License on Codeplex:


  • Outlook pst file repair tool

    Yesterday, I was doing some mailbox cleaning after a week away from the office taking care of my family (that now counts one more little girl), and I suddenly got unable to move e-mail from the inbox into folders (a message was telling me the message was already gone even though I was staring at it). Restarting Outlook or even rebooting didn't help. Despite the sleep deprivation, I immediately suspected .pst or .ost file corruption.

    One thing I learned from previous calls to support about Outlook is that there is a little known utility that ships with Office and that restores pst and ost file corruption. Scandisk for .pst if you want. You can find it in Program Files\Microsoft Office\Office12 and it's named "scanpst.exe". The icon is a broken enveloppe.

    The utility only took a few minutes to scan my pst and ost files and restore them, and shazam! I can now move my e-mail around normally.

    Oh, and by the way, if you don't know where your .pst and .ost files are physically stored, it's very easy to find if you know where to look. In Outlook, right-click on the personal folder icon, choose "Properties" (should be the last item in the menu), then click the "advanced..." button and there it is:

    Hope this helps.


  • IE6's main memory leak hot-fixed

    I just learned through Ajaxian that IE6's main memory leak has been hot-fixed two weeks ago through Windows Update.

    So what does that mean for Ajax developers? Well, it becomes a little less important to dispose of any circular references you may have in your code: when the user navigates away from the page, that memory will now be freed.

    But if your users are going to stay on the same page for a while, and objects are going to be created and destroyed frequently, the memory occupation of your application is still going to raise steadily if you don't properly dispose of those circular references. For example, the following code still leaks on IE6 and 7:

    function createDiv() {
      var d = document.createElement("DIV");
      d.expando = function() {
      window.setTimeout(createDiv, 5);

    window.setTimeout(createDiv, 5);

    The same code on Firefox 2, Safari 3 and Opera 9 shows stable memory occupation after warmup.

    So in a nutshell, it's good that this got fixed (kind of), but it really doesn't change anything for Ajax developers: it's still important to dispose of event handlers and other expandos as you destroy objects and DOM elements.


  • Why Safari for Windows looks like a Mac application

    One thing that really stands out in the Windows version of Safari is that it's exactly identical to the Mac version, almost down to the pixel level. That must have been quite a pain to achieve, and it would probably have been way easier to use the OS for many things. Does Apple really think PC users will go "gee, that Mac UI is really sweet, I think I now have an uncontrollable urge to buy a Mac"? Probably not.

    So here's my hypothesis:

    Safari for Windows is not intended to take over the Windows browser market, nor is it a showcase for the wonderful-mac-ui-that-if-only-we-knew-it-would-make-us-all-switch. It's an emulator.

    Its one and only purpose is to make sure that devs who work on PC can build apps that will run on the iPhone and on the Mac. Especially the iPhone: when you have relatively little screen real estate, making your UI fit is no easy task, and the closer the browser on your dev machine is to the real thing, the better.

    So here's my bet: when the final version of Safari ships, it will have an option to emulate the iPhone.


  • Is Safari on Windows a good thing or a bad thing?

    The first thing most web developers probably thought this morning when they learned about Safari for Windows was "oh man, yet another browser to test in". And yes, for the moment, that's what it amounts to. Coincidentally, I have spent a good part of last week making the history management in Microsoft Ajax work in Safari 2.0.4. I got it to work fine (after much Apple cursing), so the first thing I tried after I downloaded Safari 3 beta was my history tests. And sure enough, it breaks in new, unexpected ways. History management is pretty much a big hack that is different on about all browsers (Firefox and Opera are the nicest ones here, with predictible, similar behaviors). And sure enough, Safari 3 brings a totally unheard of model. I didn't find a way yet to create a new entry in history from script that doesn't navigate away from the page. None of the old Safari tricks work anymore (they were probably and rightfully considered bugs and were fixed). They weren't replaced by the more rational things that work in Firefox and Opera. Even the iFrame trick that we use on IE doesn't work because Safari now crashes if you try to dynamically add a frame to the DOM. If anybody here found a way to do that, I'd love to hear about it.

    But there is at least one thing to like about this new version: Apple is going to release it for MacOSX Tiger (the current version of their OS), which means that thanks to auto-update, the horrible, horrible browser that is Safari 2.0.4 is going away in the not so far future. When I say that it's a horrible browser, that's entirely from an Ajax developer's perspective. Your mileage may vary, but the latest Webkit, even with its flaws, fixes the most serious problems that plague Safari 2, and the new Safari 3 is based on that better codebase.

    Another thing to like is that it seems like the behavior of the browser on Windows is very very close, if not identical, to the behavior on MacOS. That doesn't entirely remove the need to test on both platforms, but at least it promises to make it possible to automate test runs on all Windows browsers as part of your integration process. This way, you'll catch most Safari regressions earlier, and that's only goodness.

    So sure, it's never fun to have yet another browser to test, and this release has its problems that hopefully will get fixed (I filed several bugs already today, and the total lack of error feedback doesn't help), and others that probably won't (why can't they respect the conventions of the host OS?) but I'm convinced that in the long term, we'll all benefit from this move from Apple. But there may be a few difficult months ahead of us as we work around new Safari 3 bugs and still have to work around old Safari 2.0.4 bugs.

    What do you think?


  • Photo Album works on Windows Home Server

    I was super-excited to learn that Andrew Grant was able to run the Photo Handler unmodified on Windows Home Server. This is actually one more reason for me to put Home Server on my to-buy list. I shoot thousands of pictures a year and only upload the very best on Flickr. But the reason why I enhanced Dmitry's handler to make it my own was that I wanted photo publishing to be as simple and as fast as possible, and a natural part of my workflow. Today I'm using a small web server that I built and that sits in my basement so that I can just dump photos on the server using a simple share but using Home Server for that would just rock. Anyway, if you have a Home Server and want a lightweight way to publish your photos, this is for you: