The Oswald Project

Now we are experiencing technical difficulties. (Please stand by)

2005-12-05T22:20:00.000-06:00

Unfortunately, the image hosting service I used had a policy unbeknownst to me whereby any accounts not logged into for 30 days would be deleted. Pretty stringent, if you ask me, but I probably agreed to it in that 3x5 window somewhere.

I'm in the process of recovering lost files and images, but I may have to recreate most of them. It feels ironic, happening to someone who so frequently stresses to others the importance of multiple backups.

"Jesus saves. You should, too," my old college computer science professor used to say. I heartily agree, but every so often I am reminded of the statement's truth in a painful way.

As the old saying goes, the weight of the lesson is akin to the pain of the mistake.

We are experiencing non-technical difficulties. Please stand by...

2005-07-27T10:50:00.000-05:00

For those wondering where my posts have gone, please be patient. Back in the real-life timescale (July), my wife and I had a healthy son, my mother-in-law unexpectedly passed away and my sister was lavishly married. I've been rather busy and I'll continue as time allows.

Lines with Endcaps in Windows CE (3 of 3)

2005-06-27T22:20:00.000-05:00

(We now return to our regularly scheduled programming. I believe we were still in February discovering lines with endcaps...)

Previously: Hatched brushes worked great...every 8th pixel

After flailing about for a while I discovered polygons. That isn't to say I'd never heard of Archimedes and triangles before, I just hadn't thought about his work in terms of my problem.

And the problem was easy, too. In any line that had a fixed width, the shape of the line was merely a Polygon() with its end vertices shaped to look like semi-circles.

Above: a 5-pixel high polygon on your monitor under an electron microscope
To break it down even farther (at a pixel-level) a "rounded glue line" was just a Polyline() where the lines in the middle extended a pixel or two past the lines at the top and bottom, like a snaking connect-the-dots viewed from across the room.

Above: Refocusing our massive scanning electron microscope on a 5-pixel high polyline instead
Having two equally promising prospects meant putting both to the test. I set up a simple test of my idea, the meat of which is listed below:

#define POLYGON_POINTS 8
#define POLYLINE_POINTS 10
   
DrawGlueLine(...) {
CPoint polyPts[POLYLINE_POINTS];
...
   
if (m_polygon)
{
   nCount = POLYGON_POINTS;

   polyPts[0].x = rect.left+1;  polyPts[0].y = rect.top;
   polyPts[1].x = rect.right-1; polyPts[1].y = rect.top;
   polyPts[2].x = rect.right;   polyPts[2].y = rect.top+1;
   polyPts[3].x = rect.right;   polyPts[3].y = rect.top+3;
   polyPts[4].x = rect.right-1; polyPts[4].y = rect.top+4;
   polyPts[5].x = rect.left+1;  polyPts[5].y = rect.top+4;
   polyPts[6].x = rect.left;    polyPts[6].y = rect.top+3;
   polyPts[7].x = rect.left;    polyPts[7].y = rect.top+1;
   
   pDC->Polygon(polyPts, nCount);
}
else
{
   nCount = POLYLINE_POINTS;
   polyPts[0].x = rect.left+1;  polyPts[0].y = rect.top;
   polyPts[1].x = rect.right-1; polyPts[1].y = rect.top;
   polyPts[2].x = rect.right;   polyPts[2].y = rect.top+1;
   polyPts[3].x = rect.left;    polyPts[3].y = rect.top+1;
   polyPts[4].x = rect.left;    polyPts[4].y = rect.top+2;
   polyPts[5].x = rect.right;   polyPts[5].y = rect.top+2;
   polyPts[6].x = rect.right;   polyPts[6].y = rect.top+3;
   polyPts[7].x = rect.left;    polyPts[7].y = rect.top+3;
   polyPts[8].x = rect.left+1;  polyPts[8].y = rect.top+4;
   // Polyline draws up to the last x-pixel - 1, so
   // draw 1 pixel farther
   polyPts[9].x = rect.right;   polyPts[9].y = rect.top+4;
   
   pDC->Polyline(polyPts, nCount);
}
   
...
}

Under the emulator, both polylines and polygons drew equally well (and equally fast). But when I ran the demo on the physical device the polylines blew the polygons away. I suspect it was for two reasons: the polygon fill was slow, and the polyline optimized itself to draw five lines instead of the nine I plotted. (Four of the nine lines are just "steps" to the next level. They have an effective length of zero.)

Also, the lines were extremely fast. On the actual device I drew 480 polylines every redraw no slower than drawing as many normal lines. Flexible these lines were not. But flexibility wasn't one of the original requirements. I needed lines that would look like a line of glue and draw extremely fast. On both those counts this solution fit the bill.

Moral of the story: I knew that I would have to go outside my toolbox to solve the problem, but I didn't know that my screwdriver would make an excellent wrench, so to speak. It turned out that it wasn't noticeably slower to draw nine (or five) lines that appeared to look like a line with circle endcaps than to draw one plain line.

I also benefited from simplifying the problem. I didn't need to draw a line at an arbirtrary width with circles of an arbirtrary radius on each end. I just needed to draw a specific-sized line. And for my specific problem I found a specific solution.

PolyTest.zip (eVC 4.0 project compiled for 4.2 standard SDK)

Antonia

2005-06-26T23:05:00.000-05:00

When I started writing here I told myself that this would be a work-only blog. If I wanted to write anything personal, I thought, I would do it in another blog, and not under a pseudonym. In that regard, I've been about as successful as the Chicago Cubs at the World Series. But some things are as important in the history of this project as any technical detail, and this record would be less of one for not having included them.

So fast-forwarding for a moment to the present, today in real life marks the sixth anniversary of my marriage to Antonia, a beautiful woman that I don't deserve to have. Five other anniversaries have come and gone, and I wonder what compels me to write this on our sixth.

What compels me is that I love her.

When I was a child, I would ask my parents how they knew that they had found "the right one." I'm not sure why I wondered about those things, but I did. The unsatisfactory answer that I always received was that "they just knew." Unhappy with their response, I would usually ponder it for a few seconds, then go play with my Legos.

It wasn't until I met Antonia I understood what they meant. I didn't understand it right away, but when the time came that I was free of any logical or emotional reasons why I should choose to spend the rest of my life with her—and there were many—I came to the place where I just knew. She was pretty, she was a lady, she was smart and she was the cutest thing in the world. But apart from that, I knew that I needed to spend the rest of my life with this woman.

Of all the choices that I've made, very few have been choices that set my life's course. It's comforting to know that the important decisions have been accompanied by the calm confidence of knowing that it they were the right decisions.

Antonia, you are not only the best thing that has ever happened in my life, you are the best thing that will ever happen in my life. I sometimes think that if you hadn't come across me, you would've been just fine. But if I hadn't found you, I would still be lost—a ship without a course, or a rudder to steer by even if it had one.

I'm glad to have found you, glad to see where we're headed, glad that our anchors are weighed and our course is set. There's no one I'd rather sail this voyage with but you, and nowhere I'd rather go than where you are.

Forever your love,
D.

Lines with Endcaps in Windows CE (2 of 3)

2005-06-22T23:28:00.000-05:00

Previously: Circles are expensive

It occurred to me that we might try using CreatePatternBrush() to draw the semi-circles on each end of the line. Normally a pattern brush uses a (small) bitmap to repeat a pattern, but its original use was to create a hatched bit-pattern brush.

These are like tessellations, and are the same repeating patterns that you can play with in Display Properties, Background (none), Pattern. If you've ever worked with a bit-pattern brush before you know how difficult it is drawing on a flat canvas and trying to predict how it will look like, in effect, stretched over a globe. Fortunately, preview windows usually take the guesswork out of things.

With a few lines of test code I had a sample up and running:

c_test.UpdateWindow();
CDC* pDC = c_test.GetDC();

// Create a hatched bit pattern
WORD hatchBits[8] =
   { 0x87, 0x03, 0x03, 0x03,
     0x87, 0xff, 0xff, 0xff };

// Use the bit pattern to create a bitmap
CBitmap bmp;
bmp.CreateBitmap(8, 8, 1, 1, hatchBits);

// Create a pattern brush from the bitmap
CBrush brush;
brush.CreatePatternBrush(&bmp);

// Select the brush into a device context and draw
CBrush* pOldBrush =
   (CBrush *)pDC->SelectObject(&brush);

CRect rect;
c_test.GetClientRect(&rect);
pDC->FillRect(&rect, &brush);

// Restore the original brush
pDC->SelectObject(pOldBrush);

It worked great! All I needed to do was separate the brushes into a right half and a left half and draw my line ends. I started experimenting with some more brushed lines all over the screen.

Above: the hatched brush test with the endcaps conveniently located on 8-byte boundaries
Uh oh. When I moved the start point to a physical (x,y) location that wasn't a multiple of 8 the brush drew a deformed circle. Since the glue lines could occur at any point in a carton, only drawing them in predefined spots that were multiples of 8 wasn't going to work.

I had a few more ideas, including dynamically modifying the brush depending on where it was going to be drawn. But it was too complicated a solution for this kind of problem. I tried a few more things until I was pretty convinced that I was at a dead end.

Note: At the time I didn't know there was a SetBrushOrgEx() (WinCE), which can be used to keep a pattern aligned. My ignorance serendipitously led to finding a better solution.

Next time: An unexpected solution

Keeping the Home Fires Burning

2005-06-22T22:45:00.000-05:00

I'd be remiss not to mention the support system that kept me going till this point in the Oswald Project. Some might say that I'm doing too much "mentioning" of things non-technical, but I'll return to the esoteric details of CE development soon enough. There will always be more software projects; these are the things that are important.

When I was unmarried and my only bills worth mentioning were car insurance and gas, I was happy to work long hours for the sake of working. The reward of a good job to me was to have done it well. Sometimes I even pulled all-nighters at work for no apparent reason other than that the work was there to do, and I liked to do it. (Dick Buckzan, a machinist who starts his day at an ungodly hour, still laughs at me about coming in one morning and finding me slumped over my keyboard at my desk.)

A decade later my “lifescape” has widened from a narrow slice of the spectrum to a panorama of responsibilities. I'm blessed and fortunate to have wooed a wonderful wife, found a nice home and fathered a beautiful son (his brother is on the way). But these blessings are also responsibilities, and in the workplace that translates into less hours in order to lead a more balanced life.

With the Oswald Project, that changed. I was thrust into a schedule that would've been unsustainable by myself.

My savior was Antonia. Despite working part-time as an accountant in tax season, she made the time to bring me lunches and dinners. She kept the household running and did the job of two parents. I don't know how she found the time to do it all.

She became a den mother to my team, well known around the office for arriving bundled with dinner, drinks and a child in tow. George and Ted enjoyed her company, and her presence always lowered our stress level a notch or two. Later, when we discovered the joy of working on our laptops in my living room with a crackling fire and wireless internet access¹, she made sure that the area was always clean and work-ready.

