Kristof Rennen’s Blog

After moving to Windows 7 a few days ago, I already found a great new feature which allows users to virtualize applications from a Windows XP machine to a Windows 7 machine.

By using this new feature, users have the possibility to install Windows Xp only applications, and run them from their Windows 7 desktop right away.

In this post I will show you how you can get this kick-ass feature up and running. Please take into account, that this feature is still in beta at this moment.

Getting The Stuff

To get this feature up and running following downloads are needed:

• Windows Virtual PC Beta
• Windows XP Mode Beta

To be able to use this features, your computer should support Hardware Virtualization which can be enable or disabled in the BIOS setup.
More information can be found here.

Installing The Stuff

Nothing special is needed to install both the Windows Virtual PC Beta and Windows XP Mode Beta.

Windows 7 asks you to reboot your computer after the installation of the first application, but you can just continue installing the second one without any problems.

The installers will create 2 separate directories:

• Windows Virtual PC
• Virtual Windows XP

The second directory looks more or less like a regular Virtual PC 2007 directory:

The Windows XP is installed into a .vhd file, which is also used when using Virtual PC 2007 or Virtual Server.

Starting It Up

When you first start up the Virtual Windows XP, you are asked for a username and password which will furthur on be used to automatically login to the XP machine when needed.

The status of the Virtual Machine can always be checked using the dedicated Virtual Machines directory. You can see the name of the machine, its status, assigned memory and primary disk location.

By double clicking the machine in the list, it is started automatically:

When the machine has finished booting, you have a clean Windows XP machine to work on:

Virtualizing Applications

To tryout the application virtualizing, I will be using Firefox since I don’t install this on my windows 7 since I’m always using IE8 ;-).

The first step to take is installing the application inside the virtual windows xp as any other regular application.

That’s all there is to it. The application has now been installed inside the virtual windows xp, but can now be virtualized from within Windows 7.

If you open the start menu of your windows 7, there is a new folder containing all the Virtual Windows XP Applications:

Starting A Virtual Application

Any virtual application can now be started directly from the Windows 7 start menu. Before an application can be started, the running virtual machine needs to be closed down.

Also when you want to start up the virtual machine, all virtual applications need to be closed down, so its always one of them both running.

If you don’t close down the machine, you will be prompted to do so when you start up an application:

When starting the application, the virtual environment gets initialized.

After the initialization has completed, our virtual application is running and can be used as any regular application.

Conclusion

Virtualizing applications on Windows 7 really is a powerful and easy to use mechanism to run incompatible applications.

I already needed it once to be able to install some software which was incompatible with both Vista and Windows 7 even when using the available compatibility modes.

Kristof Rennen Software Microsoft, Windows 7

Last week I finally got rid of my windows vista on both my home computer and my computer at work, after suffering from too many problems for too long.

Even though Windows 7 is still a Release Candidate, I took my chances and installed it on both my machines.

I must say I’m really happy with the change. Everything is running smoother than on my vista machine without any problems.
Certainly network access and file operations have been improved a lot, which is certainly handy if you have to move or copy a huge amount of files.

I will certainly post about Windows 7 in the future, after some more experimenting.

The final version of Windows 7 will be released to manufacturing (RTM) in the second half of July and will be in stores on the 22nd of october.
I really can’t wait to make my final upgrade to Windows 7 in a few weeks.

Kristof Rennen Software Microsoft, Windows 7

The last few days have been great for the Microsoft Surface in belgium.

Last sunday, VTM used a Microsoft Surface during the election show, to visualize the results.
You can read more details in my previous posts:

• VTM Goes Surface
• Microsoft Surface At The Belgian Elections

On monday VTM already launched its second surface application:

 

This application is used to browse and manipulate belgian newspapers and magazines during the late news.
In the following weeks / months, this will be a fixed item in the late news to show the headlines of the next day in the same format as the real printed papers.

With those 2 applications, VTM really gave the surface a great start in Belgium. Let’s hope a lot of great application will follow in the future.

Kristof Rennen Development Microsoft, Surface

In my previous post I already mentioned VTM using a Microsoft Surface to give an overview of the 2009 election results.

There is already a video available, posted by Luc Van de Velde of Microsoft:

Kristof Rennen Development Microsoft, Surface

Yesterday, elections took place in Belgium.
As with any election show, TV stations always do their best to impress people watching as much as they can.

VTM chose to use the Microsoft Surface during their show as the first one in belgium using this new technology for a real purpose.

The application itself consisted of 3 scenes used by the presenter to go through the results as they were gathered throughout the day:

