I have recently read the two blog posts about the new “developer experience” with Visual Studio 11 (part 1 and part 2). I don’t have the IDE yet (since the beta will be made available on February 29), but from the blog posts I see that you once again changed the look and feel. Why do you have to do this all the time? Can’t you sell a new version without redesigning the UI? We don’t get used well with a version and you change the game again. And like it wasn’t bad enough to do such a big changed, you decided to go with a chrome theme. This is what I call “Windows disabled”; you can’t get a good feeling of what is enabled and what is not. Everything is in tones of gray and confusing.

Why do you have to invest all that time in redesigning the UI with each release? Why don’t you focus on making the current UI more responsible (for instance VS2010 takes 1 minute on my machines to start) and less buggy? Why don’t you invest that time in building features that make our lives easier? Like providing multiple windows for search results (not just two) or supporting auto completion (like it was in all versions until VS2010) in the folder selection fields in the New Project dialog?

So dear Microsoft, please

1. make it possible for us to change the Chrome theme to the old colored theme
2. don’t change the UI with each version

Sincerely,
A concerned developer

PS: I still can’t get out of my mind the horror or scrolling with the mouse on Windows 8 maybe 5 screens of colorful tiles to get to the app that I want to launch. Awful! As it stands I see big failures on the horizon.

If you look in C:\Windows\System32\WinMetadata folder you’ll find the WinMD files for the Windows Runtime. You can browse the content of these files with one of the aforementioned disassemblers.

Here are two dummy WinRT components, one developed in C++/CX and one in C#.

namespace WinRTNativeComponent
{
    public ref class MyWinRTComponent sealed
    {
        int _id;
		String^ _name;

    public:
		MyWinRTComponent () {}
		~MyWinRTComponent () {}

        property int Id
        {
            int get() { return _id; }
            void set(int value) { _id = value; }
        }

		property String^ Name
		{
			String^ get() {return _name;}
			void set(String^ value) { _name= value; }
		}

        bool Update(int id, String^ name)
		{
			{
				if(_id == id)
				{
					_name = name;
					return true;
				}

				return false;
			}
		}
    };
}

namespace WinRTManagedComponent
{
    public sealed class MyWinRTComponent
    {
        public int Id { get; set; }
        public string Name { get; set; }

        bool Update(int id, string name)
        {
            if (Id == id)
            {
                Name = name;
                return true;
            }

            return false;
        }
    }
}

In the case of the native component, the output includes a DLL and a WINMD file (and of course a PDB file). In the case of the managed component, the output is either a DLL only or a WINMD only (plus the associated PDB file), depending on the Output type as defined in the project properties. If the type is Class Library the output is a DLL; this is enough if your component is supposed to be consumed from a managed language. However, if the component should be consumed from C++/CX or Javascript, then the project type must be set to WinMD File. In this case the DLL is replaced by a WinMD file, that contains, at least in the current version, both the matadata (as implied by the name) and the implementation.

Native WinRT component in C++/CX	Managed WinRT component in C#

It should be possible to use reflection with winmd files. However, the reflection capabilities of .NET 4.5 in this developer preview seem to be very limited. The only available Load method in the Assembly class is

public static Assembly Load(AssemblyName assemblyRef);

Trying to load the winmd file fails with a FailLoadException with the message “Could not load file or assembly ‘Winmdreflection, ContentType=WindowsRuntime’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0×80131515)”.

try
{
    var assembly = Assembly.Load(
        new AssemblyName()
        {
            Name = "WinRTManagedComponent",
            ContentType = AssemblyContentType.WindowsRuntime
        });
}
catch (Exception ex)
{
}

It is possible though to read information for the types described in an winmd file in native code using the IMetaDataImport/IMetaDataImport2 COM interfaces. You can find an example here. But this has the drawback that you have to instantiate an object first and then query for its type information.

To use a Windows Runtime component in a Metro application (managed or native) you have to add a reference to it. That is pretty straight forward. In the following example I’m adding a reference in a C++ Metro application to the two WinRT components, one native and one managed, shown earlier. To do this, you can go to the project’s property page and open the Common Properties > Frameworks and References page, or use the References command from the project’s context menu which opens that page directly. You can add a reference to a project from the same solution, to a Windows component or you can browse for the winmd file.

