Pavel's Blog

Color Gradient Generator

pavely — Tue, 12 Nov 2013 20:49:51 GMT

A while back, I created a WPF Mandelbrot Set program with zoom abilities. I demonstrated the use of async/await for writing code that works asynchronously (to keep the UI responsive), but is easy to write as synchronous code. Here’s a sample image:

The image is grayscale, so I wanted to make it use colors, to indicate the level of “being part of” the Mandelbrot set. The problem here is how to create a nice color gradient that moves smoothly from color to color.

One possible option might be to leverage an existing class, such as WPF’s LinearGradientBrush, set up a bunch of gradient stops with the colors to be interpolated, and then extract a color in a specific offset as needed. There are two issues with this: the first is that LinearGradientBrush has no method to get the color at a specified offset, and second, I would rather create a generic algorithm that did not depend on a particular technology.

My goal would be to create a color gradient of some kind and apply it to the Mandelbrot set to get images such as the following:

There are several ways to do this, here I’ll describe one that works for me, and is not too complex to understand and implement.

The idea is to change the color based on a sine wave. This gives a nice smooth gradient effect (although it’s not linear, which is not a requirement anyway). By changing the frequency of the RGB components (we could theoretically work with other color spaces such as HSV) we can get various gradients. Also, we can also play with the phase of each color component, creating a “shifting” effect. The basic implementation of such a gradient can be implemented like so:

 public Color[] GenerateColors(int number) {
    var colors = new List<Color>(number);
    double step = MaxAngle / number;
    for(int i = 0; i < number; ++i) {
        var r = (Math.Sin(FreqRed * i * step + PhaseRed) + 1) * .5;
        var g = (Math.Sin(FreqGreen * i * step + PhaseGreen) + 1) * .5;
        var b = (Math.Sin(FreqBlue * i * step + PhaseBlue) + 1) * .5;
        colors.Add(Color.FromRgb((byte)(r * 255), (byte)(g * 255), (byte)(b * 255)));
    }
    return colors.ToArray();
}
 

Where the Freq* are the frequencies of the respective RGB colors and Phase* are the phase shift values. Note that all calculations are done with floating point numbers (ranging from 0.0 to 1.0), converting to a WPF Color structure (in this case) at the very end. This is simply convenient, as we’re working with trigonometric functions, which like floating point numbers rather than integers. The result is normalized to the range 0 to 1, as the sine function produces results from –1 to 1, so we add one to get a range of 0 to 2 and finally divide by 2 to get to the desired range.

To create nice gradients, a lot of trial and error is needed. To make things easier, I created a helper program that allows changing the aforementioned properties using sliders, getting an immediate feedback of the result. I also added an option to export the selected values to an XML file and vice versa for importing. Here are some screenshots of the tool:

The Size slider sets the number of color entries in the returned array, and the MaxAngle parameter effectively sets the number of sine cycles to use; or put another way, the rate in which the gradient changes.

The color gradient generator and the color based Mandelbrot set can be downloaded from the following link:

Async Mandelbrot Color

MVVM View vs. Control

pavely — Sun, 03 Nov 2013 12:41:55 GMT

In the MVVM world, Views are attached to ViewModels. How can a view be implemented? Typical answers for say, WPF, are: Window, User Control and Data Template. Similar answers exist for Windows Phone and Windows 8, where “Window” may be dropped or replaced by Page.

This is certainly true, but about that User Control? Can any user control automatically be considered a View? Not quite.

The distinction between view and control (user control or otherwise) is based on reusability and dependency. A View requires a ViewModel to give it context. A View cannot function without a ViewModel. Typical XAML View would hook up to properties exposed by the ViewModel like the following:

<TextBox Text=”{Binding ItemName, Mode=TwoWay}” />

The lack of Source or ElementName in the binding indicates that the source is the closest DataContext, which is typically the ViewModel instance attached to the View.

The View is completely dependent on that ViewModel for data (and possibly commands to invoke), and is not intended to be reused in other applications. This is regardless of the actual implementation object, whether that is a Window, User Control or Data Template.

A User Control, on the other hand, when built as a control (and not a view) is independent and hopefully reusable. If it has any binding expressions in its XAML, they bind to its own properties, which of course are meant to be set by the control’s client. Such a control can typically be reused in many apps. A View may, for instance, use the Control as part of its user interface.

Here’s a simple example: login control/view.

Such a control, when built as a view would have a TextBox for username, similar to the following:

<TextBox Text=”{Binding UserName, Mode=TwoWay}” … />

When built as a control, that same TextBox would have markup similar to the following:

<TextBox Text=”{Binding UserName, ElementName=This, Mode=TwoWay}” … />

Assuming “This” is the x:Name of the User Control itself (not an external name), and UserName is a dependency property that the control exposes.

For the latter case, a Login View would be able to use the Login User Control as part of its UI, perhaps adding a “Forgot password” button to the UI. The aforementioned username would be hooked up as follows:

<mycontrols:LoginControl UserName=”{Binding UserName, Mode=TwoWay}” … />

Where the second UserName is a property of the ViewModel; in this simple case, with the same name as the property of the login control itself; this is certainly not necessary.

To summarize, a true control is independent of any ViewModel, and is built as such for maximum reusability. A View is much more specific, serving the purpose of a particular application, where reusability is not necessary nor needed; it’s tuned to the specific app’s requirements.

Using KeyedCollection<> instead of a Dictionary<>

pavely — Wed, 23 Oct 2013 14:00:35 GMT

The System.Collections.Generic.Dictionary<TKey, TValue> class is one of the most useful of all .NET collections. It maps a key to a value, and allows for fast retrieval based on the key, as it’s implemented as a hash table, calling GetHashCode on the key object to get to a specific “bucket”, and then looks up the actual value (with Object.Equals or a specific IEqualityComparer<Tkey>.Equals).

One feature that Dictionary<> doesn’t support is the ability to access items by integer index. That is, insertion order is not maintained. For most cases, this may be ok, but some cases require fast search and index based access.

Some values contain the keys themselves. Here’s a simple Customer class:

 class Customer {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Address { get; set; }
}
 

Let’s suppose that the Id of a Customer is unique, and so can serve as a key. Here’s a dictionary of such customers:

 var customers = new Dictionary<int, Customer>();
customers.Add(1, new Customer { Id = 1, Name = "Bart Simpson" });
customers.Add(20, new Customer { Id = 20, Name = "Homer Simpson" });
 

This seems harmless enough, but notice that the key (Id) is supplied twice. This may not seem like a big deal, but the key could be a more complex entity. It’s also not as elegant as we would like. I’d rather just use code like the following:

 customers.Add(new Customer { Id = 1, Name = "Bart Simpson" });
 

And get the same result, that is, the Id is still a key to search by. Dictionary<> cannot take that syntax. Enter KeyedCollection<>.

KeyedCollection<TKey, TValue> is an abstract base class that inherits from Collection<TValue>, thus giving it index-based access. A requirement is that the key is somewhere inside the value, or connected to the value, as is the case with our Customer class. The only question remains is how to return a key based on a value?

This is why we need a new class, extending KeyedCollection<> and overriding a single abstract method, GetKeyForItem:

 class CustomerCollection : KeyedCollection<int, Customer> {
    protected override int GetKeyForItem(Customer item) {
        return item.Id;
    }
}
 

This says that given a Customer, its key is its Id. Now we can use this class as follows:

 var customers = new CustomerCollection();
customers.Add(new Customer { Id = 1, Name = "Bart Simpson" });
customers.Add(new Customer { Id = 20, Name = "Homer Simpson" });
 

We just add Customer objects, and internally they are keyed by Id. The Add method used is the one from Collection<TValue>. This means, we can also access customers by index, or search using the Contains method.

