Was forbidding desktop applications on Windows RT the correct move?

Every day, someone bugs me at work about the news reports relating to how the Surface RT was not the success Microsoft had hoped it would be.  And Asus had the same conclusion.   I tell them Surface RT was a great piece of hardware.  It had the misfortune of not being able to run desktop apps.

But what about if Windows RT (Windows ARM) had allowed desktop applications (that have been recompiled to use the ARM instruction set) to run instead of just the ones that Microsoft had allowed (i.e. Office, and several built in apps, such as notepad, calculator, and some remote debugging tools).

I’ve been following the threads on xda developers on how the digital signing of desktop apps was circumvented to allow desktop apps to bypass this check completely, and in effect, open it up for desktop development.

Apart from the exploit, how was this possible at a tools level?  Well, if we go back to //build (in 2011), and look at the Beta version of Visual Studio 2012, you’ll notice something interesting: a complete version of MFC for ARM (including static lib files).  You’ll also notice that several key Windows SDK libraries were excluded (such as common controls, etc), making these MFC libraries more difficult to take advantage of.

The question remains: why would they have included MFC if they hadn’t planned on allowing developers to make desktop apps targeting ARM? My theory is that the original plan was to allow development of desktop apps for ARM, but at some point it was decided that desktop apps should be controlled and their creation only made available to Microsoft themselves.  Hence, when the first developer preview came out at //build there were still remnants of the original plans.

After this first build, subsequent builds removed the MFC libraries that were included in that first Beta.

So coming back to the original question: was forbidding desktop apps on ARM the correct move? At the surface level (pardon the pun) it looks to be a good decision.  the WinRT (Metro) environment provided for store apps, is tightly controlled, and therefore can have a better impact on battery life, potential viruses, app revenue, etc.  But it does stifle competition.  Look at VLC for ARM right now.  They can’t make a desktop app so have been forced to go to kickstarter to fund a Windows 8 (Metro) version of their app.  It’s still under development due to the tight controls over which APIs are allowed in WinRT apps. It’ll be interesting to see when, if ever, they release something.

Imagine the ability to have Chrome or Firefox for your Surface RT? Good thing?  I’m not sure.  Or your favorite app, which only needs to be recompiled for ARM using Visual Studio, and released directly from the software developer rather than through the store.  Good thing?  Hmm, the pros and cons are hard to weigh.  If you are starting from a zero ecosystem and trying to build it up, maybe desktop apps would have been a good thing.  But on the other hand it might have caused developers to focus less on the Windows Store apps and more on their legacy desktop apps.

But judging from the developer buy-in for WinRT (Windows Store apps), it’s a moot point.  The fact is, there hasn’t been enough buy-in.  And this is the key to success of the ecosystem, having developers risk getting no revenue from a store app, vs continuing with their legacy desktop apps on Intel only.  If they had allowed desktop apps on ARM, it’s possible more of those developers would be more excited about Windows RT.

New in Windows 8.1 store apps: a way to separate your app from your resources

One of the biggest complaints about the Windows 8 Windows store app approach to dealing with localization (separate translations for each language you decide to support), was the inability to decouple the various localizations from the main app.

As I’ve talked about in previous blog posts, the satellite DLL approach to Windows desktop apps, is an excellent one that can be used successfully with a lot of manual work (and can be automated quite easily when targeting Vista and above platforms).  But in Windows 8 store apps, there was no real analogy to this.

Windows 8.1 introduces a new type of package, a resource package.  MSDN describes it well here, I’ll provide a brief summary:

A resource package is a subset of your app that is used to provide language, scale, and DirectX features.  When you deploy an app to a machine, the decision is made whether you need one or all of the resource packages.  The app package itself can be deployed to a user’s machine with none of the resource packages, one of them, or all of them, depending on the particular needs of that machine. This is great for 2 reasons: it potentially increases download speed and reduces disk space.

An app bundle manifest (.appxbundlemanifest) is what describes your app’s package and all its resource packages.

The great thing about this new system, is that Visual Studio 2013 automatically handles this for you (separates the resources into separate resource packages).

There is also a package API that allows you to get information about packages, and a sample has been prepared by Microsoft and is found here:

