class Alon : public CPP, public Architecture : C++, Interop

Message Only Window in for .NET Application

Alon Fliess — Tue, 27 Dec 2011 02:16:00 GMT

Overview

.NET is great platform, it speeds up the development process, you deal with your application logic and in most cases you don't need to know that there is whole Windows operating system down there. However sometimes you do need to program against Windows without the .NET assistance. As a Windows developer, you need to keep all your weapons ready, be it .NET, COM or C++ with the native Win32 API. In this article I am going to show how to deal with Windows Message based communication protocol within .NET application.

Windows Messages

In traditional User32.dll based Windows application the Windows Messages mechanism serves as a communication channel among many parties. The Windows Operating System uses this mechanism to ask the Window to draw itself, to inform about environmental change or even to communicate a logoff event. The application itself uses this mechanism to create an event driven design model with a single thread or to communicate between threads. Other applications can use this mechanism with an application defined message (the WM_APP message range) to trigger a logical event, or even to pass memory buffer using the WM_COPYDATA.

Windows In Windows Are Based On An Object Oriented Mechanism

One of the impressive thing about the windows mechanism of Windows, considering its age and the fact that it was implemented with the C language in mind, is that is based on the Object Oriented paradigm. Each window is belong to a Window Class. The class is the factory of a window. The class defines the window's properties as well as the window's behavior. The properties are set using one of the predefined window class member such as the window's menu, or cursor. The behavior is defined by specifying the windows procedure address. The window procedure handles the incoming Windows Messages, which are in fact the methods of the window. Changing the Windows attributes can be made using the SetWindowLong/Ptr. Creating type fields (static) and instance fields can be made by allocating user-defined memory area for each Window class (static) and Window instance (dynamic) using the cbClsExtra and cbWndExtra fields of the WNDCLASS structure. Subclassing a Windows class can be achieved by changing the window procedure address to point to a custom function that handles the Windows Messages before it calls the original window procedure. You can subclass a Window instance or Window class (global subclassing).

Windows Do Not Run

In first look, it seems that that message communication is based on one window sending messages to another window, however windows do not run, threads do. Windows makes a correlation between threads and windows. The thread that calls CreateWindow/Ex is the thread that receives the Windows Messages related to this Window. In a common implementation of a Windows application, the main thread creates it's main and child windows, and then starts a message loop, also known as message pump, pumping messages that has been sent to any of it's windows, and dispatching this messages to the correct Window Procedure – the code that handle Windows Messages on behalf of the target Window.

Using Windows Messages Not For Painting The Window

Passing Windows Messages is one of the most easier inter process communication (IPC) mechanism, especially if the two parties are already implementing the Windows message handling boilerplate to handle their UI. One of the compelling feature of the mechanism is that it serves as a base for thread function call dispatching, enables a cross thread context call. For example in COM Single Threaded Apartment (STA), COM uses Windows Messages to dispatch function calls to the thread that created the component, much the same as dispatching messages to the windows created by the thread. This ensures that all the code of the COM component will be executed in a single thread- the idea behind the STA model.

Message Only Window

There are cases that you need to communicate using Windows Messages with another application or component, but your application is not based on the traditional user32.dll Windows. This happens more and more in modern native and manage applications that are based on Console or DirectX, for example a .NET WPF based application. In such cases there is no need to create a window to handle these messages, since we do not care about painting the window or handling resize messages, we do not want to pay the cost of such a mechanism and we do not want to handle the hiding of such a window. For that in Windows 2000 Microsoft has added a new type of window type, the message-only-window. Creating such a window is very easy, all you need to do is to provide the HWND_MESSAGE as the window's parent. You can do that in the CreateWindow/Ex or by using the SetParent function. You can use any predefined Window class, for example "STATIC", or "Message", as long as you subclass the window procedure to handle the coming Windows Messages.

Building A Message-Only-Window Client For .NET Applications

For handling system event, the .NET framework provides the Microsoft.Win32.SystemEvents class. However this class is made to receive Windows system event messages and can't be extended to receive custom user messages. You can always use Windows Form window to handle windows messages, however you will need to add reference to System.Windows.Forms.dll even if you don't use Windows Forms, and you will need to hide the form. A second approach, which I took, is to use C++/CLI assembly to create a message-only-window proxy. In this mechanism a native code handles the windows messages dispatching boilerplate. All is left for the managed code is to register a callback delegate on the message received event and ask the mechanism to start the message loop in the context of the thread that should handle the coming windows messages.

The Design

The NativeMessageOnlyWindow is a native class that handles the windows messages receiving, dispatching and handling. The MessageOnlyWindow is a managed C++/CLI wrapper (adapter) class that serves as the .NET interface for the mechanism. To bridge between the two, the MessageOnlyWindow class instantiates the native instance of the NativeMessageOnlyWindow and keeps it as a member that will be deleted on dispose. The managed MessageOnlyWindow class implements the IMessageCallback interface. The native NativeMessageOnlyWindow gets and holds a gcroot<IMessageCallback ^> to the MessageOnlyWindow managed class in the constructor. When the NativeMessageOnlyWindow receives Windows messages it calls to the OnMessageReceivedCallback method of the IMessageCallback interface. To get a better understanding on calling from native to .NET see this blog post.