It's rare to see the man who receives a lifetime award who doesn't think his wife, family and those around him who made his accomplishments possible. Without support systems like those it's infinitely harder to accomplish much at all. I'm not winning any awards or recognition, but even in my small corner of the world, my small achievements are due in no small part to those that I rely on.

Thanks, Antonia. There's no one I'd rather rely on than you.

[1] The CE emulator using the TCP/IP transport requires an IP address to communicate with eVC/Platform Manager. This means either being online or installing a loopback adapter.

To De-Feature or Not

2005-06-09T23:40:00.000-05:00

Worked continued at a frenetic pace through February, although it became more apparent at the end of each day there were less days remaining than the amount of work. Still, we pushed forward with our double-shift days.

I found some solace, oddly, in winning trinkets on eBay auctions. At least it took my mind off of other things for a few minutes. The actual thrill was probably more in bidding at the last second than in buying anything. I sniped in with two seconds left and won a weather station (thermometer, barometer, hydrometer). It arrived with the dials permanenty set to 74° F, 30.5 inches and 30% humidity. But it looked nice so I hung it on the wall anyway. My auctioneering activities won me a reminder from Antonia that such pursuits had a very low wife acceptance factor.

Around mid-month even the most optimistic of the project backers could see the writing on the wall, so a meeting was called to de-feature the program for a workable, but not as comprehensive, demo. Victor asked the most senior engineer, a 20-year employee, to sit in on the meeting and help make the difficult decisions.

I made up a list of about 65 major features that we were working on and asked everyone which ones we should pull out for the demo. We went over nearly every one, and each time someone voiced a reason why that particular feature should stay in.

Example:
Me: Okay, how about Shuttle Test on the Microwave sensor screen
Someone 1: Oh, no. We need that if we're going to have Microwave.
Someone 2: If we pull that out we'd have to pull out Activate Shuttle as well.
Someone 1: Yeah, we can't do that.
Me: Okay, we'll leave it in. How about Tolerance on the Pattern screens?
Someone 3: Wait, we can't pull that out!
Et cetera.

About an hour and a half later, we ended the meeting. We had pulled out exactly two and a half features.

Still, timelines and features aside, I thought the project was looking up. Some major pieces were starting to fit together and we were making very good progress. We still weren't going to be anywhere close to our deadline, but we were making progress.

Lines with Endcaps in Windows CE (1 of 3)

2005-06-09T22:49:00.000-05:00

I believe that two things are important in any craft: having good tools, and knowing how to use your tools. Having good tools means that you won't spend needless amounts of time doing things the hard way. And knowing your tools means that you know which tool is the right tool for which job. It also means that when none of the tools in your toolbox is the right one, it's time to improvise.

Microsoft Windows CE .NET: Windows CE does not support user-specified endcap styles, such as PS_ENDCAP_ROUND.
Messages like this are a pretty good indicator that it's time to go outside of the toolbox. (For some reason it's also a great motivator for me; nothing gets my creative juices going like someone telling me they don't think I can do it.)

So I set about coming up with alternative. We were looking for a way to show glue lines. They needed to look like glue lines, and they needed to draw very quickly. In a worst-case scenario, we were drawing 24 patterns x 20 events per pattern = 480 lines, several times per second.

We could've showed a glue pattern with a simple thick line , but a line with an endcap looks much closer to what a bead of glue actually looks like. It shouldn't be very hard, I thought. A round endcap is simply a half-circle at the end of each line. Even simpler, since CE doesn't support drawing arcs, a round endcap was simply a full-circle at the end of each line.

I wrote up a DrawGlueLine() function for our main dialog class to include two circles at the each end of a filled rectangle as the dimensions for a line.

