A colleague asked me how GPSAPI.lib is built and makes it into the SDK. So we found ourselves in a long discussion which included a massive flow diagram on a whiteboard. In this article, I am going to try to reproduce what we ended up with on the whiteboard, but frankly on the whiteboard it was easier to draw.
My colleague had tried to build GPSAPI by opening a build window and running build in the GPSAPI folder. What he did was:
In doing so, he built some source code in the public tree, and the output ended up in the public tree under the OAK\LIB folder. This is not what he expected in a few ways:
1.       The lib file that was created was larger than the one in an SDK that he was comparing against. This is because the lib file that was built is the actual API which is meant to be linked to create a DLL that will be included in an OS. The lib file that is included in the SDK is an output from creating the DLL.
2.       The lib file didn’t end up in the SDK\LIB folder. Again because this lib file is not meant to be included in an SDK.
3.       The lib file didn’t end up where the SDK roller would get files when creating and SDK. This is because the folder that was built is set up to be build with Sysgen, not directly with build.exe.
So we started looking at what happens to create the DLL, the SDK and ultimately an application that uses the API.
The first step in the process is running Sysgen:
We see that the first step, Sysgen Compile/Link Pass 1, is very similar to building the folder directly with Build, but the output folder changes to _PROJECTROOT. _PROJECTROOT is in the OSDesign subfolders. This is good, because it is what we expect for Sysgen. The second step, Sysgen Link Pass 2, produces both a DLL and a LIB. The DLL goes in OAK so that it can be put into the OS, and the LIB goes in SDK so that it can put rolled into an SDK for application developers to use.
What is important to note here is that the LIB in the SDK subfolder is very different from the LIB that was created in the first step. This LIB is merely a wrapper used by applications to make loading the DLL easier. A LIB file like this is created when a DLL is built.
The drawings get more complicated now because there was a branch of the files. The next step is to create the OS and we will look at this now, later we will follow the SDK through to running an application on the device.
Creating an OS that includes GPSAPI.DLL looks like:
Creating the OS is fairly straight forward. Buildrel copies the DLL to the _FLATRELEASEDIR. Makeimg puts the DLL into the OS, or NK.BIN. Then put the OS on the device. The device now has GPSIAPI on it and ready for applications to use it.
The next step is to create an SDK and use it to create an application:
The first step is to build, also known as rolling, the SDK. Rolling the SDK pulls together the header and LIB files to put into a Windows Installer file for application developers to use. Then the application developer installs the SDK on the development workstation.
Now the application developer can create a wonderful user experience that uses GPSAPI. When they set up the project, they need to link with the GPSAPI.LIB that is in the SDK to create their application. Then deploy the application to the device that has the OS that we created earlier.
Now the magic happens:

We start the device, which has GPSAPI.DLL in the \Windows folder and run the application. The magic is that GPSAPI.LIB that, linked with the application, automatically loads GPSAPI.DLL and sets up access to the functions that it contains. The app now seamlessly calls the functions.

So that is how an API gets into an OS, and the SDK is created.   You should have seen the whiteboard…
Copyright © 2010 – Bruce Eitman
All Rights Reserved