To start pumping messages, the .NET client calls the MessageOblyWindow instance StartMessageLoop method. The call has to be made by the thread that created the Window that need to be handled. This call will not return until a call to StopMessageLoop will be made from any arbitrary thread.

The MessagePump.h header file

1:

2:

   3:  // MessagePump.h

4:

   5:  #pragma once

   6:  #include <Windows.h>

   7:  #include <hash_map>

   8:  #include <vcclr.h>

9:

  10:  using namespace System;

  11:  using namespace std;

12:

  13:  namespace MessagePump

  14:  {

  15:      //Callback wrapper

  16:      public interface class IMessageCallback

  17:      {

  18:          //get called each time a new message is arrived to the message only window

  19:          IntPtr OnMessageReceivedCallback(IntPtr hWnd, UINT message, WPARAM wParam, LPARAM lParam);

  20:      };

21:

  22:      //Serves as a Windows Message Loop manager for the message only window

  23:      class NativeMessageOnlyWindow

  24:      {

  25:      private:

  26:          HWND m_hWnd;

  27:          bool m_bStop;

28:

  29:          //This map helps in correlating the hWnd we get in the WndProc to the

  30:          //NativeMessageOnlyWindow instance of that Window

  31:          static hash_map<HWND, NativeMessageOnlyWindow *> s_windowsMap;

32:

  33:          //Enables calling back to .NET interface method

  34:          gcroot<IMessageCallback ^> _messageCallback;

35:

  36:          //To stop the message loop, we need to call PostQuitMessage in the context of the

  37:          //message loop thread. To do that we are sending this message

  38:          static const unsigned int WM_APPSTOP = WM_APP + 242;

39:

  40:          //Create the message only window

  41:          void Create();

42:

  43:          //The WndProc for the message only window

  44:          static LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);

45:

46:

  47:      public:

  48:          NativeMessageOnlyWindow(const gcroot<IMessageCallback ^> &&callback) : m_hWnd(0),

  49:              m_bStop(false), _messageCallback(callback) {}

50:

  51:          //Stop the message loop, the actual stop happens asynchronously, since

  52:          //we use PostQuitMessage

  53:          void StopMessageLoop();

54:

  55:          //A blocking call, the message loop is in the context of the calling thread

  56:          void StartMessageLoop();

57:

  58:          //Return the message only window handle

  59:          HWND GetWindowHandle() const { return m_hWnd; }

60:

  61:          //Stop the message loop and destroy the instance

  62:          ~NativeMessageOnlyWindow();

  63:      };

64:

  65:      ///<summary>

  66:      /// Represents a Windows Message that encapsulate in .NET type the WndProc arguments

  67:      ///</summary>

  68:      public value class WindowsMessage

  69:      {

  70:      private:

  71:          IntPtr            m_hwnd;

  72:          unsigned int    m_uMessage;

  73:          UIntPtr            m_wParam;

  74:          IntPtr            m_lParam;

75:

  76:      public:

  77:          /// <summary>

  78:          /// Construct a new WindowsMessage class that holds the WndProc arguments

  79:          /// </summary>

  80:          /// <param name="hWnd">The target windows handle</param>

  81:          /// <param name="message">The message number</param>

  82:          /// <param name="wParam">the wParam</param>

  83:          /// <param name="lParam">the lParam</param>

  84:          WindowsMessage(IntPtr hWnd, UINT message, WPARAM wParam, LPARAM lParam) :

  85:            m_hwnd(hWnd), m_uMessage(message), m_wParam(UIntPtr(wParam)), m_lParam(IntPtr(lParam)) {}

86:

  87:          property IntPtr HWnd { IntPtr get() { return m_hwnd; }}

  88:          property unsigned int Message { unsigned int get() { return m_uMessage; }}

  89:          property UIntPtr WParam { UIntPtr get() { return m_wParam; }}

  90:          property IntPtr LParam { IntPtr get() { return m_lParam; }}

  91:      };

