Yeah, I listened to that yesterday and spent most of it shaking my head and muttering…
I heard it as well. I lost my faith in ms based on this. He claims windows is scalable and secure. And he does not know if there is a unique id chip on it… The windows Eco system brought to embedded devices… And it has several buses … Even SPI ???
Please. Someone with a reasonable technical knowledge and common sense apply a position on the ms iot team.
Crap
I just listened to the podcast as well. So basically I can get more with a netbook or mini-itx board + any gad getter device. Load it with Linux to get a real time OS and bam; Internet of Things. That combo might cost less than the Galileo.
[url]http://www.newegg.com/Product/Product.aspx?Item=N82E16813157367[/url]
Some one send this guy (the one on the pocast) a NETMF board, I think he is still high on seeing the LED blink on the Galileo… he needs to move on 
@ Rajesh - I hope your not talking about Dan as he is the PM for Galileo at MS… :whistle:
While I have to give Dan full points for being a hands on coding and robotics dude, he has been the PM for 4 months and I’m not exactly sure he has much of a team or mandate at Microsoft as to be honest this whole Galileo thing seems sketchy and foggy at best. I have written apps in the past that are too meaty for .NetMF and so might be suitable candidates for this Galileo fuzzy area, and especially so given some of the system lock downs of Windows 8 makes it difficult to port them to Windows 8, maybe Galileo might work, but its all way to undefined to be able to say much about what the target space is or what it gives us. Maybe this is just a recon mission, but really guys, its little late for that, but if you are doing recon over there, don’t forget about over here or your going to lose everything here. I think its very clear whatever Galileo is or what that space is, it isn’t .NetMF or Gadgeteer so defining their position on Gadgeteer shouldn’t be a conflict of interest for Galileo. .NetMF has been given more resources which is great, but what about Gageteer as really Dan didn’t say squat about it and really only referenced Netduino. I’m trying to reach out to these guys to understand where their head is at and argue for why I think Gadgeteer should be in their heads as well, and I’d really suggest to others to do likewise.
I think there is a bit of mind shift problem at Microsoft as no doubt they have been successful with Windows CE (I built some cool stuff with it over the years), and Windows Embedded etc and so Galileo is sort of a natural and somewhat safe extension of that mindset. .NetMF is a rogue beast in that its not really Windows and so its hard for Microsoft as a whole to get their head around that device mentality. Now to be fair I think that device dudes will need to elevate their game as well, for example security on devices or the ability to update them to fix vuls etc isn’t optional if they want to go mainstream otherwise its simply an impending unfixable train wreck a coming and no one wants that, but Microsoft really needs to embrace that ‘its too small to be windows’ concept and go with it as they have a heck of a start with Gadgeteer and .NetMF.
2 Likes
Yep, poor Dan 
No, joke aside. Are we saying that Microsoft is building a NEW VERSION OF WINDOWS that runs well on devices?
Personally I don’t think Windows® should be running on the small devices we are using…
NETMF all the way for me…
Man - shoot me now as i’m starting to sing from @ godefroi’s hymn sheet
4 Likes
Everyone comes around eventually 
The way I see it, you can have lots of devices, or you can have Windows, but you can’t have lots of devices running Windows.
1 Like
Yea we don’t need Windows on every device but C# to program them all. The only way I can see M$ getting revenue on devices this small is if they patent some sort of acceleration electronics to speed .netMF execution or abilities, and license that accelerator to ARM vendors. This opens up uCs to a legion of developers that would otherwise never touch them, get’s MS paid and gets certain vendors a competitive advantage in the marketplace.
Well that’s what I would do anyways.
[quote=“Justin”]NETMF all the way for me…
Man - shoot me now as i’m starting to sing from @ godefroi’s hymn sheet
[/quote]
Count me in. I can accompany you to the accordion… :-[
But please don’t shoot ! 
So there’s a .NETMF community here, finally ?
@ Mr. John Smith - No acceleration electronics needed, just a native compiler. There’s no reason that C# can’t compile to native code, except that nobody’s made the effort yet. The previous iteration of native compilation was operating under constraints that are no longer in place (RAM and flash shortages).
@ godefroi - My netMF history is a bit poor. What was this previous iteration?
It would be a game changer if it ever happens.
@ hagster - Very early on the NETMF team investigated a couple of strategies for native compilation. They didn’t go with AOT (ahead-of-time) native compilation, because the native code was actually significantly larger than the MSIL, and didn’t fit well in the devices they were using at the time (flash shortage). They didn’t go with JIT (just-in-time) because it involved recompiling methods over and over because there was insufficient RAM to store very many JITted methods at any given time, eliminating the performance improvement (RAM shortage).
1 Like
So wait IL is smaller than C on a uC?
@ Mr. John Smith - makes sense. A single IL command converts to a number if lines of C code. Think of all that extra stuff to do bounds and type checking. This would all be in-line code in C.
Remember we’re not talking about C here. C isn’t native code. We’re talking about machine language. It would be entirely possible to create a C interpreter.
IL is a quite high-level language. It’s lower level than C#, but still much higher level than Thumb2. Each IL instruction corresponds to somewhere between one (something like add or multiply) and maybe hundreds (something like newobj or switch) of Thumb2 instructions.
(Edit- there are apparently many C and C++ interpreters around. All of them would suffer, to one extent or another, from the same performance problems that the IL interpreter suffers from).
Today AOT would be a great idea when using G120 or even G400.
But reading through the net about this topic tells me that it would be quite a challenge to write that compiler, even if all sub components are already out somewhere.
There’s a LOT more flash available on-chip than there was back when that was written. 2MB in some cases.
It has been done already - Microsoft has been compiling Windows Phone apps for quite some time, the technology has been made public as .NET Native (GitHub - dotnet/coreclr: CoreCLR is the runtime for .NET Core. It includes the garbage collector, JIT compiler, primitive data types and low-level classes.). At the moment it is targeted at Cortex-A, but I don’t think there would be much changes needed to have it generate code for Cortex-M. Now if only the .NET Micro Framework team would get their hands on it in reasonable timeframe…