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.

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: Anandtech.com

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: BeagleBoard.org

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.

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!

Direct from the Silverlight Firestarter event here at Microsoft campus, Redmond, WA.

Silverlight 5 is coming and includes some great new features that will not only delight Silverlight developers, but will also wow users.

Silverlight 5 3D support

Yep, you read it right. Finally, Silverlight 5 will include hardware accelerated 3D support and introduces an immediate-mode API.

Luigi and Guido Rosso from Archetype, demonstrated a demo application they wrote in less than a week which displayed a full 3D model of Scott Guthrie’s body, skeleton and musculature. They were able to control the opacity of Scott’s clothes, skin, musculature and skeleton and were able to animate the entire model, spinning him around and zooming deep into his torso … to show his beating heart! :) The demo was extremely smooth and fluid, animations were blindingly fast and many chuckles were had at Scott’s ripped torso!

The key takeaway here was that Silverlight 5 will ship with exceptionally powerful 3D features that enjoy full hardware acceleration and will completely revolutionize the kinds of applications that can be built with Silverlight, eliminating the need to install 3rd party 3D ActiveX controls etc.

TrickPlay: Variable playback speed

One of the best features of Windows Media Player is the ability to speed-up or slow-down the playback speed of videos and audio (e.g. podcasts) without altering the pitch of the audio. This is a great way of watching some/all of a long video or podcast more quickly. Alas, however, this feature is currently missing from Silverlight … but it’s coming in Silverlight 5!

This means that you’ll be able to watch all of the content you care about from events like the PDC more quickly than real-time! :)

Quality, performance and power through hardware acceleration

ScottGu made it clear several times throughout his keynote that the Silverlight team has spent a great deal of time and effort further improving the quality, performance and power-consumption aspects of Silverlight.

Scott stated that they’ve made significant improvements to the time it takes to start-up Silverlight applications. This mirrors news I’ve heard from other ‘softies who have told me that  there are some significant improvements coming to start-up times for .NET applications. Faster booting apps are ALWAYS a good thing and I can’t wait to see what develops on this front.

Scott also mentioned that Silverlight 5 will also include a native 64-bit version. This is a big deal for Silverlight developers as Silverlight is often used as the UI to large, complex  databases which can easily consume more than 4GB data in order to render their data.

Video playback is now fully hardware accelerated. Text rendering quality has been improved significantly and animation quality has been significantly improved through improved hardware acceleration.

This will also result in Silverlight 5 applications consuming less power (important for mobile scenarios) because more graphics-intensive processing is being offloaded to the GPU rather than being performed by the CPU.

Remote Control support

Yep, you read that right – Silverlight 5 will support remote control – as in the little box that you use to change channels and control the volume of your TV. This is a great feature – as someone who is increasingly sourcing movies and videos from the web (e.g. Netflix, Hulu, Amazon, etc.), having to control the movie via the PC it’s running on is a pain. I cannot wait until I can control movies streamed from Netflix without having to leave the couch!

Speculation: I wonder if this is an indication that, perhaps, Media Center in Windows 8 will be built on Silverlight?

Developer goodness :

Silverlight 5 also comes with some significant improvements for developers:

Data binding debugging

Ever run into issues with Data Binding in your Silverlight apps? Ever wanted to set breakpoints on your binds and the ability to examine step through your data binding code? You can’t do this in Silverlight today, but it’s coming in Silverlight 5!

Coded UI recording and testing

John Papa also demonstrated new Coded UI tests that can record your every action against your site’s UI. Each action is recorded into a series of steps which you can modify if you wish to remove unnecessary actions. You can then replay these actions and compare the values of individual HTML elements against expected results from within a test.

This is a really massive deal which will make testing your actual UI a great deal easier and more effective than ever before.

Further reading:

As usual, ScottGu has posted further details on his blog – be sure to go read his announcement:
http://weblogs.asp.net/scottgu/archive/2010/12/02/announcing-silverlight-5.aspx

It still surprises me how many companies – especially those who should know better still don’t ship the necessary 64-bit componentry for their software.

Now don’t get me wrong – I am not for a moment suggesting that all software companies port all their apps to 64-bit for the sake of it. After all – unless an app requires more than 2GB RAM, there’s relatively little benefit to be had from porting to 64-bit.

The exception to this rule are apps that integrate into 64-bit versions of Windows. Things like drivers and Explorer shell extensions must be ported to 64-bit.

So must iFilters. These are the software components that allow Windows to index the contents of documents you store on your PC so that you can quickly and easily search for documents containing specific terms. Windows ships with iFilters for many common file types, and many 3rd parties offer iFilters for their proprietary file formats.

One particularly popular proprietary file format is Adobe’s Portable Document Format (PDF). Adobe has offered an iFilter for 32-bit Windows since the advent of iFilters back in the early days of Windows Vista. Adobe also shipped a 64-bit iFilter back in December 2008, but this OLD iFilter only worked on 64-bit editions of XP and Vista!

What about 64-bit versions of Windows 7?

Rather surprisingly, Adobe had this to say in the comments attached to their blog announcement of the old 64-bit iFilter:

http://blogs.adobe.com/acrobat/2008/12/adobe_pdf_ifilter_9_for_64bit.html

By Aman Deep Nagpal - 4:55 AM on June 28, 2010

Thank you all for your feedback. Adobe is working on the next version of iFilter which will support Windows 7 64-bit. But we don’t currently have an availability date to share.

Seriously?

Considering that 64-bit versions of Windows 7 are outstripping 32-bit versions by a large margin, you’re only now working on an iFilter for your own document format?

I mean, it’s not as if Windows 7 was suddenly thrust upon the market without AT LEAST a year of public beta. And it’s not as if Windows 7 was met with a luke-warm reception.

Come on Adobe, your customers deserve better.