March 16 2010, 01:30

How Microsoft Leaves Windows Mobile Developers to Rot in Hell

Categories: English | Programming | Rants | Windows   Tags: windows mobile | windows phone | visual studio 2010 | expression blend

I do a lot of work for a company that builds line-of-business applications based on Windows Mobile and .NET Compact Framework. Our apps are typically run on business-oriented Windows Mobile devices, most often ruggedized hardware built by manufacturers such as Intermec or Symbol. For a long time we’ve been wondering what’s going on with Windows Mobile development with respect to Visual Studio 2010 and future versions. There are significant limitations in the current development stack in terms of user experience, and for a long time we’ve had an almost desperate need to know the roadmap of these things.

Therefore, I’m currently at MIX in Las Vegas to get as much information as possible on what’s really going on with the developer story around Windows Mobile (no, not Windows Phone development – that stuff is pretty obvious – what we need to find out is what’s going on with Windows Mobile development). And what I’ve found out so far is not uplifting. Frankly, I’m pissed off to the point where I need to write about it, so here’s the story. It’s a complicated situation, so bare with me.

The Past

When Visual Studio 2010 Beta 1 came out, all mobile development features (Smart Device projects, .NET Compact Framework, Mobile WinForms designer, Device Emulator etc.) were mysteriously missing. People started asking questions, but Microsoft was almost completely silent. A few vague mentions here and there stated that “Microsoft was committed to providing mobile development support for Visual Studio 2010, but could not share more information at this time”.

When Visual Studio 2010 Beta 2 came out, mobile development support was still MIA. People such as me, and dev shops such as the one I work for, started worrying. Microsoft remained largely silent, but started saying “we’ll have more to say at MIX”.

When Visual Studio 2010 RC saw the light of day, mobile development support was still nowhere to be seen. Hopes started fading that the mobile development features would be reintroduced into the product, because by now it was surely too late. Let’s face it: if a major block of functionality is not in the RC, it’s not going to be in the RTM build either.

All through this time, details started to emerge about Windows Phone 7, and it was obvious that it was a very different beast. It gradually became obvious that the developer story around Windows Phone 7 would be totally awesome, that it would revolve around Visual Studio 2010 and Expression Blend 4, and that it would involve Silverlight and XNA. But confusion remained around how this related to Windows Mobile 6.5 and below. Would existing Compact Framework application carry forward to Windows Phone 7? Would the new development stack also run on Windows Mobile 6.5 and below? What the hell were we supposed to do with all existing Windows Mobile applications if Visual Studio 2010 could not be used to work on them? Would we be stuck with Visual Studio 2008? You get the idea.

I was at PDC09 in Los Angeles in November last year and tried to get some of these questions answered. Well, that didn’t happen. Not only was the whole event very low on Microsoft representation (probably because the economy went down the drain that year), but the people who were actually there closed like clams as soon as anyone mentioned the word “mobile”. Apparently, because anything related to Windows Phone 7 was under such heavy secrecy, things such as Windows Mobile development support in Visual Studio 2010 became subject to the some secrecy sort of by association, even though they really had nothing to do with any of the stuff that was so sensitive. A Microsoft employee listened politely to my questions during Ask the Experts, asked me to send them in email to him, and promised to get back to me with answers. That never happened, despite sending friendly reminder emails twice.

Then a few weeks ago Windows Phone 7 was officially unveiled, and any development-related questions were answered with the standard “ask us again at MIX”.

The Present

After speaking to some Microsoft people here at MIX this morning, I can now confirm the following.

1. Applications written for .NET Compact Framework 3.5 on Windows Mobile 6.5 and earlier will not run unmodified on Windows Phone 7. Parts of the code will carry forward, because things are still .NET. Basically, anything that does not deal with UI and does not do COM or Win32 interop should carry forward with relative ease.
2. The development stack for Windows Phone 7 is brand new (based on Silverlight and XNA) and will not support Windows Mobile 6.5 and earlier. It is not an evolution of the mobile development features in Visual Studio 2008, but rather it was built from scratch using newer technologies and targeting only Visual Studio 2010.
3. The mobile development tools for .NET Compact Framework 3.5 and Windows Mobile 6.5 and earlier will not be re-added to Visual Studio 2010. Developers writing apps that need to run on Windows Mobile 6.5 and earlier will have to keep using Visual Studio 2008.
4. Microsoft will not continue to innovate on Windows Mobile 6.5 and earlier, nor on the development tools targeting that platform.
5. If you’re writing business-oriented apps for business-oriented devices (e.g. the kinds of devices that Intermec and Symbol et. al. are making, typically ruggedized and equipped with barcode readers etc.) you are not likely to be coding for Windows Phone 7 anytime soon, because Windows Phone 7 currently is almost exclusively consumer-oriented and the chances of these device makers making devices based on Windows Phone 7 are very slim, for a number of reasons.
6. Applications on Windows Phone 7 will run in a tightly controlled managed sandbox, and interop with device hardware is limited to the kinds of interactions that Microsoft decides to surface first-class in the managed APIs (typically cameras, sensors, etc.) That means no such stuff as barcode readers. However, there is an interesting possibility for device makers to expose additional custom hardware as local IP endpoints so that applications could potentially communicate with them using the network stack.
7. SQL Server Compact will not be available on Windows Phone 7.

