Can old native applications run on Windows8 tablet version?

I don't understand this picture well. In the Metro style Apps, what does C/C++ mean? Native C/C++? or is it managed C++? They(Metro style apps) don't even have Win32 layer!

To make an application which compatible with both Metro style and Desktop, should we only use .NET code? The old native applications can run on Windows8 Tablet?

Yes old apps, including unmanaged native apps written with C/C++/Win32 and managed ones in .NET, will run on a Windows 8 tablet fine. Except of course if the tablet is running an ARM processor; then it will only support the new Metro-style apps (and also apps which specifically target the ARM).

In the picture, C/C++ means unmanaged native apps sitting on the WinRT API, which is also unmanaged native. There will be seamless integration with .NET for those that want to use C# or VB.NET.

On your last question, you can't make an application which is compatible to both Metro-style and Desktop ... they are mutually exclusive - you have to make a choice.

WinRT is native code, and C/C++ are native, although their Syntax when used with WinRT looks like C++/CLI. From what I hear, it seems like an API that was designed for C++ rather than C, so it's very object oriented and people seem rather excited.

C# will use the usual way of COM Interop to use WinRT.

To quote Andy Rich (MSFT) from this discussion:

Core WinRT is NOT managed - it is native and COM-based. Our language provides a fully-native projection of that in a high-level syntax, but you aren't tied to that syntax - you will be able to target the Windows Runtime using low-level COM or WRL (an ATL-like template library) as well. (The C#/VB projection is a different story, they generate runtime-callable wrapper objects which marshal between .NET and WinRT.)

C++ in Metro apps is native C++. It is recommended that you use the new language extensions, which look a lot like C++/CLI, and provide a similarly high-level experience - e.g. no need to manually deal with reference counting objects and strings, or implementing and calling QueryInterface - but in pure native code. You don't have to do that, though.

In any case, for your own classes, you can define them in vanilla C++, and compile them to a library. This way, you can share your logic between the desktop version of your app (with UI implemented using MFC, Win32, Qt or whatever) and the Metro version (with UI implemented using WinRT APIs). Similarly, for .NET apps, you can separate logic into a class library that's reused between desktop and Metro.

There's no way to write a single app that will run on both with the same UI layer, neither in C++ nor in .NET. On the other hand, you can approximate that to some extent with HTML/JS, if you avoid using WinRT APIs and stick to HTML5 standard - then you can make a "desktop version" by hosting it in a browser.

I'm a professional software developer, and while I write mainly enterprise web-based applications, I have played around with Visual Studio 2012 and Windows 8. Here's what I've discovered:

Since Metro is now a verboten term, I'll use the term "Tablet apps" to refer to full-screen apps and "Desktop apps" to refer to programs running on the Windows desktop.

I don't understand this picture well. In the Metro style Apps, what does C/C++ mean? Native C/C++? or is it managed C++? They(Metro style apps) don't even have Win32 layer!

All tablet apps use managed code. This is because the WinRT operating system can't run x86 or AM64 instructions. Both versions can run .Net code just fine, though. So all WinRT apps must use managed code, use a XAML UI, and they will only be distributed through the Windows Store.

To make an application which compatible with both Metro style and Desktop, should we only use .NET code?

Yes. That's exactly right. You must use .Net code. Old, native apps can NOT run on a Windows 8 tablet. If you're like most Windows devs who learned by doing, this is going to require an adjustment in how you write code.

Here's how I am approaching it:

A basic program that needs to operate on different form factors (tablet, desktop, phone) will have 3 classes. The Model and the Controller classes will be implemented in a DLL, along with an Interface file that defines the GUI events and methods. The only thing that actually goes in to my .EXE files is the GUI. And the only logic in the GUI is basically to raise an event when the user performs actions on the form that require the program to do something.

For example, the user fills out his name on a text field, then clicks "Submit." That would raise an Submitted event with the value from the Name box as a parameter. The controller can send feedback back to the form with a method, such as UpdateStatus()

It sounds complicated, and it takes more up-front design. The beauty of this system is that once you implement the program for one form factor, all you have to do is modify your XAML for the other form factors. Your controller and your model don't change at all. (I'm sure that someone will point out how to use XAML templates to do this, but I'm not there yet.)

As with Windows 7, 64 bit Windows doesn't support old 16 bit apps. Other than that, yes, native apps are supported.