Slashdot Mirror
On Microsoft's Embedded DevCon Keynote
An anonymous reader writes "WindowsForDevices reports on the keynote talk at Microsoft's Windows Embedded DevCon (developer conference) taking place this week in San Diego. The story includes some interesting comments and highlights from the talk. Don't miss the cool bit about the ARM7-based 'SPOT' development platform that runs a tiny version of the .NET Compact Framework -- Microsoft is demoing a robot that's run by SPOT. There's also a pointer to an online video demo of a project to create a digital picture frame using Win CE."
The point the grandparent post should be making is that using WinCE for a picture frame is a waste of money and is thoroughly not noteworthy.
Many embedded products don't have any need for connectivity so unless you build your virus into the system, it's not a problem.
Windows + .Net for a simple picture frame ?
...
wtf ? do they not teach the concept of KISS in school anymore ?
I think the likes of TRON will be around for quite sometime
Sunny Dubey
My company is using WXPe for an upcoming realtime embedded medical diagnostic system. We're solving this by basically rolling our own MSI/Installshield bundles for each and every patch, vulnerability and virus definition.
Call me crazy, but I'm not comfortable with medical equipment needing this kind of support? Was that x-ray machine scanned for viruses before you used it?...
You had better have a good firewall in your garage for those times when your car says to you we're home, would you like me to go online and fetch your calendar updates?
It's one thing for an unfirewalled windoze 98 box to be hacked and compromised by a remote attacker. It's quite another to have your vehicle compromised unbeknownst to you--
I don't think I want my car "crashing" its OS while I'm at the wheel, unrelated to any driving choices/mistakes I may have made. I can see it now--
"Honest Officer! I think my car must have caught the Download.Ject virus this morning!" I didn't drive into that bridge abutment on my own! Honest!!" The officer replies--
"Sir, didn't you listen to the latest Microsoft warning? You should never use your steering wheel / joystick to surf to 'unsafe' websites with IE! Now I have to write you a Stupid-Ticket."
But seriously...
How concerned are other developers about MS style code being let loose in a critical system like an automobile? I mean, running a PDA or a desktop printer is one thing. When they crash, people aren't so likely to DIE! A malfunctioning four ton Ford Excursion, on the other hand, is something I'd really rather not encounter.
No source considers WinCE to be a hard real-time OS. There are realtime extensions to embedded windows (WinCE and XPe) available, and some even sound pretty promising from a technical standpoint, but the bottom line is that with a non-deterministic scheduler, it's not real-time. Usually predictable, sure. Probably fast enough, of course; however, without the extensions (and perhaps in some situations with them, the technical articles I've seen were still pretty vague in spots) it's not an RTOS, and please... if anyone is going to use it behind some bit of critical hardware, put the stickers on the outside so I'll be able to avoid trusting my life to it *smirks*
Anyone want to enlighten me further?
I can't imagine how one could praise WinCE so highly. It's not hard realtime. This isn't a negative, just a fact. It just means that it is not a flexible as some other alternatives. It has NO flexibility as far as scheduler and memory management are concerned. The API is loosely based on the Win32 API, which sucks especially for this purpose, and sucks doubly because 90% of the parameters to the bloated API calls are ignored anyway. IPC options suck: thread message queues (a la WPARAM/LPARAM) and shared memory. The scheduler is capable of only 32 processes (again I consider a bitmap scheduler great if it's an option, but when you realize that WinCE drivers and BSPs are built ASSUMING this is a constant it is quite bad). There is essentially no memory protection since it is trivial and plausible that any process will enter Ring 0 even by accident. The scheduler is dead nuts simple. This is not necessarily a bad thing, until you realize that changing it is not trivial without practically rewriting most of the kernel (as the device driver model assumes the scheduler and memory model) and furthermore the OS is such a bloated piece of shit considering how simplistic the components are.
Oh yeah, there is NO standards compliance, and I'm not talking about any one in particular. I'm just looking for some basic ROAD MAP from Microsoft. It would be nice if Microsoft at least developed their own standard and abstractions that would mean that so many fundamental things wouldn't change from one release to the next. Couple this with the fact that even the basic C runtime support is sorely lacking.
As for rock solid, you are at the mercy of whoever wrote your BSP. I have seen a number and the quality varies widely. The one constant thing is they all reinvent the wheel for missing facilities and interfaces. I have seen very few WinCE implementations that proved themselves to be rock solid.
Let me just say that while WinCE may be OK for some limited uses, its no QNX or vxWorks and that's sad since Microsoft had the chance to develop something that would bring something new to the table.
Your coworker is probably quite smart. If his customers do not know any better, then I say good for him!
"The scheduler is capable of only 32 processes (again I consider a bitmap scheduler great if it's an option, but when you realize that WinCE drivers and BSPs are built ASSUMING this is a constant it is quite bad)."
This has not been the case since Windows CE 4.0.