As an extra bonus, the KeyedCollection<> can be configured to not create an internal Dictionary<>, depending on the number of items. For a small number of items, Dictionary<> is an overkill, and a linear search is faster. By default, a Dictionary is created upon first insertion, but this can be configured by using one of KeyedCollection<>’s constructors.

The idea of mapping a value to a key as was done in GetKeyForItem can be generalized, so that we don’t have to create new classes for new types. Here’s a generalized class that uses a delegate to execute the required code in GetKeyForItem:

 [Serializable]
public sealed class GenericKeyedCollection<TKey, TValue> : KeyedCollection<TKey, TValue> {
    Func<TValue, TKey> _itemKey;
 
    public GenericKeyedCollection(Func<TValue, TKey> itemKey, IEqualityComparer<TKey> comparer = null, int threshold = 0)
        : base(comparer, threshold) {
        if(itemKey == null)
            throw new ArgumentNullException("itemKey");
        _itemKey = itemKey;
 
    }
 
    protected override TKey GetKeyForItem(TValue item) {
        return _itemKey(item);
    }
}
 

With this class in hand, we can create a Customer collection like so:

 var customers = new GenericKeyedCollection<int, Customer>(c => c.Id);
 

Pretty neat.

Tip: Turning Win32 Console app to non-Console app

pavely — Mon, 30 Sep 2013 18:51:20 GMT

Let’s say you’ve created a Win32 Console Application in Visual Studio:

We get the classic main function.

Now suppose that after working on the project for a while we want to turn the app into a Windows app – no console. At first, this seems easy: just replace the main function with a proper WinMain:

 int _tWinMain(HINSTANCE hInstance, HINSTANCE, LPTSTR lpCmdLine, int nCmdShow)
 

Unfortunately, that’s not enough. Building the project produces the following linker error:

MSVCRTD.lib(crtexe.obj) : error LNK2019: unresolved external symbol _main referenced in function ___tmainCRTStartup

The linker still expects a main function.

The solution is (apart from creating a new project, adding the files, making any changes to the project again) is to switch the subsystem by using the Linker / System property tab and changing SubSystem to Windows (instead of Console):

And voila! The project links successfully.

Getting rid of the Start button – Adding a Hook

pavely — Mon, 16 Sep 2013 19:42:29 GMT

In the previous post we saw how to find and remove the start button and move the task bar window to the left to occupy the free space left by the former start button.

However, we saw that by opening the system tray, the task bar moves back to its original position. We need to know when that happens, and then use the same trick to move it back to the “right” position.

To do that we would need to register somehow for the WM_MOVE message. This is one option, and we can verify this using Spy++’s Message window for task bar (again, another exercise for the reader).

The problem is that in Windows, a window message is posted or sent to the thread that created the window. Since the task bar was created by some thread in Explorer.Exe, clearly we can’t just expect that message to arrive at our doorstep. For that, we need a hook.

The term “hook” signifies some kind of interception mechanism, and indeed this is its meaning in this case. We want to know when the task bar’s creator thread receives such a message and act accordingly.

This kind of hook is supported by the Windows subsystem through the SetWindowsHookEx API function. It allows (among other things) to look at messages targeted at a particular thread (what we need) or even every thread on the current desktop (which may be useful for system-wide, or at least desktop-wide, hooking).

Before we call this function, we need to prepare a few things. The first and most important thing is to create a DLL. This is necessary, as our hook function is called in the context of the thread that created that window, which means it’s running under an Explorer.Exe process. The only way to provide our own function in this way is to place it in a DLL. The hooking API will inject our DLL into Explorer’s process automatically.

Another thing to bear in mind is that the DLL must match the “bitness” of Explorer.Exe, meaning it has to be 32 bit on 32 bit Windows, but it must be 64 bit on 64 bit Windows, because a 64 bit process cannot load a 32 bit DLL (or vice versa).

Add a new project to the existing solution of type “Win32 Application” and select a DLL project with a suitable name, like so (you can check the Export Symbols option if you want):

Next, we’ll link with the DLL in our hosting EXE, like so:

 #ifdef _WIN64
#pragma comment(lib, "..\\x64\\Debug\\RemoverHook.lib")
#else
#pragma comment(lib, "..\\Debug\\RemoverHook.lib")
#endif
 

We need to link with the correct LIB based on bitness. For x64 projects, the _WIN64 macro is defined and so leveraged here.