92:

  93:      ///<summary>

  94:      ///Use this class to create a message only window

  95:      ///</summary>

  96:      ///<remarks>

  97:      ///With this class you can receive Windows Messages without the need to use a WinForm instance.

  98:      ///Message only windows are lightweight mechanisms that serves only for receiving windows messages.

  99:      ///</remarks>

 100:      public ref class MessageOnlyWindow : public IMessageCallback

 101:      {

 102:      private:

 103:          NativeMessageOnlyWindow *m_pNativeMessageOnlyWindow;

 104:

 105:      protected:

 106:          /// <summary>

 107:          /// This callback functions receives the raw WndProc arguments for any message that has been

 108:          /// sent to the message-only-window

 109:          /// </summary>

 110:          /// <param name="hWnd">The target windows handle</param>

 111:          /// <param name="message">The message number</param>

 112:          /// <param name="wParam">the wParam</param>

 113:          /// <param name="lParam">the lParam</param>

 114:          /// <returns>The method should return a value for the DefWndProc, usually <see cref="IntPtr::Zero"/>

 115:          /// is suitable</returns>

 116:          /// <remarks>When overriding this method, call the base class implementation to fire the

 117:          /// <see cref="MessageReceived"/> event.</remarks>

 118:          virtual IntPtr OnMessageReceivedCallback(IntPtr hWnd, UINT message, WPARAM wParam, LPARAM lParam)

 119:              = IMessageCallback::OnMessageReceivedCallback;

 120:

 121:      public:

 122:          ///<summary>

 123:          ///Constructor for the message only window instance

 124:          ///</summary>

 125:          ///<remarks>

 126:          ///With this instance you can receive Windows Messages without the need to use a WinForm instance.

 127:          ///Register a callback on the <see cref="MessageReceived"/> event and call the

 128:          ///<see cref="StartMessageLoop"/> to start receiving windows messages.

 129:          /// Call the <see cref="StopMessageLoop"/> to stop receiving windows messages.

 130:          /// Dispose the instance whenever you do not need it anymore

 131:          ///</remarks>

 132:          MessageOnlyWindow();

 133:

 134:          /// <summary>

 135:          /// Fires an event that represents a single windows message that has been sent to

 136:          /// the message-only-window

 137:          /// </summary>

 138:          event Func<WindowsMessage, IntPtr> ^MessageReceived;

 139:

 140:          /// <summary>

 141:          /// Ask the message pump thread to stop.

 142:          /// </summary>

 143:          /// <remarks>

 144:          /// The message pump thread is the thread that called the <see cref="StartMessageLoop"/>.

 145:          /// The stop operations is asynchronously, This call trigger a WM_QUIT message that will

 146:          /// eventually stop the loop

 147:          /// </remarks>

 148:          void StopMessageLoop() { m_pNativeMessageOnlyWindow->StopMessageLoop(); }

 149:

 150:          /// <summary>

 151:          /// Start the message loop in the context of the calling thread

 152:          /// </summary>

 153:          /// <remarks>

 154:          /// Call this method in the context of the thread that triggered the Windows Messages source.

 155:          /// This is a blocking call, the message loop is in the context of the calling thread.

 156:          /// This method will be return only after a call to the <see cref="StopMessageLoop"/>.

 157:          /// </remarks>

 158:          void StartMessageLoop()  { m_pNativeMessageOnlyWindow->StartMessageLoop(); }

 159:

 160:          /// <summary>

 161:          /// The message-only-window handle

 162:          /// </summary>

 163:          property IntPtr WindowHandle { IntPtr get()

 164:                  { return IntPtr(m_pNativeMessageOnlyWindow->GetWindowHandle()); }}

 165:

 166:          /// <summary>

 167:          /// clear native resources

 168:          /// </summary>

 169:          ~MessageOnlyWindow() { delete m_pNativeMessageOnlyWindow; }

 170:      };

 171:  }

 172:

The MessagePump.cpp code file

1:

   2:  //

   3:  // Messagepump.cpp

4:

   5:  #include "stdafx.h"

6:

   7:  #include "MessagePump.h"

8:

   9:  using namespace System;

  10:  using namespace System::Runtime::InteropServices;

11:

