When I first heard that the Windows 8 Developer Preview was available, I was very excited to check it out.  I have been a fan of Windows Phone 7 from the start, and was looking forward to seeing how Microsoft translated the “Metro” theme to desktops.  I first installed the preview on one of our test machines (just a decent quad-core PC), and then I started playing around.  I quickly noticed that the new OS has two “modes” (dual desktops): the traditional Windows desktop, which looks just like Windows 7, and the new Metro desktop, which looks very similar to the Windows Phone 7 UI, with live tiles, seemingly geared towards touch based interfaces like tablets and phones:



You can switch back and forth from the traditional desktop to the Metro desktop, depending on what applications you are running. All your existing Windows apps run on the traditional desktop, as does the new Visual Studio 11 Preview. All Metro style applications run fullscreen, and support both mouse and touch for input. Most Metro apps have ‘sidebar’ tools that slide in from the top, bottom, left or right, depending on the application. For example, in the Metro version of IE, the browser address bar and buttons for refresh, bookmark, etc. slide up from the bottom of the screen and thumbnails for the open ‘tabs’ slide down from the top of the screen and then slide away when you are done.



After playing with the Windows 8 Developer Preview on a traditional PC for a while, I then decided to try it out on my Sony VAIO HD touchscreen PC. The experience was much better, using touch for input. It was like working with a gigantic Windows Phone 7 device (only turned to landscape mode). The performance of the OS was very good. Apps, and I’m talking about Metro apps, were very responsive. The new ‘common dialogs’ for Metro are tailored to touch but work just as well with mice.

The next step in my evaluation of the Windows 8 Developer preview was to see how the current shipping version of LEADTOOLS works on Windows 8.  All of the LEADTOOLS 32-bit demo applications ran just fine under the Windows 8 traditional desktop.  I was able to run the pre-compiled exes, both the CDLL applications and the .NET applications, with no problems.  For the demos that used .NET 2.0/3.0/3.5, I was prompted by the OS to first download and install support for the older versions of the .NET Framework runtime.  Once I did that, those apps ran just fine as the .NET 4.0 versions.

The final step in my evaluation of the Windows 8 Developer preview was to try and write a Windows Metro style application.  I browsed the MSDN resources for the new Windows Runtime (WinRT) and found a tutorial that suited my needs.  I used information from that to basically create a HelloMetro application using C#.  I wanted to take it a step further, and add some LEADTOOLS stuff to the application.  I was pleasantly surprised to find out that the existing LEADTOOLS .NET 4.0 assemblies can be used without issue in a Windows Metro application.  So, I wrote a small app to just load a LEAD CMP image.  The biggest obstacle for me here, was dealing with the differences between the new WinRT Stream object and the old .NET Framework Stream object, which LEADTOOLS RasterCodecs.Load() requires. After doing a little research, I was able to come up with the below code to create a System.IO.Stream from an IRandomAccessStream. This gave me the stream I needed to load the CMP image.

var winRTStream = await storageFile.OpenAsync(FileAccessMode.ReadWrite);
IInputStream inputStream = winRTStream.GetInputStreamAt(0);
DataReader dataReader = new DataReader(inputStream);
await dataReader.LoadAsync((uint)winRTStream.Size);
var buffer = dataReader.ReadBuffer((uint)winRTStream.Size);
System.IO.Stream oldRTStream = buffer.AsStream();

Of course, I wanted to then display the image, so I had to find a way to convert the LEADTOOLS RasterImage object to something that could be displayed in Metro, which happens to be the Windows.UI.Xaml.Controls.Image FrameworkElement.  I found out that in WinRT, they have BitmapSource and WriteableBitmap classes, which are similar to the same named classes in WPF and Silverlight.  So, I wrote some code to create a WriteableBitmap from from a LEADTOOLS RasterImage, which I could then assign to the Image element.

At the present time, the MSDN documentation for the WinRT is still pretty rough.  I found most of the helpful tips in various newsgroup and forum posts.  Also, the WinRT itself is still missing quite a bit of functionality that I would expect will be added by the time it is actually released.  For example, WriteableBitmap object only supports 32-bit images right now.  Maybe that will remain, but I can’t imagine that being the case.

Overall, I’m pretty excited about Windows 8, the Metro UI and the new Windows Runtime.  The fact that you can consume the WinRT in C++, C# and VB.NET apps is a big bonus for me because I already have skills in those areas.  Also, the fact that the UI is all done in XAML is another big plus for me because I’ve been developing in WPF and Silverlight and those skills can be carried over as well.  All of this means that I don’t have to completely re-learn how to program for Metro.

Stay tuned, as I am sure there will be a Metro follow-up to this. The engineering team at LEAD is already working on developing Metro-ready controls, so keep an eye out for that as well. If you would like to get started with our Metro SDK early, check out the pre-release.

Update
Microsoft has released the Windows 8 Consumer Preview and .NET 4 Framework DLLs no longer work in Metro apps. For more details, check out my follow-up post about the WinRT.

Otis Goodwin