Developing for Windows Mobile 6: The WM6 SDK Explained

Windows Mobile 6 was Microsoft's smartphone and Pocket PC operating system of the mid-to-late 2000s, and the Windows Mobile 6 SDK — the software development kit — was how you built applications for it. If you have arrived here from an old link, or you are maintaining software that still targets these devices, this guide explains what the SDK actually contained, how the pieces fit together, and where mobile development has moved since. It is written to be genuinely useful rather than a nostalgia piece, so where a specific version number or download address cannot be stated with confidence it is deliberately left out.

Why there were two SDKs

The single most confusing thing about Windows Mobile 6 for newcomers was that it was not one platform but two closely related ones, and the SDK reflected that split. Microsoft shipped the kit as two separate downloads:

• Windows Mobile 6 Standard SDK — for Windows Mobile Standard devices: the non-touch smartphone form factor, driven with a numeric keypad, a directional pad and softkeys rather than a stylus or finger on the screen.
• Windows Mobile 6 Professional SDK — for Windows Mobile Professional (and the closely related Classic) devices: the touch-screen Pocket PC style of hardware, typically operated with a stylus.

This two-download arrangement was, as the original post noted, "to keep in line the naming scheme beginning with WM6 of the mobile products." Earlier releases had used names like Pocket PC and Smartphone; Windows Mobile 6 rebranded those into Professional, Classic and Standard, and the SDKs were named to match. Which one you installed depended entirely on the devices you were targeting — and many developers simply installed both, because the two families shared a great deal of common ground.

What was actually inside the SDK

A Windows Mobile SDK was not a program you ran on the phone. It was a bundle of developer resources that plugged into Microsoft's desktop tools. Broadly, each SDK provided three kinds of thing:

• APIs, headers and libraries — the documented programming interfaces for the operating system: the shell and UI, telephony, messaging, contacts and calendar (PIM) data, networking, storage, and the hardware-facing services a phone exposes. For managed developers these surfaced as class libraries; for native developers, as C/C++ headers and import libraries.
• Device emulator images — virtual Windows Mobile devices that ran on your PC, one or more per form factor, so you could launch, install and debug an app without owning the hardware.
• Tools, samples and documentation — helper utilities, sample projects that showed how to call the APIs, and reference documentation for the platform.

The SDK slotted into Microsoft Visual Studio, which was the hub developers actually spent their day in. Visual Studio provided the editor, the compilers, the debugger and the deployment machinery; the SDK told it how to build for, and talk to, a Windows Mobile target.

Two ways to write the code

There were two mainstream ways to build a Windows Mobile 6 application, and the choice shaped the rest of the project.

Managed code with the .NET Compact Framework

The most approachable route was managed code running on the .NET Compact Framework, a trimmed-down version of the desktop .NET Framework designed for the limited memory and processing power of a handheld. You wrote in C# or Visual Basic, laid out forms with a designer, and got garbage collection and a familiar class library. The trade-off was that the Compact Framework was a subset of the full framework — not every desktop class was present — and it added a managed runtime layer on top of the OS. For business apps, data-entry tools and line-of-business software, this was usually the pragmatic choice.

Native code in C++

The other route was native C++, compiling directly to the device's processor instruction set. Native code gave you the most direct access to the platform APIs, the smallest runtime footprint and the best performance, at the cost of manual memory management and more code to achieve the same result. Performance-sensitive software, low-level utilities and anything that needed APIs the Compact Framework did not wrap tended to go native.

The build, test, deploy workflow

Whichever language you chose, the day-to-day loop looked the same, and the emulator was central to it:

1. Create the project against the target platform — you picked a Windows Mobile 6 Standard or Professional project type in Visual Studio, which pulled in the matching SDK's references and settings.
2. Build against the SDK. Compiling produced a package suitable for the device — for managed apps typically a CAB installer or a deployable assembly, for native apps a compiled executable and any supporting libraries.
3. Test in the emulator. Visual Studio deployed the build into a device emulator image matching your target form factor and let you run and debug it there — setting breakpoints, stepping through code and inspecting state exactly as you would on the desktop. Choosing the emulator that matched the real form factor (Standard vs Professional) was important, because input and screen behaviour differed.
4. Deploy to a device. Once it behaved in the emulator, you deployed to real hardware — historically over a USB cradle using Microsoft's desktop sync software — to confirm real-world behaviour, performance and hardware quirks the emulator could not fully reproduce.
5. Iterate. Fix, rebuild, and run again — mostly in the emulator for speed, on the device for final confidence.

The emulator deserves emphasis because it is what made the SDK genuinely usable: you did not need to own a Windows Mobile phone to start writing and debugging software for one. That lowered the barrier considerably for anyone curious about the platform.

Getting the SDK

The original announcement linked directly to Microsoft's download centre for the two SDK packages. That specific link is long dead, so we have not reproduced it — pointing you at a broken address would help no one. The SDKs were free downloads from Microsoft in their day. If you need them now for legacy maintenance, treat them as historical software and obtain them only from a trustworthy source; current availability, because Microsoft's download locations for this era have changed repeatedly over the years.

Where this fits in 2026

It is worth being direct about the present. Windows Mobile is discontinued, as is its successor Windows Phone; both platforms are unsupported, receive no security servicing, and have no active app marketplace behind them. The tooling described here expects Visual Studio releases from a different era, and nothing new ships for these devices. In short, the WM6 SDK is legacy technology.

If you are choosing where to build a mobile app today, the practical targets are iOS and Android — natively, or through a cross-platform framework that produces apps for both. The value of understanding the Windows Mobile 6 SDK now is narrow but real: keeping old in-house software alive, reading the history of how Microsoft approached mobile before the modern smartphone era, or simply satisfying the curiosity that brought you to this page.

Key terms, briefly

• Windows Mobile 6 — Microsoft's smartphone / Pocket PC operating system of the period, split into Standard, Professional and Classic editions.
• SDK — software development kit: the APIs, emulators, samples and documentation needed to build apps for a platform.
• .NET Compact Framework — a smaller version of .NET for mobile and embedded devices, used for managed (C#/VB) Windows Mobile apps.
• Device emulator — a virtual Windows Mobile device that runs on your PC for building and debugging without physical hardware.
• Pocket PC — the earlier name for the touch-screen device family that WM6 rebranded as Professional / Classic.