Unfortunately, drawing circles is computationally expensive, and the performance was nowhere close to being fast enough. I considered other algorithms. The Abrash/Hardenbergh integer-only circle algorithm draws circles much more quickly, but implementing an x86 assembly (which I'm not very good at) routine just to draw endcaps seemed like overkill.

So, it was back to the drawing board. At least we knew what didn't work. As Thomas Edison told a reporter in 1879, "I have not failed 5,000 times. I have successfully discovered 5,000 ways that do not work and I do not need to try them again."

We had found way #1 that did not work.

Next time: Simplyfing the problem and trying again

Meetings on Meetings

2005-06-06T00:40:00.000-05:00

The next day Victor held an early meeting about the project. He wanted to know what our day's plans were and if we had any obstacles. Then we talked about other parts of the program. And then we talked about future features, and things that we might do sometime in the future. Two hours later we were ready to get started on the day.

The next day we had another meeting, and the day after that. Over the course of the next few weeks we spent 100 or so man-hours having meetings about how the project more productive.

I'm not a big fan of meetings for the sake of having a meeting. I realize that on any large project, meetings tie the principal participants together and keep everyone appraised of its status. And having many great minds in the same room brainstorming is a thing of wonder. But I prefer a meeting with a set topic and duration. Unfortunately, my preferences weren't the driving force behind our meetings. I haven't worked at a company yet where someone told the president that his meeting was wasting time and he was talking about irrelevant things. So we kept having meetings.

One day, Rutherford called me into his office. He had a strange habit: he would walk through the engineering department without saying anything. A few moments later, Stasi style, one of us would get a call from his office asking to stop by.

His sentences were steeped in bureaucratic style and usually began with steepled fingers, pursed lips, and an opening of "as you know..." or "moving forward..."

"As you know, we've all been working very hard on this project," he started, predictably. "We've also made an international commitment to a major vendor that this project is very, um, important to."

He paused awkwardly. I said nothing, wondering where he was going. And since the awkward pause was his own, I left him on the hook. He looked around, then continued, "Moving forward, if you can, uh, get this project finished by our deadline, we'd like to pay for you and, um, Antonia to have a nice meal downtown, and maybe spend the night."

He smiled, as if he had just offered to double my salary. I tried to decide whether I should be amused, offended or even grateful. I think I ended up offused.

"Well, thanks," I said lamely. Then my jaw steeled, "We're working very hard on this project and we'll do the best we can." I stood up and walked back to my desk.

Later, I calld Antonia with the "great" news. She was mad. "For working 70 hour weeks they're offering you dinner and a hotel room? How about a $10,000 bonus!" I couldn't have agreed more.

The Ides of February

2005-05-26T22:41:00.000-05:00

The first week of February turned out to be a really bad week.

I was working on several parts of the project where we had seriously underestimated the amount of time they would take. Added to that, Ted was taking too long on his tasks and needed more supervision than I had time to give. And the end-of-February deadline, now just four short weeks away, loomed larger than ever in my mind. All these factors compounded to exacerbate my worries, but I was relieved by the thought of my upcoming three-day weekend, a yearly family ski trip to visit my aunt and uncle in Vermont over Superbowl weekend.

A group of a customer's operators were traveling to Relay Corp. for a week of training so I arranged to have Ted sit in on the training for two days. It was expensive for us to pay for his time while he didn't work on the project, but it was worth it to get him up to speed on our business. At least it got him to stop calling our technology "widgets."

Late in the week Rutherford let us know that we had a meeting with Victor Relay, the President, about the timeline. (It was typical for him to let us in on meeting dates with about 15 minutes to prepare. I've always suspected it was to give himself a preparedness advantage.) I was enthused that we would finally be able to talk about our timeline concerns and project struggles. Our Engineering Dept. felt warm, so I grabbed a drink of water. I wasn't sure if it was pre-meeting jitters or our cantankerous HVAC acting up again.

Victor started the meeting with a very open-ended question.

   "Well, how's the Oswald Project coming?" he asked, looking at me.
   I explained frankly: "Not so good. We're running into some hurdles and it might mean that we'll miss our deadline."

There. I'd said it. It felt good to get it in the open and off of my chest. But surprisingly, Victor didn't follow it up. He seemed more interested in talking about the nuances of the UI than about Our Big Problem. He honed in on a particular part of the project that I had been working on, a representation of a folder-gluer with a symbol underneath it for every trigger position. I explained that in order to finish the UI in the time allotted I had changed the spec from showing each trigger directly under its position on the folder-gluer. The new method spaced out all triggers in a common area and drew a line from the trigger to its position on the gluer when it was selected.

(In the design phase I had shown a mock-up screen with 4 nicely spaced triggers, but the actual software was supposed to be able to support up to 24 triggers. Not that most installations shipped that way, but they could. There was no way to space 24 triggers directly beneath the folder-gluer. Faced with an impossible specification, I changed it.)

   I tried to carry the conversation forward, but he tenaciously held onto this single UI point. "That won't work!" he cried. "How will operators know which trigger they're looking at?"
   He had a point, but so did I. "They didn't know what trigger they were looking at in the mock-up, either," I countered. "This isn't any different."

But he wouldn't let it go. I could feel myself getting more frustrated. I stood up, grabbed a hanging whiteboard and put it sideways on the boardroom table. I drew the screen and drew out my problem. Aha! I'd clearly illustrated why I was right and he was wrong, I thought.

Rutherford quietly snuck out a side door, leaving his notes on the table as if he would come back. It was the second time he'd made such an exit at an Oswald meeting. He didn't return.

This meeting was quickly getting out of hand. Victor changed tack. "I have an idea. How about when the operator touches a trigger we draw the trigger number and the stations that it's assigned to over here," he proposed, gesturing towards an open area in my drawing.

I stared at him blankly. We didn't have a way of finding out what stations a trigger was assigned to, and what he was suggesting was about a week's worth of work. "I don't think we have the time to try to put that in," I said weakly, wishing we could go back to talking about the timeline. My arm-turned-easel was getting tired and my voice felt parched.

   He didn't let up. "It's not too hard. We could just draw it here and here," he pointed again to the whiteboard.
   "Victor, we can put it in, but then we won't have time to work on other things. Besides, it wasn't in the spec."
   "But I don't see what's so hard about it. Besides, you already changed the spec!" He was incessant.

That was it. How could he not see how trivial this was? "I changed the spec to make it easier, not harder! Look, Victor! This isn't important to the project. It wasn't in the spec and it will take time to add it. That's time we don't have. The entire project is in danger of missing our timeline!" Other people in the room became noticeably nervous, but I didn't care. George, who was sitting next to me, tugged at my sleeve to try to get me to sit down. "We're already working insane hours on this project without adding features to it. This isn't the way the project was supposed to go. This isn't what I signed up for!"

There was a long, uncomfortable silence. I was aware of how hot my head felt. "Look," I said, softening, "In a perfect world it would be a nice feature to have. But I don't see how we can put it in and do everything else and still meet our deadline."

Victor nodded, and changed the subject. We talked for a little while longer, and all agreed to meet with him the next day. It was late.

- - -
We got back to work--our 2nd shift--but later that evening Victor called and asked to see me. I walked into his office, a large, well-furnished room the size of Antonia's and my first apartment. I thought I knew what he was going to say but he surprised me. Instead of discussing the obvious, he talked to me about leadership. He pointed out that I had disillusioned my team and offered suggestions for building strong teams. Usually, I would have soaked up that kind of advice. But after our clash I was in no mood to learn. I told him that I thought the project had a 1 in 3 chance of success, and we would do our best. I left his office not knowing where the project was headed, and I wondered if he did, too.

Regardless, at least I had my weekend to look forward to.

The next day, after a fitful night's rest, I felt a little strange. I went into work but my head was in a vice and my bones were being stretched on the rack. Instead of Antonia picking me up at work on the way to the airport as planned, I drove home early take a nap and sleep it off. When I woke up, my fever registered 103°. We needed to leave immediately to catch the flight, but I could barely get out of bed, much less drive to the airport. I was loath to cancel the trip, but we had no other option.

Instead of swooshing down the snowy slopes I spent the weekend bottled up in bed.

On Sunday, I unpacked my unused suitcase. It was the symbol of an unrealized vacation, and combined with the knowledge that there would be no more vacations for a long time to come, it felt terrible. That was one of the worst weekends of my life.

This is the Part Where I Introduce Victor Relay

2005-05-25T22:23:00.000-05:00

If there is a single reason why I still work at Relay Corp., it's Victor Relay. Victor offered me my first job, a summer internship, while I was still in college in the mid 90's. I accepted. I didn't have a job description, but I was handy with computers and Relay was starting to move into the digital age, so I made myself useful and carved out a niche. When I met Antonia that same summer and got a full-time offer that fall, I stayed.

Victor taught me about business, about dealing with people and about life. He wasn't just a boss, he was a mentor. As Relay Corp. grew (I'm employee #7) to over 50 employees, including a London branch, Victor had less time to spend with me, but the time that he did was just as important. When my salary came up for review last year I negotiated directly with Victor. My direct boss at the time, Rutherford, was present only as a token to his position.

Victor was a great motivator and leader. As great bosses do, he made work more than just work. Work became a place to better my skills and myself. Since I loved the work anyway, I thrived. I designed and developed an ERP system that ran the company. When I decided to finish my Computer Science degree, Relay Corp. offered to pay my tuition. (I didn't accept, but that was for other reasons.) When Victor stopped by, it was to check on how I was doing, or if I needed better tools. (I always needed better tools.) If I had just returned from a vacation, he was genuinely interested in how my trip had been.

I'm not alone in my adulation. Many people at Relay would say the same thing. So would people at Victor's church and in his personal life. Victor's unique quality is that he makes people feel important. No matter what he's doing, he always has time to talk. And when he talks, he looks you in the eye, smiles and makes you feel like the most important person in the building. Former President Bill Clinton was reported to have such a quality. I've met only two or three other people like that in my lifetime.

With his good looks, pleasant charm and mellifluous voice Victor could've made a run at anything and been successful. But he chose to grow Relay Corp. and grow the people that worked there.

Perhaps one day I'll own my own business. If that happens, it will be to a large degree because of the influence that Victor has had on my life. I will focus on my people, believe in my company and make others believe in my company, and lead by example like Victor.

Here's to you, Victor. I hope I grow up to be like you one day.

A Disheartening Discovery

2005-05-10T23:52:00.000-05:00

January was a long, cold month. Like a Polar Bear Club member's inaugural dive, knowing in advance how much I was going to be working didn't prepare me for actually working that much. George worked three days per week, so Mondays and Tuesdays (nights included) were our days to really shine. As the nights wore on Ted worked alongside me out of loyalty, but he would eventually wear down and call it a night.

Getting George to work more hours was like pulling teeth, and since he was training for an upcoming marathon he liked to go out for a nightly run. I was envious that he was going out and taking care of his body while mine was slumped over a keyboard.

I persuaded Rutherford to let the company reimburse me for working dinners. This soon settled into a routine of Panera Monday, sandwich Tuesday and Chinese Monday. By Thursday and Friday we were so exhausted we just worked late and went straight home.

By midnights I was physically spent, but my mind wouldn't stop racing. To fall asleep I started reading Showstopper, the chronicle of Dave Cutler and the development of Windows NT from 1988 - 93. As a software developer on a death march reading about other developers on their death march, it was remarkably prescient--and sometimes depressing--reading material. Though I was falling asleep later and later, I found myself waking earlier and earlier, eager to get back to the project and implement a new idea.

But even though our project productivity soared, it seemed as though outside events were conspiring against us. Nitin, our new Systems Administrator, had been on the job about three months and was finally taking charge of all major systems. But two mission-critical systems crashed badly one week, and as the resident expert on the systems (I had written one of them) I was called on to resurrect them.

Also, the project's popularity was its own enemy. Everyone wanted to see a demo of the mock-up screens I had done in Visio. I wound up performing at least half a dozen demos of the software. One for the field servicemen's annual meeting, one for the salesmen, one for visitors from our UK division, etc. We even jury-rigged a complete demo controller running off of a laptop input for a trade show.

Every time I was called on to do the dog and pony for the project, that meant that I wasn't working on the project. It was frustrating, but not as frustrating as what I found out in our annual year-end meeting.

Every year at the end of January the entire company gets together for a year-end review. If we hit our sales target for the previous year, everyone receives a 3% bonus. Having already spent the money five times over in our minds, we all cheer, shake the president's hand, and go home happy. But this year--even though we had hit our target--I was more interested in the projected numbers for the upcoming year. On the charts, in big, bold fonts, were revenue numbers from the Oswald project starting in May. May!

I tried to ask a few shielded questions about the sales numbers, but my answers were deflected. John Dell (no relation), our ebullient and well-loved Sales & Marketing Director, was confident in his sales team's ability to sell our finished-by-May project. And then I realized that even though I had told my boss and our Engineering Director that the March demo with our OEM was in jeopardy and the May date wasn't going to be likely, either, no one else knew.

Double-Buffered Drawing

2005-05-04T23:46:00.000-05:00

Double-buffered drawing has been around for a long time. I won't try to improve on any on the tutorials and examples out there, which are probably better than anything I could do anyway.

This is just a post to show some example code for how to do this in Windows CE. The principles remain the same:

Create an off-screen buffer
Draw in the off-screen buffer
Copy the buffer to system (or graphics) memory

Source snippets:

// Create an off-screen buffer to draw in
CDC dcOffScreen;
CBitmap bmpOffScreen;
dcOffScreen.CreateCompatibleDC(pDC);
bmpOffScreen.CreateCompatibleBitmap(pDC,
   rect.Width(), rect.Height());
   
CBitmap* pOldBmp =
   dcOffScreen.SelectObject(&bmpOffScreen);
dcOffScreen.FillSolidRect(&rect,
   GetSysColor(COLOR_STATIC));
   
// Set the pointer to the up or down bitmap (if it exists)
if (state & ODS_SELECTED)
   pBmp = (m_bmpDn.m_hObject ? &m_bmpDn : &m_bmpUp);
else
   pBmp = &m_bmpUp;
   
// Draw whichever bitmap the pointer is set to
pBmp->GetBitmap(&bmpInfo);
TransparentImage(pDC->GetSafeHdc(), /* hdcDest */
   pRect->left, pRect->top,
   bmpInfo.bmWidth, bmpInfo.bmHeight, /* dest */
   (HBITMAP) bmp, /* hdcSrc */
   0, 0, bmpInfo.bmWidth, bmpInfo.bmHeight, /* src */
   CLR_TRANSPARENT);
   
// Blit the off-screen DC back over to the button DC
pDC->BitBlt(rect.left, rect.top, rect.Width(),
   rect.Height(), &dcOffScreen, 0, 0, SRCCOPY);

Pick-Me Buttons

2005-04-27T23:55:00.000-05:00

Now that we knew how to draw transparently...

What you see above is a group of pick-me buttons, which I so named because they seemed to jump up at me and say, "Pick me! Pick me!" Right now they're entirely pre-drawn, but eventually we'll be able to draw everything except the button image using RoundRect(), GradientFill(), and Ellipse().

One of my true passions has always been computer interfaces. How do we interact (link: see Usage Note) with these powerful machines that force us to work by their rules? But I'll spare you the soap box (in this post). What this meant for this project was that the entire user interface was my canvas, and I was an eager painter.

Pick-me buttons aren't really 2D or 3D controls. They live somewhere in the 2½D world. Their shadow gives them a sense of height and a different platform than the background they rest on. The illusion is compounded by the way that they jump up when selected, and their shadow correspondingly shrinks.

These buttons really only work in a horizontal arrangement, which makes them good if you have a landscape display. They use more space than their Win32 counterparts, toggle button and radio button groups. But in my opinion they're well worth the real estate. Also, for our application the only input was by a touch interface. Touching one of these buttons and seeing it spring to life gives immediate visual feedback and tactile gratification.

They worked even better when we set up our button class to reduce flicker by buffering its draws off-screen.

Drawing Transparent Controls

2005-04-27T22:43:00.000-05:00

A quick search of the Windows CE newsgroups shows no small number of questions about transparency in controls. With its pared-down API, CE doesn't make it quite as easy as regular Win32 to draw transparently. Still, it can be done, and (as we found) it's not too difficult, either.

The biggest and foremost obstacle is, as the help puts it, that "all windows implicitly have the WS_CLIPSIBLINGS and WS_CLIPCHILDREN styles [set]." (In "regular" windows, a WM_PAINT message would cause a window to repaint its entire background. CE, an OS that usually runs on low-horsepower devices, tries to save some time by only drawing the region not covered by other windows. When a parent window is finished painting it selfishly tells all child windows to go paint themselves.) This works fine if you want to paint normal-looking buttons

but as soon as you want to get fancy (move your mouse over the button to see the fancyness)

it makes life a little harder.

In our case we wanted buttons with round corners. Also, they needed to depress and visibly lose their shadow (see above), which meant that if we merely painted the button image over itself we would still see the border from the last button image.

Also, many static images in our application needed a transparent background. (The alternative was to use icons, which don't scale well past 16x16 increments, or to "hard-code" the background into each image, which was a terrible option for obvious reasons.)

Enter our saviour, TransparentImage(), the CE equivalent of Win32's TransparentBlt() (or just blitting with a monochrome bit-mask).

Note: You might be tempted to just use SetBkMode(TRANSPARENT) in OnCtlColor. But the problem with doing that is that the control becomes too transparent and won't even repaint in response to a WM_ERASEBKGND message. On the other hand, passing back a brush created with the current background color would work just fine in OnCtlColor. You just have to make sure that you keep the brush valid (for example, make it a class member) or use a stock brush.

A note on my nomenclature: I use c_ as a prefix for control variables (to differentiate from m_ for data variables), a habit I picked up from the Flounder.

For drawing transparent static controls, this worked great in the parent window's OnPaint handler:

// Draw the "background" images transparently
// NOTE: Validate the control so it doesn't try to re-
// paint itself with its default bmp.  Other options:
//    1. c_sensor.SetRedraw(false);
//    2. c_sensor.SetBitmap(bmp);
//    3. Subclass CStatic and paint our own control
c_sensor.ValidateRect(NULL);
 
pDC = c_sensor.GetDC();
pOldFont = pDC->SelectObject(&m_fontSmall);
c_sensor.GetClientRect(&rect1);
DrawBitmap(pDC, &rect1, IDB_SENSOR);
 
// Draw the centered text overlay on the bitmap
overlay.Format(_T("%d"), m_sensorNum);
pDC->SetBkMode(TRANSPARENT);
pDC->DrawText(overlay, &rect1, DT_CENTER);
 
pDC->SelectObject(pOldFont);
c_sensor.ReleaseDC(pDC);

DrawBitmap calls a parent-class function that calls TransparentImage(), like so:

TransparentImage(pDC->GetSafeHdc(), /* hdcDest */
   pRect->left, pRect->top,
   bmpInfo.bmWidth, bmpInfo.bmHeight, /* dest */
   (HBITMAP) bmp, /* hdcSrc */
   0, 0, bmpInfo.bmWidth, bmpInfo.bmHeight, /* src */
   CLR_TRANSPARENT);

where CLR_TRANSPARENT is a pre-defined color set to hot pink, RGB(255, 0, 255). (I figured we wouldn't have much use for that color, and even if we did, I'd rather not see it!) For even more flexibility, you could also looked for a pre-determined pixel--say (0, 0)--and use its color as the images transparent color.

The most robust way to do this would be to use option #3 from above and subclass our own static controls. That way, we could control our background repainting in OnEraseBkgnd and our normal painting in DrawItem. But the statics were easy enough to handle in their parents' OnPaint method. We did subclass the buttons and used an off-screen buffer to do all our drawing before blitting them back over to the screen. But that's a post for another day.

Final note: You might look at our solution and say, "Hey, that's not really transparent. You're just faking it by drawing the same background color!" and you'd be right. This is good-enough transparency. It works well on a monochromatic background. True transparency involves using GetPixel() to see what's "underneath" and duplicating it, or at least part of it, in the draw. Yeah, that's also another post for another day.

Using a Custom SDK and Emulator with EVC

2005-04-25T00:21:00.000-05:00

If you're not debugging on a physical device, you need a good emulator for testing code. In our case, our hardware spec still wasn't finished and a prototype wasn't close to being complete. But we did know that our 15" flat-panel display would run at 1024x768, which meant that the emulator default of 800x600 cut off a significant portion of our screen.

So we needed a custom emulator to run at that resolution. (We also needed it to handle the custom IOCTLs that we were sending, but that wouldn't come till later.) This shouldn't have been very hard to do, but as with all things just starting out, we didn't even know where to start troubleshooting because we didn't have a "known good" reference point.

Note: In my case, I had installed Platform Builder 4.2, then installed PB 5.0. When our SBC vendor told us that they only had a BSP for 4.2 I uninstalled version 5. This led to several wasted days of troubleshooting why coreroller.dll wasn't correctly registered, even after reinstalling v4.2. Moral of the story: don't try running 4.2 and 5.0 on the same system, as this search will attest to.

1. Make sure that you have a good platform and the Emulator Debug configuration is working.

Note: Make sure that in Platform Settings, for the emulator configuration, the Enable KITL option is unchecked! If you build a platform and export an SDK with this option turned on, eVC will not connect to the emulator unless Platform Builder is running and it can connect via KITL.

If you need to, rebuild the platform for that configuration.

2. Select Platform, Configure SDK... The SDK Roller will start in "Export SDK Wizard" mode. Run through the wizard and select the options for your platform. In our case we're using MFC for applications.

3. At the end of the wizard click Finish, but don't build the SDK yet. Select Platform, Configure SDK again, which now starts up the SDK Configuration Settings dialog. You may want to change some settings. For example, make sure that TCP/IP is the default transport. We wanted to mirror our device as closely as possible, so in the emulation tab we set the following:

Fixed screen resolution: width: 1024, height: 768, color: 16 (bits)
Memory: 64 (MB)

Note: If you plan on buildling multiple SDKs--we're on version 9 right now--you'll want to make sure to put the version number in the that the Platform name, and maybe even in the MSI file name setting. Otherwise, when you use Windows' uninstall applet, all of your SDKs in the uninstall list will have the exact same name.

4. When you've configured your settings, select Platform, Build SDK and watch it build (or work on something else if you're the industrious type). It should take a few minutes to build the MSI file and add the customized help, ending with this message:

MSI file construction completed. 0 error(s), 0 warning(s).

5. If you've been using eVC you should exit it now. The Platform Manager behaves strangely if you install an SDK while it's still running. Closing eVC usually terminates the Platform Manager as well, but after several bad experiences I always check-and-terminate cemgr.exe if it's still running. For good measure, I also exit Platform Builder.

6. Install the MSI file you created. It should take a few minutes, depending on which options you installed. When you restart eVC you'll see a new option in the Select Active WCE Configuration combo box of the WCE Platform toolbar (or select the Build, Set Active Platform menu). Rebuild your project under that platform and launch the emulator.

Note: If eVC fails to connect to the emulator you might need to reboot and restart eVC. Some people recommend always rebooting after installing an SDK, although I can usually get away without having to do that. If it still fails to connect, make sure that the KITL transport option is unchecked for your platform.

Another Note:The Platform Builder Help also has a step-by-step topic entitled Exporting an SDK.

Once we had our custom emulator up and running we never looked back. (For one thing, screen design was so much easier when we could see the entire screen!) Using the emulator made our development time so much faster. Even after we got our prototype, if we wanted to test the app, we would have to pull out the CF card from the hardware, copy the new executable to the card, put the card back into the prototype, reboot it, and run the app. Using the emulator meant that we could compile, download and run in a matter of seconds.

Last note: Compared with hardware, the emulator is of course slow, especially when debugging, but for quick testing it's more than adequate. Some of these eVC tips show how to get the most out of your emulator cycles.

Thoughts Concerning the Instruction of Computing Machines (or, Methods to Programme Electronick Devices)

2005-04-10T23:04:00.000-05:00

Dear Reader,

A curious piece of information has come to my attention that I thought most worthwhile to share with you. It appears that an astute portion of my readership has been following this tale with some interest, yet the details of my work are befuddling and torpor-inducing.

Therefore I thought it advantageous to share the proceƒs of my work, which I hope will enlighten the fellowship of readers. To my esteemed colleagues I ask leniancy while my path follows this slight detour, and now let us turn to the subject at hand.

Using an electronick computing machine I am able to manipulate a software programme, being a set of instructions for the computing machine, or computre, that charge its core with strict obedience, so that anon the same results are repeated.

The programme, which is so named Platfourme Builder, produces the desired result of specifying which components of a large system I should build. Certain components allow me certain functions--exempli gratia, a component known as Clear Type reveals the most wondrous movable type before my eyes.

Once my components are selected, I must only build this system, and using such built system I am able to package a reference of my system which would rival our dear Britannica. This reference is known as exporting the SDK, whose acronym is unknown to me but likely represents Scientific Device Kit.

Such SDK is then used in my IDE, known as eVC, for the purposes of writing specific instructions for my system. I apologise for the liberal use of acronyms when English words would suffice, but I find no other way of expreƒsing my language to you. What I call an IDE you may know as an integrated development environment, or a system for developing systems. Specifically, my environs is called by the name eVC, a system written in the third great instruction language (known as C) for embedded electronick devices.

When the instructions are properly built and ready--with nearly 20,000 operations at the present time and more being added daily it is a terrifyingly complex proceƒs--the system is run in a world which emulates ours. This other world, a sphere within a sphere, so to speak, is termed an emulatour, which purpose is to test our system before the instructions are run on an actual device.

Knowing that the instructions will work properly in the emulatour, I then place a copy of the instructions on the physikal device and attempt to monitor the electronick wizardry as it deciphers my commands.

From start to finish this is a most complicated proceƒs and at times days are spent sorting out the minutest nuance of our system. You may wonder if this is frustrating, and that is decidedly so, but it is also wondrous and fascinating, and the vexation of every impediment I encountre is but naught when compared to the delight of discovering its solution.

It is my desire that this discourse has been of some benefit to you.

I remain your most humble servant,
D. Philippe

High-Speed Timers with Windows CE

2005-04-09T10:32:00.000-05:00

A paradox that has always fascinated me about computers is the way that they do so much while being so stupid. At their heart computers have only a primitive bit of intelligence:
is it a 1?
is it a 0?
That's it. However, the redeeming quality of this neolithic process is the computer's ability to make more of these determinations in one second than you or I can make in our lifetimes. I've heard it called the dopeler effect: the tendency of dumb things to appear smarter when happen rapidly.

Primitive paradoxes aside, what this means in the real world is that computers work so well because they can do things amazingly faster than we can do them. Windows CE, for example, provides a timer that lets you track up to 1,000 things per second. For nearly all of the day-to-day programming tasks this is fast enough. But if you're working with high-speed machinery or programming servos on a robotic arm or, like us, watching cartons fly by at about 40 ft/sec (12 m/s) it's nowhere near fast enough.

For our purposes, we needed a timer that would fire 20,000 times per second, or about 50 µs. So, we stole the timer that Windows CE uses for the kernel profiler. It means that we lost any kernel profiling abillity but I don't know that we would've used it anyway.

Disclaimer: This is how we did it. This doesn't mean that it's the "best practices" way of doing it. (But boy, does it work!)

Setting up a high-speed timer isn't very hard. There are just three things to do. First, we need to modify timer.c. (Do make a backup.) For an X86 platform, we find this in %_WINCEROOT%\PUBLIC\COMMON\OAK\CSP\I486\OAL\timer.c. We'll make as few changes as possible.

// Our own interrupt task
extern void PolledInterruptTask(void);

...and later on...

int ProfileInterrupt(void) 
{ 
   PolledInterruptTask(); 

   dwReschedCount++;
    
   if (dwReschedCount < dwProfilingMultiple)
      return SYSINTR_NOP;

   dwReschedCount = 0;
   return SYSINTR_RESCHED;
}

Now we have a have an interrupt that will fire our custom task, whatever it is. We still need a way to start the profiler, which we can do using a custom IOCTL.

In oemctl.c we need to add the following case to OEMIoControl():

   switch (dwIoControlCode) { 
   case IOCTL_START_CUSTOM_TIMER: 
#ifndef DEBUG 
      // Start up the profiler timer 
      OEMProfileTimerEnable(50); 
#endif 

      retval = TRUE; 
      break;

With the OAL parts working, we should build the platform. At this point we can also export a custom SDK to use with eVC (more on that in a later post).

Our last step is to call the new IOCTL as our application starts up. In our initialization code we might have something like this:

   if (!KernelIoControl(IOCTL_START_CUSTOM_TIMER,
      NULL, 0, NULL, 0, NULL)) {
      LOG(__FILE__, __LINE__,1,
         "High-speed timer startup failed!");
   }

It took us a little while to get everything working right, but once we did we tested it on a prototype and could verify that everything was working correctly. But was it running at 50 µs? It would be a little while before we could test it and find out.

Note 1: The MSDN lists a more in-depth way of implementing timers in CE in this article: Implementing Rock-Solid Windows CE Timers On Windows CE .NET 4.1 Platforms

Note 2: Modifying timer.c is also known as cloning the public code, which this MSDN article talks more about: Cloning the Microsoft Public Code

Ted's Excellent Adventure (2 of 2)

2005-03-27T23:17:00.000-06:00

Just because someone shows up in jeans and sneakers doesn't mean that they're not a great programmer, and I was willing to give Ted the benefit of the doubt. Usually I'm not usually one to judge someone based on their look or clothes. Well, on second thought, I take that back. I usually do form an opinion, then remind myself that I shouldn't judge a book by its cover.

Ted's book was tall and in its forties. He had blond, wavy hair and an easygoing smile. His voice was pleasant and accentless, and though his thick frame wasn't as brawny as it had once been I could tell by looking at him that he hadn't stared at computer monitors his whole life. And he definitely liked the "casual" part of business casual.

After the cursory tour of the company--oh look, here are more offices, and just wait till you see our bathrooms!--I gave him the executive overview of what we did and what the project was about. We set up a work area and held a small meeting about the project.

In a previous CE project that was similar to ours, Ted said, the team he worked on used a 3-tier architecture approach. He recommended it for our project as well. We agreed. After all, the application needed some architecture. Right now it was just a collection of loosely related dialogs and a lot of code written in here's-my-first-crack-at-it-MFC (by me).

Meanwhile, I was working on some nagging CE issues. We still didn't have a way to share memory between the UI app and the real-time app. Our attempt at using memory-mapped files hadn't worked. (That turned out to be a blessing in disguise.) I had a devilishly hard time getting Platform Builder to configure and export a custom SDK, and when I finally did it wouldn't work. So I let Ted port the application into the 3-tier framework. I had some questions about it but I waited until he was finished.

While we worked we got to know more about Ted. He was a former Air Force Search and Rescue parajumper, but the pay rate didn't cut it so he switched to programming. (Some switch!) As an independent contractor he had worked on projects for Intel and Alpine. He did software projects for a living, but his meraki aspiration was in board game design. He had invented a multi-level tic-tac-toe game and was hoping that a big retailer would pick it up. He gave a few of us his game as a present.

The framework that Ted implemented was a sound one, but it had some bureaucratic parts that I didn't like. And while Ted had been on the team that implemented it, he wasn't the designer and wasn't privy to the details that I wanted to know about. It had been previously implemented on a "push" system, where the process control (or object) layer worked off a timer to constantly push data out to the (dumb) dialogs. Our design was different: the dialogs had to be intelligent and needed to request data from the control layer when they recognized the need for new data. Ted didn't like the idea.

Ted had a few idiosyncracies, as we all do. One was that he was fairly certain of his opinions without being able to say why. (On the other hand, I'm also rather opinionated but can usually make up a pretty good reason.) So it was frustrating to try to elicit a reason for why he was sometimes so firmly attached to a particular idea.

He also had a minor disease I started calling "weekenditis." On Monday mornings he would arrive in the depths of despair, bemoaning the sad state of our project and pledging to incorporate a time-consuming, application-wide fix that wasn't in the timeline. Usually the problem wasn't nearly as bad as he made it out to be. I learned to defer these fixes and steer him back to the more important tasks at hand.

He had helped us implement SourceSafe, which replaced our highly efficient but less-than-traceable verbal system. (Don't laugh: I know of at least one Fortune 500 company that still works on major projects by emailing unencrypted .zip files back and forth.) He used it to check out files and make tiny changes to irrelevant things, like code formatting. I would rather have had him spend his time on more important things.

But the small drawbacks were easily outweighed by how big of an asset he became to the project. He fit right into the team, and that's not an easy thing to do. He found a nearby place to stay (roomates.com) and quickly made friends with almost everyone in the company except Vince Pawlowicz, who didn't get along with anyone anyway. (It helped that he had a cool game to give out.) Our "personal Moses" he was not, but maybe our hopes had been unrealistic anyway. I refactored the timeline¹ and we moved on.

For better or for worse, Ted was now a permanent part of the team.

[1] Rutherford, Alec and I had a meeting about how best to use Ted in the light of us still needing a "CE expert." We made some adjustments to the timeline (i.e., shuffling our already-overworked resources around but not adjusting the deadline). Alec remarked that he didn't see how we could possibly finish the project on time, which apparently wasn't what Rutherford wanted to hear because he said nothing but smiled falsely and closed the meeting.

Ted's Excellent Adventure (1 of 2)

2005-03-23T23:26:00.000-06:00

Q: How comfortable would you be hiring a guy based on a 10-minute phone interview?
A: Not very

Nevertheless, that was the position that we found ourselves in after scouring the country for WinCE developers. I suppose it meant that either the CE developer market was very hot and no one was available to work on new projects, or that the market was very cold and no one was available to work on new projects.

To be fair, we were asking a lot. We needed an experienced, on-site developer who was free within 3 weeks and available for about 3 months. We were looking for our own personal Moses, come to free us from the shackles of our DOS world and lead us into the promised land of Windows CE. There were other people (and companies) available, but none that met those criteria.

After searching every way we knew how, including using a national developer contracting service, we ended up with exactly three prospects. One was Daron, the WinCE training instructor. He was a Microsoft MVP in whom I had every confidence. The other two were prospects from the independent contractor agency.

On the telephone, Sudeep Swarnapurishwara sounded every last bit like his name foretold. Although he lived in the area and was very experienced, he had a few strikes against him. His English was terrible (despite having lived in the U.S. for a dozen years), he sounded too confident about anything that we asked him (including topics where he misunderstood what we were asking him), and he was taking a month-long trip to India during the month the project was scheduled to end.

Our next call was more promising. Ted Nulder lived in California but was willing to relocate to Chicago for the duration of the project. He had experience with two previous CE projects and he interviewed very well. I think the call with him gave some people in the conference room that warm fuzzy feeling.

So between Daron and Ted it came down to a matter of price. Daron didn't come cheap: between $160 - 200/hr, depending on whether he worked off- or on-site. I tried to beat up his company on the price--I've learned a thing or two from our killer purchasing manager--but they weren't willing to budge. By comparison, Ted cost about half that. In our selection discussions I pointed out that productivity between different programmers varies by an order of magnitude, but at that price difference I could feel the hollowness of my own argument.

Our own engineers bill out at $200/hr, so for us to balk at that kind of price conjures up images of pots and kettles. But balk we did. Ted made arrangements to start on Jan. 4, the first working day of 2005. For $90/hr, we were the proud new owner of a CE expert. Our Moses was on his way to lead us through the desert of development into a future flowing with ~~milk and honey~~ products and profits.

Or so we thought.

I was interested to meet the kind of guy that would move to a different city and live there while working on a long-term project. (I'm married, with a 2-year-old son and another on the way, so it wasn't something that I would've done.) So Tuesday morning, when the receptionist rang and said that Ted had arrived, I walked to the foyer to greet him.

An old quote says that you never get a second chance to make a first impression, and I believe it. What kind of impression I made on him, I'll probably never know. But the impression that he made on me, I'll never forget.

Even to this day when I think about it, I can still feel the way my heart sank. I think it was the jeans and sneakers that said it best.

Writing Kernel-Level Code

2005-03-19T16:05:00.000-06:00

If you need access to kernel-level routines, Windows CE provides the OEM Adaptation Layer (OAL) to do just that via custom kernel IOCTLs. A custom IOCTL lets you write code with kernel-mode functionality and provides your application with a means to call it.

First, a quick timeout for some pretty graphics. The OAL looks something like this:
(Now why did they ever replace good ol' ascii art with those newfangled graphics?)

While we're in timeout I'll take a second to point out that IOCTL stands for I/O control (code) and can be pronounced eye-okk'-tull if you're feeling brave.

Okay, back to the tutorial. Creating a new IOCTL isn't very hard. All you need to do is define a custom code for kernel handling that can be called in an application with KernelIoControl. Here's how to do it.

1. Open oemioctl.c, which should be in
$(_WINCEROOT)\platform\cepc\kernel\hal\oemioctl.c.
The basic structure of the OemIoControl function is a large switch statement. Adding new functionality is as easy as defining a new case and handling it.
Note: You should be able to find a list of currently defined codes in ..\OAK\INC\pkfuncs.h.

2. Define a new control code. Valid control codes for OEMs are between 2048 - 4095. (MS reserves 0 - 2047 for itself.) Hopefully 2,000 custom codes are enough. (For comparison, we're using 17 codes right now.)

A control code might look like this (excuse the width problems):

#define IOCTL_ZOOM_TAXI
   CTL_CODE( FILE_DEVICE_HAL, 0x0800,
   METHOD_BUFFERED, FILE_ANY_ACCESS )

The third parameter, METHOD_BUFFERED, is ignored in CE. CTL_CODE expands to

#define CTL_CODE( DeviceType, Function, Method, Access )
   ( ((DeviceType) << 16) | ((Access) << 14)
   | ((Function) << 2) | (Method) )

3. Add a new case under the main switch statement in OemIoControl:

case IOCTL_ZOOM_TAXI:
   LoadYellowCabGfx();
   ZoomTaxi(LEFT_TO_RIGHT, TRUE);
 
   retval = TRUE;
   break;

Note: This is a good time to put defensive programming to work. Any problems here and you'll hang or crash the entire system. For starters, make sure that you check the actual size of the incoming buffer against the reported size.

(From the MSDN 2535 lab notes: Just for testing purposes, you might want to try incrementing a counter every time you pass your IOCTL and printing a RETAILMSG that displays the value of the counter. If you run into some problems and you're wondering if anything is actually happening this is a nice sanity check.)

4. Build your platform.

5a. If you're using Platform Builder, open your project and add the following where you need it:

#include <kfuncs.h>
 
KernelIoControl(IOCTL_ZOOM_TAXI, // I/O ctl code
   NULL,           // input buffer pointer
   0,              // input buffer size
   &dwTaxi,        // output buffer pointer
   sizeof(dwTaxi), // bytes that can be returned
                   // in output buffer
   &dwNumTaxis);   // size of data returned

Make sure that you #define IOCTL_ZOOM_TAXI in your project as well.

5b. If you're using eVC, you'll need to configure and export your custom SDK from PB first, then install it. The standard emulator won't know about your custom control codes. (I'll write more about custom SDKs later.) Then add the above code.

6. Make sure to add the WINCEOEM preprocessor symbol, which includes OEM headers (see kfuncs.h). On the Project menu, click Settings. On the C++ tab, select the Preprocessor category and add
,WINCEOEM
at the end of the Preprocessor definitions list.

In the Additional include directories field, add these two directories:
$(_PROJECTROOT)\cesysgen\oak\inc,$(_TARGETPLATROOT)\inc

As you can see, it's not very hard to do. For small things like hardware info and hardware access, it's a lot easier to do than writing a driver. But be careful how many times you call into the kernel. KernelIoControl is handled by generating an exception, which the kernel routs to the OAL and to your IOCTL. The cost of a kernel call in a real-time environment needs to be evaluated in your app.

By the way, if you're wondering what the heck we're doing with a taxi call in the kernel, uh, we're not. But someone else once did.

Below is the PDF of the MSDN lab:

MSDN 2535B_Lab5.pdf (con permiso)

Update:
Microsoft MVP Steve Maillet writes: In Windows CE, "kernel mode" simply means that a thread has access to the virtual address space 0x80000000 - 0xFFFFFFFF without triggering an access violation. That is only difference between user mode and kernel mode in Windows CE. Any thread can call SetKMode() to switch between the modes as long as the process it is running in is trusted (or the trust system is disabled).

The New Old Thing

2005-03-15T23:11:00.001-06:00

Apart from Microsoft Word and Excel, I can't think of any applications that made smooth transitions from their previous, powerhouse DOS selves into Windows. In fact, every application that I can think of apart from the above two was either more awkward to use or had less features than its DOS counterpart. This was due to at least a few things:

Writing Windows apps (at the time) was harder
The Windows event model was more restrictive than a comparable (i.e., complete control) DOS app
The companies who produced these apps didn't fire their entire development team and hire Win16-proficient programmers. There was a natural learning curve as the programmers started learning how to program for Windows.
The shell, which had previously been subservient to the all-powerful application, was now the master. The applications were learning to accept their new, lesser role.

The net effect was usually that Application X for Windows, v1, was a buggy, clumsy product. It was followed a few months later by a less-buggy, clumsy product. These apps were usually written pre-MFC 1.0. They didn't understand the MDI interface. They didn't use standard Windows controls. Their dialogs tried to control the application instead of vice versa. And the print system was usually ported by someone who could print in ANSI codes in his sleep but was a novice when it came to device contexts and the Windows driver model. I could go on.

But I digress. That was just an illustration of the choices that we faced (granted, 10 years later) in moving our embedded app to CE. We decided to go with a two-pronged approach. The real-time part would run alongside the kernel and the user interface part would run as a stand-alone application. We would use some kind of shared memory (we didn't know what yet) to communicate between them.

The smallest timer resolution in CE is 1ms, but we needed something much more accurate. We included the profiler and overloaded the profiler interrupt to poll a little faster, like oh about 20,000 times per second. (Just a few snips here and there in timer.c.) I know that it's not the Windows Way, and now we won't be able to use the profiler. But hey, this is still DOS2Win, v1. We're allowed a few of these.

The CE OAL makes it easy to write kernel-level code via kernel IO control codes. (Course 2535, Lab 5) Writing code for custom control codes (called IOCTLs) in oemioctl.c compiles the code into the kernel, where you can call it in the application via KernelIOControl later.

Figuring out how to run code faster than 1ms and how to run in kernel mode were two big steps to porting our trusty old code to CE. But we still needed to get the apps to talk to each other, figure out how to control the real-time app from the UI app, and test the whole thing on some hardware to see if it ran fast enough. All of these were milestones that loomed large on our ever-diminishing horizon.

Fits and Starts

2005-03-14T22:15:00.000-06:00

It was becoming quickly apparent, even to lummoxes such as myself, that the timeline was far too agressive. I put together a quick spreadsheet to show that even with another developer (which we didn't have) we wouldn't be able to finish the project in time. I held a meeting with Alec and Rutherford. Rutherford, in classic style, took my two pages of notes and reserved a conference room for the three of us to talk about them.

   "So what are you saying?" he asked, finally giving me free reign without asking a leading question.
   "I'm recommending that if the date is more important than the product, we should do this in Zinc, then back-port it to Windows CE. If the product is more important, then let's do it in CE and move the date."
   The mention of Zinc was like offering to kill his dog, but the proposition to move the deadline made him pale in comparison. He started shaking his head as I was talking, as if to let me know that no matter what I said he wouldn't approve.
   "So what you're saying," he attempted to summarize as he walked towards a whiteboard, "is that for a greater chance of success we could do it in Zinc-DOS. But if we added a programmer," he emphasized, using my project-won't-be-complete-even-with-additional-help spreadsheet in a way I hadn't intended, "we might be able to finish it on time."
   Trying to put it into terms we were all familiar with, he continued. "So if we do it in Zinc, then move it later, it's like getting a...double. But if we hire another programmer and do it in CE Microsoft it's like hitting a home run."

Oh no! The dreaded appearance of a climactic sports term in an Important Meeting! I've seen too many important decisions swayed people who casually threw out phrases like "home run," "slam dunk" and "touchdown." They're great. They get your blood pumping. Yeah! A slam dunk! Let's see the replay! Awesome! Let's go do this, uh, thing! Uh, what were we talking about?

   "Yeah," I allowed, cringing. "We might hit a home run."

Alec sided with Rutherford, and so it was decided--as much as it was ever really a decision--to go ahead with CE and hire a contract worker for additional development. We needed an expert to help show us the ropes. I recommended the instructor from the course I had just taken. He was available. I posted an ad in a CE newsgroup. We contacted Doug Boling, who was busy on another project. You would think these guys would be perfect--after all, they have the guy who wrote the definitive MFC book--but they couldn't get a quote together.

For my part, it was time to sit down and learn all about app development on CE with MFC. MFC isn't Microsoft's darling anymore. That prize goes to C# and the .Net Framework these days. (Don't be surprised if you see a billboard that reads "C# - The official programming language of Microsoft Corp." on that link, although I don't know of any major MS applications written in C#.) As far as I know, no one has written much about MFC on CE. Maybe it's a dying breed. More likely, it's just not cool anymore and it won't sell books.

Despite the lack of printed matter, the web proved to be an excellent resource. I saved some of the links that helped me along the way:

CE Architecture

MFC/Examples

CE Graphics

It was really slow going at first, but I learned in fits and starts. While I'm usually the kind of guy who thrives in a completely new, sink-or-swim environment, it's always tough learning under the gun. The microsoft.public.vc.mfc newsgroup is an excellent resource. I have a theory that if you want to learn something fast, get yourself to the point where you can answer (some) other people's questions. Then you'll know that you at least know something.

Then one week, after almost a month of futzing around with example code, reading books and tutorials, and tinkering with prototypes, it all clicked. I had just gotten back from vacation, it was shortly before Christmas, and I decided to implement what I knew. I figured I could always learn more, but I might as well start somewhere. That was a great week. I wasn't even working very much overtime. I was in the zone. (It must've been all those home runs and slam dunks.) I wrote over 2,500 lines of code that week. And the application started to come alive.

MSDN 2540

2005-03-13T17:20:00.000-06:00

Warning: boring reading ahead!

Here are the contents of the MSDN 2540 course:

Update: Embedded Fusion now offers MSDN 2540N on DVD. It gives you the option of spending $500 for a dry course on DVD rather than $3,000 + expenses for a dry course in person. I don't know if you can place a value on having a good instructor help you through the labs, but $500 is pretty cheap in comparison.

Update to the update: (from a comment on an earlier post) 2540, 2530 and 2535 are the Windows CE .NET V4.x versions of the MS training for Windows CE. MSDDN 2540N is the V5.0 content that was completely re-written for V5.0 [Ed. note: "completely" might be a bit of a stretch, as in how the Platform Builder 5.0 docs were "completely" rewritten from 4.2.]

Module 1: Advanced Building of a Windows CE Image
- Directory Structure of Platform Builder
- The Build Process
- Building in the Integrated Development Environment
- Modifying Configuration Files
- Creating a Component
- Modifying CEC Files With the CEC Editor
- Adding a BSP
- Export Wizard
- Lab 1: Advanced Image Customization and Build
Module 2: Advanced Debugging
- Using Breakpoints
- The Real World: Debugging Process
- Using Remote Tools
- IDE Debug Commands
- What are Debug Zones?
- Other Debugging Techniques
- eXDI
- Lab 2: Exploring Debugging Features
Module 3: Kernel Features
- Definition of Real Time
- Windows CE Kernel Features
- Handling Processes, Threads, and Fibers
- Protecting Applications
- Synchronization Objects
- Memory Model
- Structured Exception Handling
- Optimizing a Windows CE Device
- Lab 3: Kernel Tracking Thread Priorities
Module 4: Understanding Device Drivers
- Windows CE Architecture
- Driver Source
- Driver Resource Management
- Resource Manager
- Device Driver Interrupt Handling and the IST Model
- Device Driver Memory Management
- New DMA Routines
- Driver Loading Mechanism
- Service Manager (Service.Exe)
- Device Notification Mechanism for Applications
- Device Power Management
- Common Driver Architectures
- Native Device Drivers
- Stream Interface Drivers
- USB
- NDIS
- FSD
- Emulation Support
- Lab 4: Implementing a Stream Interface Driver
Module 5: Networking and Communications
- Web Technologies
- Lab 5.1: Enabling a Web Server
- Networking Options
- Lab 5.2: Implementing Microsoft Message Queuing
- Component Services
- Networking Security
- Real-Time Communications
- Multimedia Communications
Module 6: Implementing a Shell
- What Is a Shell?
- Shell Options
- Components of a Custom Shell
- Required Shell Functionality
- Installing a Custom Shell
- Handling Device UI Rotations
- Customizing the UI
- Lab 6.1: Implementing and Handling Screen Rotation
- Lab 6.2: Windows CE Skin Implementation
Module 7: Preparing an Application Development Environment
- Windows CE .NET Application Development
- Native Application Development
- Win32 Programming Primer
- Lab 7A: Exploring Embedded Visual C++ 4.0
- Managed Application Development
- Building, Deploying, and Launching the Application
- Overview of the .NET Compact Framework
- Adding .NET Support to a Windows CE Device
- Lab 7B: Exploring Visual Studio .NET

MSDN 2535

2005-03-13T17:10:00.000-06:00

Warning: boring reading ahead!

Here are the contents of the MSDN 2535 course:

Module 1: Advanced Building of a Windows CE Image
- Directory Structure of Platform Builder
- The Build Process
- Building in the Integrated Development Environment
- Building in the Integrated Development Environment (continued)
- Modifying Configuration Files
- Creating a Component
- Modifying CEC Files With the CEC Editor
- Adding a BSP
- Export Wizard
- Lab 1: Advanced Image Customization and Build
Module 2: Advanced Debugging
- Using Breakpoints
- The Real World: Debugging Process
- Using Remote Tools
- IDE Debug Commands
- What are Debug Zones?
- Other Debugging Techniques
- eXDI
- Lab 2: Exploring Debugging Features
Module 3: Kernel Features
- Definition of Real Time
- Windows CE Kernel Features
- Handling Processes, Threads, and Fibers
- Protecting Applications
- Synchronization Objects
- Memory Model
- Structured Exception Handling
- Optimizing a Windows CE Device
- Lab 3: Kernel Tracking Thread Priorities
Module 4: Implementing a Boot Loader
- Role of the Boot Loader
- Boot Options
- Implementing a Boot Loader
- Sample Boot Loader Requirements
- Building a Boot Loader
- Debugging a Boot Loader
- X86 Boot Options
- Boot Loader in Manufacturing
Module 5: OEM Adaptation Layer
- Operating System Boot Sequence
- Developing OAL
- Required OAL Functions
- Optional OAL Functions
- Debugging an OAL
- Building the Windows CE Kernel
- Implementing OAL Registry Functions
- Power Management
- Implementing Certification Model
- Lab 5: Exploring the OAL
Module 6: Device Driver Architecture
- Built-In Vs. Installable Drivers
- Device Manager
- ActivateDeviceEx
- Registry Enumerator
- Services
- Bus Drivers
- DMA
- Resource Manager
- Interrupt Model
- Device Driver Power Management
- CETK
- Lab 6: Implementing a Stream Interface Driver
Module 7: Device Drivers Examples
- Driver Source
- Arrangement of the Driver Libraries
- Battery and Notification LED Drivers
- PC Card Socket
- Keyboard Device Drivers
- Display Drivers
- DirectDraw
- USB
- 1394
- NDIS
- Audio Device Drivers
- File System Driver
- Lab 7: Implementing a File System

MSDN 2530

2005-03-13T17:00:00.000-06:00

Warning: boring reading ahead!

Here are the contents of the MSDN 2530 course:

Module 1: Overview of Windows CE .NET
- Overview of Windows CE .NET
- Core Operating System Architecture
- Advanced Features of Windows CE .NET
- Networking and Communications
- Real-Time Communication
- Multimedia Support and Architecture
- Security Features and Architecture
- Internationalization
Module 2: Overview of System Development
- Selecting a Windows Embedded Operating System
- The Windows CE Platform Development Cycle
- The Application Development Options
Module 3: Configuring and Building with Platform Builder
- Introduction to Platform Builder
- Platform Development Cycle
- Configuring the Platform
- Building the Platform Image
- Downloading the Image
- Demonstration: Configuring, Building and Downloading
Module 4: Overview of the Windows CE .NET Debugging Process
- Overview of the Debug Process
- Release Builds and Debug Builds
- Introduction to the Kernel Debugger
- Demonstration: Kernel Debugger Windows
- Understanding Windows CE Remote Tools
- Other Debugging Techniques

The Beginning, A Very Good Place To Start

2005-03-11T21:12:00.000-06:00

Everything must start at the beginning. (I think I read this pearl of wisdom somewhere.) Our beginning involved a lot of speculation about what we could and couldn't do. The Filipinos have a term for it: pauli uli, or as we say it in English, running around like a chicken with your head cut off. Jack Ganssle says it better: furious activity is no substitute for understanding.

Unfortunately, understanding was at a premium, so we made the requisite substitution with a big helping of furious activity. I filled out the online form for a Windows Embedded Introductory Kit. (In hindsight, I strongly recommend ordering the kit on CD or DVD. The downloads can take literally hours, even with a high-speed Internet connection. And what if you have to reinstall... I did. Twice.)

The kit comes with Platform Builder 5.0 and Embedded Visual C++ 4.0 (eVC). (Visual Studio 2003 will only compile apps for WinCE if you want to use the .Net Framework.) Whidbey, the upcoming Visual Studio 2005, will have integrated support for compiling native apps for CE, and eVC will say good-bye. (eVC is really just a tempermental, stripped-down Visual Studio with Platform Manager support, anyway.)

We bought a book by Doug Boling, Programming Microsoft Windows CE .Net. It's a good book, but it was ironic that we had decided to write the UI app in CE with MFC. The book proudly states in the introduction: "Since the goal of this book is to teach you how to write programs for Windows CE, the examples avoid using a class library such as MFC [...]" (!) It's a good book, and I recommend it despite the pages and pages of cut-and-paste source listings.

Eventually it was decided that I would attend a CE training session. There are a few companies that do such training, and only two were offering a session in November: VenturCom (now Ardence) in Boston and BSQUARE in Seattle. We chose the one on the right coast and off I went for a week of training. (George didn't go, which was a shame, but he works part time.)

On the flight to Boston I happened to sit next to a Director of Engineering for General Dynamics. We talked and I showed her the software spec and our timeline. A former engineer herself, she was quick to tell me how nuts we were. In return, I scoffed at their policy that a productive programmer wrote just 300 lines of code per week, but I started to have my doubts whether our timeline was doable.

The training was excellent, thanks to the instructor. The MS docs were out of date (and sometimes plain wrong) and the computers we were working on were less than stellar, but the quality of the teacher more than made up for it. Remember that favorite teacher of yours back in high school? The one who really loved what he did, was good at it too, and showed a geniune interest in you? They say that the instructor can make or break the course, and this guy made it.

Windows CE training comes in three courses: MSDN 2530, 2535 and 2540. The meat of the course is in 2540 but the other two are good as well. I'll post the TOC for all three courses in some upcoming posts.

Update: Embedded Fusion now offers MSDN 2540N on DVD. It gives you the option of spending $500 for a dry course on DVD rather than $3,000 + expenses for a dry course in person. I don't know if you can place a value on having a good instructor help you through the labs, but $500 is pretty cheap in comparison.

With my week-long CE training firmly under my belt I was ready to tackle the world. I wrote a summary of my trip in an email to family and friends and flew home.

bostonTrip.pdf

Why Windows CE?

2005-03-07T22:50:00.000-06:00

It looks like I've gone live, thanks to Mikehall's "look at Windows CE, Windows XP Embedded (and anything else that's cool or interesting)." Since this is in the CE category, maybe that means it's not cool or interesting. But hey, I'll take one out of three. I should also mention that I've never written a weblog before. Any tips some of you more experienced posters have would always be appreciated. (Heck, I'll even take grammer tipses.)

So why did we choose Windows CE? There were a lot of reasons; most of them were good. As I mentioned before, we were using an unsupported platform for development. But we'd used it for ten years, so we knew exactly what we could and couldn't do. But now (this was early August 2004) we were at a crossroads. A major OEM had contacted us and arranged a demo of an as-of-yet uncompleted system for March 2005. Like any company in our shoes, we agreed to the date first and asked the engineers second.

George and I had come up with a rough DOS/Zinc timeline that was already aggressive. Perhaps "timeline" is the wrong word. It was a deadline with tasks stuffed into it to make them fit, AKA a "Stalin deadline." ("There's no line like the deadline," Stalin used to say. OK that sucked I just made it up.) Alec, our new Engineering Manager, was eager to make a good impression with the Director. Alec was a wizard at chip design. He was in his early forties, but his young looks and great hair were betrayed by his considerable paunch. We held a meeting to see how we could cram the timeline into the deadline.
"Come on, a week to work on fonts?" Alec asked with mock incredularity.
"Okay, maybe I can do it in 3 days," I allowed.
We hadn't factored an OS change into the mix.

Looking back, I think our options were fivefold:

Continue using Zinc
This would've required that we reinstate our licenses for two developers, upgrade to the current shipping version, and buy a high-speed graphics library.
Zinc's former big brother: VxWorks
Embedded Windows: CE or XP
We never really considered XP because of its size.
Linux
As Donald Rumsfeld was (in)famously quoted, this was a "known unknown." I have some experience with Linux and SunOS, but not in the embedded world. And Linux isn't a real-time kernel without real-time extensions. (Not including projects from sites that end in .edu, which we weren't seriously considering.)
Something else or roll our own: ???

This was a good starting point, and we used it to start looking at prices. WinCE got a boost from the fact that our potential SBC manufacturer provided a BSP for its PC/104 SBC.

Our potential costs looked something like this:

Zinc	~$6,000/developer* + royalties**
VxWorks	~$10,000/developer + annual maintenance + royalties
WinCE	$995/developer for Platform Builder + $3/device***
Linux	If the point of using Linux is that you get a free, open-source kernel, paying big bucks for real-time extensions doesn't seem to make sense. So Linux didn't make the cut.

* For starters we needed licenses for two developers
** Our current Zinc run-time license didn't include royalties
*** $3 is for the core OS. The Pro version, which includes little niceties like Help, costs $16/device. We thought that we would only need the core OS. Also, Platform Builder came with a 120-day evaluation period. (Tip: definitely get the CD or DVD; the download-over-the-web install can take up to 4 hours, even on a T1.)

By comparison, our current costs were $0/developer and about $25/MS-DOS license. (In case you're wondering, yes, 24 years later Microsoft still sells MS-DOS.)

If you read through that table just now like I read through a similar list of options back in October, I think you'll agree that it wasn't much of a choice. There were still some critical questions to answer, though. Could the bulk of a modern OS run as fast as practically running on bare hardware? How hard would it be to port 100,000 lines of code over to CE? Would our I/O handling be fast enough?

One of the biggest problems, which I may post about later, is the bewildering way that Microsoft markets CE. What is Windows CE? Eight years after its release, I'd wager that a lot of people in the embedded industry couldn't give me the right answer. MS has done a great job of confusing the market about CE and Pocket PC. (As a bit of proof I submit: the first MS-owned link from a "Windows CE" Google search.) And putting the ".Net" moniker in CE 4.2 was about the worst thing they could've done in the emdedded market. MS already has a reputation for bloatware; what self-respecting engineer wants to put .Net--which for all intents and purposes to most people means the .Net Compact Framework--in an embedded controller?

I found some good articles that helped reassure us about CE:

Real-time determinism in Windows CE
Straight from the horse's mouth: Real Time Systems with MS Windows CE
Real-Time Behavior of the .NET Compact Framework

The last article, about running .Net managed code and still getting mostly deterministic behavior, reassured us that Win32 code could at least run faster than 50-odd µsecs. Still, without taking the steps to port a good portion of the codebase to run a test, we couldn't measure how fast it would run.

But something else that was less than reassuring was a high level of confidence in CE by people who had no idea why they were so confident in it. Maybe it's the classic difference between engineers and people who manage engineers. Rutherford, our Director of Engineering, unnerved me with his confidence about switching to CE. Fiftiesh with a graying pompadour and a self-described bureaucrat, Rutherford had a background in steel manufacturing. Maybe he held Microsoft stock, maybe using a Microsoft product gave him a warm and fuzzy feeling, or maybe it was the fact that we'd recently lost a sale to a competitor whose system ran Windows. (Even though our controller ran theirs into the ground during a week of independent testing, they taunted us with our "old" DOS system. It was wrong, but it stuck, both with our non-customer and back at the office.)

For watever reason, Rutherford was set on CE. He couldn't remember its name--to this day he calls it "CE Microsoft"--but it got his vote. I remember preparing for a checkpoint meeting early on in the design phase about the control flow of the new UI. Rutherford and I were talking about the switch:
"That's if we move to CE," I reminded him, expressing my doubts.
"We're going to CE Microsoft," he said pointedly.

CE 5.0 had just been released, but our vendor was only supplying a BSP for 4.2. Version 5.0 has some great features for developers but there's little incentive from a customer standpoint to want to upgrade. Someone in Korea took the time to put together a really nice PDF that shows a comparison of CE 5.0 vs. 4.2. (Update: Found the original.)

In case you're wondering if I think we made the right decision, I absolutely do. There's no question in my mind that we needed to move away from DOS and start using a more modern RTOS and better toolchain. Whether this project was the best project to jump into a new OS is what I'm less sure about.

In Detroit and at other car-makers, a common engineering practice is to change one major system on a new model, but not more than one. For example, BMW might change the engine on their 3-Series, or put it on a new frame, but they don't typically do both in the same year. We were changing everything: new hardware, a new OS, new software and a new toolchain. And we were doing it on a timeline that was so tight it didn't allow for losing even a half-day. It was the classic case of biting off more than we could chew.

With the decision to use CE locked in place, we were all set to start porting our real-time app and writing the new UI app. The only problem was that none of us had written for CE before, and we didn't know where to start!

Good Ole Days

2005-03-06T23:08:00.000-06:00

This is all leading up to why we chose Windows CE. It's taken me longer than I thought I would, and I think I should (quickly) explain our previous and current systems before I discuss our Big Decision.

No engineering company is complete without the folklore of its past, and ours is no exception. We began with the first controller, as most companies do. It practically used vacuum tubes and mechanical relays to accomplish the ridiculously easy task of checking the glue level and sounding an alarm if it got too low. That grew into controllers that were dedicated to looking for some particular pattern of events. They were hardware-only. We even sent our customers manuals with instructions for how to set a row of 8 DIP switches to represent binary distances! We quickly left that behind in favor of the enormous, 8-bit power of the Boss Bear, which featured a 2-line, 40-character display.

Unfortunately, the Boss Bear BASIC programs were limited to 32K, which meant that as the program matured we had to strip out features to include others. Sometimes 3 or 4 lines of code were crammed into a single line of text to save space. Variables names were shortened to the minimum, comments were left completely out. That suited George just fine, who would rather not comment anything anyway. George was and is the longest-tenured programmer here. He has a slight build, wears his hair long, and works part time. He lives away from the office but commutes in once or twice a month. He's quirky to work with and at the same time he's one of the most likeable guys in the world. In some ways, he reminds me a lot of Mel; the guy could probably write a compiler in 8 lines of code using only pointer arithmetic, preprocessor directives and macro expansion. Uncommented, of course. One day I'll have to write about George, but that's a post for another day.

Well, the world of Boss Bears came and went, and we pushed into the age of embedded boards running on Intel chips with our next system. It was written in a mixture of C/C++ and ran on a 486 DX2/66 on the STD bus. It used a 10.4" EL display and had a full keypad and dedicated buttons on the front. It was a marvel of its day. The display used to burn in within weeks, but that was a small price to pay compared to the potential of this 486 powerhouse!

The program ran on MS-DOS 5, which was overclocked to give us a 50µsec polling loop. It used the Zinc Framework. If you've never heard of Zinc you're not alone. In fact, the nine of us who have heard of Zinc are the oddballs. Zinc employed a write-once, compile-for-anything idea. It wasn't actually "anything," but they started with compile keys for 3¹/₂ major OSes: DOS, Windows, Unix and OS/2. Zinc was too far ahead of its time. If the tides of history had flowed a little differently, it might have been what Java is today. Unfortunately, the company fell on hard times and was bought by WindRiver. But WindRiver couldn't figure out what to do with it and later sold it to PSA, a group of former Zinc consultants.

Eventually, though, our customers demanded more and more powerful machines, so the next version was born. We stuck with the STD bus but upgraded the processor to a Pentium, sans bunny people and blue people, which ran as hot as that SBC form factor would allow. The display was upped to a 12" TFT running at 640x480 but the effective area stayed the same. The right side and bottom were covered with a two-column keypad for data entry and a button strip for commonly-used functions.

Astute readers have probably noticed a pattern emerging from generation to generation. In each new system, software grew more powerful and took over what had been dedicated hardware before. Previously, for example, for an important toggle button we had a physical pushbutton that was mounted into the face of the controller, and wired into I/O. Now it was done with a screen overlay.

And the next controller, the Oswald Project, called for zero hardware buttons. Instead, a single 15" display running at 1024x768x16bpp would take care of all controller functions. But we had a problem: Zinc couldn't drive anything higher than 640x480 without a new graphics library. And that library didn't work on the version of Zinc that we had. And the license for the version of Zinc that we had was expired.

The time was ripe to pick a new development system and toolchain. Up next: our choice of OS (for real this time).

The Company

2005-03-05T14:56:00.000-06:00

If I was a box maker and I wanted to find a bad box that was moving at more than 20 MPH and pull it out of my production line, how would I do it? It turns out that it's a very difficult and unique problem. That question, and others related to carton gluing and detection, are worth about $50 million annually to our tiny niche of the packaging market.

But our niche solves an important problem. (Every business exists because it solves some problem. And businesses thrive when they solve the right problems for the right people.) We solve a problem that is unique, we solve it very well, and there are big companies that are willing to pay us a lot of money to provide them with our solution.

In the world of boxes there are two major types: corrugated (the kind of boxes we used to move into our house last summer ) and cartons (the kind of box that my Cinnamon Life comes in). The corrugated market is a down-and-dirty market. Boxes are cheap, and so is the equipment that runs them. But the folding carton market is a gold vein. Anything that comes in a box--from a tiny tube of Blistex to a big box of Cheerios to a smaller tissue box to a complicated bottle carrier--is produced in the folding carton market. Consumer-oriented companies have one way to get you to buy their product when you're at the store: the look of the packaging that it comes in. So it's in their best interests to produce the best looking cartons that will catch you or your kids' eyes first.

It's a huge business. The next time you finish your last can of Coke, rip open that Coca-Cola Fridge Pack™ (Pepsi countered with its Fridge Mate™--how original) and you'll notice three or four patent numbers printed on one of the flaps. Most people, myself included, would never think that someone would patent something as simple as a box. But if you look at them closer, they're not so simple. A lot of engineering goes into the designs and several Fortune 500 companies are willing to spend a lot of research dollars to preserve their competitive edge.

Cartons are usually printed on 4- or 6-color presses, then run through a cutter, then loaded onto a folder-gluer. The folder-gluer is a bit of a misnomer: it folds, but it doesn't usually glue. That part is left up to systems like ours, which glue the boxes, and do quality control on them. Any spoilage on the gluer costs the most. The most expensive part of the life cycle of a carton is on the gluer. Even worse, a single misfed or skewed carton can jam up the entire line and ruin hundreds of other cartons. The Georgia pine used in the substrate of some cartons, like soft drink 24-packs for example, is so strong that when it jams up it can bend the steel of the machine.

But it's not just the strength of the cartons that bends the machine, it's the speed that they move at. Some gluers can run upwards of 200,000 cartons per hour (CPH). That's really, really fast. Even 60,000 CPH is so fast that when I look at it it looks like a solid sheet of board moving past.

Even at those speeds, we produce a system that can lay up to 16 lines of glue on a single carton, monitor that glue (or any other pattern), and pull out a single bad carton from the jet stream of good ones. It's not cheap; a complete system can cost around $80,000. But if you're the guy who just bought a $500,000 folder-gluer, we're in business to make sure that you pay a little more to get a great gluing/detection system to go along with it.

It's taken us a few tries to get it right. Our current system is the fifth generation of controllers that we make. This generation is as perfect as it can get, but it's also a maxed out system, and our customers are always clamoring for more features. So our next generation of controllers will be expandable to 24 patterns, big enough to run even those tricky beverage carriers. And it will be cheaper. It'll also run faster. It will be easier to use, too, thanks to a completely reinvented GUI. Oh, it'll also solve world hunger. Enter the Oswald Project.

Hello, WWWorld

2005-03-04T22:54:00.000-06:00

Partly at the suggestion of Mike Hall, I've decided to start a weblog about a very, very small corner of the universe known as Windows CE. Specifically, this is a blog about a real-world project using CE.

There are other blogs about WinCE written by people who know far more about it than I may ever know. (I'll link to them as I find them.) And there are some good online tutorials for getting started with CE. But as far as I know there are no weblogs about the trials and triumphs of actually working on a corporate CE project. So I'm starting one today.

Today is March 4, and this marks the seventh month of the Oswald Project, although in all fairness we've only been doing serious development since Jan. 4 of this year. The finish date for this project was supposed to be March 25, which is a scant 3 weeks away from today. But despite our three month death march, we are still far behind schedule and will badly miss our target date. That day was supposed to be a live demo at one of the most important (potential) customers of my company's 76-year life.

Speaking of my company, I will try to post everything that I can about this project within the confines of a competitive marketplace. In the ideal world of academics and research I wouldn't have any qualms about posting information relevant to this project. But in the dog-eat-dog marketplace of free enterprise and international espionage, there is a possibility that our work does not go unnoticed by our competition. And our competition has been nipping at our heels as of late...

So to protect the innocent--and the guilty, of which there are a few--the names and specifics have been changed. I will call this project the Oswald Project. Oswald is an obscure painter.

Painting aside, this blog will mostly cover the technical details of what it takes to create a brand new Windows CE project and ship it to a customer. But if I start to wax philosophical or wander off into stories of my personal life, please forgive me. I’ll soon get back on course.

I also have a lot of background to write to get you up to speed. (We'll see how that fits with my 70-hour work weeks.) But eventually, I'll catch up to real life and start posting about what's currently happening. Until then these posts will have a historical bent. Perhaps those are better: with the passing of time, feelings and opinions fall by the wayside and only the facts remain.

Up next: some background on the company and our reasons for choosing WinCE.

This blog Copyright © 2005 D. Philippe