“Microsoft is turning the source code for its embedded .Net Micro Framework over to the community and slowly withdrawing from that business, company officials are confirming. On the rumored list of teams most heavily impacted by second wave of Microsoft layoffs announced on May 5 was the .Net Micro Framework team – as well as the related MSN Direct unit. Indeed, both groups were affected, a Microsoft spokesperson confirmed on May 6.”
This might impact .Net apps on WindowsCE.
-Ad
Windows CE and Mobile devices support the .Net Compact Framework, not the [/i]Micro[/i] Framework.
The Compact framework is a light version of the Desktop .Net Framework, while the Micro Framework is essentially a small embedded OS that happens to run apps compiled to a very limited subset of .NET MSIL code (it doesn’t even support multi-dimensional arrays!), its been used in fancy multi-media remotes, networked sensors and other places that even the most spartan WinCE configuration is overkill.
Nice of them to turn it over, rather than simply discontinuing it.
From the link in OP:
-Ad
Right, but you should read that as:
“The .Net Micro Framework is one of a number of embedded platforms (Others include Windows CE and Windows XPe) Microsoft has licensed to third parties and made available to teams inside the company.”
Rather than:
“The .Net Micro Framework is one of a number of embedded platforms Microsoft has licensed to third parties, and made available to teams inside the company, such as the Windows CE and Windows XPe teams.”
I see where the confusion comes in though, now that you point out that particular paragraph, the wording is pretty ambigous.
Isn’t WinCE scalable for the embedded market with lower requirements than Windows Mobile? You know like the SPOT watches and internet toasters?
I always thought that WinCE was Microsoft highly customizeable platform for anything from watches to palmtops.
-Ad
On a completely different note, how long do you reckon before someone ports it to the Nintendo DS or the venerable Gameboy advance?
Even if the MSIL is limited, it would still be kinda funny to see a .Net game running on the DS or GBA. Hardware calls and C/C++ inter-op are possible, so it would just be a matter of getting the HAL made and then creating an assembly to map all the hardware features.
Also, the MSIL execution core might make a nifty lightweight, garbage-collected, embeddable scripting language.
could be could but .Net micro framework is still worse than JavaME in term of language crippleness.
they both are interpreted, tough I like the C# syntax better than Java, I think .Net micro framework simply can’t compete with plain C in the embedded market, because of the memory constrain, Devs actually have more control over memory.
And in term of platform dev like psp or ds, I think that lua got more momentum in the homebrew scene.
Yeah the major problem of bytecode VMs is the upfront memory requirements to JiT all that bytecode into native machine code. I doubt this problem would go away in embedded devices for a long time to come.
-Ad
It always depends on what your target platform is capable of.
Some embedded system can’t even handle C, making assembly the only viable language.
Others are quite capable of handling managed language systems. On some scenarios the applications are JIT ahead of time, when the application gets deployed into the system.
C and assembly hold the biggest slice of the embedded development languages, but there are quite a few solutions out there making use of Java and .Net. Even obscure languages like Oberon get used in some scenarios.