The next step is to create the actual hook function in the DLL; this must of a certain prototype, as mandated by the SetWindowsHookEx function:

 LRESULT CALLBACK HookFunction(int code, WPARAM wParam, LPARAM lParam) {
 

To make the function visible outside the DLL, we’ll add a DEF file (File / Add New Item) and place the function’s name (HookFunction in the example under the EXPORTS part):

 LIBRARY
EXPORTS
    HookFunction
 

Before we complete the function’s body, let’s set up the hook in the EXE. After we got a handle to the ReBar control hosting the Task Bar, we need to find out the thread that created it (inside Explorer):

 DWORD tid = ::GetWindowThreadProcessId(hReBar, nullptr);
 

GetWindowThreadProcessId returns the thread ID of the window’s creator and optionally the process ID as well (not interesting for us, hence the nullptr). Now we can set up the hook:

 HINSTANCE hDll = ::GetModuleHandle(L"RemoverHook.dll");
HOOKPROC hookProc = (HOOKPROC)::GetProcAddress(hDll, "HookFunction");
s_hHook = ::SetWindowsHookEx(WH_CALLWNDPROCRET, hookProc, hDll, tid);
 

We get the HINSTANCE of the DLL and the address of HookFunction and call SetWindowsHookEx with a WH_CALLWNDPROCRET hook type, which provides messages after they have been processed by the target thread; we could have used another hook where we see the message before it gets handled and we could even cancel it, but this is good enough.

The hook handle (s_hHook) is stored in a shared memory section inside the DLL, along with the ReBar control handle, so that both processes (our hosting process and the injected process, Explorer.Exe) have easy access to these:

 #pragma data_seg("Shared")
__declspec(dllexport) HHOOK s_hHook = nullptr;
__declspec(dllexport) HWND s_hRebarWnd = nullptr;
#pragma data_seg()
#pragma comment(linker, "/section:Shared,RWS")
 

This is a nice trick to get shared memory without resorting to memory mapped file objects. The last line has “RWS” as attributes to the data segment, where “S” is the important part, making it shared. Without it, these variables would be private to each process, just like any global variable in a DLL.

Next, we implement the hook function like so:

 LRESULT CALLBACK HookFunction(int code, WPARAM wParam, LPARAM lParam) {
    if(code < 0)
        return ::CallNextHookEx(s_hHook, code, wParam, lParam);
    auto msg = (CWPRETSTRUCT*)lParam;
    if(msg->message != WM_MOVE || msg->hwnd != s_hRebarWnd)
        return ::CallNextHookEx(s_hHook, code, wParam, lParam);
    if(s_hRebarWnd) {
        RECT rc;
        ::GetWindowRect(s_hRebarWnd, &rc);
        ::SetWindowPos(s_hRebarWnd, nullptr, 0, 0, rc.right, rc.bottom - rc.top, SWP_NOZORDER | SWP_NOACTIVATE);
    }
    return ::CallNextHookEx(s_hHook, code, wParam, lParam);
}
 

If the hook action code is zero or above, we can act. The documentation states that lParam is a pointer to a structure, CWPRETSTRUCT, containing all the information about the message. if it’s in fact WM_MOVE and the window is the ReBar control, then we simply move it to the left in the same way it was done from the hosting executable and that’s it.

One final thing to do – our EXE can’t exit – if it does, the hook is automatically “unhooked”, so a simple call to Sleep(INFINITE) would keep the process alive and unobtrusive.

Just as a final proof, we can open Process Explorer, and look at Explorer.Exe for our injected DLL:

If you’re feeling like it, you can add some GUI and allow removing and restoring the Start button, if you so desire. The complete source code can be downloaded here.

Getting rid of the Start button in Windows 8.1

pavely — Sun, 15 Sep 2013 15:52:57 GMT

Windows 8.1 brings back the famous Start button, but alas – it’s not the good Start button from Windows 7. It’s just yet another way to get to the new Home screen. This makes the Start button (at least for me) completely useless, as there are already several ways to get to the Home screen (Windows key on the keyboard, mouse moved to the bottom left corner, touch devices can press the hardware Start button, the Charms bar has a Start button…).

There are utilities that can simulate the old Windows 7 Start button, if I don’t have such a utility, at least I’d like to get rid of the button, since it takes valuable space on the task bar. But how?

My first guess would be that the Start button is a Window, so it has an HWND. Let’s find it and then get rid of it by closing it or hiding it. How can we find the Start button’s HWND? We turn to our trusted tool, Spy++.

Search (in Windows, if you have Visual Studio or the Windows SDK installed) for “Spy++” or “Spyxx” and run the tool (at this point it doesn’t matter if you run the 32 or 64 bit version). This is how the tool looks like when run:

We need to find the HWND of the Start button. For this we’ll open the Spy menu and select Find Window…. A small window appears with a “bullseye” crosshair which we can drag on top of any window to get some more information:

Click and drag the finder tool over the Start button and then release the mouse button:

(The Handle value itself may be different on your system). Click OK to see the properties of that Window:

Clearly, the Window caption is “Start”, so we got our man, so to speak. However, the caption “Start” may be localized, and perhaps it’s called something else on a different UI regional settings. To find the Start button in code, we’ll need something more definite. This is the Class name of the Start button’s Window, which we can find in the Class tab:

In classic Windows, every window belongs to a class. There are predefined classes like “button”, “listbox” and others, but for custom windows, new classes need to be created, as was clearly done with the Start button.

Next, we need to find out the relationship of the Start button’s window to the desktop, so we can find it. Clicking on the Synchronize button shows the Window’s position in the parent/child hierarchy:

Here we can see that the Start button is a child of a window with a class name of “Shell_TrayWnd”, which is in itself a direct child of the desktop.

Let’s start coding. Create a new Visual Studio C++ Win32 project (a normal EXE or a console app) (you can use any VS version for this (I’ve avoided C++11 specific features). Add an #include for <windows.h>.

In the main (or WinMain) function, we’ll get to the Start button in two steps: first, find that “Shell_TrayWnd” window and then the Start button itself:

 HWND hDesktop = ::FindWindow(L"Shell_TrayWnd", nullptr);
HWND hStart = ::FindWindowEx(hDesktop, NULL, L"Start", nullptr);
 

FindWindow looks for a top-level window (we can verify with Spy++ that the “Shell_TrayWnd” indeed is top level, but examining the “Windows” tab in the properties window of Spy++. FindWindowEx looks for a child window, given a parent window. Note that both functions can search for a specific class name, which is what we need. The functions can also search by window title, but that’s too brittle for most purposes, certainly for ours, as the “Shell_TrayWnd” window has no caption.

if we find the Start button, we can make it go away by destroying it (politely) or by simply hiding it (both approaches work equally well):

     if(hStart) {
//        ::SendMessage(hStart, WM_CLOSE, 0, 0);
        ::ShowWindow(hStart, SW_HIDE);
    }
 

I’ve commented out the destroying option.

When executed, this little app gets rid of the Start button!

Unfortunately, we’re not done yet. The button is gone, but it left out empty space, which we want to use for the TaskBar. We need to move a sibling window of the Start button, with a class name of “ReBarWindow32” to the left – this is the window that holds the TaskBar itself. We can verify this with Spy++, and I leave that as an exercise to the reader.

So, we continue with a similar searching technique to move the ReBar window like so:

 HWND hReBar = FindWindowEx(hDesktop, nullptr, L"ReBarWindow32", nullptr);
if(hReBar) {
    RECT rc;
    ::GetWindowRect(hReBar, &rc);
    ::SetWindowPos(hReBar, NULL, 0, 0, rc.right, rc.bottom - rc.top, SWP_NOZORDER | SWP_NOACTIVATE);
 

We locate the window, get it’s bounds into a RECT structure, and move it to the left to position 0,0. Note that if the TaskBar is docked to the left or right (as some people prefer), we’d have to change our code accordingly. I’ll leave that as another exercise for the reader.

Now we’re done, or at least it seems so:

Not quite, unfortunately…

Clicking on the system tray down arrow causes the taskbar to be restored to its former glory… including the Start button. It will not actually show, as it was hidden or closed, but the empty space returns.

What can we do about that? We need to write a hook – which we will in the second part of this post…

Interpreting a Handle’s Access Mask

pavely — Mon, 19 Aug 2013 08:13:38 GMT

When opening a handle to a kernel object with some Open* Windows API function (e.g. OpenProcess, OpenThread, OpenEvent, …) an access mask must be specified, indicating the type of access requested from the resulting handle. Requiring too much access may cause the call to fail, so a best practice is to require the only access flags that are needed to get the job done.

For example, suppose we want to know when a running process terminates. This requires obtaining a handle to the process in question and calling WaitForSingleObject on that handle. For this, only the SYNCHRONIZE access is required:

HANDLE hProcess = ::OpenProcess(SYNCHRONIZE, FALSE, pid);if(hProcess) {    ::WaitForSingleObject(hProcess, INFINITE);    printf("Process terminated\n");}

What if you have an existing handle, how can you see the access mask associated with the handle? Process Explorer can help.

Looking at the lower pane when a process is selected (switched to handle view, we can see the access mask column. However, by default, Process Explorer does not show the access mask:

Right click the header and select "Select Columns…". Check the access mask checkbox (at least):

Now the access mask is shown, but it's just a hex value. We need to interpret the bits, which unfortunately Process Explorer doesn't provide for us.

Sure, we can look up the various API docs and figure out the bits, but I've written a simple command line tool to interpret access masks. Running the tool without arguments shows its usage:

Let's try this with some random handles I see in the following Process Explorer snapshot:

Let's take handle 0x8, for some key object:

How about handle 0x1c?

This tool turned out to be useful for me occasionally, and maybe it will help you too.

You can download the tool from here.

My first PluralSight course has been published!

pavely — Thu, 08 Aug 2013 09:57:09 GMT

In the last few months, I’ve been working on a course for PluralSight.

Creating a video course is not easy, as I found out first hand. In fact, it’s more difficult than writing a book. With a book, I can change a sentence or a paragraph, at any time and any place. A video course is different… changes are hard, and recording sessions cannot be done just anywhere. But I’ve learned a lot from the experience, which should make next courses a bit easier…

My first course is about a favorite subject of mine, Windows Internals. This deals with the way Windows works, all the essential terms are there, such as processes, threads, virtual memory, user and kernel mode, device drivers and others. I’m showing various tools that can be used to look at these concepts, as well as some code, mostly in C++, but some in .NET. The course is pretty long, over six and a half hours, and I’m not nearly done. I plan to create a “part 2” for this, as there are topics I didn’t get a chance to cover in depth.

If you’re a PluralSight subscriber, give the course a look!

Extreme DevCon 2013

pavely — Mon, 15 Jul 2013 18:08:53 GMT

Next week, John Bryce Training, along with some of its partners, set up a two day conference named Extreme Dev Con 2013, on the 22nd and 23rd of July in Hertzliya (Israel). The conference consists mainly of full one-day seminars, several happening at the same time (naturally).

I will be presenting a full day seminar, titled something like “.NET deep dive for performance”. The rough topics are listed in the above link, but basically I will cover various topics that somehow relate to that elusive thing called “performance”. From process and AppDomains, through the garbage collector and friends, threads and tasks, perhaps some C# 5.0 with async and await, and also profiling, I will try to cover as much as I can with the time frame given. I will use a lot of code demos (and some tools) to make the theoretical concepts more concrete.

Registration is not free, unfortunately, but this should be worth it if you’re a .NET developer who cares about the code you write, and want to gain a deeper understanding to the way the CLR works and gain some practical insights into the framework’s power.

I hope to see you there!

Build 2013 Summary

pavely — Sat, 29 Jun 2013 05:07:09 GMT

The Microsoft Build 2013 conference is now over, so it’s time for some summaries and impressions. All the following is my personal thoughts from my viewpoint, and may not reflect the way things actually are. Last caveat – some of the information is based on the sessions I attended. Naturally, I couldn’t attend most sessions, and I may not even remember all info given in the session I attended. Still…

The conference was 3 days in length. With about 14 sessions going on at the same time slot, this is too short a conference; 4 days would have been better. Sure, all the sessions are recorded and will be available for viewing – but that’s not the point. If I just wanted to view sessions, I wouldn’t need to go to Build at all. The point of Build (besides the “experience” in general), is to be able to talk to people, especially from Microsoft and perhaps get some answers to nagging questions.

So, what’s new?

Nothing earthshaking. The conference date was unusual – not the October/November timeframe, but late June. This was (to me) a hint that Microsoft had something new to show the world; alas, I was disappointed. There was nothing really new; I can’t shake the feeling that if the dates were in October/November, there would have been truly new things to show.

Windows 8.1 – this is the next version of Windows. Windows 8 was called “Windows Re-imagined”, and Windows 8.1 is called “Windows Refined”, which is pretty accurate. No earth-shaking changes, but refinements and improvements across the board. Is that really worthy of a Build conference? I don’t think so.

So, what’s new? Here are some things I found interesting:

The Start button – a lot have been said about the return of the Start button (not quite the Jedi, unfortunately). There is a Start button on the TaskBar now, but clicking it does not open a Windows 7 style menu, but instead shows the tiles, although it maintains the desktop background. A new Apps view is available when swiping up (or pressing a down arrow at the bottom of the Tile screen). So now there are things in the Home Tile screen, but not everything (as was in Windows 8). You can opt-in and select which apps (Modern or Desktop) to show in the home screen.

This is pretty much the way it works in Windows Phone. And while in the Phone this is a good experience, in Windows 8.1 it’s not quite there. The problem is that the Apps view is still a mess; in the Phone it’s a nice list with search capabilities. In Windows 8.1 it’s a mess of apps, although the Search helps. Since Windows 8.1 is running on various form factors, but always larger than the Phone, this seems a below par experience. The new Start button is mostly useless.

However, there is a new option to boot to desktop. Here’s the TaskBar properties Navigation tab:

Windows Azure

Windows Azure is Microsoft’s cloud platform, and its capabilities are truly amazing. It’s not just the capabilities themselves, it’s much more than that. There are so many services exposed that rely on the Azure infrastructure, that developers are sure to find services that would make their lives easier when building all sorts of apps, from server based apps to mobile client apps. The number of services and the rapid pace of their inclusion is staggering. I remember not so long ago, when Azure was young (and it still is), where the basics where there, but not much more: web role, worker role, table and blob storage, queues and a basic service bus. Azure has come a long way since then with many services too long to list here. I recommend watching the second day keynote to get a sense of the new stuff.

Visual Studio 2013 and .NET 4.5.1

Microsoft unveiled Visual Studio 2013 preview, and at the same time released Update 3 for Visual Studio 2012. As was noted in Ballmer’s keynote, Microsoft has been moving to rapid release cycles for all (or at least most) products, including Visual Studio. many feature enhancements exist in the editor, the Edit and Continue feature is now supported for 64 bit .NET projects (as well as 32 bit), XAML intellisense can now help with standard Windows 8 / Windows Phone StaticResource values, and more. Debugging has been enhanced by a new hub for profiling and call stack information for async/await debugging. This means that when a breakpoint is placed after an await operation completes, the call stack shown includes call information before and after the await call.

To gain some of these features, .NET 4.5.1 is required and is installed automatically with the VS 2013 preview. There are some improvements in this release as well, but as you can guess from the version number, nothing earth-shaking.

C++

C++ got a few new features. C++ 11 features that were part of a compiler CTP back in November 2012 were incorporated in release form. async/await is not there yet (yes, I mean roughly the same feature as in C# – implemented with the concurrency::task<> class), by the way. In Heb Sutter’s talk, he said async.await (in C++) should be available after VS 2013 ships, sometime later this year. If you’re a C++ developer, you should watch his talk.

In the VS 2013 IDE, C++ enjoys some new features. One of them is the ability to format source code with rules for formatting, such as indentation, spaces, etc., just like in C#. I think it’s about time, and is a great feature. Pressing Ctrl+K,D (just like in C#) corrects the source code to comply with these formatting rules. Here’s a snapshot from Tools / Options:

Windows Runtime and Store apps

Naturally, there’s a lot of focus on these areas. Many new UI controls have been added to WinRT, usable by all languages leveraging XAML (C++ and .NET) and also from JavaScript (WinJS). Some new Binding properties have been added, getting closer to the Silverlight/WPF set, including UpdateSourceTrigger, FallbackValue and TargetNullValue. Curiously, no StringFormat just yet. A new markup extension, ThemeResource allows for automatic theme changes (Dark, Light, HighContrast) without restarting the app. It’s similar to WPF’s DynamicResource, but only works for theme changes.

Other improvements in the core WinRT exist as well. I suggest watching the relevant sessions to get all the details.

What about the desktop?

Windows Store apps are good and well, but what about desktop apps? It seems Microsoft has finally realized that although there are nearly 100,000 apps in the Windows 8 store, there are millions of desktop apps out there. These apps were neglected since the Windows 8 original release, and now some balance is being restored. There were sessions about desktop apps and new features they can use, such as DirectComposition (which is also the underlying composition engine in Store apps XAML engine), Direct2D (applicable to Store apps as well, of course) and some other features.

Still, this is not enough. Desktop apps are neglected. There was no mention of new features in WPF; this is really annoying, considering the many new UI controls added to WinRT. Some of these would be useful in the WPF space as well. However, WPF was mentioned twice in the second keynote! I though Microsoft may have forgot that WPF exists.

In the native C++ world, for desktop apps, XAML cannot currently be used. Microsoft seems to insist that C++ developers would have to continue using antiquated libraries, such as MFC, or some open source cross platform library, such as Qt. There is currently no decent native library from Microsoft for desktop apps. Since using WinRT types from desktop apps is possible, and in fact most can be used, I find this restriction artificial and unjust. There’s no reason to prevent XAML from working in desktop apps, and this seems to suggest Microsoft has not yet fully understands the importance of desktop apps, not just for existing apps, but for new apps as well. Not all apps benefit from a touch interface; some are only feasible with a mouse, menus and other common desktop app features.

Windows Phone

Sorely lacking new features and announcements was Windows Phone. There was no mentioning of Windows Phone 8.1 or any other new version, for that matter. It seems Microsoft chose to focus on Windows 8.1 as far as client platforms go. I managed to speak to one member of the Windows Phone team, and he basically said that this time all focus went to Windows 8.1, and (of course) he can’t talk about Windows Phone future.

There were about 20 sessions on Windows Phone, but there was nothing new, so this is more suitable for a TechEd conference, where the present is discussed. Build is mostly about the future, and this opportunity to talk about the Phone has been missed entirely.

Conclusion

There were other interesting things to look at, such as the new Kinect (part of XBOX One, but will be available for the PC as well, sometime in 2014) and some interesting innovations, mostly shown in the keynotes. Overall, this is not one of the best Build conferences. Hopefully, next Builds will be better.

Kernel debugging with a Hyper-V virtual machine

pavely — Wed, 26 Jun 2013 03:23:13 GMT

One of the best ways of investigating the way Windows works is through a kernel debugger. Windows supports a local kernel debugging mode that can be activated in one of two ways:

Setup windows to run in local debugging mode by running bcdedit /debug on from an elevated command prompt and then restart. Finally, run WinDbg and select File / Kernel Debug… from the menu and then select the Local tab and click OK:

The main downside here is the need for restart, and more subtly – some apps behave strangely when the debug flag is on.

2. Use the LiveKD tool from SysInternals. This doesn’t require the debug flag – just copy Livekd.exe to the folder where WinDbg is and run Livekd –w from an elevated command prompt.

The problem with both approaches is the fact that breakpoints cannot be set – the system is running. For breakpoints, another system is required. Using a second physical computer is usually inconvenient, if at all possible. Fortunately, a Hyper-V VM can be set up as a target system for kernel debugging with some simple configuration without having to run various scripts. Here’s how to do it:

Open the settings of the VM and expose a COM port as a named pipe (COM1 in this example):

The pipe name doesn’t matter.

2. in the VM, run msconfig.exe and select the Boot tab:

3. Click the Advanced Options… button and check the Debug checkbox and select COM1 as the debug port. Leave the default baud rate as is:

4. Restart the VM for the settings to take effect. Once this is done, the system will always start in debug mode, so nothing else is required on this target machine.

5. On the host machine, run WinDbg.exe elevated, and select File / Kernel Debug… menu option. Enter the pipe name as \\.\pipe\pipename, where pipename is the pipe name given in the VM settings (debug in our example):

6. Check the Pipe and Reconnect checkboxes. Click OK. Now the debugger command window shows this:

Opened \\.\pipe\debug
Waiting to reconnect..

7. Now click the Break toolbar button (or select Debug / Break from the menu, or hit Ctrl+Break). After a few seconds, the command windows will show the following, and the VM is completely frozen (this is from a Windows 7 32 bit VM):

Connected to Windows 7 7600 x86 compatible target at (Tue Jun 25 20:08:54.926 2013 (UTC - 7:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.17207.x86fre.win7_gdr.130104-1435
Machine Name:
Kernel base = 0x82610000 PsLoadedModuleList = 0x82758810
Debug session time: Tue Jun 25 20:08:50.420 2013 (UTC - 7:00)
System Uptime: 0 days 5:09:28.494
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*                                                                             *
*   You are seeing this message because you pressed either                    *
*       CTRL+C (if you run console kernel debugger) or,                       *
*       CTRL+BREAK (if you run GUI kernel debugger),                          *
*   on your debugger machine's keyboard.                                      *
*                                                                             *
*                   THIS IS NOT A BUG OR A SYSTEM CRASH                       *
*                                                                             *
* If you did not intend to break into the debugger, press the "g" key, then   *
* press the "Enter" key now. This message might immediately reappear. If it *
* does, press "g" and "Enter" again.                                          *
*                                                                             *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
8267a754 cc              int     3

You can now run any legal command that affects the target VM. If you don’t have symbols set up correctly for Microsoft’s symbol server, set the symbols path (File / Symbol File Path) to something like SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols (to connect to Microsoft’s symbols server and cache symbol files in c:\symbols) or more simply use the .symfix command, followed by .reload.

Use the .reload command in any case, to make sure required symbols are loaded. Then you can use the lm command to list the loaded kernel modules.

You can try something simple, like breaking when new processes are created:

bp nt!NtCreateUserProcess

Issue the g (go) command and do something in the VM that requires creating a process. A breakpoint like the following will hit:

Breakpoint 0 hit
nt!NtCreateUserProcess:
82866423 68b8060000 push 6B8h
Enter the !process –1 0 to find out which process invoked NtCreateProcess:

PROCESS 85c84cb0 SessionId: 1 Cid: 06d4    Peb: 7ffda000 ParentCid: 0664
     DirBase: bec0d300 ObjectTable: 97376718 HandleCount: 671.
     Image: explorer.exe

This is Explorer.exe. The sky is the limit from here…

WDCIL Presentation and Demos

pavely — Tue, 18 Jun 2013 19:48:13 GMT

This evening I gave a talk on the Task Parallel Library (TPL) and the asynchronous programming features of C# 5.0 & .NET 4.5 at the Israeli Web developers user group. Thank you all for coming, I had a lot of fun!

Although the TPL has been around in release for for more than 3 years, I’m still surprised to find developers who know little about and don’t use it. This is unfortunate, as I consider the TPL one of the best parts of .NET. I wish more developers learn it and use it. The same goes for C# 5.0. For those who attended, I gave away a free copy to one lucky winner of my book, WPF 4.5 Cookbook.

As promised, here is the SkyDrive link to the presentation and demos, some of which I didn’t show because of time constraints.

Link: http://sdrv.ms/13Z5L0U

My C# 6.0 Wish List

pavely — Wed, 05 Jun 2013 10:33:15 GMT

I’m on a wish list streak, so why not wish myself new features in C# 6.0?

There has been no public talk about C# 6.0 (or the next version of .NET, for that matter). Still, I imagine someone is working on that at Microsoft (maybe not Anders, who seems to prefer the JavaScript world, with his TypeScript language); hopefully, others have taken the lead for the future of C#.

Firstly, it must be well understood that adding features to a language is a big deal. Once added, these can never be removed. Whereas features to the .NET framework itself can be “deprecated” in future versions, and even eventually removed, languages don’t have that luxury. Someone somewhere may have used a feature you want removed, but you can’t because someone may have used it.

This is why adding features to C# is not just about throwing anything that comes to mind; features must be valuable in some sense, they must serve a purpose coming from necessity, or from the realization that something worthy is lacking.

That said, the following list is not a result of a complete or thorough considerations of various factors; it’s just some things I think can benefit the language and (of course) the developers that use it.

1. Generic operator constraints

I’ve been asking for that for years… and still hope to get it. The following code does not compile:

public static T Sum<T>(params T[] values) {    if(values == null || values.Length == 0)         return default(T);     T sum = values[0];    for(int i = 1; i < values.Length; i++)        sum += values[i];    return sum;}

The compiler refuses to use the + or += operators with an unconstraint generic type. Not all types have the + operator. The obvious solution is to constrain the generic parameter:

public static T Sum<T>(params T[] values) where T : operator+ {

However, that is not currently supported. The only supported constraints are base class, interfaces and a public default constructor. There may be reasons why this is not supported, but I think there are better reasons to have it.

Technically, we can get a similar effect that works with the C# 4.0 dynamic keyword:

public static dynamic Sum(params dynamic[] values) {    if(values == null || values.Length == 0) return null;     dynamic sum = values[0];    for(int i = 1; i < values.Length; i++)        sum += values[i];    return sum;}

This compiles and works correctly, but sacrifices type safety and performance, because the calls work through reflection (or custom dynamic binding if the object supports it), which may not be good enough for some scenarios. It does have an interesting advantage – it can work on values of multiple types, such as adding a vector to a point (not strictly mathematically correct, but useful in practice), or multiplying a matrix by a vector.

With operator constraints, it would be possible to (e.g.) create a single class to represent a mathematical entity that works with different precisions. For example:

class Matrix<T> where T : operator+, operator-, operator*, operator/ {    public static Matrix<T> operator+(Matrix<T> a, Matrix<T> b) {        //...    }}

This would allow a Matrix of double, float, int, BigInteger, Complex and any other type supporting these operators.

2. Auto implemented interfaces

An interface is an abstract entity, requiring implementation to be used. For example, calling Array.Sort with an array and an IComparer or IComparer<T> implementation can customize the way sorting works. For that, we have to create a class that implements the interface for just this purpose:

class Book {    public string Name { get; set; }    public string Author { get; set; }    public DateTime Published { get; set; }} class BookDateComparer : IComparer<Book> {    public int Compare(Book x, Book y) {        return x.Published.CompareTo(y.Published);    }}

Book[] books = ...;Array.Sort(books, new BookDateComparer());

This doesn’t seem too bad, but we’re losing code locality – the BookDateComparer class may be defined far away from where it’s used. I’d rather do this:

Array.Sort(books, new IComparer<Book> {                            int CompareTo(Book x, Book y) {                                return x.Published.CompareTo(y.Published);                            }                  });

And we have code locality. All methods in such interface need not have any visibility modifier – it’s really just for this implementation – it’s inaccessible to any other piece of code. We can also have other members (fields, properties) – these too need no visibility modifiers; they are private by definition.

Technically, simple interfaces such as IComparer<T> can be worked around with a generic class like so:

class GenericComparer<T> : IComparer<T> {    Func<T, T, int> _comparator;    public GenericComparer(Func<T, T, int> comparator) {        _comparator = comparator;    }        public int Compare(T x, T y) {        return _comparator(x, y);    }}

Array.Sort(books, new GenericComparer<Book>((x, y) => x.Published.CompareTo(y.Published)));

But this is insufficient for more complex interfaces, hence the feature suggestion.

3. Operators in interfaces

While on the subject of interfaces, I would appreciate the ability to define operators in an interface, so that implementations would be forced to support them:

interface IVectorOperations {    Vector operator +(Vector v);    Vector operator -(Vector v);}

This would allow executing operators through interfaces, which currently cannot work. From a syntax perspective, it looks a bit strange, as operators in C# are implemented as static methods. But using static methods in an interface is illogical. So I suggest the binary operators accept just one argument (which is the second), the first being the instance itself (this). That’s similar to how operators are typically implemented in C++.

The implementation syntax can stay the same (static method) or adopt this syntax (I’m not sure which is best).

4. Class-level and method-level using

The using statement (as bringer of namespaces for the compiler to search through) can only be used in the global section of the file and inside a namespace declaration. For example:

using System;using System.Collections.Generic; namespace DemoApp {    using System.Threading;     class Demo {    }}

Sometimes, however, certain types are needed in a class scope, or even a method scope. But using can’t be used there, forcing us to use the full name of the class, add a using at an allowed scope (possibly polluting other methods and classes) or use aliases (with using in allowed scopes). All these solutions work, but again, may cause issues and are against code locality. I would prefer something like this:

public void DoWork() {    using System.Threading.Tasks;     Task.Run(() => {        //...    });}

This constrains the using to a particular method where the Task class is needed, and may be the only method that needs it.

5. Multiple private inheritance (“mixins”)

Don’t be alarmed – I don’t want real multiple inheritance as in C++ – this would require a major change in the CLR, and in any case I don’t want that. Still, looking at C++, the concept of private inheritance has its advantages; the inheritance is of implementation only, invisible outside the class. Here’s my suggested syntax:

class Animal {... } interface IMammal { ...    } class Carnivore {    public void EatMeat() { ... }} class Sleepy {    public void Sleep() { ... }} class Tiger : Animal, IMammal, private Carnivore, Sleepy {    public void Eat() {        EatMeat();    // from Carnivore    }     public void Rest() {        Sleep();    // from Sleepy    }}

The Tiger class has two private inheritance classes: Carnivore and Sleepy. They’re pure implementation. Clients of Tiger can only see the Animal class and the IMammal interface.

This can be implemented by the compiler with a simple containment:

class Tiger : Animal, IMammal {    Carnivore _carnivore = new Carnivore();    Sleepy _sleepy = new Sleepy();     public void Eat() {        _carnivore.EatMeat();    }     public void Rest() {        _sleepy.Sleep();    }}

We just don’t have to see all the ugliness, and simply use privately inherited classes. In case of name clashes (e.g. an Eat method in Tiger and in Carnivore), we can use an extended syntax such as Carnivore.Eat() to call the method provided by the private inheritance. If the private classes require constructor arguments, they can be provided with the regular constructor like so:

public Tiger() : base(), Carnivore(10) {}

6. More generics features

Some more features I’d like to see with generics. The first is to provide a default for a generic type:

class MyClass<T = string> {}

This means using MyClass<> (with empty angle brackets would mean using MyClass<string>. This could be implemented using an attribute, much the same as default arguments (from C# 4.0) are specified.

The second feature is specializing for a particular type. For example, we have the List<T> class, but we may want to specialize for specific T, like the following:

class List<bool> : IList<bool>, ... {    public void Set(int bit) {        //...    }    //...}

This could be used for optimization and/or for expressing a better API (such as the Set method in the above example). The compiler should choose the most specific implementation, only reverting to the “true” generic type if no specific type fits.

Both of these features exist in C++ templates, and I’m certainly not “pushing” towards the template capabilities in C++ – template meta-programming and such is too much for C# and I think it’s inappropriate (and probably impossible to implement in the CLR). However, the above two features can be useful, and should require just slight modifications to the CLR.

7. Generic attributes

The last feature I’d like to suggest is generic attributes. Currently, custom attributes cannot be generic, and I see no reason why it should be so. It would be beneficial to write a single attribute that could be used with different types. Here’s an example:

class MyAttribute<T> : Attribute {    public int Value { get; set; }    public T Data { get; set; }} [My<string>(Value = 10, Data = "hello")]class SomeClass {}

The closest we can get today is use a Type constructor parameter, to “force” providing a type, but it’s difficult to get a value for that type (unless object is used).

8. Add some keywords to LINQ’s query syntax

I would add take (Take extension method), skip (Skip), union (Union), except (Except), intersect (Intersect). for example:

var query = from x in coll1 union coll2            orderby a            take 10            select a;

That’s my list for now. We’ll see if any of it comes true.

My Wish List for Windows “Blue”

pavely — Fri, 17 May 2013 21:48:09 GMT

Many rumors are flying around at this time about the upcoming release of Windows 8.1 (code named “Blue”, which represents a wave of product updates, including Windows Phone and others). I thought I‘d state my hopes for this release, not just in terms of user features, but also from a developer’s perspective. As a developer, I spend most of my time on my trusty laptop, not some tablet based device. Naturally, the desktop world is my friend.

The Windows 8 Start screen is close to perfect for tablet devices, but for the desktop – it’s practically useless. With many programs installed, it’s difficult to find anything in there. I use the excellent search facility of Windows 8 – just press the Windows key and start typing (although I wish all the search results would show - not separated to Apps, Settings and Files). This brings me to the first request – the Start button. Yes, it’s been rehashed quite a bit, but the organization of folders and shortcuts is invaluable and should be back at least on non-tablet devices, but preferably in Windows 8 Pro versions as well, as these devices are often used for development. And no, third party tools and extensions are not an acceptable solution.
Allow running Windows Store apps in a Window, not just full screen – this is also a popular request – and why not? In a tablet world this may be too much – but the desktop? Let me run what I want in whatever size I see fit. There’s really no reason not to allow this. If not that, at least allow more than one app to run concurrently in full screen in different monitors. A pretty typical development setting includes 2 or 3 monitors – I wish we had the freedom to use these as we see fit.
On the actual development front we have WinRT, which is a new platform based on the familiar COM foundation that has various “projections” to languages, such as C++, C# and JavaScript. However, this is only available (at least on the UI side) to Store apps. But why should that be? In the .NET world, there is WPF – arguably the most powerful UI platform on Windows. C++ developers had to use old libraries such as MFC to do their UI – but this model is still limited to the HWND-based Win32 behavior and restrictions. WPF gets rid of HWNDs, which is a major part of its power and flexibility. Now similar power exists for C++ developers but only under WinRT. Why should that be? Let’s have the power of no HWNDs in native code, too. All the required platform components are already there – Direct2D (which is really how XAML is rendered in WinRT), Direct Composition, the Windows Imaging Component (WIC), the Windows Animation Manager, Windows Media Foundation and more – it’s just a matter of allowing XAML usage in desktop apps, not just Store apps.
I’ve had customers that have been using MFC for years and exposed to WPF ask me more than once – why is there no WPF-like library in native code? Indeed, why? I remember in the beta days of WPF (then called “Avalon”), I searched the MSDN docs relentlessly, trying to find the native library that Avalon wraps. I was eventually astonished to find that there is none. WPF is a managed only library. But now, after all the WinRT work as been done, what’s stopping it from migrating to the desktop apps world? Nothing, in my humble opinion, and I wish that would happen. With the new C++11 features, a powerful native UI framework is sorely missing.
WinRT is based on ideas starting from WPF, but it’s a lot less powerful. It’s about as powerful as Silverlight 3. Yes, 3; not even 4, not to mention 5. I understand there was a lot of work involved in getting WinRT out there, so not all features could be implemented. I hope more features appear in Windows 8.1, comparable at least to Silverlight 5. I don’t expect the entire WPF library to be implemented, and in fact, some things are better off not being there, but I think it should get close. It’s frustrating working with WPF and then going over to WinRT only to find a lot of things missing.
Open up Windows Phone some more – Windows Phone 8 is certainly more “open” that Windows Phone 7.x. But it’s still pretty closed. One argument for that is the assurance that apps could not exploit the user’s information or device for malicious purposes. Sure, there is that risk. But that what capabilities are for. There is a capability for location awareness, for instance, so the user must consent to the app being installed on his phone (from the Store) based on the app’s advertised capabilities and requirements. I say – add more capabilities, but allow more freedom for phone usage.
While we’re on the phone’s subject – let’s have a window or an app that summarizes the things that have changed while the phone was unattended. Missed calls, messages, tweets, Voip calls, whatever – all in one easy to find list – not scattered around among the various apps as it is today.
There are other small features I can think of regarding the phone, but this one stands out; I won’t discuss the rest here.

There are more things I wish for the Windows OS – but I think that’s enough for the upcoming release. We’ll have to wait and see how much of it (if any) comes true.

XAML as DSL

pavely — Sun, 05 May 2013 20:14:34 GMT

About 3 years ago, when .NET 4 and Visual Studio 2010 were just released, I’ve blogged (part 1, part 2) about the changes that took XAML from its WPF inception to the System.Xaml namespace and System.Xaml.Dll assembly, to be available more generally, not just for WPF. I’ve shown that XAML is just a declarative way of creating objects, setting their properties – sometimes in interesting ways. I did promise at the end of that second post that I’d show how to use attached properties, but never did have the time to deliver. 3 years later, it’s high time I make good on that promise.

The idea of a Domain Specific Language (DSL) is not new. Probably the most well known DSL is SQL – a language for working with databases. A DSL is typically constrained to a specific domain or a specific task (hence the name). A DSL may be a completely new language (such as SQL), and this is termed “external DSL”, and it can be constructed using a specific language semantics, such as C#, by leveraging certain language features that make up the “new” language. in C#, extension methods and “fluent interfaces” are most often used for that task.

What about XAML? The declarative nature of XAML makes it a good candidate to be a DSL. It has simple and strict rules, but it allows extensions, with type converters, markup extensions and attached properties.

An example

Suppose we want to create a text adventure game (“interactive fiction”) language (yes, I know I have a fetish for text adventures…). We could use XAML to describe not just the world that comprises the game, but also the actions that need to take place in certain scenarios.

The first step is to create an object model suitable to describe a text adventure. Here are a few simple classes to get us started:

[Serializable][DictionaryKeyProperty("Name")][DebuggerDisplay("{Name}")]public abstract class Entity {    Dictionary<string, object> _properties;     public string Name { get; set; }    public IDictionary<string, object> Properties {        get {            return _properties ?? (_properties = new Dictionary<string, object>(4, StringComparer.CurrentCultureIgnoreCase));        }    }}

public enum RelativeLocation {    In, On, Under, Behind} [Serializable][DebuggerDisplay("{Name} ({GetType().Name}) {RelativeLocation} {Location}")]public abstract class Thing : Entity {    public Thing() {        Article = "a";        Count = 1;    }     public string Location { get; set; }    public RelativeLocation RelativeLocation { get; set; }     [TypeConverter(typeof(StringListConverter))]    public string[] Nouns { get; set; }     [TypeConverter(typeof(StringListConverter))]    public string[] Adjectives { get; set; }     public string Article { get; set; }    public bool IsTransparent { get; set; }    public int Weight { get; set; }    public int Size { get; set; }    public string ShortDesc { get; set; }    public string LongDesc { get; set; }}

[Serializable]public class Item : Thing {    public Item() {        CanTake = true;    }     public bool IsOpen { get; set; }    public bool CanOpen { get; set; }    public bool IsContainer { get; set; }    public bool IsLocked { get; set; }    public string Key { get; set; }    public bool CanLock { get; set; }    public bool CanTake { get; set; }}

A few interesting things here:

1. The DictionaryKeyProperty attribute indicates which property should be considered a key, should such an object be placed in a dictionary. This will allow us to avoid using the more awkward and generic x:Key XAML attribute.
2. The TypeConverter attribute indicates how a string is to be converted to a more complex type, such as the Nouns property:

[TypeConverter(typeof(StringListConverter))]public string[] Nouns { get; set; }

This particular converter turns a string into an array of strings. Here’s the implementation:

public class StringListConverter : TypeConverter {    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value) {        var target = context as IProvideValueTarget;        Type type = null;        if(target != null) {            type = (target.TargetProperty as PropertyInfo).PropertyType;        }        string svalue = (string)value;        var words = svalue.Split(new [] {','}, StringSplitOptions.RemoveEmptyEntries);        return type == typeof(string[]) ? (object)words : words.ToList();    }     public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType) {        return sourceType == typeof(string);    }}

The code can actually convert to an array of strings or a list of strings (it looks for a comma as a separator to split the words). Converters is one of those things that make XAML friendly, readable and easy to use.

Let’s take a look at something more interesting: markup extensions. Suppose we want to be able to place items in rooms or other containers. For example, a ring may be in the bedroom, or on the table, or in a box. We want to be able to “say” that as easily as possible (we are striving for a DSL). Here’s some XAML that accomplishes this:

<Item Name="ring" Location="{In box}"         Nouns="ring" Adjectives="small,diamond" Article="a"></Item><Item Name="box" Location="kitchen" Nouns="box" IsOpen="true"> </Item><Room Name="kitchen" Attributes="Cold,Dark" ShortDesc="A small kitchen"></Room>

Note the {In box} location of the ring. To make that work, there must be a class named In or InExtension that accepts a string as a constructor argument. In fact, we can create a bunch of those like so:

public abstract class RelativeLocationExtension : MarkupExtension {    public RelativeLocation RelativeLocation { get; private set; }    public string Name { get; private set; }     protected RelativeLocationExtension(RelativeLocation rl, string name) {        RelativeLocation = rl;        Name = name;    }     public override object ProvideValue(IServiceProvider sp) {        var target = sp.GetService(typeof(IProvideValueTarget)) as IProvideValueTarget;        if(target != null) {            if(target.TargetObject.GetType().IsSubclassOf(typeof(Thing))) {                target.TargetObject.GetType().GetProperty("RelativeLocation").SetValue(target.TargetObject, RelativeLocation);            }            else                throw new ArgumentException("object must be a thing for a location");        }        return Name;    }} public class OnExtension : RelativeLocationExtension {    public OnExtension(string name) : base(RelativeLocation.On, name) {    }} public class InExtension : RelativeLocationExtension {    public InExtension(string name)        : base(RelativeLocation.In, name) {    }} public class UnderExtension : RelativeLocationExtension {    public UnderExtension(string name) : base(RelativeLocation.Under, name) {    }}

Any markup extension must implement the ProvideValue method. The provided IServiceProvider can be used to get the context in which the markup extension is used. The IProvideValueTarget interface is the most common and useful to use. It lets the code know on which object and which property is set with the markup extension. Markup extensions provide a powerful extensibility mechanism that’s still easy to use by our DSL.

Attached properties

WPF invented attached properties, now used in other XAML based technologies. Attached properties are defined by one type but can be set on any object. They are “attached” to objects, providing the idea of context properties. By the way, they don’t have to be dependency properties (as in WPF/Silverlight) in any way. Their implementation is irrelevant to the XAML parser.

In fact, to parse attached properties, the XAML parser requires the defining class to have a static GetXxx and/or SetXxx for the attached property Xxx. In the implementation, we need to store/retrieve the value of the property from some attached property store – conceptually similar to the way WPF manages an attached property – by using some global static variable.

Technically, that store needs to implement the IAttachedPropertyStore interface. Although it’s not difficult to implement (most use a dictionary), .NET provides a default implementation accessible with the convenient AttachablePropertyServices static class. Here’s an example of creating an attached property named Commands.Script (in this case read only):

public static class Commands {    public static IList<ScriptCommand> GetScript(Entity entity) {        IList<ScriptCommand> value;        AttachablePropertyServices.TryGetProperty<IList<ScriptCommand>>(entity, new AttachableMemberIdentifier(            typeof(Commands), "Script"), out value);        if(value == null) {            value = new List<ScriptCommand>();            AttachablePropertyServices.SetProperty(entity, new AttachableMemberIdentifier(                typeof(Commands), "Script"), value);        }        return value;    }}

Now we can use the property like so (for a Room in this example):

<Room Name="kitchen" Attributes="Cold,Dark" ShortDesc="A small kitchen">  <Commands.Script>    <ScriptCommand Verb="smell">      <Print Text="You smell hot peppers eveywhere." />    </ScriptCommand>    <ScriptCommand Verb="listen">      <Print>You hear nothing special.</Print>    </ScriptCommand>  </Commands.Script></Room>

ScriptCommand and Print are some other classes that are part of the object model for the game.

From XAML to Objects

Here’s some part of a complete XAML we may wish to parse:

<GameFile xmlns="http://xamlventure/2013" >  <GameFile.Resources>    <Variable Name="light carried" Value="True" />    <CanMoveToCondition Direction="North" Name="canMoveNorth" />  </GameFile.Resources>    <Item Name="ring" Location="{In box}"             Nouns="ring" Adjectives="small,diamond" Article="a">    <Commands.Script>      <ScriptCommand Verb="take" DirectObject="ring">        <Print Text="Your hand is stopped by an invisible shield around the ring."             Condition="{Property Glowing, Object=ring, Value=True}" Continue="false"/>        <Print>The ring shines momentarily as you grab it in your hand.</Print>        <PausePrint />      </ScriptCommand>    </Commands.Script>    </Item>  <Item Name="box" Location="kitchen" Nouns="box" IsOpen="true">      </Item>  <Room Name="kitchen" Attributes="Cold,Dark" ShortDesc="A small kitchen">    <Commands.Script>      <ScriptCommand Verb="smell">        <Print Text="You smell hot peppers eveywhere." />      </ScriptCommand>      <ScriptCommand Verb="listen">        <Print>You hear nothing special.</Print>      </ScriptCommand>    </Commands.Script>  </Room>

The XAML uses other classes not described above, with some other markup extensions, such as {Property} and {Condition}.

Note the XML namespace at the top of the file. This defines the relationship between XAML types and .NET types. The .NET types may be spread across multiple .NET namespaces, but the XML namespace maps to all of those. This is done using the following attributes:

[assembly: XmlnsDefinition("http://xamlventure/2013", "XamlVenture.ObjectModel")][assembly: XmlnsDefinition("http://xamlventure/2013", "XamlVenture.ObjectModel.MarkupExtensions")][assembly: XmlnsDefinition("http://xamlventure/2013", "XamlVenture.ObjectModel.Actions")][assembly: XmlnsDefinition("http://xamlventure/2013", "XamlVenture.ObjectModel.Conditions")]

This is easier than the alternative XAML namespace mapping (this is the way WPF/Silverlight works to get the correct mappings).

The next step is to turn the XAML into the GameFile root object with everything inside. The simplest way to do this is with the XamlServices class:

var root = (GameFile)XamlServices.Load(path);

This returns the root GameFile object and everything else inside it. GameFile is defined like so (partial):

[Serializable][ContentProperty("Entities")]public sealed class GameFile {    [DebuggerBrowsable(DebuggerBrowsableState.Never)]    Dictionary<string, Entity> _entities = new Dictionary<string, Entity>(32, StringComparer.CurrentCultureIgnoreCase);     [DebuggerBrowsable(DebuggerBrowsableState.Never)]    Dictionary<string, Verb> _verbs = new Dictionary<string, Verb>(8, StringComparer.CurrentCultureIgnoreCase);     [DebuggerBrowsable(DebuggerBrowsableState.Never)]    Dictionary<string, Resource> _resources;     public IDictionary<string, Entity> Entities {        get { return _entities; }    }     public IDictionary<string, Verb> Verbs {        get { return _verbs; }    }     public IDictionary<string, Resource> Resources {        get {             if(_resources == null)                _resources = new Dictionary<string, Resource>(4, StringComparer.InvariantCultureIgnoreCase);            return _resources;         }    }     public Game Game { get; set; }}

The ContentProperty attribute is another common helper that sets the “default” property for the particular type.

If more control is required during parsing, such as running some extra initialization after or during certain object creation, a more elaborate parsing loop can be created:

using(var reader = new XamlXmlReader(path)) {    using(var writer = new XamlObjectWriter(new XamlSchemaContext())) {        while(reader.Read()) {            switch(reader.NodeType) {                case XamlNodeType.StartObject:                    writer.WriteNode(reader);                    break;                 case XamlNodeType.StartMember:                    goto default;                 case XamlNodeType.EndObject:                    writer.WriteNode(reader);                    AnalyzeObject(writer.Result);                    break;                 default:                    writer.WriteNode(reader);                    break;            }        }    }}

After each XAML token is read, the code can do something with it. The most useful node type is EndObject, indicating a complete object has been written. This is a perfect opportunity to do something with that object, such as create extra objects based on its state, set some other properties or anything else that’s required. (the AnalyzeObject dummy method above indicates such operations).

After the parsing is complete, the resulting object model can be transformed to another form or another object model if needed; or it can just be used as is in the target application.

Conclusion

XAML is an effective DSL; being XAML – and XML – makes it easy to work with – as a developer and as a user, as there are many ways to simplify XML input.