Compartir a través de

What is Platform Builder?

  • Artículo

I work in the Windows Embedded CE group on the "PB IDE tools" team. That might take a bit of explaining. (Sometimes, I'm not entirely clear myself.)

CE is the "miniature" version of Windows. (The big version, referred to as "NT" on this blog, is familiar to most people -- nearly everybody knows what I mean when I talk about Windows 2000, XP, or Vista.) When talking to family members and friends, I get the most success by explaining it as "the operating system that runs Pocket PCs and SmartPhones". That's accurate (assuming they don't confuse it with PalmOS or their Nokia cell phone), but not a complete description. The CE operating system is actually used in a lot of other things such as industrial automation, GPS navigation systems, and routers. While skiing with my sister's husband, I was trying to explain this and I noticed that the little barcode scanners they were using to scan our lift tickets were running CE, so that made it a bit easier to explain. In any case, CE tends to be used in computerized components that are used as "devices" or "appliances" and not "computers".

I am a member of the "IDE Tools" team. Officially, this means that my team is responsible for the Platform Builder shell and project system used to develop for CE, but unofficially it means "if it runs on the desktop and it isn't owned by any other team, it belongs to the IDE Tools team". As a result, I get to stick my fingers in nearly every aspect of development for the desktop - compilers, debuggers, build systems, setup, C#, C++, scripting, you name it. If it runs on a Windows NT platform (Windows 2000, XP, Vista, etc.), I'm supposed to know all about it. It's my job.

Platform Builder ("PB") is the IDE for developing the CE operating system. This also takes a bit of explaining.

CE is different from NT in a lot of ways. You don't go out, buy a copy of CE, and install it on your phone/PDA/router/refrigerator/toaster. You buy a phone or a PDA with CE already built into it. That copy of CE was customized and tweaked to make it a (hopefully) perfect fit for the phone or PDA onto which it was installed. Typically HP, Samsung, HTC, or some other hardware vendor will design and develop some hardware to meet a need, then use the PB tools to tweak the CE operating system to work well with their hardware. The hardware and the CE operating system are then sold as a single item. So you won't see a copy of "Windows CE" on the shelf at your local software retailer.

PB has a catalog that allows the vendor to choose the parts of the operating system they need. A minimal CE operating system with just a kernel and basic device drivers is about 300K. A fully featured CE OS with a web browser, web server, solitaire, .NET Compact Framework, media player, etc. can be 64 MB or more. Somewhere in the middle is an OS that (hopefully) has all of the features you need for your device. This is important because each additional megabyte of flash or RAM adds to the cost of the hardware, reduces battery life, and increases device size and weight. These costs become especially significant if plan to ship 1 million CE-based talking toasters. (Are you sure you don't want a nice English muffin right now?)

Most devices running CE are proprietary hardware designs with a unique combination of microchips designed to fill a specific niche in the market. This usually means that the CE operating system needs to be customized somewhat to run on the specific hardware. Often, device manufacturers have to write their own device drivers since they're using proprietary hardware. PB provides many tools to help with this process. PB provides an integrated development environment (IDE) to allow developers to edit and compile their code (driver, application, etc.), copy it to the device ("download"), run their code and control its execution (remote shell), and debug their code (debugger).

Four different teams work on PB - debugger/connectivity, remote tools, build, and shell/project system (that's my team!). The responsibilities of the other teams are fairly self-explanatory and well-defined. The debugger/connectivity team works on the PB kernel debugger, the KITL connectivity layer, and the platform manager/connection manager transport layers. The remote tools team works on tools that run on the desktop to provide data about what is going on within a device (remote registry editor, remote file viewer, kernel tracker, etc.) The build team (currently one person, recently split off from the shell/project system team) is responsible for improving the CE build system. The responsibilities of my team (shell/project system) are a bit more nebulous, and we tend to wind up doing anything not covered by any other team (this drives my manager nuts).

The exact boundaries are sometimes hazy, but since the goal is "get the product working well", not "make my team look good", the boundaries don't have to be rock-solid.

Comments