I suppose it depends on what you mean by compatibility. It will be interesting to see if current .NET apps will be able run on top of the ARM CLR or if Microsoft will actually strip out support for anything that's not Metro.
I've tried porting two Codeplex apps for cinterpreters to WP7.
The one which depended on a .dll couldn't be done because Silverlight doesn't support them.
The other which was self contained took me about three hours because I had no idea what I was doing because I am not a professional programmer by any stretch of the imagination.
I spent another hour creating a user interface so I could test it.
Windows 8 doesn't share a codebase with WP7 (except perhaps at a very low level). The Metro stuff on W8 is built on the new WinRT API/framework. What's hard to port to WP7 may be trivial to port to W8.
Disclaimer: I work for MSFT, but don't have any internal knowledge of W8 or WP7 that isn't public.
Given the ease with which I was able to port one project from codeplex, I am not surprised that Microsoft is lining up the ducks.
The project which I couldn't port (Ncalc) relied on ANTLR and thus a .dll.
The other (Irony) was .NET based and the main difficulty was cleaning up the structure created by VS Professional to Work with Visual Studio for Windows Phone [Express] and converting the console based code to event based...and that was easy even for me.
Anything that involves saving files will have to be reworked, since you no longer can use System.IO.. I'm trying to port a compression library and have run into this issue.
Good to know. A quick search online indicates that System.IO isn't gone, but does have a reduced set of classes. That could definitely affect some apps.
Porting pure .Net apps should be trivial - if you also believed that Java was "build once and runs everywhere"!
But how many real world (especially corporate in-house) .Net apps don't also assume a windows file structure, or a keyboard, or a mouse or 8.3 names, or .......
So the problem is, do you sell it as "Windows" and deal with all the tech support and returns because it doesn't run Grandmas scrapbook app. Or do you run a massive ad campaign to tell everybody it's "Windows but not really Windows" !
edit: sorry won't let me reply to you -------------
That's rather the point - just porting the .Net runtime to ARM isn't the whole story. Can you have a single Windows8 design that does corporate desktops and smartphones?
If Windows8 for tablets has to have apps in "c:\program files", have 12 function keys, have a mouse with a wheel etc, for backwards compatibility then they are going to have quite a task to deliver iPad type tablet experience as well.
> But how many real world (especially corporate in-house) .Net apps don't also assume a windows file structure, or a keyboard, or a mouse or 8.3 names, or .......
I don't understand your arguments here. W8 is still Windows. The file system is still there. The keyboard is there if you plugged it in, and you can use the on-screen keyboard if not. Your app shouldn't be expecting 8.3 filenames unless it was written before 1995.
There might be complexities porting your app to ARM, but not because of the stuff you mentioned.
The one which depended on a .dll couldn't be done because Silverlight doesn't support them.
The other which was self contained took me about three hours because I had no idea what I was doing because I am not a professional programmer by any stretch of the imagination.
I spent another hour creating a user interface so I could test it.