Having done that you can instantiate the WinRT components.

auto obj1 = ref new WinRTManagedComponent::MyWinRTComponent();
obj1->Id = 1;
obj1->Name = L"marius";

auto obj2 = ref new WinRTNativeComponent::MyWinRTComponent();
obj2->Id = 1;
obj2->Name = L"marius";

(source www.zdnet.com)

WinRT is a native layer (written in C++ and being COM-based) that is intended as a replacement, or alternative, to Win32, and enables development of “immersive” applications, using the Metro style. Its API is object oriented and can be consumed both from native or managed languages, as well as JavaScript. At the same time the old Win32 applications will continue to run just as before and you can still (and most certainly will) develop Win32 applications.

Microsoft has created a new language called C++ Component Extension, or simply C++/CX. While the syntax is very similar to C++/CLI, the language is not managed, it’s still native. WinRT components built in C++/CX do not compile to managed code, but to 100% native code. A good news for C++ developers is that they can use XAML now to build the UI for immersive applications. However, this is not available for classical, Win32 applications.

You can get a glimpse of the new system and the tools by downloading and installing the Windows Developer Preview with tools, that includes the following:

• 64-bit Windows Developer Preview
• Windows SDK for Metro style apps
• Microsoft Visual Studio 11 Express for Windows Developer Preview
• Microsoft Expression Blend 5 Developer Preview
• 28 Metro style apps including the BUILD Conference app

Notice this is a pre-beta release and you might encounter various problems.

Before you start here are several additional articles that you might want to read:

• WinRT: An Object Orientated Replacement for Win32
• C++ Component Extensions: The New Face of COM
• C# and Visual Basic on the WinRT API
• Creating Windows Runtime Components in C++
• Tutorial: Creating and using extension SDKs
• Using the Windows Runtime from C++

There are also several new forums available on MSDN forums for developing Metro style applications, which you can use for addressing technical questions. Hopefully thee will be answers from Microsoft people working in this area.

Example
Let’s say we have the a simple COM local server called COM3264Server.exe. There is just one interface called ICoCOM3264Server. Here is the IDL file:

[
	object,
	uuid(733C70A7-F7EC-4C15-85D2-5CDB14F4110B),
	dual,
	nonextensible,
	pointer_default(unique)
]
interface ICoCOM3264Server : IDispatch{
   [id(1), helpstring("Says hello")] HRESULT SayHello(void);
};
[
	uuid(2F25FC66-2380-42FD-8476-8B5917FB1BF1),
	version(1.0),
]
library COM3264ServerLib
{
	importlib("stdole2.tlb");
	[
		uuid(9268A299-E817-4C5D-8627-C2582B66F16D)
	]
	coclass CoCOM3264Server
	{
		[default] interface ICoCOM3264Server;
	};
};

The implementation of the method SayHello() is straight forward; it just displays a message box with a text that varies between the two architectures, x64 and x86.

STDMETHODIMP CCoCOM3264Server::SayHello(void)
{
#ifdef _WIN64
   ::MessageBox(NULL, _T("Hello from 64-bit COM server!"), _T("COM3264Server"), MB_OK);
#else
   ::MessageBox(NULL, _T("Hello from 32-bit COM server!"), _T("COM3264Server"), MB_OK);
#endif

   return S_OK;
}

Registry
When you register the COM server, the 32-bit and 64-bit versions are registered in different parts of the registry. On 64-bit machine, the registry has two views (or modes):

• a native view, for 64-bit application; (e.g. registry path for CLSIDs is HKEY_CLASSES_ROOT\CLSID\)
• a WOW64 view, which enables redirections for 32-bit applications, a process transparent to the user (e.g. registry path for CLSIDs is HKEY_CLASSES_ROOT\Wow6432Node\CLSID\)

Here is the Registry registration of the (native) 64-bit COM server (notice the registry key in the status bar of the editor, and the path to the server executable).

