Can anyone say if FSX has been re-written in .net or is it still a Win32 application?Paul

Somehow I doubt it's been re-written in .NET.James

I wouldn't be surprised if some .net features are in there though, in light of being able to fly online in the ways we are going to be able to.

No .NET. Still C++ and some ASM.

Just because I'm curious Mike, would you deem it possible (performance wise) to write something like FS with managed code?

Anything is possible, the real question is why would we want to?

Isn't MFC and the Win32 API obsolete as of Vista? My understanding is that they are being replaced by the WinFX API and the rest of the .NET framework.Will it not be like running a DOS application in current Windows? Like a backwards compatibility thing rather than a program native to that operating system?I'm also surprised there's no .NET code because the FAQ's say that the best experience will be with Vista, which sounds like it's using some of the new Vista APIs (The new Windows Presentation Foundation (WPF) being a likley candidate) which are all .NET libraries.Maybe I have things a bit mixed up though. Can you shed any light on this?Paul

In a nutshell, .NET simply adds an abstraction layer on top of existing Windows API's to increase developer productivity and code safety. Typically when performance is critical, you look to peel away the layers..NET utilizes the same underlying API's (Win32, GDI+, DirectX). Managed code typically requires additional overhead to produce "safe" code. Both .NET and managed code would decrease performance relative to assembler and unmanaged C++ to access the same lower-level APIs. The .NET runtime (DLL's) would also consume more memory that could be potentially used by the sim. We could also speculate about Just-In-Time compiling and the potential for studders, but probably a topic for another day.Regards,Rich

At the end of the day it's still 0's and 1's (or is it 1's and 2's? ) as far as the CPU is concerned. I could program using a hex editor if that's all I had. ;)