(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.