On, the other hand, the 32-bit COM server is registered under the Wow6432 node.

So if both versions are registered in Windows Registry, which one is picked? Well, both the server and the client can specify which architecture to use:

• the COM server can do this via the PreferredServerBitness Registry value
• the client can do this using one of the flags CLSCTX_ACTIVATE_32_BIT_SERVER and CLSCTX_ACTIVATE_64_BIT_SERVER, which overrides the server preference

If neither the client nor the server specifies a preference, then:

• If the computer that hosts the server is running Windows Server 2003 with Service Pack 1 (SP1) or a later system, then COM will try to match the server architecture to the client architecture. In other words, for a 32-bit client, COM will activate a 32-bit server if available; otherwise it will activate a 64-bit version of the server. For a 64-bit client, COM will activate a 64-bit server if available; otherwise it will activate a 32-bit server.
• If the computer that hosts the server is running Windows XP or Windows Server 2003 without SP1 or later installed, then COM will prefer a 64-bit version of the server if available; otherwise it will activate a 32-bit version of the server.

Server Preference
The server can specify its preferred architecture in the PreferredServerBitness value under AppId (available only on 64-bit Windows). This integer value can be:

• 1: Match the server architecture to the client architecture. For example, if the client is 32-bit, use a 32-bit version of the server, if it is available. If not, the client’s activation request will fail.
• 2: Use a 32-bit version of the server. If one does not exist, the client’s activation request will fail.
• 3: Use a 64-bit version of the server. If one does not exist, the client’s activation request will fail.

Here is the value set in Registry to specify the 64-bit architecture.

When you run the client, it launches the 64-bit version and in my example the following window pops-up:

If I change the value to indicate the 32-bit architecture, the other COM server is launched and the displayed message is:

Client Preference
The client code I used so far looked like this:

   ICoCOM3264Server* pServer;

   HRESULT hr = ::CoCreateInstance(
      CLSID_CoCOM3264Server,
      NULL,
      CLSCTX_LOCAL_SERVER|CLSCTX_REMOTE_SERVER,
      IID_ICoCOM3264Server,
      (void**)&pServer);

   if(SUCCEEDED(hr))
   {
      pServer->SayHello();

      pServer->Release();
   }

However, the 64-bit version of Windows added new flags to the CLSCTX enumeration.

• CLSCTX_ACTIVATE_32_BIT_SERVER: used to activate or connect to a 32-bit version of the server; fail if one is not registered.
• CLSCTX_ACTIVATE_64_BIT_SERVER: used to activate or connect to a 64 bit version of the server; fail if one is not registered.

As I mentioned earlier, if the client uses one of these flags, it overrides the server preference (specified via the PreferredServerBitness Registry value).

In the following example, the client requests the 64-bit COM server:

   HRESULT hr = ::CoCreateInstance(
      CLSID_CoCOM3264Server,
      NULL,
      CLSCTX_LOCAL_SERVER|CLSCTX_REMOTE_SERVER|CLSCTX_ACTIVATE_64_BIT_SERVER,
      IID_ICoCOM3264Server,
      (void**)&pServer);

And if you run it, no matter what the server specified, the 64-bit COM server is launched.

To read more about the subject see the MSDN links above.

A few days ago I used my father’s laptop to do some web browsing. My father is not a computer specialist, but he knows how do use a computer for basic stuff like writing documents, browsing the web or downloading pictures from his digital camera. His laptop runs Windows XP and he had IE 6. Seeing that I though that’s so 2006. So I decided to upgrade that to IE 8. While IE8 was downloading I also decided to download and install Chrome for my own use. It took about a minute to download and install it. I was already surfing the web with Chrome by the time IE8 had done downloading.