12:

  13:  namespace MessagePump

  14:  {

  15:      MessageOnlyWindow::MessageOnlyWindow()

  16:      {

  17:          m_pNativeMessageOnlyWindow = new NativeMessageOnlyWindow(gcroot<IMessageCallback ^>(this));

  18:      }

19:

  20:      IntPtr MessageOnlyWindow::OnMessageReceivedCallback(IntPtr hWnd, UINT message, WPARAM wParam, LPARAM lParam)

  21:      {

  22:          return MessageReceived(WindowsMessage(hWnd, message, wParam, lParam));

  23:      }

24:

  25:      hash_map<HWND, NativeMessageOnlyWindow *> NativeMessageOnlyWindow::s_windowsMap;

26:

  27:      void NativeMessageOnlyWindow::Create()

  28:      {

  29:          //Create a Window that can only receive messages

  30:          m_hWnd = CreateWindow(L"Message", L"", 0, 0, 0, 0, 0, HWND_MESSAGE , nullptr, GetModuleHandle(0), nullptr);

  31:          if (m_hWnd == nullptr)

  32:              Marshal::ThrowExceptionForHR(GetLastError());

33:

  34:          //Set the Window's WndProc to our Windows Procedure

  35:          auto result = SetWindowLongPtr(m_hWnd, GWLP_WNDPROC, (LONG_PTR)WndProc);

  36:          if (result == 0)

  37:              Marshal::ThrowExceptionForHR(GetLastError());

38:

  39:          //Keep the correlation between the hWnd and the MessageOnlyWindow instance

  40:          s_windowsMap[m_hWnd] = this;

  41:      }

42:

  43:      void NativeMessageOnlyWindow::StopMessageLoop()

  44:      {

  45:          //Two stop marks

46:

  47:          m_bStop = true;

  48:          SendMessage(m_hWnd, WM_APPSTOP, 0, 0);

  49:      }

50:

51:

  52:      void NativeMessageOnlyWindow::StartMessageLoop()

  53:      {

  54:          m_bStop = false;

  55:          //Create the Windows

  56:          Create();

57:

  58:          MSG msg;

59:

  60:          //The traditional message loop

  61:          while (GetMessage(&msg, NULL, 0, 0))

  62:          {

  63:              TranslateMessage(&msg);

  64:              DispatchMessage(&msg);

  65:          }

  66:      }

67:

  68:      NativeMessageOnlyWindow::~NativeMessageOnlyWindow()

  69:      {

  70:          if (m_hWnd == nullptr)

  71:              return;

  72:          StopMessageLoop();

  73:      }

74:

  75:      LRESULT CALLBACK NativeMessageOnlyWindow::WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)

  76:      {

  77:          //Find the correlated NativeMessageOnlyWindow instance

  78:          auto iter = s_windowsMap.find(hWnd);

  79:          if (iter == s_windowsMap.end()) //instance not found

  80:          {

  81:              OutputDebugString(L"NativeMessageOnlyWindow, a message can't be dispatched, HWDN not found.");

  82:              return DefWindowProc(hWnd, message, wParam, lParam);

  83:          }

84:

  85:          auto This = iter->second;

86:

  87:          if (message == WM_APPSTOP && This->m_bStop) //Is Stop

  88:          {

  89:              PostQuitMessage(0); //Send WM_QUIT to stop the message loop

  90:              s_windowsMap.erase(iter); //Remove the NativeMessageOnlyWindow instance from the hash map

  91:              This->m_hWnd = nullptr;

92:

  93:              return DefWindowProc(hWnd, message, wParam, lParam);

  94:          }

95:

  96:          //Trigger the callback call to the managed wrapper instance

  97:          return reinterpret_cast<LRESULT>(

  98:              This->_messageCallback->OnMessageReceivedCallback(IntPtr(hWnd), message, wParam, lParam).ToPointer());

  99:      }

 100:  }

 101:

1:

   2:  using System;

   3:  using System.Runtime.InteropServices;

   4:  using System.Collections.Generic;

   5:  using System.Linq;

   6:  using System.Threading;

   7:  using System.Threading.Tasks;

   8:  using MessagePump;

   9:  using Microsoft.VisualStudio.TestTools.UnitTesting;

10:

  11:  namespace TestMessagePump

  12:  {

  13:      /// <summary>

  14:      /// Summary description for UnitTest1

  15:      /// </summary>

  16:      [TestClass]

  17:      public class UnitTestMessagePump

  18:      {

  19:          /// <summary>

  20:          ///Gets or sets the test context which provides

  21:          ///information about and functionality for the current test run.

  22:          ///</summary>

  23:          public TestContext TestContext { get; set; }

24:

  25:          [DllImport("user32.dll", CharSet = CharSet.Auto)]

  26:          static extern IntPtr SendMessage(IntPtr hWnd, UInt32 msg, UIntPtr wParam, IntPtr lParam);

27:

28:

  29:          [TestMethod]

  30:          public void TestMethodSendingMessages()

  31:          {

  32:              var messagePump = new MessageOnlyWindow();

  33:              var messageList = new List<WindowsMessage>();

  34:              var loopHasStarted = new ManualResetEventSlim(false);

  35:  // ReSharper disable InconsistentNaming

  36:              const uint WM_APP = 0x8000;

  37:  // ReSharper restore InconsistentNaming

38:

  39:              messagePump.MessageReceived += message =>

  40:                                                 {

  41:                                                     lock (messageList)

  42:                                                     {

  43:                                                         messageList.Add(message);

  44:                                                     }

  45:                                                     loopHasStarted.Set();

  46:                                                     return IntPtr.Zero;

  47:                                                 };

  48:              bool loopHasStopped = false;

49:

  50:              Task.Factory.StartNew(() =>

  51:                                        {

  52:                                            messagePump.StartMessageLoop();

  53:                                            loopHasStopped = true;

  54:                                        });

55:

  56:              Thread.Sleep(1000);

  57:              SendMessage(messagePump.WindowHandle, WM_APP, UIntPtr.Zero, IntPtr.Zero);

  58:              var result = loopHasStarted.Wait(1000);

  59:              Assert.AreNotEqual(result, false, "Timeout, a message hasn't arrived");

60:

  61:              SendMessage(messagePump.WindowHandle, WM_APP + 1, UIntPtr.Zero, IntPtr.Zero);

  62:              SendMessage(messagePump.WindowHandle, WM_APP + 2, UIntPtr.Zero, IntPtr.Zero);

63:

  64:              Assert.AreNotEqual(loopHasStopped, true,

  65:                         "The message Loop should not be stopped until we call the StopMessageLoop");

66:

  67:              messagePump.StopMessageLoop();

  68:              Thread.Sleep(3000);

  69:              Assert.AreEqual(loopHasStopped, true,

  70:                         "The message Loop should stopped since we have called the StopMessageLoop");

71:

  72:              var numberOfAppMessages =

  73:                  messageList.Count(

  74:                      message =>

  75:                      message.Message == WM_APP || message.Message == WM_APP + 1 || message.Message == WM_APP + 2);

76:

  77:             Assert.AreEqual(numberOfAppMessages, 3, "There should be three WM_APP + x Messages in the list");

78:

  79:          }

  80:      }

  81:  }

