Hacker News new | ask | show | jobs
by sumtechguy 775 days ago
WinCE was an interesting beast. The ones we made were MIPS (picked over an ARM system). Running a wildly patched 2.12. Also your PCMCIA issues? Trust nothing. It could be anything. But my guess is it is the driver, as getting that type of flash card to work consistently and correctly takes a steady hand. Your flash could also be slightly corrupt. We had almost that exact same chipset and found it would randomly stop taking commands after awhile and the flash leveling would cause writes to time out leaving half written pages. You also discovered Visual C++ for wince has a lot of interesting bugs. I think it got so bad we were about to start breaking each method into one cpp file as things could 'smear' between methods before the whole thing went EoL. There are newer versions of the compiler that may help some (maybe you already have it). If you got into the right program (or the right company) you could get the ODM build set. Which would compile the whole OS (based on a very bespoke version of visual studio 6 and a crazy mixture of using mklink and crazy batch files). But it would also let you debug the drivers. As for my 'trust nothing' I mean it. The API calls that should 'just work' may randomly crash or leak. Good luck!
2 comments

We had the ODM. Had to rewrite critical pieces of it to make it work at all. The timer service had races - we fixed it and offered the fixes back, but arrogant Microsoft wouldn't take them, they were smarter than us and didn't need our help. So we had to repatch every release as they shipped the same broken code again and again.

Had to rewrite the DHCP code, theirs was one run-on procedure written by some intern. Didn't handle half the cases, took forever to conclude if it ever did at all. We needed to roam across subnets on the order of 100's of ms. Theirs took seconds to maybe complete. Junk. They of course rejected that too.

Best if WinCE were buried and forgotten?

I think MS didnt really 'own' the code. There was another company (b squared?) that owned large portions of it. We had the same DHCP issue. Also fixed many bugs in the ATL code taking up precious flash space for our bespoke version as we were 2 vendors removed from getting to talk directly to MS.

> Best if WinCE were buried and forgotten?

I am going to say yes. If someone ever finds one of the ones I worked on, my advice is to set it on fire then once it is done smoldering bin the thing and just get something better.

From my experience (though it was with CE 7) I got the impression that core kernel code is decent, but the rest of stack is haphazard collection of barely working hacks. APIs look like their NT equivalents, but not really, often missing crucial functionality. Documentation is often wrong or outdated, especially in BSP area, where it frequently mixes up how OAL interacts with the kernel with details of the optional PQOAL library. Same thing with driver documentation, where it confuses driver interface with describing MDD libraries. Finer semantics of the interfaces are mostly guesswork. Multiple barely documented touch device stacked on top of each other, with various ways of loading the driver and sending events to GWES. And the build system... that thing is just hideous.
If I remember right, Bill set several teams to writing an os for devices. The one that finished first, shipped. The 'winners' weren't even OS programmers. Thus, the naïve implementations of so many critical OS functions (drivers, timers, interrupt handling, flash)
I hate that attitude. I found a bug, fixed it, offered back to the company and they said "Don't worry, we'll find it ourselves eventually." Er, OK?
Wow, I had no idea it was that iffy under the hood. I might do more messing with the flash if it gets goofier. Yes, the issues with VC++ got annoying in a hurry.
Had one bug where we had a stray tab between methods. Would cause it to crash out the compiler. Putting us squarely in the no tabs camp.