http://code.msdn.microsoft.com/windowsapps/Package-sample-46e239fa

as well as another great sample that shows you how this resource package approach could be used in a game:

http://code.msdn.microsoft.com/windowsapps/Games-with-resource-62bd72aa

If you’re ok with targeting Windows 8.1 for a future Windows Store app (see previous blog posts on pros and cons of targeting Windows 8 vs Windows 8.1), this is an excellent new system that I believe will be a great boon for developers.

A note about Stroustrup’s The C++ Programming Language 4th Edition

As far as C++ books are concerned, this is the definitive reference, from the inventor of C++, Bjarne Stroustrup.  I grew up with his 2nd, 3rd, and Special Editions, and I highly recommend that you take a look at the 4th for its great C++11 content.

Now, I don’t recommend you buy it right away.  Yes, I know you may be surprised by that statement, but let me explain. Stroustrup is one of those authors that takes accuracy seriously.  Due to that, he tends to go through many “printings” of his books.   He makes changes (corrections) in each of these printings, based on reader feedback.

Take a look at the errata for his 3rd and special editions:

http://www.stroustrup.com/3rd_errata.html

He went through 21 revisions of the 3rd edition, and 14 revisions of the special edition (which was basically a continuation of the 3rd edition, except in hard cover).  So a total of 35 different 3rd editions when you include the special editions (disclaimer: some of these overlapped, i.e. there were early special edition printings equivalent to 3rd editions in higher printings, but you get the idea)

Why am I mentioning this?  Because the 4th edition is very young.  He’s already up to the 3rd printing after a couple of months:

http://www.stroustrup.com/4th_printing3.html

Also, complaints have been made about the flimsy (physical) nature of the original release of the 4th edition.  Yes, it’s a paperback.  However, it looks like Addison-Wesley has heard the complaints because a hardcover version of the book will be released on July 29th!

So I recommend you take a look at buying the hardcover version after a few months of revisions.  You’ll have the majority of “big” fixes, and then you can follow along the errata pages for future fixes.

How do you know what printing you’re going to get if you order from somewhere online?  It’s hard to know, you could get a very early one based on stock. But amazon tends to go through stock quickly.  Another thing you could do is to get one from your local bookseller, and take a look on the inside to see what printing you’re getting.

Visual Studio 2013 support for targeting Windows 8

I’ve been working my way through the multitude of //build 2013 session videos on channel9, and I came across an interesting presentation:

Upgrading Windows 8 Apps to Windows 8.1

There is a lot of really great information about the gotchas for deciding on making an app that is specific to Windows 8.1.

The main point you need to remember: once you make your app target Windows 8.1 (e.g. by converting to an 8.1 app and taking advantage of 8.1 specific APIs), your app will not run on Windows 8.  On the other hand, if you target Windows 8, your app will run under both Windows 8 and Windows 8.1

Here’s the kicker: Visual Studio 2013 will NOT support creation of new Windows 8 store apps, you’ll only be able to create Windows 8.1 store apps.   However you will be able to edit and build existing Windows 8 projects with Visual Studio 2013.

So if you want to continue to target Windows 8 when creating new store apps, you are going to need both Visual Studio 2012 and Visual Studio 2013 installed. You’ll really only need Visual Studio 2012 to create the project, and once it’s created you can switch over to Visual Studio 2013.

This seems to me to not be a technical limitation, but more of a way to encourage developers to target Windows 8.1 from the get go if creating a new app.

To me it would make more sense to support creating Windows 8 store apps in Visual Studio 2013, since the infrastructure is already there to continue to edit and build existing Windows 8 projects.

Why MUIRCT is so cool (aka separating Win32 resources into satellite DLLs, the easy way)

MUIRCT is a utility that Microsoft made available starting with the Windows Vista SDK.  It’s a localization utility that allows you to “split” resources from a DLL that has already been built.

