There were a number of announcements at TechEd US last week with many status updates on forthcoming products. Bruce Kyle has written up the list on the US ISV DE blog. It’s interesting to see the ramp-up for Windows Mobile 6.5 beginning with the launch of registration for the Windows Marketplace for Mobile and an announcement of support for the latest draft of the W3C Widgets spec. In fact, there is a Windows Mobile Ramp-Up track on MSDN to facilitate learning about mobile development.

One aspect I’m particularly interested in exploring is the Windows 7 native support for the ribbon UI. This is something I’ve been investigating for a while for a side project and so I’m considering limiting myself to Windows 7 for now so I can take advantage of this control. As I understand it, the plan is to provide support for Windows Vista around the time of Windows 7 RTM.

The release of a beta of Virtual PC for Windows 7 allows Windows XP applications to run in a way that integrates them into the usual Windows desktop without it being obvious that an entire second copy of Windows is running. Virtual PC on Windows 7 requires hardware virtualisation and I was looking for a quick way to determine whether that is supported on any given PC.

SecurAble by Gibson Research Corp supports both Intel and AMD CPUs and tells you simply whether the processor is 64-bit capable, whether it supports Data Execution Prevention technology, and whether it supports hardware-assisted virtualisation.

I have an old printer. Very old. It’s an Epson EPL-5500 and I got it in about 1995/6 and it has served me well ever since. Soon I might need a new printer – soon I won’t be able to get toner cartridges for this one – but for now it is fine. It worked fine in Vista but now that I’ve decided to enter the 64-bit world with Windows 7, I need 64-bit drivers and they don’t come with Win7. After all, who still uses a printer that is more than a decade old?

My printer is connected to my Windows Home Server and I know that server operating systems have the ability to host drivers for the printers they share so that when you connect to the printer, the driver is downloaded. Using Remote Desktop to connect to WHS, there is an Additional Drivers button on the Sharing tab of the printer properties.

WHS is based on Windows Server 2003 so it doesn’t intrinsically know anything about Windows Vista or Windows 7. It does know about 64-bit Windows XP, though. By default the x64 checkbox is unchecked and the driver isn’t installed. When you check the box, you’re prompted to enter the DVD containing the driver. Unfortunately, WHS is 32-bit only so inserting the WHS DVD doesn’t help. I found a copy of Windows Server 2003 64-bit on an old MSDN DVD and used that to provide a copy of the 64-bit driver. This gives me a ‘Yes’ in the Additional Drivers dialog and now I can connect to the printer from Windows 7. When I do, Windows prompts me to elevate permissions so that the driver can be installed and all is well.

Windows Home Server to the rescue again (sort of) and now all my Windows 7 PC’s will be able to print again.

Yesterday, a note was posted on the IE blog about the “hang recovery” feature in IE8 on Windows 7. During testing, it was found that the timer used to determine if a tab in IE is not being responsive was found to be a little too sensitive on some people’s computers, especially while using the built-in developer tools.

Today, two updates for IE8 on Win7 RC are available through Windows Update. The first is the expected “compatibility list”. Since IE8 (and Windows 7) ship with an empty compatibility list, one needs to be downloaded after first install. The second update is one to mitigate the issue of seeing the “webpage is not responding” dialog too frequently. The updates are both rated “Important” and it’s recommended that you install both updates.

Yesterday, I started experimenting with building a simple application using the .NET Compact Framework v3.5 and Visual Studio 2008. It was pretty simple to get running using the emulator after downloading and installing the Windows Mobile 6 SDKs (make sure you get the Refresh).

As part of the SDK install, you are reminded that you will need to install the Windows Mobile Device Center (WMDC) application in order to connect to a real device. Since I am running Win7 RC, I was a little nervous about this. I remember trying to install ActiveSync on Vista and getting in a mess before discovering you needed WMDC instead. I assumed that Win7 would come with WMDC but since the SDK couldn’t see it I gambled and installed anyway.

