Code, technology, opinion ... and who knows what else?

Month List


Comment RSS

On the eve of the Windows8 Consumer Preview


In less than 24 hours, the near feature-complete Windows 8 Consumer Preview (aka Beta) will be made available for everyone outside Microsoft to download, install, touch and taste.

Windows 8 is undeniably, one of the biggest single updates to Windows since the introduction of Windows 95. Some argue that it’s the biggest shake-up to Windows since the launch of Windows 3.0 back in 1990.

I couldn’t agree more!

I’ve been using Windows 8 on a daily basis since the developer preview (DP) was released in September 2011. I have been running Windows 8 on a variety of devices – installed locally on a Samsung Slate and Sony Vail Z Series laptop, running in virtual machines and accessing both locally and via remote desktop using a MacBook Pro (primarily running Windows 7) coupled to a 29” Apple Thunderbolt display in order to see how Windows 8 looks and feels on a larger-format display.

Now the the Windows 8 story is stabilizing and with the imminent introduction of the Windows 8 Consumer Preview (CP), I’ll be increasing my posting volume considerably in the coming weeks and months. My goal is to offer you, dear reader, with a balanced, real-world view of Windows 8 – both the good, and the bad – without any of the over-the-top hyperbole and anti-Microsoft-at-all-cost fanaticism we see all too often on the web today.

I’ll be discussing Windows 8 from both the end-user perspective, as well from the perspective of a seasoned developer interested in exploring Microsoft’s exciting new app platform and examining strategies for porting existing Win32/.NET apps to run in the new MOSH environment.

I encourage you to add your comments, questions, thoughts and opinions, but please keep things reasonable and constructive. Unnecessary flames and abusive nonsense will be removed.

Permalink | Comments (0) | Post RSSRSS comment feed

An Accurate Windows 8 Platform Architecture Diagram?

Since Microsoft unveiled details of Windows 8 to the world during the //BUILD conference in September 2011, there has been some confusion about where and how the new WinRT API sits in relation to .NET and Win32.

Part of this confusion is due to the oversimplified, ambiguous and misleading platform architecture diagram unveiled during the conference (click image for un-obscured version):


In this diagram, it appears as though there is no more .NET & CLR, it looks like Silverlight doesn’t exist and, worse, makes it look as though WinRT is an entirely new Windows subsystem that sits alongside Win32!

I spent a lot of my career at Microsoft building and presenting architectural diagrams to explain the relationships between the various technologies I worked on and other current and new technologies. But I don’t think I ever created something as confusing, misleading and ambiguous as the diagram above!

A tip for whoever designed the above diagram: If you’re going to unveil your brand new OS & app platform architecture to your developer community, make sure your architecture diagram is clear and accurate.

Win32 & .NET are NOT “going away”!

During and since the //BUILD conference I’ve had MANY conversations (and overheard many more) with people expressing concern that .NET and Win32 are “going away”! I’ve seen people state that WinRT doesn’t utilize Win32 API’s and that it “resides directly on top of the kernel just like the Win32 API”!! Nothing could be further from the truth!

The reality is that Win32 and .NET are not going away! WinRT is not magic – it’s simply a collection of native COM objects that are exposed to the outside world using .NET/ECMA-335 compatible metadata (rather than the traditional IDL metadata format employed by all COM objects in the past). This allows WinRT objects to be consumed by native C/C++, managed C#, Visual Basic, etc. and Javascript via Microsoft’s Chakra Javascript engine.

Several other people have attempted to provide a more accurate diagram with varying levels of success. Fellow ex-Microsoftie Doug Seven posted his re-rendering of the Win8 architecture, and MVP & author Shawn Wildermuth recently posted his perspective while explaining how Silverlight sits in this architecture.  Famed Microsoft-watcher Mary Jo Foley also has a post discussing the angst caused by the poorly designed Windows 8 architecture diagram above.

While these newer attempts to describe the new architecture are increasingly accurate, they don’t deal with the issue of the relationship between WinRT and Win32. Nor do they clarify the position of .NET & CLR.

To clarify reality:

Because of the continuing confusion I thought I would offer-up what I believe to be a pretty accurate diagram summarizing the Windows 8 platform architecture:

Windows 8 Platform Architecture

Hopefully, this new architecture diagram should make things a lot clearer. This new diagram is by no means perfect, but I believe it accurately expresses the major components of the existing and the new OS components. Let me know if you think it needs any further changes in the comments below.

Permalink | Comments (0) | Post RSSRSS comment feed

How NuGet hosed my Javascript Intellisense but still saved the day


The Issue

I have been banging my head against a brick wall over the last few days trying to get JavaScript & JQuery Intellisense working in Visual Studio 2010 for a web project I am currently working on. I have read all the threads over at StackOverflow, I have read many of the threads on MSDN’s discussion forums and on many pages around the web.

All to no avail – as you can see above, no matter what I did, I could not get any JQuery Intellisense. But why? While it’s not perfect, Visual Studio 2010 has some pretty good (and rapidly improving) Javascript Intellisense support. I know this because I’ve used it on many projects in the past. But for some reason, it was just not working in this current project.

The Problem

I hunted high and low:

  • I made sure I had the JavaScript sources local to the project (to rule-out CDN/connectivity issues)
  • I checked that I was referencing the correct version of JavaScript
  • I added “///<references path=”Scripts/JQuery-1.6.4.js" to my source
  • I checked that there were no errors being reported in any of the sources

Nada. Nothing. It should work, but it wasn’t Sad smile

I thought I’d check in case there were any JQuery updates published to NuGet, so I opened up the NuGet Package Manager console window in VS and typed the following:

PM> update-package

I was surprised to see a number of errors returned, including:

Update-Package : 'jQuery' was not installed in any project. Update failed.
Update-Package : 'jQuery.vsdoc' was not installed in any project. Update failed.

Huh? That’s odd. Let’s see what packages we have installed:

PM> get-package

Id                             Version      
--                             -------      
EntityFramework                4.1.10331.0  
EntityFramework                4.1.10715.0  
jQuery                         1.6.2        
jQuery                         1.6.4        
jQuery.UI.Combined             1.8.16       
jQuery.Validation              1.8.1        
jQuery.vsdoc                   1.6          

To quote Chris Griffin: ”WHAAAAAAAAAT?” Two versions of JQuery? SRSLY?

The Remedy

I remembered that just a couple of weeks ago, I’d updated my NuGet packages and noticed that a new version of JQuery had been downloaded, the old version appeared to be removed from my project and replaced with JQuery-1.6.4. I thought it had been done right, but I guess something must have gotten screwed up in the upgrade.

So, I used "uninstall-package …" several times for each JQuery library until all references to JQuery were removed. Then I used "install-package JQuery” to re-add the latest JQuery to my project. I ran “Rebuild” to re-generate the JavaScript Intellisense, and was delighted to see JQuery Intellisense restored to its full working glory:



I hope this post helps anyone else out there who’s been struggling to get JavaScript Intellisense working in VS 2010.

Permalink | Comments (0) | Post RSSRSS comment feed

Visual Studio 11 Developer Preview Native ARM Compiler

In my previous post, I outlined the news that Microsoft has ported Windows 8 to run on ARM-based devices.

While we await details of which specific devices Windows 8 will run upon, we can at least get started with the process of making sure our existing code can compile for Windows/ARM.

In order to do this, we can use the ARM cross compiler & linker for C/C++ that Microsoft included within Visual Studio 11 Developer Preview.

On a machine with Dev11 installed, you can find the command-line tools themselves in the following folder:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_arm\

Visual Studio, however, makes it a breeze to compile your code to ARM binaries. Simply open the Configuration Manager and then drop-down the “Active Solution Platform” selector.


If you don’t see ARM in the list of available platforms, hit “New” and select “ARM” (copying settings from Win32).


Your project is now ready to be built as ARM code.

When you rebuild your project, your ARM binaries will be placed in the debug or release folder under “<project folder>\ARM\”. If you now open this folder in the Developer Command Prompt and type “dumpbin /headers <name of EXE> | more”, you’ll see that the file is marked as being an ARM binary:


If you then run “dumpbin /disasm <name of exe> | more”, you’ll see the code within the EXE being disassembled and displayed on the screen:


Now, of course, just because your code may compile doesn’t necessarily mean it will run without issues on an ARM device but at least you can get a head-start while we wait for Microsoft to release details of, and hopefully make available, real ARM devices running Windows.

For developers using a language targeting the CLR (i.e. C#, VB.NET), your code should generally require little/no change whatsoever and should run unmodified on an ARM device. The main reasons you may need to modify your code before running on ARM include:

  • Your code contains “unsafe” code that makes assumptions about machine/processor architecture specifics which may require modification when running on an ARM device
  • Your code is an add-in and is built specifically targeting x86 / x64. in this case you will need to modify and rebuild your assembly.
  • Your code references an API that has been removed/modified in Win8 in which case you’ll need to modify your code to work-around the missing API. Microsoft hasn’t released details yet about whether any API’s have been removed in Windows/ARM.

In general, aim to keep most of your .NET code clean and machine architecture independent and the job of porting your code from Intel to ARM will be much easier.

Permalink | Comments (0) | Post RSSRSS comment feed

Windows 8 to support ARM

I have just returned from a great week in Anahiem, CA, where I attended Microsoft’s BUILD conference where Windows 8 was unveiled in detail, along with Windows 8 Server and the next version of Visual Studio (VS11).

I’ll have a lot more to say about Windows 8 in future posts, but I just wanted to briefly cover a subject that I’ve had many conversations about during and since BUILD.

One of the most important new features of Windows 8 is that Microsoft have ported Windows to run on devices powered by ARM processors.

ARM processors are used by almost all smartphone and tablet manufacturers due to their great performance per watt characteristics. Companies like nVidia, Qualcomm, Freescale, Ti and Marvell combine ARM processor cores with graphics, networking, WiFi, Bluetooth, audio and other useful hardware into individual (tiny) packages that are referred to as Systems On a Chip (SOC):

Image Source:

Hardware manufacturers then attach SOC’s to circuit boards, add some memory, physical connectors for USB, radios for WiFi, cellular, GPS and BlueTooth, etc.


Image Source:

OEM’s then take the (often miniscule) motherboard, add a battery, some storage, a screen and some buttons, stuff everything in a case and create a wide variety of smartphones and tablets for your enjoyment.

image imageimage

While ARM cores have primarily been extremely frugal in terms of electrical power consumption, their processing performance has not allowed them to be used in more complex and sophisticated devices such as laptops and PC’s. Until recently.

Current-generation ARM-based chips are now able to compete from a performance perspective with some of Intel’s low-end processors whilst sipping a small fraction of the power required by Intel’s chips. Further, while today’s ARM-based SOC’s are not as powerful as Intel’s processors, from a processing performance standpoint, ARM is working hard to execute on its aggressive plans to rapidly close the performance gap with Intel whilst keeping its power-consumption requirements very low.

By porting Windows 8 to run on ARM-based devices, Microsoft is massively expanding the reach of the world’s most widely used operating system and application platform to a MUCH broader ecosystem than now includes a large array of different devices offering a wide variety of form factors, sizes, styles, shapes and designs. And by creating new user experience tuned for both touch and traditional keyboard/mouse interactions, Microsoft is providing a formidable platform upon which application developers can build compelling new applications and experiences to delight their customers with.

The first generation of Windows really started with the launch of Windows 3.0 in 1991. The second generation of Windows started with the launch of Windows 95 and has pretty much carried us forwards (albeit with some important improvements) through Windows XP, Vista and Windows 7.

The third generation of Windows starts here and now with Windows8’s new-found touch-centric, multi-device evolution. It’s going to be fascinating to see how this story unfolds, how customers react to the biggest change to Windows since Windows 95 ushered-in the start menu and how the rest of the industry adapts to the re-emergence of what they thought was a sleeping giant.

Game on! Smile

Permalink | Comments (0) | Post RSSRSS comment feed