Compartilhar via

What exactly is an SDK?

  • Artigo

Posted by: Sue Loh

To explain SDKs I will start with what an OS Design is.  The CE OS has a ton of “components” that can be controlled using SYSGEN_ environment variables, that are set or unset based on what an OEM chooses out of the Platform Builder catalog.  A “component” is not a well defined thing – usually it is a few APIs, some DLLs and/or EXEs, a few registry settings, some .bib settings.  When an OEM adds a component to their OS Design, they do more than add a new DLL or EXE.  The sysgen process has to go through header files and add the new APIs to the header files for applications to compile with, and it has to add the new API code to coredll (or other DLL that applications link with to get the API) for applications to link with.  So, an OS Design is a collection of SYSGEN_ variables, and when an OEM builds it they get a unique set of header files and libs that applications can link against.  That is the SDK.  Windows CE OEMs can use the "SDK roller" to generate the SDK for their platform after they create their OS Design, and give out the SDK for other people to build applications with.

SDKs are not magic.  You can look at them.  If you install a Windows Mobile 5 SDK (Pocket PC or Smartphone) it goes to c:\Program Files\Windows CE Tools\wce500\ by default.  If you look there, you'll see that you get a set of header files and libs.  You also get some sample code, emulators and help files.  If an OEM rolls an SDK for Windows CE and you install that, you'll see a similar set of headers, libs and help files in the same place.  The main "magic" thing about an SDK is that when you install it, Visual Studio finds out about its existence and starts offering it as an option to target when you create a "Smart Devices" project.

The SDK contains the definitions that match the OS on the device, and nothing more.  The number of possible SDKs is equal to the number of possible OS Designs (since they go hand in hand), and I believe if we have N possible SYSGEN_ variables to set or clear, then there are 2^N possible Windows CE OS Designs.  (Imagine our test matrix!)  To make our OEMs' lives a little easier, so that they don’t have to sift through hundreds of components deciding what they want, the OS Design Wizard gives them recommended starting points – like "web pad" or "set top box."  After an OEM starts with one of these templates, they can add or remove features to get exactly the OS they want.  Each time they change the set of components in their OS Design, they change the SDK that matches their OS Design.

That means that there is no common set of APIs that all applications are safe using.  An application that works on one Windows CE device may not work on a different device, because it may call APIs that don't exist on the second device.  Said in other terms, an application that is built against one SDK would not necessarily build succesfully against a different SDK, and if you run an application on a device that doesn't use the SDK the application was built for, the application is not guaranteed to run.

That said, it is possible to build app code against the SDK for one OS Design, and run it on a different OS Design.  As long as all of the OS components that the app uses are present on the OS Design it runs on, it will run successfully.  If the app calls an API that does not exist on the OS Design, or if it links against a DLL that’s not present, the app will fail to run.  So, as soon as you start running code on a different OS Design than you built for, you are no longer guaranteed that your code will work right.  Most likely it won’t run at all, but it’s also possible it’ll run and hit failure cases you never ran into before.

Windows Mobile simplifies this by a TON.  While general embedded OEMs are free to pick and choose OS components as they wish, Windows Mobile is a very specific set of components.  It only has two OS Designs: Pocket PC and Smartphone.  This greatly simplifies life for the Windows Mobile application developers.  They know if they write an app and it works on one Pocket PC, it will have a very high chance of working on all Pocket PCs.  (At that point, compatibility issues are more about stuff like working on different screen sizes, not different sets of OS APIs.)  In fact, by most definitions of the word "platform," Windows Mobile is a platform (because you know exactly what APIs it supports) while Windows CE is not.  Windows CE is a toolkit for OEMs to create their own platforms.

Meanwhile, it is a tougher job to write applications for general embedded devices.  To target a lot of different devices, an application developer would have to pick a base set of SYSGEN_ variables that they require, and say that their app would not run on devices that don’t include those SYSGENs.  More likely, what happens is that an OEM builds their own applications, or gets a partner to build the applications specifically for their device.  In that case what they do is roll their own SDK to build the applications against.  If they change the SYSGEN_ variables in their OS Design, they’d have to re-roll the SDK and rebuild the application to guarantee they didn’t cause incompatibility.

For maximum portability you could work against a “minimal” SDK – from an OS Design that doesn't set any SYSGEN_ variables.  You get NO optional OS components; only the bare minimum that the OS supports.  If you build an application against the minimal SDK then you are guaranteed it’ll work on all OS Designs, because by definition a minimal OS Design cannot contain anything that could be excluded on some other OS Design.  But you have the obvious drawback that you can’t use any APIs beyond what’s in the minimal OS Design.  For example, UI would be completely out because user interface components are not part of the minimal OS.

To improve life for Windows CE OEMs and application developers, they (other people at Microsoft) tried to make a "Universal SDK" or "Standard SDK."  If an OEM adds the universal SDK component (SYSGEN_USDK) to their OS Design, it sets a common set of SYSGEN_ variables to add the necessary features to the OS.  An application developer can get the standard SDK online (Windows CE 4.2 or Windows CE 5.0) and be confident that when they build applications against it, the applications will run properly on any device that includes the universal SDK component.  (Varying screen size can still be a problem.)

However I say "they tried" because it turns out, nobody was using the standard SDKs.  OEMs were not including that component in their devices.  (Oh and also in CE5 -- I don't know if it was a bug or intentional -- the standard SDK component added features which bumped the device up to higher than normal licensing fees.)  Application developers were not using them; they were just using the Windows Mobile SDKs.  And it was taking a lot of effort to maintain the SYSGEN_USDK component.  So in Windows CE 6.0 this option is gone.  There is no more standard SDK.

One other note, we try very hard not to break application compatibility from one OS release to the next.  That means, if an OEM builds a CE5 device with a particular set of SYSGEN_ variables, and later makes a CE6 device with the same set of SYSGENs, we really want the apps built against the OEM’s CE5 SDK to continue running unchanged on the CE6 device.

Comments