• A startup scene
• A coalition scene
• An evolution scene

The startup scene

The startup screen showed the logo of “De Stem Van Vlaanderen”, the same one as used on the plasma screens behind the presenters.

The coalition scene

This scene was used to navigate through all the possible coalition combinations between the 7 big factions.

An overview of all factions is shown, which can be expanded or collapsed showing the total number of seats reached by that faction.

By dragging the faction itself into a pie, 3D pie pieces visualize the possible coalitions.

The evolution scene

This scene is used to show the evolution of factions and cartels between the elections of 2004, 2007 and 2009.

By dragging the title of the faction into the bar below, the results of that faction are shown.

By using different discs the results from all the factions could be visualized in an interactive fashion.

This shows us how nicely a Surface can be integrated into any environment, and according to me the application really looks nice so they gain my vote

Let’s hope they will come up with various nice applications in the future.

Kristof Rennen Development Microsoft, Multi-Touch, Surface

In my previous article, I talked a little about the inside and outside of a Microsoft Surface unit. To actually start developing Surface applications, a few more steps are required.

Prerequisites

• Microsoft .NET Framework 3.5
• Microsoft Visual Studio 2008 with C# Project features
• Microsoft Windows Vista 32 bit
• Microsoft XNA Framework Redistributable 2.0 (available here)
• Microsoft Surface Development Kit (not publicly available)
• A minimum screen resolution of 1280 x 960

Creating projects

After the installation of the prerequisites is done, extra templates have been added to Visual Studio to be able to create new Surface projects.

 

There are 2 options to create a new Surface project:

• Using WPF
• Using XNA

I will be choosing WPF now, so when the new project is created a basic structure is foreseen which looks like this:

Following files are already available:

• A first surface window
• An app.xaml to initialize the application
• An application xml file to describe the application (description, name and icons)
• Some resources

Running projects

There are 3 possibilities to run a Surface application:

• As a standard windows/wpf executable
• On a Surface unit itself
• Inside the Surface simulator

Any Surface application can be started as any regular wpf/windows application by double clicking on the executable, or by hitting F5 inside Visual Studio.

The application will then look like this:

The second way of running a surface application, is by running it on a surface unit or inside the surface simulator.

Surface Simulator

The surface simulator is an application installed when you install the Surface sdk. It simulates a multi touch device, by supporting multiple mice, tags, … anything which is supported by a real Surface unit.

The simulator can be found here:
C:\Program Files\Microsoft SDKs\Surface\v1.0\Tools\Simulator\SurfaceSimulator.exe

When multiple mice are attached to the computer, they can all be used to interact with the application although working with multiple mice on a single computer is not really easy

If you are like me running on a screen resolution less than 1280 x 960, you will receive following error message unable to run the simulator. I’m going to try to find a solution for this so I can develop surface application on my laptop as well.

To run the application inside the simulator, you have to make sure the simulator is running before you start the application. When the simulator is running, and you start the application using the executable or by hitting F5 inside visual studio, the simulator will show the application:

Conclusion

Now that we have our environment set up, we can start developing our kick ass Surface applications. The development itself is more or less the same as WPF development. Only a few controls have a specific Surface control which needs to be used (SurfaceButton, SurfaceCheckbox, SurfaceWindow, …)

An important tip when starting with surface development is not only relying on the simulator to test the applications. It’s really needed to test the application properly on a real unit as well since the interaction with multiple people around the application is a lot different than running it on a single machine with multiple mice.

In the coming weeks I will be posting a little more on my experiences while developing one of our Surface applications, so stay tuned.

Kristof Rennen Development Microsoft, Multi-Touch, Surface

As of today, we are working on a Microsoft Surface application which gave me the idea starting to blog about news, features, nice to knows, … anything you may want to know about the Microsoft Surface and the development of Surface applications.

In this first article, I will be talking about the Surface in general, and what it is all about.

The Idea

Microsoft Surface fundamentally changes the way we deal with digital content on a computer.

Instead of working with a dull mouse and keyboard, which is not very intuitive to all users, we will be using our hands and fingers to operate the Microsoft Surface.

We can grab data with our hands, move it around by performing simple gestures, and this even with multiple persons simultaneously.

All computers only have a single input device which is the mouse. The surface on the other hand is a full multi-touch device, supporting up to 52 touch points (that are a lot of mouses).

The Outside

The Surface itself it built as a small table, where the plate itself is the multi touch device.

Because it looks so natural, it can easily be included in various surroundings.

The surface of the Surface, is a kind of matted glass material, feeling really soft to the fingers, and allowing fast movement.

