Tag Archives: windows runtime

c++, development, microsoft, software development, visual studio, windows

Adapting a native code DLL to be called from a Store or Universal Windows app

I am writing a Bridge game in C# – yes, I have been doing this for some time, it does run now but it is not ready for public unveiling.

It is good fun though and a learning experience, as I am writing it as a Windows 8 Store app. This means it can also be a Universal Windows Platform app but I have kept it compatible with Window 8.1 as I don’t want to lose that large market of Windows 8 users who have not upgraded to 10. Hmm.

Bridge is a card game in which a pack of 52 cards is dealt into 4 hands of 13 cards. Each hand is played as a sequence of 13 4-card “tricks”, and each trick is won one of two opposing pairs of players according to the cards played. Each pair of course tries to win as many tricks as possible, so one of the points of interests is how many tricks can be won if you play perfectly (ie with full knowledge of all four hands). Another point of interest is how each card played affects the potential number of tricks you can win with best play. For example, leading a King might cost you a trick (or more) if your opponents hold both the Ace and the Queen of that suit.

This is called “double dummy” analysis and smart people have written algorithms to calculate the answers. A double dummy analysis is useful in a bridge game for two reasons. One is that users may like to know, after playing a hand, what their best score could have been, or even to analyse the hand and see how if they played this card rather than that card at trick such-and-such the outcome would have varied. The other is that you can use it to assist the software in finding the best play. Of course it is important that the software plays fair by not using knowledge of all four hands beyond what would be known by human players; but it is legitimate to try out various possible hands that match what is currently known and use double dummy analysis on these hands.

One such smart person is Bo Haglund who wrote a C++ Windows library for double dummy analysis, called Double Dummy Solver (DDS) and released it as open source under the Apache 2 license. It works very well and is widely used in the Bridge software community, and has now been ported to Mac and Linux; you can find the latest code on Github.

Modifying a native code DLL to use with a Store app

I wanted to use the library in my own Bridge game but faced a compatibility problem. Windows Store apps can only call into DLLs that meet certain requirements, such as using only a subset of the Windows API, and DDS did not meet those requirements. My choice was either to port the DLL to C#, or to modify the code so that it would work as a Windows Runtime native DLL.

I have no doubt that the code could be ported to C# but it looks like rather a long job that would result in a library with slower performance (please feel free to prove me wrong). I thought it would be more realistic to modify the code, so I created a new Windows 8.1 DLL project in Visual Studio 2013 (I am now using Visual Studio 2015 but it is the same for this) and set about modifying the code so that it would compile.

In no particular order, here are some notes on what I learned.

I was able to get the DLL to compile after disabling the multi-threading support (more on this later), and commenting out some functions that I don’t yet need.

Another issue I hit was that Visual C++ by default performs “Security Development Lifecycle” checks (compile with /sdl). This means that that common functions like strcpy, strcat, sprintf and others will not compile. You have to use “secure” versions of those functions, strcpy_s, strcat_s, sprintf_s and so on. These are specific to Microsoft’s libraries though. Of course you can just not compile with /sdl, or define _CRT_SECURE_NO_WARNINGS, but I chose to fix all of these. Now the library compiled.

But did it work? No. I had introduced a stupid bug which took me a while to fix. Did it then work? Yes, but it took me some time to get it working from C#.

Next, I kept getting DLLNotFound exceptions. OK, so you have to add the DLL as content in your C# project, and make sure it is set to copy to your output. I still got DLLNotFound exceptions. It turns out that you get this exception even when the DLL is present, if there is a dependency in the DLL which is not found. What dependency was not found? I downloaded the Sysinternals Process Monitor utility and set the filter to monitor my C# game. I excluded SUCCESS results. Then I tried to load the DLL. This told me that it was looking for the file msvcr120_app.dll (the Windows Runtime version of the Visual C++ runtime library). My first thought was to add runtime libraries from the appx deployment packages, in:

C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1\ExtensionSDKs\Microsoft.VCLibs\12.0

image

Then I discovered that all you need to do is to add a reference to the Visual C++ runtime packages, much easier. That fixed DLLNotFound.

Next, I had some problems calling the 64-bit DLL with Platform Invoke (PInvoke) from C#. I found it easier to compile both my C# app and the DLL itself as 32-bit code. I may go back to the 64-bit option later.