The combination of these facts leaves shops like us in a veritable twilight zone. We would like nothing more that to rewrite our apps using the new platform and developer stack. Unfortunately, that’s not our call to make. There is a solid barrier between the Windows Mobile 6.5 world on one side, and the Windows Phone 7 world on the other. Neither the development platforms nor the apps written for them can cross this barrier. Hence, the devices we target need to move to the new platform first, which is unlikely to happen. So we are forced to stay on the old developer platform, which means not only continuing to struggle to create anything beyond the most primitive of user experiences, but also doing so in an old and outdated IDE!

Now, I’m usually a very vocal advocate of making clean breaks with the past in order to create something better for the future, so when Microsoft finally does exactly that, shouldn’t I be happy? Well, if you think about it, that’s not at all what they are doing here. Rather, they are leaving something existing behind in favor of something brand new that serves a completely different purpose. Windows Phone 7 does not replace Windows Mobile 6.5, because the former is completely consumer-oriented whereas the latter is primarily enterprise-oriented. The new development platform as shown off today here at MIX is simply outstanding, breathtaking, amazing – it’s everything we want mobile development to be! There’s just one problem: it targets a completely different set of devices and customers, and therefore we don’t get to code for it.

In other words, we now actually have two completely separate mobile development platforms, with completely different target devices and customers. The “older” platform will still be around for quite a while, because there’s nothing yet to replace it - I’m fine with that! There is no compatibility or interop between these two platforms – I’m fine with that too! What I’m not fine with is the fact that the older platform is not carried forward as-is to run within Visual Studio 2010! The fact that the newer platform also has the word “mobile” in its description is not a valid reason, because they really have nothing to do with one another. The fact that they both deal with mobile development is almost coincidental.

I’m not asking for a new and greatly improved version of the Windows Mobile 6.5 developer stack (although that would have been nice) – I understand that Microsoft chose to focus on the consumer story now. I’m only asking that they allow us to keep using the same developer stack with the new IDE, so we can at least take advantage of the IDE and language improvements. Including the existing mobile developer toolset in Visual Studio 2010 in addition to the new stuff would have been the right thing to do, and I can’t imagine that it would have been particularly hard. Instead, they just chose to drop it from the product, leaving Windows Mobile 6.5 developers to rot in hell with Visual Studio 2008. That’s what pisses me off.

The other thing that pisses me off is that Microsoft has been so nonchalant about informing software vendors of their plans. A lot of shops (including ours) could have really used this information a year ago when the decisions were made (and believe me, we have really been trying hard to get these answers). It would have helped a tremendous deal in our strategic planning to know that the platform on which we have bet our business would be dropped from Visual Studio in the 2010 timeframe. This information could have been shared publicly without disclosing anything about Windows Phone 7, and that would have been the right thing to do.

The Future

Looking forward, I have heard some hints today that the enterprise side of things is being discussed and thought about for the future. Microsoft focused on the consumer story for this release to fend off the competition in that space, but a more business-oriented version of Windows Phone 7 and the accompanying developer stack might very well be coming in the future. Essentially built on the same stack of technologies, but with a less constrained runtime execution environment and a different deployment story.

If and when that happens, devices makers such as Intermec and Symbol would be more likely to get on the new platform, and then shops like ours could move away from the old platform for good. For now, however, we are left to rot in hell.

October 15 2009, 00:19

How to Make Internet Explorer (And Others) Remember Username and Password

Categories: English | Windows   Tags: internet explorer | remember password | authentication | credentials

<UninterestingFluff>First of all, as if the following worn-down cliché had not been used enough times in the blogosphere already: I do apologize (mostly to myself) for not posting more in the months that have passed since I first created my blog. [Insert the usual excuse about being so busy with this and that and yada yada yada…] In all honesty, for every day I don’t get around to posting something, it feels more and more almost like I wasted all the time and effort that went into creating the design and setting everything up just the way I wanted it. Can’t have that. And I really do have a lot of stuff to post – in fact, I maintain an offline list of subjects I sooo badly want to blog about! I guess it’s been a classic case of a vicious circle – the longer I wait, the heavier the burden of getting caught up. Anyway, I’m going to make a serious attempt at breaking the circle now, so expect more frequent postings from here on out.</UninterestingFluff>

