I've redone the Windows 8 architecture slide (so you won't have to)
Mary-Jo Foley's article about a slide shown at last year's Microsoft BUILD conference raises uncertainties that bug me as a developer. It's the graphic that attempts to lay out the architecture of Windows 8, particularly in relation to Metro versus the Desktop. As a long-time Windows API programmer, I regard this graphic as the most important yet about Windows 8. Something doesn't seem right!
Somehow all the different interpretations of this chart don't make sense to me. Something's not right, especially the position the Win32 API is given. So I decided to do some digging to see if I could uncover what is really going on under the hood.
So Where are the Metro Applications Anyway?
My first problem was finding where the Metro applications were located so I could inspect them and their layout, as well as dependencies. It turns out they are in the folder \Program Files\Applications but one won't notice this because the folder is both hidden and requires administration rights to access. Once I found the folder, the rest was easy. Each Metro app has its own folder. A Metro app folder appears to always contain four files at minimum:
- AppxBlockMap.xml
- AppxManifest.xml
- AppxSignature.p7x
- resources.pri
AppxManifest tells Windows what the startup file is, which is either an HTML file or an EXE.
Let's Check Some Metro EXEs for Dependencies.
Most of the Metro apps were HTML, but a few were EXE files. I decided to use the Depends utility that comes with early versions of the Windows SDK to check these EXEs for their operating system dependencies. There are two types of EXEs. One appears to be .NET style applications that use the CLR. The other appears to be C++ applications that use the WinRT. The .NET apps only showed one primary dependency, mscoree.dll, which is the CLR runtime execution library; mscoree.dll will then have its own dependencies in the operating system. The C++ style apps have a number of dependencies. The copper application has the following dependencies:
- mfplat.dll
- mfreadwrite.dll
- D3D11.dll
- D2D1.dll
- DWrite.dll
- ole32.dll
- msvcp110.dll
- msvcr110.dll
- vccorlib110.dll
- kernal32.dll
Some of these are C++ runtimes, some DirectX DLLs and others are Win32 API dlls.
Added to this are two dependencies, for which I could not find the files anywhere on the hard drive. I hoped to find them since it would give me a glimpse into the WinRT. They must exist somewhere, but Windows does not make this easy to find. They are named:
- api-ms-win-core.winrt-string-L1-1-0.dll
- api-ms-win-core.winrt-L1-1-0.dll
They are obviously WinRT files. Also the naming of the files are similiar to how much of the kernel services are named. There are plenty of OS dlls that start with something like "api-ms-win" or "api-ms-win-core" and so on. A good bit of what used to be the Win32 API has been moved to these kernel files (not the same as kernel32.dll) since Windows Vista. The Depends utility had a very hard time loading an EXE and scanning for dependencies since the Windows kernel is made up of many, many files now.
The Windows 8 chart needs to be redone!
From this inspection of Metro applications and their dependencies, the Windows 8 chart seems even more wrong to me. Maybe I am missing something. Maybe I am making some wrong assumptions. I am not saying my interpretation of this chart is any better (or worse) than others. But I figured I would take a try at it and see if I could rearrange it to something that makes more sense to me and which fits the model I have built in my mind from this little excursion into Metro apps and their dependencies.
So I present my version of the chart. Rather than be critical of it, why not post some comments of how it could be improved to be more accurate. My chart is only a guess (only Microsoft knows for sure), but it is a calculated guess based on what I currently know of Windows 8.
Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.