The viewing angle and brilliancy of the screen is made so a lot of users can have a clean image, when surrounding the table.

The Inside

The inside of consists of 3 major parts:

• Near infrared camera’s
• A computer
• Rear projection system

In total, there are 5 camera’s monitoring the surface for movement tracking. The reason Microsoft uses 5 camera’s, is to solve field angle problems. Each camera monitors it’s own small area of the surface, resulting in better speed and resolution. It was also needed to get the table as low as it is now.

The camera’s themselves can read unlimited numbers of touch points on the surface. The limit of 52 is only set because of CPU processing limits.

The computer inside the Surface is a high-end machine, but runs on mainly conventional components. It is powered by a Core 2 Duo 2.13 Ghz CPU, and has 2GB of RAM.

The Operating System on the surface computer, is a standard non-modified Microsoft Windows Vista operating system. An extra layer is running on top of this windows vista, called the shell.

The read projection system, projects the computer’s image to the underside of the tabletop.

Communication

The Surface offer 3 ways of communication:

• WiFi
• Ethernet
• Bluetooth

There are already sample application using the WiFi possibilities to automatically load content from a wireless device, if put on the Surface.

Development

To develop Surface application, there is a choice between Windows Presentation Foundation and XNA. Custom WPF control have been built to support the Surface specific interactivity.

The development can be done using the Microsoft Surface SDK, which integrates with Visual Studio 2008 and allows the developers to run a Surface Simulator to test the application locally on a windows vista machine.

Technical Specifications

Size: 108 x 69 x 54 CM
Weight: ca 90kg

Network:

• IEEE802.11b
• IEEE802.11g
• Bluetooth 2.0
• Gigabit Intel Network Adapter

I/O:

• 2 headphone jacks
• 6 USB 2.0 ports
• RGB component video
• S-VGA video (DB15 external VGA connector)
• Component audio
• Ethernet port (Gigabit Ethernet card [10/100/1000])
• External monitor port
• Bays for routing cables
• On/Standby power button

 Display:

• Type: 30-inch XGA DLP® projector
• ATI X1650 graphics card with 256 MB of memory
• Maximum resolution: 1024 x 768
• Lamp mean-life expectancy: 6,000+ hours

Computing System:

• 2.13-GHz Intel® CoreTM 2 Duo processor
• Memory: 2 GB dual-channel DDR2
• Storage: Minimum 250 GB SATA hard-disk drive

More Information

More information can be found at the following locations:

• The Official Website
• The Surface Blog

In one of my coming articles, I will be talking about Microsoft Surface Development.

Kristof Rennen Hardware Hardware, Microsoft, Multi-Touch, Surface

A few years ago, when I started doing Test Driven Development, the defacto .NET standard was NUnit. Ever since I’m using the NUnit framework to do my testing.

Even though there are many other frameworks (like MbUnit) with lots of cool features NUnit is missing, some neat stuff can be done using NUnit as well.

In this article I’m going to show some basic and advanced usages of SetUp and TearDown possibilities of the NUnit framework.

SetUp

The SetUp is the method executed before every test, which can be used to prepare the state of the system you are going go test.

TearDown

The TearDown is the method executed after every test, which can be used to restore the state of the system you have tested.

The important keywords here are “every test”.

One of the basic rules of Test Driven Development is that tests need to be fast. Only when tests run fast, they will be executed a lot so you can depend on the results to know that everything is working correctly.

Since logic inside SetUp and TearDown will be executed for every test, this can cause tests to become slow (certainly when you are doing a lot of database access, which is not the scope of this article).

NUnit has a solution for this, and supports TestFixture SetUps and TearDowns and even Namespace / Assembly SetUps and TearDowns (sounds nice hu?).

Assembly SetUp / TearDown

In some cases it might be handy to have some SetUp and TearDown code which will be executed once for each assembly containing your precious tests.

To enable this feature, you just add a TestClass to the root of your assembly (root namespace), and mark it with the correct attributes.

The following requirements need to be fulfilled to have it working:

• The class must be in the root namespace (root of the assembly)
• The class must be marked with the [SetUpFixture] attribute
• A public default contructor needs to be available to make sure NUnit can make an instance
• The AssemblySetUp method must be marked with the [SetUp] attribute
• The AssemblyTearDown method must be marked with the [TearDown] attribute

Namespace SetUp / TearDown

The same priciple as with the Assembly SetUp and TearDown can be applied for each Namespace inside a TestAssembly. Just add the same class to a namespace root, and it will be executed once for that namespace.

