.NET Could Be Key for Windows on ARM
A lot of talk in the tech world lately is focused on Microsoft’s Windows 8 OS being released for ARM platforms (with some restrictions). This, combined with the HTML5 Metro interface people either love or hate, are among the largest changes to Microsoft’s Windows line of operating systems in history, and with it comes an interesting fact for developers looking to have apps available for both Windows 8 on Intel and Windows 8 on ARM: .NET’s CIL virtual machine.
.NET CIL
If Microsoft does not port the .NET runtime to Windows 8 on ARM, allowing apps compiled from C#/VB/C++ to CIL to execute on either supported hardware platform, then they are either shooting themselves in the foot with their competitors’ weapon, or else trying to shift their developers’ focus to HTML5 Metro apps with Windows Phone compatibility as opposed to driving them away altogether.
CIL was designed based on the principles of Java, namely “write once, run anywhere.” But with the advent of HTML5 and the problem that almost every new developer on the scene is web-driven, Microsoft may have something with making every part of their programming API HTML5-based (drinking game: drink everytime an acronym is mentioned in this article, you’ll be smashed in minutes).
But exposing the Windows API to both HTML5 and .NET allows their existing, lower-level .NET developers to continue porting apps to Windows 8 while also allowing HTML5 newbies the ability to get in on the Windows app market, possibly tying their apps to web services as well for a fluid experience across computers and mobile devices.
And, of course, Java is long-dead and more than likely will not be ported to the new Windows 8 for ARM OS. The reason for this is elaborated on below, related to the death of native code due to the increasingly-prevalent “walled garden effect” that even prevents Linux from being installed anymore via the new signed EFI crap.
Windows is no stranger to non-x86 platforms
A little-known fact these days since most IT training focuses on Windows Server 2003 and now Windows Server 2008 is that Windows NT 3 and 4 back in the day (before Windows 2000) supported Intel x86 processors as well as MIPS and PPC architectures as well.
In fact, the reason why Windows NT 3.51 is accepted as the “complete” version of Windows NT 3 is because it was the first version to support all three architectures – Windows NT 3.5 did not support PPC, as it was still in development. The leaked Windows source code from Mainsoft a few years back confirms this, with core elements of the OS having directories for x86, MIPS and PPC just like Linux does except more scattered (possibly the reason the support was scrapped).
In addition, Windows CE has allowed large portions of its source code to be made available to hardware manufacturers could tailor it to their platform and extend it as needed for embedded systems and their applications, an oft-overlooked fact due to the nature of embedded systems’ niche markets.
It is unclear as of now whether genuine native apps written in C++ calling the Win32 API will be supported on Windows 8 for ARM, and how device drivers will be supported – as one tech writer put it, “the days of native code are dead.” What do you think? Which programming style will bring you as a developer to the platform? Let us know below.
About Anthony:
Anthony is the Silicon News editor-in-chief. Many dedicated readers know him from his prior blog The Coffee Desk before its sale in early 2010, which was featured in everything from Yahoo! News, Slashdot.org, and countless other news agencies pulling in millions of unique visitors a month. He has ample experience with software, hardware, and networking, having been employed by numerous companies ranging from U.S. government agencies, research and development firms and Google. Though his approach is usually technical and dry, he is notorious for his subtle and witty observational humor.
27 comments on “.NET Could Be Key for Windows on ARM”
Leave a Reply
-
Tweets
- Using the iOS SDK to interact with SOAP, XMLRPC, REST or JSON web services? Then read this: http://t.co/JjcOqdHM
(about 121 days ago) - Bidirectional Switching Power Supplies: Innovation With Renewable Energy http://t.co/MwOaYkMI
(about 122 days ago) - Is 3D Printing just hobbyist crap or ready for the big-time? Analysis: http://t.co/W7Zrvtjz
(about 125 days ago) - Magento as an e-commerce platform: Is it right for you and your business? http://t.co/kdA3H11o
(about 126 days ago) - What type of corporation do you need for your upcoming startup or business? Here's the skinny: http://t.co/esTKnmS6
(about 127 days ago)
- Using the iOS SDK to interact with SOAP, XMLRPC, REST or JSON web services? Then read this: http://t.co/JjcOqdHM
Before going on about this kind of thing, you should at least check some of the basic information. For example, this architecture diagram:
http://community.devexpress.com/blogs/ctodx/Windows8Architecture_485458D4.png
Metro apps can be C/C++,C#, VB, HTML5/JS. This is common, well known knowledge.
Exactly – I’m not sure what the point of this article is.
“If Microsoft does not port the .NET runtime to Windows 8 on ARM…”
It’s already ported. What are you talking about?
“…to HTML5 Metro apps with Windows Phone compatibility…”
Windows Phone 7/7.1 apps can’t be written with HTML5 – developers use Silverlight (.NET) with C# or VB (and a select few get to use native code). Windows Phone 8 might use WinRT as its development platform, but that’s yet to be confirmed.
“It is unclear as of now whether genuine native apps written in C++ calling the Win32 API will be supported on Windows 8 for ARM…”
It’s not unclear at all – you can read exactly which Win32 APIs are available for Metro-style apps in Windows 8 right here: http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
The only desktop programs that will run on Windows RT (Windows on ARM) are Microsoft Office and the essentials like Windows Explorer.
You forgot that NT 4 also ran on Alpha
I completely disagree with the statement ‘native programming is dead’. In fact it is more important than evrer, imho. Major app and game developers supporting ios and android can use this native code to easily port across platforms. Another advantage of native code is performance and memory usage. These devices may be powerful, but not compared to a desktop. Resources are limited on these devices. Native code allows devs to exploit as much performance as possible. If ms wants w does phone app to take off, they need to allow native app development.
Java is NOT dead. Look up ADF mobile, which is going to bring java to the IOS
Unless it mangles the API to where no Java code is interpreted/compiled/executed on the iPhone itself (barring remote execution before fetching the result), Apple won’t have it. Developers outside the Jailbreaking community always try a new way to get an interpreted language like Java or Python/Perl onto iOS and Apple always shoots them down. That said, Java is still used internally by many companies and isn’t “dead,” just most new developers don’t approach a problem with “Let’s use Java!” in favor of newer, sexier and better-supported methods.
“It is unclear as of now whether the Pope is Catholic or whether bears shit in the woods.”
First, no need to go back so far to 3.51 times, later Windows versions supported Alpha (win2000) and IA64. (all versions still even)
Second, the reason why the .NET engine is not ported is because it has become fat, and is no longer suited to low powered platforms. It has become a desktop engine. Java suffers from this too (JavaME vs the rest).
The “run everywhere” mantra is just a first order theoretical approximation, not a hard truth. It works fine since usually in a company you don’t mind your bookkeeper having to wait 10 seconds before it starts. If he shuts it down in the first place.
Now with mobile that is different. JITted App startup can be slow, and, worse, eats time.
Third, the bit that holds back native is simply that Google pooh poohed native early on (to get the masses to consider Java at all). That in itself isn’t bad, it has happened before (rumours that XP would be .NET only), but the crucial mistake they made is to not properly handle architecture in their stores, leaving each programmer to their own detection mechanisms and shipping fat(multi arch armv5…armv7) binaries.
A decent integration of architectural aspects in marketstore and a native toolchain that created binaries for multiple binaries in one go, and packed them into an archive could have easily solved that. Apple has shown how to do this (e.g. with the ppc->x86 turnover)
Well-said Marco. But do you think as mobile processors get faster (the new iPad as a prime example) this will still be relevant? What about all of the existing .NET apps that surely one would want on a netbook running Windows 8? Plus, as someone else pointed out, Metro can be implemented with .NET as it stands so it looks like .NET will already be on Win8 ARM in some form or another.
Stephen:
I’m not sure. It depends on how tweakable the JVM/CIL is. But from what I saw of that, it either needs several magnitudes of CPU, or a game changing change to the VMs. But such game changing changes will probably not allow recompilation of existing apps.
Not that is a serious prospect on the whole anyway. Desktop apps generally have too much polling behaviour, and don’t play nice with suspending of applications, limited battery life etc.
While Metro can do .NET, and .NET can run on ARM, that doesn’t mean that the combination of these is sane. And, that is for new code. I think existing code is out of the question anyways. (see e.g. experiences with porting Java code to Android, or objective C apps from OS X to iOS) Wishful thinking.
.Net is only a layer on Win32 and DirectX. As Win32 is not evolving and WinRT moving to became the new Microsoft platform, it’s really understandable that .Net will never reach ARM devices.
If people can do new application for IOS and android they can do too new things for windows. It’s the first time since the last 20 years that our windows 3.0 code have to be rewritten.
Maybe it’s just the time to move to WinRT or to move away from windows Operating system.
“it’s really understandable that .Net will never reach ARM devices.”
-commentator on this article
Good grief, that is so wrong. .Net is running on ARM TODAY. Not only does VS.Net 2012 completely support .Net on ARM, v2010 does as well, as that is how WinPhone apps are written. The UI pieces use Silverlight instead of WPF, and it is using Compact Framework (to get around the bloat issue you claim is a dealbreaker), but it most certainly is .Net. The real issue in terms of where .Net will run is what base assemblies are included with the runtime.
And on the bloat issue, there is also a regular .Net config for projects to require only a bare minimum of BCL (it’s called “Client Profile”).
Win32 can’t be killed. Just sayin’.
Look up Monodroid and/or Monotouch in google or go to http://xamarin.com and after that tell me that you still believe .NET/C# will not be available on Windows 8/ARM edition.
Please quote my exact words where I said a .NET technology would definitely not be included in Windows 8, please. If you actually read and comprehend the article, a fifth-grade level skill, you will see that I merely explore the possible outcomes either way without making any claims about what will definitely occur. It amazes me how people somehow misread commentary for claim. Jesus.
Well, you said:
>>If Microsoft does not port the .NET runtime to Windows 8 on ARM
I merely pointed to a non-Microsoft entity that already has ported C#/.NET to non-intel hardware. Which makes it likely they will try something for ARM if Microsoft doesn’t (or maybe they gey hired by Microsoft to do it).
Now I do not know what the 5th grade level is (non-american)however you could have made the text more readable by splitting your 6 line sentence. Especially the
>> as opposed to driving them away altogether.
makes no real sense to me, what do you want to suggest with this?
Martin
Right there, you just admitted to misreading my word containing “if” (the first word of the very sentence) as my claim of definite fact. If you can’t read and comprehend English (non-American, as you say) then get the hell off my blog and stop misinterpreting this post like 50% of the other readers have apparently given their claims and the words they are putting in my mouth.
Next time I’ll be sure to use short and simple sentences like you’d find on simple.wikipedia.org (look up the XKCD comic on the matter) so everyone can follow along without any confusion, my mistake for assuming fluency in English.
>> my mistake for assuming fluency in English.
If only that was the sole mistake you made in this article.
regards
The .NET micro framework is already on the ARM platform (as well as Analog Devices’ Blackfin, to boot). How hard would it be to have the full-blown .NET on ARM? At this point it would just be laziness.
I haven’t looked Win8 HTML5 API and what kind of API it has. But I have some experience using PhoneGAP to run HTML5 coded on Android, IPhone and Windows phones. In my opinion there was not enough controls to make anything serious with HTML5. For POCs and demo applications it was enough but….
When creating app with i.e. native Android tools you get control of activity life cycle, hardware buttons and etc. Just wondering how you can do that with HTML5 on Win8? At least in my opinion that kind of functionality is required when you publish something to market.
On the other hand..If you have some special extensions for HTML5 it again makes it non portable to other HTML5 devices and here we go..We have nice HTML5 apps but you cannot really port them easily to other devices..Deja vu..?
And, of course, Java is long-dead and more than likely will not be ported to the new Windows 8 for ARM OS.
That’s one hell of a crazy assumption to make, given that Java already runs on a) Windows and b) ARM.
Metro apps in .Net are explicitly supported, first-class environment on ARM; I’m not sure how anyone’s confused about this.
Someone could probably port java or something but whats the use given tools like IKVM and java -> C# converters?
I’m sure mixed-binary and pure native apps will have their place in games and high-performance applications as well.
Considering that there are a lot more Android Phones out there and Android developers use Java to develop the code (at least before the byte code is converted from Java to Dalvik). All Blackberry development is done in Java as well. Most non-smart phones run a version of Java-ME.
To say Java is dead is being REALLY silly. There are a HUGE number of businesses that use Java out there (admittedly mainly on servers) and a huge number of Android Phones and Tablets in use. There are a BILLIONS of devices out there that use Java – far more than the number of Windows PCs! Every BluRay player uses Java – also a huge number of other devices. That is why many ARM chips have Java instructions built into the hardware!
You are right (to some extent) about the desktop – although there are still a large number of Java applications in use on Desktop Windows PCs. As somebody who (did) write .NET (and Java) but who now focusses solely on non-MS technologies I have seen a HUGE upswing in the use of Java and technologies like Python and PHP.
As you say – .NET is very much alive and kicking but so is Java (and Java usage is growing rapidly). We will see.
Pingback: Microsoft Releases Tablet: Microsoft Surface » Silicon News
Pingback: My Homepage
Pingback: Mozilla Hacks Weekly, July 5th 2012 ✩ Mozilla Hacks – the Web developer blog
Pingback: anabolin adenoncus biprong