82:

Download the VS 2010 solution from here.

Enjoy!

My Dev Academy Lecture Recording

Alon Fliess — Mon, 12 Apr 2010 15:28:24 GMT

In the last Dev Academy I have given a lecture in the TDM (R&D Manager) track about Software Porting, The Why, When, and How. During the lecture I have talked about many different migration scenarios: from VB 6.0 to C#/VB.NET. From VC++ 6.0 to VC 2008/2010, From Unix/Linux to Windows, From old .NET to new .NET etc. I have talked about the porting project, best practices and tools. This is the link to the lecture’s slides. There are many useful links inside it. This is the link to the lecture video recording (sound track in Hebrew).

Thanks to the people that came to the first meeting of the Windows Platform Developers User Group

Alon Fliess — Thu, 05 Nov 2009 07:39:44 GMT

Thanks for all of you that despite the traffic jams, made it and came to the first meeting. And thanks again for your feedbacks, all of them were excellent!

Here are the links for the resources that we talked about:

Windows 7 Training Kit
Visual Studio 2010 Training Kit – The kit contains the MFC labs for the Windows 7 features
XP2Win7 – stay tuned for a new release next week, or two.
Removing the Kernel Dispatcher lock by Arun Kishan
Mark Russinovich: Inside Windows 7
Mark Russinovich: Inside Windows 7 Redux
Parallel Computing in Native Code: New Trends and Old Friends
Dave Probert: Inside Windows 7 - User Mode Scheduler (UMS)

My lecture about Windows 6.1 Kernel changes can be downloaded from here.

We are waiting to your comments and suggestions for the forthcoming meetings. Please spread the news about the new group!

The first meeting of the Windows Platform Developers User Group

Alon Fliess — Wed, 04 Nov 2009 07:45:32 GMT

Come and join Pavel and me to the first meeting of the Windows Platform Developers user group. If the Windows platform is interesting you (and it probably does, otherwise you won’t be reading this post) you have to come. This is the chance to influence the spirit of the group. Pavel and I wanted to have a group for people like us. Those who develop for Windows with any needed tool, not just .NET or C++ but both and even more. The first meeting will be about Windows NT 6.1, this is the shortest way to say Windows 7 & Windows Server 2008 R2. Why did we decide to have this subject? we had three good reasons: First Windows 7 has just shipped to the public. Second we were deeply involved with the work behind delivering the message to the developer audience and third it is fun and interesting. In the spirit of the new group we will start by diving into kernel changes of the new operating system and we will see how we can leverage those enhancement in our code. The second part will be the fun part when we will show the new feature using lots of demos!

This is the place to thank Guy Burstein and Yifat Haramati, without them we could not have this new user group!

So be there or be…

17:30 Microsoft Ra’anana, Dekel room

More Windows Ribbon Tools & Resources

Alon Fliess — Sun, 01 Nov 2009 18:19:45 GMT

As the co-author of the “Introducing Windows® 7 for Developers” book I wrote the two chapters about the new Windows Ribbon Framework. The first Ribbon chapter deals with the Ribbon markup language and the second chapter deals with the code behind. To let the reader the ability to understand and play with the markup language before reading the code behind chapter, I have created an open source project named RibbonExpolorer. The Ribbon team from Microsoft has also created such a tool named PreviewRibbon that they have just released.

Both tools are good and both gives you the ability to play with the markup language. The main difference is that the RibbonExplorer is built in C++ using ATL while the PreviewRibbon is built in WinForm using .NET and COM interop. RibbonExplorer also gives you the ability to change property values on the fly. So if you are a .NET developer that want to have a WinForm based application for Windows 7 and you want to have a Ribbon you can use the PreviewRibbon sources as a good example for interoperating . Another great wrapper for .NET and WinForm can be found in Arik Poznanski blog series about the Windows 7 Ribbon.

And again for full explanations of the Ribbon Markup Language and the Code behind, read the two chapters in the book.

Make your application runs and shines on Windows 7