After getting a simple application running with the emulator, I decided to try it on a real device. Connecting my phone with a USB cable, I ended up with Win7 detecting and then losing the connection and then re-detecting over and over every few seconds. I am not sure what went wrong but I guessed that maybe installing WMDC had been a mistake so I tried uninstalling and then reconnecting the phone. This time the driver for the phone downloading from Windows Update stalled.

I found a post on the TechNet forums from someone at Microsoft describing a driver install issue with Windows Mobile and the Win7 Beta. Although I would have expected this issue to be resolved by now, following the instructions to remove the RNDIS driver and then re-installing WMDC did the trick and on the third attempt the phone was detected and the drivers correctly downloaded and installed.

I’m not sure exactly what the problem was and I hope that either I was just unlucky or that this issue is resolved before Win7 ships. Now that I can connect to the phone from Visual Studio, the next step is to deploy my test app and ensure it works on the device.

Update 8 May: Today, I just plugged my phone into a different Win7 machine and it automatically went off and downloaded everything it needed including Windows Mobile Device Center and everything just worked. I guess I went wrong before by trying to preempt what software I needed to install based on the SDK messages. Just plugging in the phone would have given me what I needed.

I’ve been running builds of Win7 on my 1525 for some time after doing an in-place upgrade from Vista 32-bit to the Win7 Beta. We recently announced that we won’t support build to build upgrades from Win7 Beta to Win7 RC (which will be available to MSDN/TechNet subscribers tomorrow) I could either revert to Vista and do another upgrade or install from scratch. I decided to take the opportunity to move to 64-bit and since that’s not possible when doing an upgrade from 32-bit Vista I installed from scratch. Although all the hardware was successfully detected, this left me without some of the Dell utilities including things like the Wi-Fi sniffer and full scrolling support from the Trackpad driver.

There’s a useful post on the TechNet forums about which drivers to use on a Dell Inspiron 1525 if you want to upgrade from 32-bit Vista to 64-bit Vista or Win7 and this helped get me up and running. It turns out that some of the 64-bit drivers aren’t listed for the 1525 but address the same hardware on other Dell machines and so work just fine.

I like to have a couple of desktop clock gadgets so that I can see the time in different time zones without having to think about it. A while ago I found a gadget that I like but there are lots of clocks in the Windows Live Gallery and so I’m never sure if I’m picking the same one when I install on a new machine. Sure, I could copy the file locally and make sure I just install that each time but that pre-supposes that I have access to the copy when I need it. Instead, I’m going to bookmark it here and then I know how to find my way back. It’s the Digital World Clock – thanks SARWAR.

The Visual Studio and Internet Explorer teams discovered an issue affecting some of the code wizards in Visual Studio after installing IE8. Visual Studio hosts the browser control to implement the code wizards and the custom security manager that is part of VS doesn’t expect a request from IE about an URLACTION that wasn’t previously routed through the security manager.

The Visual Studio team have posted a workaround on their blog.

For as long as I can remember (I think going back to IE3), Internet Explorer has displayed a ToolTip containing the contents of the ALT attribute for IMG elements. Other browsers including Netscape 4 also showed the ToolTip. In IE7, this looks something like this:

In IE8 standards mode, the ToolTip is no longer shown. This is a change we made to be more standards compliant, more interoperable with other current browsers, and to encourage more accessible mark-up. ToolTips are still shown in quirks and IE7 standards modes.

The problem comes because having the ALT attribute displayed as a ToolTip encourages two behaviours that aren’t compatible with the accessible web. The first is that content authors naturally enough set their ALT text to be something appropriate for a ToolTip but not ALTernate text to represent the image in scenarios where users can’t see the image. The second is that content authors actively don’t put alternate text because they don’t want a ToolTip displayed. Neither of these is desirable.

The solution for content authors is to use the TITLE attribute if they want a ToolTip. The TITLE attribute applies to other elements with the same effect and not just images. The ALT attribute should be used for text that’s an alternative to the image.

Back in December, the Office Sustained Engineering team wrote a blog attempting to answer the question, “Why doesn’t Office just fix all of the bugs before they ship?”. In fact there description applies to any product from Microsoft and in fact products from many companies.

The truth is, even for a project working on a quality driven release, at a certain point someone needs to decide on the ship date and figure out working back from that how to lock down and stop making code changes. If you don’t do that then you’ll never ship anything. This reminds me of a conversation I had with a friend when we went snowboarding earlier in the year. The ski lifts have a closing time displayed on them after which time nobody else will be allowed to get on the lift and anybody already on will be allowed to reach the top. We discussed how the staff would have to be pretty strict on closing at exactly the time displayed or else they’d never be able to close. If they let through “just one more person” then, given that new people arrive back at the lift all the time, at what point would you say “enough is enough”. How would you explain to the person that you stopped that you really shouldn’t have let the previous person go either because, after all, it’s now well past closing time.

And so it goes with bugs. On any product of reasonable complexity, we receive a steady stream of incoming bug reports all the time, every day. Many of the reports relate to bugs that have already been fixed. Some of them relate to issues that are hotly debated where there are disagreements about if the product is supposed to work that way by design or not. And of course some of them relate to previously unknown defects. At some point you have to say “enough is enough” and after that point only really critical issues (such as security vulnerabilities) are serious enough to get fixed. This is a really difficult time for the engineering team. Most developers are at least partly perfectionists and no one wants to ship a product with a defect that could be fixed. Might even be easily fixed. At some point, the tough decisions have to be taken though.

The Office SE blog goes into more detail on this and other areas.

What about the bugs that were in the last release and the one before? They keep getting reported and you keep shipping without fixing them. It’s true that there are some bugs that survive past multiple releases. Sometimes they are things that where there’s a disagreement about what the correct behaviour is. Sometimes, though, they are just seen as low priority and a decision is taken not to fix them. Of course, every bug is the most important bug in the product to the person that reported it, but if there are common workarounds and perhaps the bug is only cosmetic and easy for a user to ignore then it may never make the cut and get fixed. Most customers would be disappointed if they bought a new version of a product and the only difference was a large number of fixes for minor issues they’d never personally run into. There is always a balance between working on new features/functionality and going back and fixing the gripes that a few customers have in less common scenarios.

Scott Hanselman has a post talking about how to encourage users to upgrade their browser from IE6 to something newer. It’s true that there are still a large number of people using IE6. Previous versions of IE are the biggest competitor to new releases and in the past it has often taken around 18 months before the number of users of a new release surpasses the number of users of the previous release.

As it turns out, adding conditional messages to pages asking people to upgrade their browser has limited success. Many of the users still with IE6 installed are on corporate desktops who can’t upgrade to a newer version. Unfortunately, in trying to make IE7 more compliant with web standards, many internal corporate sites coded to work with IE6 behaviour weren’t compatible with the new IE7 rendering. Instead of spending the resources to upgrade those sites, many corporate customers had remained with IE6.

We learned many lessons during the IE7 product cycle and we’ve incorporate this learning into IE8 through the many compatibility mechanisms. By forcing IE8 to render pages in the new CSS2.1 standards based rendering engine by default, we had the potential to break sites within corporate customers in similar ways to their experience with IE7 and this isn’t the best way to endear yourself to your customers. While being in standards mode by default is the right choice for the long term, many customers in the short term just want their sites to continue working and so we have to strike a balance.

Unfortunately, it wasn’t feasible to incorporate IE6 compatibility into IE8 and so customers who haven’t upgraded from IE6 to IE7 because of internal compatibility restrictions will still need to do the same work to move to IE8. On the positive side, customers who moved to IE7 already will have a much smoother transition as they look at deploying IE8.

On 2nd May, 1997, the Tony Blair led the Labour Party to the first election victory over the Conservatives for 18 years. This was a landslide victory, the worst performance by the Conservatives for over 90 years, and a popular call for change by the people of the UK. The country was desperate for something different. There was such a feeling of relief, of new optimism, a belief that things would be better now.

History will judge whether the New Labour experiment was a missed opportunity. As time passes, it’s inevitable that more and more people become disillusioned with the status quo, with the fact that perhaps life isn’t as different as they’d hoped for. The Blair government became side-tracked, embroiled in World affairs that with hindsight might best have been avoided, and yet in their finer hours I believe they did make changes that improved many peoples’ lives.

My politics aside, however, I sense even greater hope and optimism in the United States. The people of this country are ready to cast aside the previous leader and look ahead to a change for the better. The inauguration of Barack Obama carries so much more significance than just a change of president, more than the change of administration from one party to another. 40 years after the civil rights movement, the dreams of many who never thought they’d live to see the day will come true. I still remember the feeling of a new beginning from that day back in 1997. There are millions of people for whom today must feel a thousand times more powerful.

Can we look forward to a new beginning both in the United States and throughout the World? I hope the answer is, “Yes, We Can.”

Scott Hanselman: I'm asking for brown bread rather than wheat, ...

I now can see where I’ve been going wrong only in reverse. Whenever I’ve asked for brown bread, I just get a “Huh?” in response.

I had a look around yesterday for an up-to-date binary of cURL to run on Windows. The build I had already didn’t support SSL. This page has a builds with both SSL and SSPI support and the dropdown allows you to select other versions.

W3C XHTML 1.0 Appendix C: This appendix summarizes design guidelines for authors who wish their XHTML documents to render on existing HTML user agents.

W3C XHTML Media Types: The use of 'text/html' for XHTML SHOULD be limited for the purpose of rendering on existing HTML user agents, and SHOULD be limited to XHTML1 documents which follow the HTML Compatibility Guidelines. In particular, 'text/html' is NOT suitable for XHTML Family document types that adds elements and attributes from foreign namespaces, such as XHTML+MathML.

Mark Pilgrim: Despite Chris Wilson's assertion that "we cannot definitively say why XHTML has not been successful on the Web," I think it's pretty clear that Internet Explorer's complete lack of support for the application/xhtml+xml MIME type has something to do with it.

Sam Ruby: what is wrong with using XML for this?  Come on.  I can answer that with two words: IE, and Postel.

Chris Wilson (back in 2005): I made the decision to not try to support the MIME type in IE7 simply because I personally want XHTML to be successful in the long run.  I love XHTML (go look, my name is in the credits for XML 1.0); it’s capable of being truly interoperable if done right.

Internet Explorer doesn’t support XHTML served with the application/xhtml+xml MIME type and IE8 won’t add that support either. I wasn’t around when the feature decisions were taken for IE8 but I do know that the wish list is long and it only makes sense to implement a reasonable number of features in each release of any software product. It also makes sense to focus your resources on things that will have the most impact for the most customers.

Internet Explorer is an interesting product because it has many different audiences with each with different priorities. People browsing the web want it to be fast, easy-to-use, and safe. Web developers want good tools and a consistent experience across browsers. Enterprise IT managers want reliability, ease-of-deployment, and most-of-all compatibility with the applications that worked with previous versions and that run their business. Application developers want compatibility and also extensibility/customisation either of the browser itself or of the browser control they include in their applications. It’s hard to please all of the people all of the time, especially when you have hundreds of millions of users.

At the PDC in October, Alex Mogilevsky presented on the new rendering engine in IE8 that provides interoperable support for CSS 2.1. The IE team decided that CSS 2.1 support was a “must have” feature for IE8 and Alex describes the huge amount of work involved in making that happen (of interest, he also covers some of the history of the way IE worked in previous versions). With everything else that was a priority for IE8 XHTML wasn’t high enough up on the list and it didn’t make it into IE8. Will it make it into the next version of IE? Who knows. Those decisions certainly haven’t been taken yet.

With all the recent discussion about well-formedness I was wondering about what the web would be like if there _were_ broad support for XHTML. What percentage of new content would be served with application/xhtml+xml? Would all the Classic ASP and PHP developers try to use XHTML but then get frustrated at the fragility of pages that have to be perfectly marked-up? Would there be a gradual move of applications towards XHTML or would it be reserved for the elite minority? Is showing nothing for a slightly incorrect page the right answer for most web developers?

Jonas Sicking: When Netscape decided to rewrite their browser engine and use what has
become gecko (the engine used by firefox), one of the biggest problem with taking marketshare was compatibility with existing pages, even though the new engine was perfectly able to parse HTML 4 by spec.

In fact, we can still see this today. While firefox now has a worldwide marketshare of about 20%, our marketshare in many countries in Asia is tiny. Our market research data has shown that the main reason for that is website compatibility. Even though Firefox parses valid HTML4 very well.

Compatibility is extremely important and the W3C HTML 5 working group is putting a huge amount of effort into describing the interoperable way to process HTML documents that are not well-formed. Meanwhile, XHTML guarantees that pages will only be displayed if they are well-formed – there is no error recovery. I ask the question again: what valuable properties does a well-formed document have?

Of course, XHTML isn’t just about well-formedness. The documents are truly XML and have the ability to embed mark-up from other namespaces such as SVG and MathML and to be processed with standard XML tools. There is also work underway in the HTML 5 WG to define the mechanisms for these languages to be embedded in HTML. What value is there in XHTML if it only differs from HTML in which type of parser I instantiate to read a document?

Sam Ruby: Whenever I find myself updating a script I wrote months or even years ago, these days my first step is to do a git init.

Over the last few months, I’ve seen quite a few people commenting about how git is a “better” source control system than Subversion. Today I watched this video as Linus Torvalds talked at Google about the ideas behind the creation of git. It’s both entertaining and informative and I think now I understand what they meant.

There’s an interesting debate going on in the W3C HTML working group about whether well-formed HTML is important in the specification process for HTML5. It feels to me somehow intellectually that well-formedness is a valuable goal but when it comes down to explaining why it matters I’m finding it hard.

Which of the following is “better”:

normal<b>bold<i>bolditalic</b>italic</i>normal

or

normal<b>bold<i>bolditalic</i></b><i>italic</i>normal

The first is shorter (and works in all the popular web browsers) while the second is well-formed. Well-formedness isn’t about being smaller. It’s also not about performance: it turns out that the parsers in browsers often process certain non-well-formed mark-up faster than if it had been well-formed.

Since browsers have to parse both alternatives and the HTML5 process is about ensuring that they do so in a predictable and interoperable way then should there be any weight behind well-formed documents? After all, the spec doesn’t prevent you from choosing to be well-formed if you want to.

The analogy I’ve been considering is about indentation in C++ source code: few people would probably write C++ without a sensible indentation strategy to help make the code readable. Yet the C++ spec doesn’t need to say anything about indentation – it’s a best practice but not a formal part of the language definition. Could writing well-formed HTML be a best practice that’s not a formal part of the language definition?

I’ve been spending some time on a side project to create a Vista boot image that installs unattended and configures a development machine with all the tools I want configured they way I want them. The goal is to install everything including Visual Studio and all the little utilities that I use frequently as well as configuring the common things the way I like them like the mouse sensitivity, colour scheme, etc.

The simple starting point for this project is to get Vista to install unattended using an answer file created with the Windows Automated Installation Kit (Windows AIK). I found an excellent guide to creating the answer file: FireGeier’s Unattended Vista Guide. This provides a simple walkthrough of how to configure the AIK and how to build increasingly complex unattended installs.

I finally got around to buying a proper chair to sit on to use my PC at home.

My hope is that now it is more comfortable to sit here I might actually get around to reading RSS feeds and even posting to my blog. :)

This is mostly a bookmark for me because this isn’t something I need right now but is definitely something I can see needing in the future. According to the fine members of the win_tech_off_topic group, SWIG is a good tool for building the interop layer between C/C++ code and another runtime, be it Java, Python, or .NET.