Is it too late to split Windows 8 into desktop and tablet versions?
extremetech.com
extremetech.com
I can happily continue to run all of my existing apps without having to touch the Windows App Store, or any other locked down stuff.
The only downside is, apparently, the launch screen. If they don't see sense and allow a launch direct to the Desktop then I'll be annoyed.
You are stuck in the problem of either adding a 'bit' of backwards compatibility until you get into the state of supporting 1980s netware apps because some customer in one focus group mentioned them. Or you deliberately change things to differentiate it.
Average Joe will buy it because MSFT has a massive ad budget
Of the rest; (money>sense) > iPad : Android ;
(money > sense) ? iPad : Android ;
i.e. the 2nd '>' should've been a '?'and 90% of the world still runs Windows on their "traditional" computers, so this is an appealing proposition.
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.
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.