The Problem

Just to pick a random topic out of my great big pile, I decided to mark the beginning of this new and more active era with something that a lot of people around me always seem to struggle with: how to get Internet Explorer (and a number of other applications that also access HTTP servers using the WinInet API, such as Visual Studio Team Foundation Client) remember your credentials (username and password) for sites that require authentication, and reuse them on subsequent accesses.

Below is the dreaded password prompt as it looks in Internet Explorer 8 on Windows 7:

As you’ve probably noticed, with the default settings, if the server you are accessing is not on the local LAN, you can check that “Remember my credentials” checkbox all you want – the password prompt is till going to pop up the next time you access the server in a new browser session.

So what’s going on? Well, in short, the default settings make sure that credentials are only saved and reused for URLs that are on the local LAN. This is for some sort of clever “security reasons” no doubt – because as we all know, it’s much more secure to force users to write down their passwords on sticky notes and attach them to their monitors, than to save those passwords is the heavily secured and encrypted protected storage of the user profile. Yeah. Seriously.

The Solution

Actually, there are two effective solutions to this problem, one of which I advocate more than the other:

• The really easy (but in my opinion somewhat blunt and unnecessarily dangerous) approach is to make Windows save and reuse credentials for any URL within the Internet zone.
• The slightly more demanding (but in my opinion considerably safer) approach is to add specific sites for which you want Windows to remember credentials to the Trusted Sites zone and make Windows save and reuse credentials for that zone only.

I’m going to show you how to accomplish the latter (if you really want to do the former I’m sure you can figure it out). Here’s how you do it:

1. Go to Control Panel and open Internet Options.
    
2. Go to the Security tab, select Trusted Sites and click Custom Level:
   
   
    
3. Scroll to the bottom of the options list and in the category User Authentication –> Logon, select Automatic logon with current user name and password:
   
   
    
4. Click OK, and then click Sites.
    
5. Uncheck the Require server verification (https:) for all sites in this zone checkbox, and then add the sites for which you want credentials to be saved and reused to the list of sites for this zone with both HTTP and HTTPS schemes:
   
   
    
6. Click Close and then click OK.

That’s it. Hopefully, next time you access one of the configured URLs either by browsing to them via Internet Explorer or connecting to them by some other means through an application that uses WinInet for HTTP connectivity under the hood, the credentials prompt will not appear. Screen shots are from Internet Explorer 8 on Windows 7, but the steps should be identical all the way back to Internet Explorer 6 on Windows XP.

February 3 2009, 17:30

How To Enable Use of Saved Credentials with Remote Desktop to Almost Fully Authenticated Machines

Categories: English | Windows   Tags: remote desktop | group policy | authentication | credentials

I use Remote Desktop a lot, and being able to save Remote Desktop shortcuts to specific machines as well as save the credentials to connect with is a very handy feature that saves a lot of time. However, sometimes when trying to connect to a remote machine with saved credentials, the following message would appear (username obscured for obscure reasons):

Just to make sure this ends up in the indexes out there, the full message is:

Your credentials did not work

Your system administrator does not allow the use of saved credentials to log on to the remote computer [computer name] because its identity is not fully verified. Please enter new credentials.

This happens whenever Kerberos cannot be used as the authentication protocol, which include (but may not be limited to) the following situations:

• Connecting to a machine in another domain and the appropriate trust relationships to perform cross-domain authentication do not exist
• Connecting to a machine in the same domain but without connectivity to a domain controller

Windows reverts to using NTLM, and by default the group policy for domain machines prohibit the use of default or saved credentials when using this older authentication protocol. However, unless this policy has been manually configured at the enterprise level it can easily be changed on an individual machine using the Group Policy Editor.

1. Hit Start –> Run and type “gpedit.msc”.
    
2. Navigate to Local Computer Policy –> Computer Configuration –> Administrative Templates –> System –> Credentials Delegation.
   
   
    
3. Double click the policy “Allow Delegating Default Credentials with NTLM-only Server Authentication”.
    
4. Set the policy to “Enabled”.
   
   
    
5. Click the Show button and enter the string “TERMSRV/*” into the list. You can also be more specific here in case you don’t want to allow the use of saved credentials with all remote machines but rather just a select few.
   
   
    
6. Click OK twice to close the policy.
    
7. Repeat steps 3 – 6 for the following policies:
   • “Allow Delegating Default Credentials”
   • “Allow Delegating Saved Credentials with NTLM-only Server Authentication”
   • “Allow Delegating Saved Credentials”

That should be it, hopefully no more of that annoying dialog. I have used this on Windows Vista and Windows 7 Beta 1. The same procedure should apply to Windows XP as well (it this policy change is needed on XP at all – I don’t recall ever having to jump through these hoops pre-Vista), but I have not tested it so the details may vary.