Alon Fliess — Fri, 07 Aug 2009 10:21:00 GMT

Moving applications to new platform is not an easy decision to make. Sometimes you have no choice, new desktops and laptops run the new operating system and you have to support your clients. Sometimes you do have a choice, you install your application with the system and you can choose the operating system that your code will run on. There are two factors in this dilemma: first is the investment effort on making the application compatible with the new O/S comparing to the benefit (ROI). Second is that the application will probably need to continue running on the old operating system. In the case of Windows 7, if you have moved to Windows Vista, compatibility is almost not an issue, but if your application is still running on Windows XP than you have to invest a little to move it to the new platform. To help you moving to a new platform Microsoft DPE has contracted us (Sela) to develop Compatibility Labs (Part of the Windows 7 Training kit) that guide you through the common compatibility issues that you may encounter moving your application from Windows XP to Windows 7. The labs provide two levels of information on each of the problems. The first level is based on few slides that describe the problem and the way to solve it, and a deeper level that gives you much more details as well as a code sample of the problem and the solution, both in native (C++) code and managed (C#) code.

So, you have moved your application and it now can run on both platforms, now it is the time to make it Windows 7 friendly. Here you have another dilemma, most of the new features are Windows 7 only features, some are Vista based and other will be downgrade also to Windows XP. If you will use a Windows 7 only feature, your application will not run on Windows XP.

To solve this problem I like to divide the new features to two groups. The first group is the group of features that you based your application core implementation on. For example, if you decide to use the .NET framework 3.0 as your runtime, you cannot install your application on Windows 2000. For the most of us, this is not an issue, for others it is a show stopper. So if you need I/O priority and Transactional File System for your application implementation, you need Windows NT 6.0 (Vista, Server 2008) as your minimum bar. In 4-5 years, for most of us it may be not an issue.

The second group is the group of features that make your application shines on the new platform, or at least looks new and modern like the new platform does. For Windows 7, the Ribbon, the Taskbar, Multi-touch support and Restart Manager are good samples of such features. With good design you can add these features to your application as add-ons making it compatible to Windows XP and great on Windows 7.

To learn how to use these new features we have made with Redmond DPE two projects. The first one is the Windows 7 Training Kit it contains slides, demos and Hands on Labs for the new Windows 7 features. You will find .NET (C#) labs and demos as well as many native (C++) labs and demos. If you have downloaded the RC Kit in the past, download again. We have added new labs for the RTM.

The second way to learn how to use new features in Windows NT 6.0 and Windows NT 6.1 is to download the XP2Win7 project. The project is still in its beta phase and we are working hard to fix bugs, simplify it and add some more features. XP2Win7 is an application that can be installed and runs on 9 different platforms (only 8 have been tested). The platforms are Windows XP, Windows Vista x86, Windows Vista x64, Windows Vista WOW 64 (x86 on x64 machine), Windows 7 x86, Windows 7 x64 and Windows 7 WOW64. Of course it should run also on the server platforms, but we have not tested this scenario.

When you install the application on Windows XP, you get a simple picture album viewer. Installing it on Windows vista enables new features such as Aero Glass, Restart Manager, NT service is moved to be a Scheduler Task, A preview handler for the album is installed, Transactional NTFS is used with SQL server. Moving to Windows 7 enables another set of features such as Shell Library support, Taskbar integration, Multi-touch, Sensor and Location and Trigger Start Service.

The installation kit also installs the source code. To build the application you need Windows 7, Visual Studio 2008 SP1, Windows 7 SDK (most of the code is managed and can be built and “single-step debug” without the need for the SDK). To build the native x64 project you need to install the x64 compiler tools that are not installed by default by the VS 2008 setup program. To run the application you also need SQL Server express edition. We are planning to lower the bar and remove the SQL Server dependency from the code. So if you want to see how to do a distributed transaction of TxNTFS and SQL Server, download the beta code, it will not be there in the release.

This is also the place to thanks Yochay Kiriaty from Redmond DPE that gave us the chance to be part of such great projects and to David Bassa the CEO of Sela that made it possible. Also thanks to Dima Zurbalev, Sasha Goldshtein, and Noam Sheffer that spent (and still) nights (daytime at Redmond) and days in the last few months and to Josh Reuben, Ariel Ben Horesh, Ram Dayan, Konstantin Triger, Tomer Shamam and Pavel Yosifovich that also took part in the projects.

Stay tune, more projects are coming!

Finally – Our Windows 7 .NET Wrappers are out

Alon Fliess — Sat, 14 Mar 2009 08:45:00 GMT

During the last few months a small team from Sela, has developed course materials, exercises and demos for the DPE Metro Program, that show how to develop with the new features of Windows 7. As you may know, all of the new feature of the system are exposed to native developer, using Win32 API and COM. To use C# and .NET we developed set of wrappers. Sasha developed the Taskbar wrappers, and also wrote about it in his blog. Dima developed the Sensor & Location Platform wrappers and I developed the Shell Libraries wrapper and the Multi-touch wrappers.

You can download these wrappers from here:

Taskbar & Libraries

Sensor & Location Platform

Multi-touch

For the Taskbar & Libraries we have used the Vista Bridge project with few modifications. The other wrappers don’t depend on the Vista Bridge. Currently the Windows Bridge team is looking at our wrappers as a prototype for the next version of the bridge, and they are in contact with us.

So, what is in there for you?

Sasha has wrote a lot about the Taskbar. I will talk briefly about the other wrappers and in future posts I will dive into the gory details.

Sensor & Location Platform

The Sensor API is designed for working with sensors (light, accelerometer, buttons, temperature, etc.) in a vendor-independent manner. In previous Windows versions you had to learn and target each vendor's specific API.

The Location API builds upon the Sensor API and provides location information for location-aware application. The location information may be provided from many different sources: GPS, WiFi hotspot or GSM cell triangulation. Windows 7 Sensors and Location platform selects for you the best source automatically with no need to even understand the different providers. For the developer, this new set of APIs provides an abstraction of the underline infrastructure freeing the developer to handle the high level of application logic.

The API has many benefits (a partial list):

1. Frees you from the burden of interpreting various protocols used by GPS receivers (NMEA +non-standard extensions, NMEA2000 and others.

2. Not bound to any particular technology or vendor. No need for serial port/emulation.

3. Multiple applications may use the information simultaneously.

The S&L (Sensor & Location) wrapper is a framework that provide a managed access to the S&L Platform. It is a framework, because the design allows hardware vendor to extend the wrapper to support new .NET sensor types.

As opposed to the native API that are based on COM GUID for any type information the .NET wrapper is based on strong type design. This means that the developer knows the sensor type that she uses, and the exact report that she gets. For example for ambient light sensor, a specific data report will be generated with a strong type property telling the light intensity reading in LUX. In future post I will talk more about the wrapper.

Shell Library

Windows 7 introduces a new concept of Libraries as destinations where users can use their files as collections of items that may span multiple locations across computers. Libraries supersede the functionality of previous Windows versions known folders (e.g. Documents, Pictures, Music) and replace them as a main “storage” destination. Applications have a straightforward method for interacting with Libraries programmatically with the Library API. They can create, interact with and support Libraries as first-class items in their experiences.

In previous versions of Windows, each application had its own proprietary library. For example, Windows Media Player had a different set of scopes than iTunes and neither was consistent with your Music Folder. With the Library API applications can define and consume a consistent set of user-defined scopes.

Libraries may also contain network folders. This enables a better user experience at work and at home. Whenever the user opens a common file dialog he or she gets an aggregation view of all of the library locations that are available.

The Shell managed wrapper can be found under the Windows7.DesktopIntegration.dll. It contains wrappers for the new Windows Shell Taskbar and the new Windows Shell Libraries which in turn depends on the Windows Vista Bridge. The Vista Bridge that comes with this project is based on version 1.4, and it is slightly modified to support some of the new Windows 7 features.

To support the Windows Shell Libraries operations, the Windows 7 Integration Library contains the ShellLibrary class. The class has few static functions to create, load or delete a library and many other instance methods to work on the library instance itself.

Using the class is just a matter of using one of the static functions to get a ShellLibrary instance and then calling a method on that instance. The following code opens an existing library and adds new folder location to it:

public static void AddFolder(string name, string folderPath)

{

using (ShellLibrary library =
ShellLibrary.Load(ShellLibrary.CreateLibraryFullName(name), true))

{

library.AddFolder(folderPath);

}

More on Shell Libraries in future posts.

Multi-touch

One of the more exiting features of Windows 7 is the multi-touch support. First I have to admit that I had so much fun writing code and cool demos for multi-touch. I have two multi-touch machines, one is the HP Touchsmart, a 25.5” dual touch all-in-one computer which runs the Windows 7 beta 64 bit version, and another Dell latitude XT machine, that has a true multi-touch support from N-Trig which runs the 32bit version of Windows 7.

Windows application can target one of 3 levels of touch integration:

Good: No specific touch APIs are used but the application UI is appropriately sized and
works well with the built-in gestures

Better: The gesture APIs are supported to give
smooth natural interactions

Best: Deep touch focused experiences designed
to take advantage of Multi-touch

Windows 7 User32 controls have built-in support for multi-touch, for example you can scroll text in a Window using your fingers.

When you want to add touch support to your application you need to get touch information from Windows. There are two different approaches to choose from. The easiest approach is to let Windows understand the user intent. The user uses her fingers to take actions like rotate, translate, scale, double finger tap, and so on. You can ask Windows to interprets these actions to a simple Windows message called gesture, that informs your application about the specific action with the related data. For example the user did scaling operation with 2.5 scaling factor. There are two main problems with this simple approach. The first is that you get only one interpretation for the user action. If the user rotate and scale in the same time, you will get only one gesture, not both. The second problem is that is the user needs to manipulate more then one object in the screen, let say by using her two hands, or another user’s hand, you will not get the correct interpretation at all.

To overcome these problems you should register to get the low level Windows Message, which is the WM_TOUCH message. This gives you the row touch information. You need to decode the message, there is a good chance that this one message contains many different touch messages from each and any of the fingers that simultaneously touch the screen. The next action is to decide which message is belong to which item. Suppose you have many pictures on the screen, you need to correlate the touch message to the target picture. This can be done by doing hit-test using the location information of the touch event. Now you have to figure out what is the user intent. This is a hard task if you need to do it yourself, but don’t worry, Windows 7 provides a Manipulation Processor that does it for you. All you need to do is to pass the row touch message to the Manipulation Processor, and to get the Manipulation Delta event from it, which in turn is very similar to the gesture information, but include all the actions together. If you also want to have an inertia on each of the object you can use the Inertia Processor. This Processor is a little bit complicated and I will write about it in a future post.

All of those messages and API are native Win32 and COM based. WPF 4.0 will have a full support for touch enabled applications, including Manipulation and Inertia. If you don’t want to wait to WPF 4.0 or you need to crate WinForms base touch enabled applications, you can use our wrapper. The wrapper lets you create a touch handler for WinForm, or WPF (or even for any User32 Windows Handle). This handler can be GestureHandler or TouchHandler. After creating the handler you should register for the gesture or touch events. If you use the TouchHandler you will probably create at least one instance of ManipulationProcessor or ManipulationInertiaProcessor which wrapps the native COM based processors.

If you have a WPF 3.5 application you can use the stylus events as touch events, just use the WPF handler to enable WPF touch events.

To get better understanding of how to use the touch wrapper we created many demos, for WinForm, WPF and even a C++/CLI Win32 application that uses the wrapper. I will write a future post with more details.

Summary

Windows 7 is a cool operating system. The end-user gets a better experience when using the Shell and the built-in applications, but it is our task to use the cool features in our own applications. For the .NET developer, we will get better support in the future, whether in .NET 4.0 or from the Windows Bridge team, but for now you can enjoy using the wrappers that we developed for DPE.

Back to the Future - Summary of my lecture at Tech-Ed Eilat

Alon Fliess — Mon, 07 Apr 2008 17:05:17 GMT

Technorati Tags: COM+,WCF,Architecture,C++,SOA,.NET

For all of you who have been at my lecture I hope that you enjoyed and that you have learned few new things, If you didn't get my message, here is a summary:

Think about the future, the present is the past of the future.
Invest in the architecture.
Decoupling is the name of the game, always was and always will be.
Know your framework roadmap.
New technologies make decoupling easier.
Using WCF interoperabilities lets you re-use old code component
Using WCF interoperabilities lets you use WCF based service as a component
Porting ASP.NET ASMX based web services is easy
Porting Remoting to WCF may be a little bit harder

The setup of the demo solution:

On Vista: If UAC is enabled, run VS2008 under the Administrator's credentials
Install the databases using the provided teched2008.sql script. This installs three databases, one for the ATL based bank, one for the EnterpriseServices based bank, and one for the WCF IMax ticket ordering service.
The Banks' Databases need some valid accounts, add a client to the CPPBank and a business account to the ESBank.
On Vista: To host the service in a process that is not run under admin, you need to execute the CounfigureNetwork.bat batch file (under admin rights)
Open the solution, Select the target architecture (x64 or x86) and build it. (The x64 version is fully tested, the x86 may need some tweaks in the post build actions)
After (any time you do it) you reregister one of the COM+ application to the COM+ Catalog, you need to configure the COM+ service. Use the addresses from the endpoint addresses.txt file, otherwise you will have to update the service references of the WCF clients.

The solution:

The UI:

Activate the Services and place an order. To use the WF, check the "Use WF" and activate the host.

You can download the presentation from here, and the code from here.

I will be more than happy to get your feedbacks.

Enjoy!

337 - ORPC to SOA or as I call it Back to the Future, Tomorrow morning

Alon Fliess — Mon, 07 Apr 2008 02:46:00 GMT

If you are in Tech-Ed Eilat, remember to come to my lecture on Monday 7/4 at 09:45, Topaz Opel room, Hilton.

Why do you want to be there:

I will take you to a time travel
You will see plenty of technologies speak together:

C++, ATL, COM, COM+, VB Script, C#, Enterprise Services, WCF, Windows WF, .NET Remoting, ASP.NET ASMX
I use the OLE DB Template technology to access database in ATL
I Use LINQ to SQL technology to access database in C#
And I use WPF in my client code!

I will show you some real magic
If you want to move to WCF (.NET 3.x) but keep your current investment you must come and see how.
If you need to call a service from an existing VB 6.0 or native C++ code with no need to upgrade it, come and see how.

See you tomorrow!