The following requirements need to be fulfilled to have it working:

• The class must be in the root of the namespace
• The class must be marked with the [SetUpFixture] attribute
• A public default contructor needs to be available to make sure NUnit can make an instance
• The NamespaceSetUp method must be marked with the [SetUp] attribute
• The NamespaceTearDown method must be marked with the [TearDown] attribute

Fixture SetUp / TearDown

For every test fixture (test class), a one time SetUp and TearDown can be added as well. Those will be executed once before and after all tests in the same class.

The following requirements need to be fulfilled to have it working:

• The class must be marked with the [TestFixture] attribute
• The ClassSetUp must be marked with the [TestFixtureSetUp] attribute
• The ClassTearDown must be marked with the [TestFixtureTearDown] attribute

Test SetUp / TearDown

The default SetUp and TearDown as described above will be executed before and after every test.

The full structure of the project looks like this:

A final test class, with all features included as described above, can look like this:

When executing all tests in the assembly using the NUnit Gui, we can see the following output printed out on the console:

The following conclusions can be made based on the result above:

• The AssemblySetUp is executed once at the beginning of the full assembly
• The AssemblyTearDown is executed once at the end of the full assembly
• The NamespaceSetUp is executed once at the beginning of the full namespace
• The NamespaceTearDown is executed once at the end of the full namespace
• The ClassSetUp is executed once at the beginning of the full class
• The ClassTearDown is executed once at the end of the full class
• The SetUp is executed at the beginning of each test
• The TearDown is executed at the end of each test

This was an introduction to some more advanced SetUp and TearDown possibilities of NUnit. Using it in a real project depends on your specific needs, but the above can be used as a good starting point if you’ll ever need it.

Kristof Rennen Development .NET, NUnit, TDD, Test-Driven

In my two previous posts, How An ASP.NET DataBind Can Cause A Memory Leak and How An ASP.NET PostBack Can Cause A Memory Leak, I showed you how a UserControl inside a Repeater could cause serious memory problems.

Well after working on the memory issues for several days already, a co-worker of mine finally found a solution to ensure all user controls and pages are disposed properly.

Davy explains how he solved our problems in his blog post about the topic: Guaranteeing Disposal Of UserControls In ASP.NET

 Well, thanks to Davy’s great technical knowledge, we finally managed to get the memory in this application and all our future applications stable, proven by a rerun of our stress test scenarios.

Thanks Davy!!

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling

In my previous post How An ASP.NET DataBind Can Cause A Memory Leak, I talked about how I suffered from serious memory leaks in my current project, because of some user control not being disposed when doing manual databinding multiple times.

After being really happy about my tedious quest being finished to fix the problems, I today noticed the memory leak still occurred in exact the same location, but when using the functionalitity in another way.

The case is still the same:
Page -> UserControl -> Repeater -> UserControl

So the loaded page of the scenario, contained a user control of our own. This user control had a repeater, repeating over the rows of a generic list, creating another UserControl for each found row.

Every row, rendered through the ASP.NET Repeater, has 2 buttons available:

• A button to edit the given row
• A button to delete the given row

The button to edit the given row is not giving me any problems. When I click it, the user gets redirected to the edit page and everything gets cleaned up pretty well.

The delete button on the other hand, is performing a postback on the same page, calling an event to handle the delete:

Ofcourse this delete event is doing the following stuff:

• Getting the row’s id from the CommandArgument
• Calling our business layer to delete the record
• Performing a databind to reflect the changes

It is the last action, which performs the databind, which is now triggering the memory leak … again.

The problem

By doing a postback when clicking the button, a new instance of my user control with all it’s needed resources is created.
Because I’m doing a DataBind() at the end of my “Action”, a second instance of the same user control with all it’s resources is created, leaving the first one undisposed forever.

The second one though, is being disposed properly and does not give me any problems.

The only explanation I would have for this kind of behaviour, is that it all happens inside one postback cycle.
Probably if a control is then created multiple times, only the last one gets disposed at the end of the cycle, leaving the other ones up to the Garbage Collector.

In our case the Garbage Collector is not of any use, since the user control has references to other undiposed objects, causing all those objects to remain in memory and causing a memory leak in the end.

The solution

Well, to be honest I don’t know a proper solution right now and I will probably need some time to figure out a proper way to fix this.

If I add the databind, the application is suffering from a memory leak, which is totally unacceptable.
If I remove the databind, deleted records are still shown on my page, which is totally user unfriendly.

I’ll keep you posted if I find a proper solution, and I then hope ASP.NET is not going to disappoint me ever gain.

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling