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.
Disclaimer: I work for MSFT, but don't have any internal knowledge of W8 or WP7 that isn't public.
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.
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.
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.