Windows CE 6 Arrives Complete with Kernel Source 169
An anonymous reader writes "Microsoft has launched the sixth edition of their embedded OS Windows CE and this time has included the full source. From the article: 'Developers can now access shared source code for the Windows CE kernel -- as well as certain device drivers and application-level components -- directly from within the Windows Embedded CE 6.0 distribution package. To do this, they click on a function in the IDE that installs the shared source, and indicate their acceptance of the associated shared source license.'"
A Trend, I'm Sure (Score:4, Interesting)
Who is MS targeting this new version of CE to? (Score:3, Interesting)
What kind of portable or industrial machine is going to need those kinds of capabilities, much less have the onboard hardware to fully utilize 'em?
Wow ... (Score:3, Interesting)
I realize this isn't open source persay, but I'm very interested in it, and I wonder why they decided to open the CE kernel up. I also wonder if there is enough code to flash CE 6 onto a CE 5 device (I have a T-Mobile MDA with Windows CE 5, I wonder if I can simply drop the new kernel in there).
Re:Who is MS targeting this new version of CE to? (Score:3, Interesting)
Writing this on a notebook that outpaces the US$ 100K workstation of a couple years back.
They had to do it. (Score:2, Interesting)
I recently worked in a shop which did development in both WinCE and Linux. The source code has been available for WinCE for quite a while, under NDA.
Truth be told, they had to open the source code. The Linux group consistently delivered features before the WinCE guys. The problem was that anyone hired for WinCE development had a substantial ramp up time, whereas we could hire engineers who already knew Linux.
The open source nature of Linux allowed us to hire engineers already proficient in writing Linux drivers and code. Can't say the same for WinCE. In fact, while I think the shared source license is a step in the right direction, it won't bridge the gap between Linux and WinCE in the embedded sector. Linux is already a dominant player, and the shared source initiative won't put WinCE in the hands of budding engineers. Instead, they'll look at Linux, which is truly free.
A few years ago, when I mentioned that Linux was leaving Windows in the dust in regard to new technologies (like 64 bit computing), I received an interesting reply: "That may be true, but Windows on the desktop already has something Linux doesn't: inertia." Just as Windows gained inertia on the desktop, Linux has now achieved that "inertia" in the embedded world which will make it difficult to dislodge.
This move seems to indicate that Microsoft is becoming aware of how compelling Linux is to embedded developers.
Re:They had to do it. (Score:3, Interesting)
While I don't really disagree with you about Linux/CE, I'll present the same story but from a different standpoint. We use 3 main OSes for development: Linux, VxWorks and WinCE. The other day we received a code drop for a Linux wireless client from a major vendor everyone has heard of. It was a piece of crap. That's great that it was open source, but it was a piece of crap bit of open source. And when you're knee-deep in a project that's already late you don't have time to learn 30K lines of new source and figure out what they screwed up.
Meanwhile (at the same time), we uncovered three problems with CE:
- the DHCP client wasn't waiting long enough for a server response in a particular configuration
- the USB8023 driver wasn't getting enough data from a site survey on an RNDIS device due to an improperly sized buffer
- adding a second IP address to an adapter was producing some wacky behavior (that's the technical term
Within two weeks, MS engineers had diagnosed the 2nd and 3rd problems (we figured out the first) and sent out hotfixes that were later addressed by a QFE (which, for CE, is like a mini service pack). If we had had full source we would've needed an engineer that was intimately familiar with the USB8023 driver and RNDIS, an engineer that was intimately familiar with the way adapters bind to a protcol in CE, and someone with a rudimentary knowledge of DHCP. Your company may be lucky enough to have all on hand, but most companies probably do not.
Three weeks later, Vendor X is still working on those Linux bugs. It doesn't really help that the damn thing is open source.
I realize that these are both anedcotal examples, but maybe it will be refreshing for some to see a viewpoint on
Two endnotes:
- The CE source for the DHCP client is already distributed. It helped to have it on hand.
- The kernel is a very small part of CE. Having the kernel source won't help most people's problems, because most people aren't making kernel changes. Most CE work is done at the driver level, the OAL (the OEM adaptation layer that sits between the hardware and the OS), and the application level.
Yes, but who has the options? (Score:3, Interesting)
So why didn't you hold the vendor accountable for the poor quality? You seemed to expect Microsoft to fix its bugs, why didn't you expect the same service from vendor X?
While MS certainly did respond quickly, they always had the option of ignoring you. Fortunately for you, they paid attention to your problem. I'll bet that a lot of other people were also experiencing the same problem.
However, what do you do when you find yourself with a problem that you can't reliably reproduce, or one that the vendor doesn't think is worth the effort to fix?
With the source code, you can always bring in another engineer to work full time on the problem. Without the source code, your schedule is at the vendor's mercy.
The difference is subtle, but important - especially if you have to meet a deadline.
A difference of degree (Score:3, Interesting)
I think they're lowering the cost for everyone. It turns out that most companies that are making a CE product want the source. MS didn't charge for it (well, the CE licenses were pretty expensive to begin with), and it was just costing everybody lawyer-hours.
-- Hamster