Concurrency issues

Now I had everything working; except that my DDS port was far inferior to the standard one because it was single-threaded. The original used QueueUserWorkItem which is not available in a Windows Runtime DLL. I searched for what to do, and came across this MSDN article which recommends using RunAsync, WorkItemHandler and IAsyncAction. However my DLL was not currently compiled using /ZW for “Consume Windows Runtime Extension”. I could add that of course; but then my DLL would have a dependency on the Windows Runtime and if I wanted to use the code for, say, Windows 7, it would not work. or not without yet more #ifdef blocks. No big deal perhaps; but my preference was to avoid this dependency.

There may be other solutions, but the one that I found was to use the Concurrency Runtime. Previously, QueueUserWorkItem was called in a for loop. I simply modified this to use a parallel_for loop instead, using the example here for guidance. I also added:

#include <ppltasks.h>

using namespace concurrency;

to the top of the code. It works well, speeding performance by about three times on my quad-core desktop. Of course I was greatly helped by the fact that the code was already written with concurrency in mind.

image

The effect is spoiled by the time it takes to load the DLL but fortunately you can get DDS to solve multiple boards in one call though I have yet to experiment with this.

.net, development, microsoft, professional, software development

Internal Windows Runtime apps are prohibitively expensive to deploy, says Microsoft Regional Director

5 Comments

Now we know why Microsoft has been so reluctant to divulge details of how to deploy a business app that uses the Windows Runtime (also known as Metro apps or Windows Store apps; though in this case the Windows Store app designation is particularly silly since these apps are precisely not Store apps).

Presuming Windows MVP and Regional Director Rockford Lhotka is correct, a business that wishes to sideload Windows Runtime apps (in other words, to deploy but not via the Windows Store), a business needs to purchase a $30 sideloading key which, by a stroke of marketing genius, is only available in packs of 100.

image

Note the above screen grab shows a price of more than $30.00. I believe this is because Lhotka’s figures do not allow for any reseller markup, though there could be regional differences as well.

Here is what Microsoft’s Antoine Leblond said back in April 2012:

To enable sideloading of a Metro style app onto a PC:

  • Set Group Policy for “Allow all trusted apps to install”. If you cannot use Group Policy, then you can set this through the following setting: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1
  • Verify that the app is signed by a CA that is trusted on the target machines
  • Activate a special product key by using a script on the target machine to enable sideloading. We’ll go into more detail about how the IT admin will acquire the product keys in an upcoming blog post. The product key only needs to be install and activated once on the PC.

I have not seen the promised upcoming blog post but would be interested in doing so if anyone has a link?

Sideloading keys are only valid on Windows 8 Pro or Windows 8 Enterprise.

As a further disincentive, if you want to avoid running a PowerShell script on each target machine, you will need either System Center or InTune to manage the PCs. InTune is the cheaper option, at $6.00 per device per month. Lhotka calculates:

Let’s assume that your organization has 100 Windows RT or Windows 8 Pro devices, so you buy $3000 worth of side-loading keys. And let’s assume you use InTune. Finally let’s assume your devices have a 3 year life – which is pretty typical for corporate devices where you buy a service agreement from Lenovo or Dell or another vendor.

These 100 devices will cost $3000 for keys, plus $6 per device per month. This means that your org with 100 devices will pay around $23,000 extra to deploy a WinRT app just for this licensing.

and he concludes:

Right now it appears that Microsoft has worked very hard to devise a licensing and deployment scheme for WinRT apps designed specifically to discourage the creation of any WinRT business apps. Whether this is intentional or accidental I can’t say, but it is surely the case that no responsible business or IT manager could look at these scenarios and think that a move to WinRT for business app development makes sense at this time

That said, I am not sure he is being completely fair. I doubt a business will subscript to InTune just to support sideloading, and for those who do not want to subscribe, running a PowerShell script is not that hard. It seems to me that the problem could be mostly fixed by offering the sideloading keys in smaller packs.

I would add that now is probably not the moment to deploy a Windows Runtime app. The platform is not as good as it should be, and there is a case for waiting for the first major update in my opinion.

Still, $3000 for a licence pack is substantial, especially for a small business with fewer than 100 PCs.

The “Modern UI” side of Windows 8 has not taken off as yet, and a rational approach would be to encourage rather than discourage corporate developers to target the platform.