Let’s give an example.  You have a large legacy app with dozens of DLLs, all using the model of code+resources in the same module.  After all, up to this point there has been really no good techniques within Visual Studio itself to use the satellite DLL approach, without doing a lot of manual work.  Things like creating dialog boxes, etc are simply easier to do with the built in wizards (class wizards, event handlers, etc) if the code and the resources reside in the same EXE/DLL.  Unfortunately this is the exact opposite of what we need from a translation/localization perspective.    The satellite DLL approach allows you to keep your code and your resources separate, but it involves a lot of manual work, especially if you have a complex app with many EXEs and DLLs.

What if there was a way to continue with the old style code+resources in the same module approach during development, but then separate out the resources after the fact, and require only minor changes to your code?  How is that possible?  When you load a resource from a handle (e.g. let’s say your app is test.exe, and you pass in the HINSTANCE of test to LoadString, how does the operating system know to look elsewhere for the resources?  A single handle can’t represent two separate modules behind the scenes can it?

Turns out, in Vista and higher, MUIRCT can separate these resources for you, and the operating system will load them automatically when you do a resource load.  And you have control at the individual resource level as to what is treated as language neutral (what stays in test.exe) and what is localizable (what goes into the satellite DLL)

Example:

Create a new MFC app, test.exe using all the defaults

Compile the app, then run the following on the output:

muirct -q test.rcconfig test.exe test2.exe test2.exe.mui

The above commmand splits up the app test.exe into two components, a language neutral part (the EXE) and a DLL named test.exe.mui which contains the localized parts. Now translating this test.exe.mui using a resource editor, your code is separate from your resources.

Then you would store for example your app in two folders:

test2.exe en-us\test2.exe.mui

When you run your app, the operating system knows to look for your resources in en-us folder (or what ever your ultimate fallback language is selected to be)

So if you have a bug fix to test.exe, you don’t need to redo all the languages because the resources and the code are separate.

I’ve only just scratched the surface on this topic, there are many more technical details you’ll need to learn, fortunately this whole process (including a full example of an rcconfig file) is provided by Microsoft in a walkthrough and sample code here:

http://archive.msdn.microsoft.com/hellomui

and

http://archive.msdn.microsoft.com/MUIIzer

Note: this approach works in Vista and higher.  if you need XP support, you’ll need much more extensive changes to your application as there is no support for this technique at the OS level, so you end up writing a lot of extra code, which makes the whole thing pointless.  So I would recommend only using this if you are able to drop XP support from your list of supported operating systems.

Finding the kernel32.dll module handle in a Windows Store app using approved APIs

As there are a lot of forbidden Win32 APIs in Windows Store apps (i.e. APIs that, if you call them, will cause your app to fail app certification), there are often other alternative APIs that you have to call instead.  For example, the CreateFile API is banned, but for Windows Store apps they made CreateFile2.

But what about if I wanted to get the module handle of a DLL? Specifically of kernel32?  Well, looking at the help for GetModuleHandle we see the unfortunate info:

Minimum supported client	Windows XP [desktop apps only]

So we can only use this with desktop apps.  For your own packaged libraries you can use LoadPackagedLibrary API.  But this doesn’t work for system DLLs.  So how can you the the handle to kernel32.dll, for example, by using only approved store APIs?

This is where VirtualQuery comes in.  Interestingly, the API’s help page lists the following info:

Minimum supported client	Windows XP [desktop apps | Windows Store apps]

This is great news, because VirtualQuery can get you the module handle of any DLL just by querying any particular known function in the DLL you want the handle to.

I discovered this trick a while ago – previously I used it to find the module handle of the DLL any code is being called from.  See:

http://www.codeguru.com/cpp/w-p/dll/tips/article.php/c3635/Tip-Detecting-a-HMODULEHINSTANCE-Handle-Within-the-Module-Youre-Running-In.htm

You probably know where I’m going here, but VirtualQuery itself is a function exported from kernel32.dll!

So all we need to do to get the module handle of kernel32.dll is to do a VirtualQuery of VirtualQuery:

HMODULE GetKernelModule()
{
    MEMORY_BASIC_INFORMATION mbi = {0};
    VirtualQuery( VirtualQuery, &mbi, sizeof(mbi) );
    return reinterpret_cast<HMODULE>(mbi.AllocationBase);
}

And then from your own code:

HMODULE kernelHandle = GetKernelModule();

You can now pass this into functions such as GetProcAddress (which is also approved).  As you can see, we have a powerful way to get the module handles of any particular DLL that we have in our process address space, and then use that to get function pointers to any particular function.

Note you should only use this technique on approved APIs in Windows Store apps.   But for debugging purposes (and just to have some fun), it might be cool to do something like the following:

Generate a blank XAML (C++ Windows Store) app, add a button to the blank form. Double click on the button. Add this code in place of the event handler:

typedef int (WINAPI *pMessageBox)( __in_opt HWND hWnd,
  __in_opt LPCTSTR lpText, __in_opt LPCTSTR lpCaption, __in UINT uType);

typedef HWND (WINAPI *pGetActiveWindow)(void);

typedef HMODULE (WINAPI *pGetModuleHandle)(__in_opt LPCTSTR lpModuleName);

void App1::MainPage::Button_Click_1(Platform::Object^ sender,
  Windows::UI::Xaml::RoutedEventArgs^ e)
{
 static pMessageBox MessageBox_p = 0;
 static pGetActiveWindow GetActiveWindow_p = 0;
 static pGetModuleHandle GetModuleHandle_p = 0;

 HMODULE kmod = GetKernelModule();

 GetModuleHandle_p = (pGetModuleHandle)GetProcAddress(kmod, "GetModuleHandleW");

 HMODULE mod = GetModuleHandle_p(L"user32.dll");

 MessageBox_p = (pMessageBox)GetProcAddress(mod, "MessageBoxW");
 GetActiveWindow_p = (pGetActiveWindow)GetProcAddress(mod, "GetActiveWindow");

 MessageBox_p(GetActiveWindow_p(), L"Hello", L"Hello", MB_OK);
}

Build and deploy your app, run it, and the press the button and see what happens.  Something you don’t ever want to do in a production app :)