Next step was to start the installer, but surprise, IE8 was requiring .NET 3.5 SP1. This was only 56MB or something so it didn’t take lot of time to download (but this could be very different in other geographical locations), however I thought that was a prerequisite whose purpose I don’t necessary see. So I started to install it and surprise: I got an error message that .NET 2.0, which was already installed, could not be uninstalled because it was not found. After some failed re-attempts I decided to uninstall .NET 2.0 manually and it worked well. However, running the .NET 3.5 SP1 setup again ended with the same error. So I decided to try .NET 3.5 without SP1. After a longer download the setup ran into the same error. Next, I downloaded .NET 3.0 and tried to install, but with the same error. At that point it was quite clear to me that there was something wrong with the uninstallation of .NET 2.0. After reading reports of similar problems on the web and without any suggestion being actually helpful I decided to download version 2.0 of the framework. Its setup allowed me to Uninstall or Repair and I chose to Uninstall. It said everything was OK so I tried 3.5 SP1 setup again, and this time it worked! Finally I was able to start the IE8 installation and it required to download and install a few updates and a couple of Windows restarts, and eventually it was up and running, one hour later after starting!

So my question to Microsoft is: how do you expect someone without good knowledge about computers and software installation be able to go through such a scenario? Chrome installation worked gracefully with 3-4 clicks and in less than a minute I was able to use it already. IE8 requires lots of updates and prerequisites like .NET and restarts and God forbids something goes wrong, you’re lost in installation. If the installation doesn’t work, you don’t have a product!

This is one reason (and definitely not the most important one) I prefer Firefox and Chrome over IE.

The curious thing was that my environment was similar to the one I had at the office: Windows 7 Ultimate, Visual Studio 2008 SP1, Office 2007, same browsers, etc. So I had to rule out a problem with Visual Studio. It must have been some weird setting in Windows 7, though I had done identical installations at home and at the office. Well, it turned out I didn’t have identical setups: at home I had both Romanian and English keyboard layouts, and for English I had both “US” and “United States-International”, the later being the default input language for the English layout.

Changing the default input language to English (United States) – US (as shown in the image above) solved this problem (without restarting Windows, only the applications where the problem occurred).

You can find this from Control Panel > Change Keyboard or other input methods > Keyboard and Languages > Change keyboards.

All 16 god modes

You can create them all by making and running (from the desired parent folder) a .cmd or .bat file with the following content:

mkdir ControlPanel.{ED7BA470-8E54-465E-825C-99712043E01C}
mkdir LocationSensor.{00C6D95F-329C-409a-81D7-C46C66EA7F33}
mkdir BiometricDevice.{0142e4d0-fb7a-11dc-ba4a-000ffe7ab428}
mkdir PowerOptions.{025A5937-A6BE-4686-A844-36FE4BEC8B6D}
mkdir TaskbarIcons.{05d7b0f4-2121-4eff-bf6b-ed3f69b894d9}
mkdir Credentials.{1206F5F1-0569-412C-8FEC-3204630DFB70}
mkdir InstallFromNetwork.{15eae92e-f17a-4431-9f28-805e482dafd4}
mkdir DefaultPrograms.{17cd9488-1228-4b2f-88ce-4298e93e0966}
mkdir PublicKeys.{1D2680C9-0E2A-469d-B787-065558BC7D43}
mkdir WifiNetworks.{1FA9085F-25A2-489B-85D4-86326EEDCD87}
mkdir Network.{208D2C60-3AEA-1069-A2D7-08002B30309D}
mkdir Computer.{20D04FE0-3AEA-1069-A2D8-08002B30309D}
mkdir Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}
mkdir workplaceConnetions.{241D7C96-F8BF-4F85-B01F-E2B043341A4B}
mkdir Firewall.{4026492F-2F69-46B8-B9BF-5654FC07E423}
mkdir PerformanceRatings.{78F3955E-3B90-4184-BD14-5397C15F1EFC}

(You can get the GUIDs of the folders from the above listing).

You can read more about this here.

Create a folder with the name GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Same icon as Control Panel

Commands available in GodMode folder

On the other hand you can get the same from the Start menu by searching for the name. Here is an example of the commands made available when searching for “defrag”.

Start menu results for "defrag"

This feature also works in Windows Vista and Windows Server 2008, but it is reported that is crashes with Vista 64 bit.

This feature only works from Windows Explorer. It is not available from tools like Total Commander or FreeCommander.

For more information on these releases check the Windows Team Blog.

Update: Windows Server 2008 R2 is not yet available.