Note: a Microsoft Regional Director does not work directly for Microsoft. Lhotka works for Magenic. A Regional Director is an independent professional who is recognized for their ability to train and evangelise development on Microsoft’s platform.

development, microsoft, mobile

Windows Runtime flaws spoil new Windows Store (Metro) apps

1 Comment

The Windows Runtime, the new touch-friendly platform in Windows 8. It solves many problems. Not only is it tablet-friendly, but apps are sandboxed for security, and easy to deploy. No setup hassles, just one-click (or tap) install or uninstall. It also supports three types of development covering most tastes: native C++, .NET Framework, or HTML and JavaScript. In order to ensure responsive apps, Microsoft made many of the APIs asynchronous, so that users would not have the frustration of a frozen user interface or spinning hourglass during long operations.

At least, that is the theory. When I came to write my own simple app though, I was surprised how fiddly it was, and that something trivial like displaying a tweet including a working hyperlink turned out to involve Run elements, a ContentControl, a converter class and so on. Even then, I could not get the mouse cursor to turn to a hand icon when hovering over the link.

This hands-on experience gives me sympathy with others struggling to implement more complex projects. Some have posted about their experiences. Here is Frank Krueger, who has ported his neat iCircuit electronic circuit simulator from iOS and Android to Windows RT:

You would be shocked to see some of the crazy bits of code I had to put in because the Win8 platform, while very rich, is also very generic and doesn’t help you at all to build standard apps (document based, tools, etc.) That is to say, Cocoa is a very mature platform designed to make apps feature-rich and consistent while also making the developer’s life easy. WinRT on the other hand gives you rectangles and a blog post that says “good luck”.

He lists a number of problems, including having to reboot Windows constantly while testing the Share Charm; having to disable media elements in he app because of 500ms delays, no control over buffer sizes, and playback issues; and graphics issues:

I want to do real-time 2D vector drawing. Direct2D is perfect for this. But WinRT puts all sorts of limitations on onscreen rendering, most notably: you can only have 1 DirectX swap chain (view) per window. That means I can’t use Direct2D for rendering the scope which means the scope is slower than it needs to be. Dear Microsoft, go spend a few minutes and see how beautifully CocoaTouch and OpenGL work together on iOS. You might get inspired.

Next up is Media Monkey, a popular Windows media player which has been ported to the Windows Runtime platform. I was pleased to see this, as it lets me play FLAC music files on Surface RT. It is not very stable yet though, and I have had difficulty getting it to index the collection of FLAC files which I have on a network-connected drive.

image

What I found most interesting though were comments about the difficulty of displaying lists beyond a trivial size. One user complained:

When I first started MM scanning my music library, I was seeing the Album list grouped into sections headed up by the Alphabet letters. However, as more Albums got added, the heading letters vanished – and I now have an unbroken list of Albums – a great wodge that is very tiresome to navigate through by scrolling.

to which the Czech developer replied:

It’s a big problem, but not in MediaMonkey, but in system itself. Disabling groups is only crashes prevention because of system limitation :-(. Because of this we cannot use semantic zoom as well.

This has caused me to wonder whether part of the reason for the small number of excellent Windows Store apps is the difficulty developers have in getting them to work right. If so, that is a sad state of affairs for Microsoft’s shiny new platform.

In fairness, this is version 1.0, and the best hope is that a significant update to the platform will come before too long with improved controls, performance and features.

.net, professional, software development, windows

Microsoft answers Windows Runtime questions

3 Comments

I watched the Windows Runtime (WinRT) “Ask the Experts” session from Build 2012; I did not get to attend in person as it conflicted with Herb Sutter’s session on C++. The session was chaired by Martyn Lovell.

image

Here is what I thought most significant or interesting.

  • Microsoft knows that certain types of apps cannot be implemented as Windows Store apps. The implication is either that the desktop will never go away, or that some future version of Windows Runtime will have extended capabilities. Kamen Moutafov: “There are certain types of system management, system configuration applications that you cannot write a Windows 8 style app for. The platform is not well suited for this type of application.”
  • The WebView control is a problem. An attendee reported z-order, memory, input, and performance issues. This is not only because it hosts the IE10 engine, but also because the system does not cope well with the runtime layers involved: JavaScript running within XAML in a C# app, for example.
  • Someone asked why WinRT apps cannot span or support multiple monitors. The answer, only half joking, “Jensen Harris said that is how it is supposed to be!” Second answer is that this may change in future, and perhaps was just too hard to do well in version 1.0.
  • There was considerable discussion of usage of asynchronous APIs (typically using Async and Await). Can you use them too much? The answer is that you can, and some apps perform badly as a result. An example of a bad usage would be to iterate through many hundreds of files in a directory and fire off an async call for each of them. Lots of aysnc calls returning together will choke your app. Advice is to try limiting the number you fire off, for example, only processing the first page or two that is visible in the user interface.
  • Someone asked how can WinRT apps communicate with desktop apps? This is meant to be restricted to protocol handlers and file types, so that the user is in control. Microsoft attempted to block all other routes.
  • Someone had an app in the marketplace that worked on x86 Windows 8, but he discovered that it crashes (does not even load) on Surface RT. How did it pass certification? Answer: Microsoft has seen instances where apps do not behave the same. Certification is not an exhaustive test. Even so, disappointing to make available an app that will not even load.
  • Can a WinRT app create UIs on multiple threads? Yes you can create two views on different threads. See CoreApplication.CreateNewView.
  • How can you detect if a file exists without raising an exception? Apparently this can’t be done. It may be addressed in future.
  • If you are creating a component to be used by other apps including JavaScript apps, it is best to create in in C++. JavaScript to C# to WinRT is apparently sub-optimal.

Watch the session yourself here.

.net, microsoft, windows

The Windows Runtime App Certification Kit: not too good detecting crashes and hangs

3 Comments

Now that I have a lovely ITWriting.com App I thought I should check out whether it is ready to fly.

I therefore ran the App Certification Kit that installs with Visual Studio 2012.

image

The tool asks you to select an installed app and then exercises it. I saw my app open, though I did not see it get beyond the first screen.

image

Eventually – bad news:

image

However, there is only one thing wrong with it:

image

Yes, the version installed is the debug build. I can fix this simply by rebuilding in release configuration.

What does the Kit test? Here is the list:

  • Crashes and hangs test
  • App manifest compliance test
  • Windows security features test
  • Supported API test
  • Performance test
  • App manifest resources test
  • Debug configuration test
  • File encoding
  • Direct3D feature level support
  • App Capabilities test
  • Windows Runtime metadata validation

That sounds most impressive and makes a great list for you to show to your customer.

I am sceptical though. If the app was not exercised beyond the opening screen, might it not be a bit buggy after all?

I inserted the following line of code into the the Click event handler for reading a blog:

int iCrash = 1 / string.Empty.Length;

I then rebuilt the app in release mode and ran the App Certification Test. Great news!

image

and specifically:

image

Thanks though to my umm, bug-unfix, the app crashes whenever I click to read a blog.

I mention this not to poke fun at the App Certification Kit, but to observe that it does not do a good job of automatically detecting crashes and hangs.

The implication is that the human testers are the ones who will do this before an app is admitted to the store. I think they would find my obvious bug; but how much time will they have to test every feature of an app?

.net, microsoft, professional, software development, windows

Developing a Windows Runtime app: some observations

2 Comments

What would it take to create a Windows 8 Modern UI content reader for this site? Just for fun, I built a simple one; or rather, I slightly adapted Microsoft’s Metro style blog reader tutorial.

The app only has four screens (or pages) but despite its simplicity I found the tutorial somewhat fiddly. Getting the data from the WordPress RSS feed is simple, thanks to the Windows.Web.Syndication namespace which is part of .NET Framework 4.5. Most of the work is in the user interface, which means switching between XAML and C#. Of course as a developer I would rather work in C#.

Further, the Visual Studio editor for C# is better than the editor for XAML. In C# I can easily navigate the code using Go to Definition, Find all References, and so on.  In XAML it takes longer to find things like referenced styles and resources. Plus XAML is XML, which I find harder to read than an elegant language like C#. Even commenting out a line is more hassle in XML.

I did not like the colours used by the tutorial for the list of posts in SplitePage.xaml. It took me a while to work out what to change. Was the colour defined in a resource, or in a template, or in a style, or directly coded as an attribute of the relevant TextBlock object?

Of course you can open the XAML in Blend if you prefer, the designer-oriented tool that comes with Visual Studio 2012. Blend is more complex than the Visual Studio XAML editor, but may be better once you have figured out how it works.

The amount of work involved in making your app well-behaved is proportionately larger if your app is essentially very simple. You have to deal with different layouts for different screen sizes and orientation, as well as the small Snapped layout. You also have to consider what happens if your app is suspended and resumed.

The above means that despite the apparent simplicity of a Modern UI interface, with its chunky buttons, there is more to consider than with, say, a Windows Forms application whose window is never rotated and over which you have full control.

Still, I was pleased with my app which has reasonable functionality based on a small amount of work.

Visual Studio 2012 is impressive, though I did experience some screen corruption after switching back and forth between the Metro and Visual Studio environments for debugging. Restarting Visual Studio fixes it. Using the simulator seems more robust in this respect.

image

The App Bar

One thing though. If you squint at the above screenshot, you will see that I have put a Read button to the right of the post title. Clicking or tapping this opens the post in a embedded web browser view that is nearly full-screen. However, this Read button is not included in the tutorial, which says:

On the split page, we must provide a way for the user to go to the detail view of the blog post. We could put a button somewhere on the page, but that would distract from the core app experience, which is reading. Instead, we put the button in an app bar that’s hidden until the user needs it.

This may in fact be an excuse to include an App Bar in the tutorial; but I disagree with it. With the App Bar, the user has to right-click or swipe down to display the App Bar, and then click or tap the View Web Page button.

image

That is two actions rather than one. Is it really better than having a small button in the UI?

It seems to me that tucking things into the App Bar is fine in cases where there is real merit in an immersive experience, such as in the web browser, but less compelling when you already have a screen with a back button and a scrollable list. I was also concerned that users might not realise they needed to display the App Bar in order to use the app properly.

Let the design debate continue.

Design-centric

Microsoft’s Modern UI continues a trend which began with Windows Presentation Foundation (the first incarnation of XAML), which is to make a platform richer for UI designers and more challenging for developers who lack design skills. Nothing wrong with that; but if you remember how easy it was to snap together an app in Visual Basic 3.0, you may feel that something has been lost.

I guess that recognition of that fact was one of the motivations behind Visual Studio LightSwitch, in which you define the data and business rules, but the screens are generated for you. LightSwitch has complexities of its own though.

.net, development, software development

Using Windows Runtime (WinRT) APIs from desktop applications

After trying out Windows 8 notifications from a Windows Forms application, I did a bit of research into using the Windows Runtime (WinRT) API from desktop applications.

It turns out that this is something Microsoft planned for:

Desktop apps should for the most part be able to use WinRT. This is an area where we should have more information moving forward.

says Microsoft’s David Lamb, in Developer Support. He was answering a question about the Proximity APIs.

How do you do it? In C/C++, according to Steve Harne:

For this to build, you’ll need to set the following compiler switches in the the C++ Win32 Console wizard generated project:

C/C++ / General Settings
    Enable Windows Runtime Extensions (/ZX)
    Additional #Using Directories (/AI) -> set this to "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata" (modify as per your installation)

C/C++ / Code Generation
    Disable Minimal Rebuild (/Gm-)  -> this is not compatible with /ZX

In .NET applications you can set a reference to Windows.winmd. This is a WinRT metadata file, which you can browse in the Visual Studio object browser.

image

You even get a short summary describing each class and class member.

Note that as Microsoft’s Larry Osterman explains here:

there is absolutely no (zero) il in the windows.winmd file – it’s a metadata-only assembly. This is important because winmd files only describe structure, they don’t contain code (note that the C# compiler can produce hybrid winmd files that also contain some code, this was to support certain C# scenarios)

While a lot of stuff works, there will be WinRT API calls that make no sense other than for real WinRT apps. It is also worth noting that all of this is specific to Windows 8 (and higher, I presume). Since most desktop apps will need to be compatible at least with Windows 7, this requires some care. Lamb also says:

WinRT APIs may be tied to Metro style apps, Desktop apps or potentially available to both. The documentation will list which environments (Desktop, Metro style or both) a given API works in.

and in fact you can see this in the documentation. For example, the docs for the ToastNotification class states:

Applies to: Metro style apps | desktop apps

image

whereas if you look at the ContactPickerUI class, it says:

Applies to: Metro style apps only

For those APIs where desktop use is supported, you can go right ahead.