Porting Win32 code to 64 bit: watch out for pointers

During the porting of an application to 64 bit, I recently found out about a very interesting registry key value, that, when set, will force the Windows memory manager to give you a high address (greater than 32 bit).  This is useful if you’re dealing with a lot of code that may inadvertently store pointers in 32 bit values.  Normally you’d get a 32 bit pointer in a 64 bit program, unless you specifically ask for it using the MEM_TOP_DOWN flag for VirtualAlloc API, but there is a way to force this behavior upon all apps:

In your registry, under:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management

Just create a DWORD value named AllocationPreference and set it to hexadecimal value 100000.   (hex value 0x100000)

Even if you’ve been super careful writing code, for example, using DWORD_PTR instead of DWORD everywhere it matters, you’ll be surprised how quickly you’ll find previously hidden problems lurking in your code.  I recommend that this value be set on all of your QA team’s machines as well.    The site I link to above gives a great explanation as to what the key value actually does.  You can find more information from Microsoft about the value here:

http://msdn.microsoft.com/en-us/library/bb613473.aspx

 

How do my API wrapper functions avoid triggering linker errors?

Now that we have a stable (VS2012+Update 3) solution for XP support, there is no longer a need for these wrappers.

I was going to make a general write-up on how all of my API wrapper classes work, but in searching around, I found out that Antony, who graciously contributed the x64 version of the xpsupport wrappers, already wrote up an excellent article a while back describing how the linker resolves symbols.  Please read:

http://blog.macrium.com/2012/05/upgrading-to-vnext-yet-supporting-windows-xp/

Thanks to Antony for his contributions to this project and his great description.

So using assembly allows us to avoid the dreaded “duplicate symbol” error, if we had tried to do this in C/C++.   Interestingly, GCC has a much more elegant way of doing this:

http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winstorecompat/src/GetTickCount.c

notice the last line (edited to avoid use of a macro):

DWORD (WINAPI *__imp_GetTickCount)(void) asm(“__imp__GetTickCount@0”) = GetTickCount;

The asm keyword can be used to define a symbol that can be overridden by an arbitrary symbol.  This functionality is not available in MSVC.

I’ll be talking more about wrappers in the near future, specifically in the area of forbidden Win32 APIs in Windows Store apps.