Systems Development Kit

An SDK is a group of tools that help developer's create files/software. Like Mozilla's XPToolkit that helps develop cross-platform ui's. Or Sun's JDK (Java DK) that assists creation of Java

There's talk of evil companies creating SDKs that ease the process so far that you don't learn enough and are tied into the language for all eternity

uhuh

(perhaps they should've put random crahes, messy interface, to ensure none of that)

(Along with what is written above:) SDK can also stand for Software Development Kit (I've never heard systems development kit). They are usually add-ons to a product that expose the programmability aspect of that product, like the Netscape Plug-in SDK, or the Microsoft Platform SDK, or what not.

An SDK usually includes several things:

    *)Header files to #include: Obviously any C coder with his or her salt knows that header files are the first line of documentation. If it's not a C SDK (could be VB, Java, Perl, Python, anything), than it's some sort of library entry point exposure, methods list, etc.

    *)Libraries to link against: A lot of times, you will get libraries to compile-time link against (maybe even at runtime). Sometimes you will be lucky and even get debug libraries, or at least symbol files. Ahh, symbolic debugging. There is no greater joy.

    *)Documentation: No guarantee on the quality of documentation or even it's existance, but usally, most SDK providers document their stuff. Always read the readme. Sometimes, it's all you get. Nine times out of ten, you get an API list at the very least.

    *)Sample Code: (Thanks go out to Dhericean for pointing this gaping hole out to me) Sample code is one of the greatest tools a software developer can have. Reason? Because it's almost always gonna work. Why doesn't your code work? Mainly because it isn't the sample code. Samples are oftentimes a quiet readme into the mind of the developers. They show you the style and method to best not hurt their baby. Maybe your message loop should be structured this way, or let's NOT poll for interrupts. Sample code sets down the playground rules to help your code play more nicely with the pre-written binary components.

    *)Errata: This is the best part. The gotcha's. Boy, and some of 'em are rough. The errata are a combination of readme items, and firefighting aids. (What do you mean no UNICODE!! argh!). Usually there are a list of known serious bugs, API flaws, and a pile of "just don't do that"-s. Pay attention. Usually they know EXACTLY what they are talking about when they say something doesn't work.

Developing platform specific and product specific products can be kind of neat to watch it all work in the whole picture, but it is oftentimes frustrating along the way (for those items that are not SDK'ed well, or an SDK was thrown together at the last second). But it does show the mettle of a good software engineer to be able to use one, and to learn into it and work with it.

Log in or registerto write something here or to contact authors.