Windows SDK

Introduction

The Windows SDK is a platform-specific package that contains the STRIDE Runtime source and PAL implementation, along with integration tools to build a stride library and a strideDaemon and a TestApp applications. It is intended for this article to be used as a reference. For more information about using the SDK, please see Off-Target Environment.

Target Makefile

The SDK Makefile (based on GNU make semantics) provides targets for building the STRIDE Runtime library and two executable applications - a strideDaemon (for a multiprocess application environment), and an TestApp (see this for more information).

The default make target builds the STRIDE Runtime library. When a multiprocess runtime library is specified (see RTSINGLEPROC below), and a strideDaemon executable build as well. To build the test application, specify the testapp make target.

The testapp target compiles SCL source markup present in the Runtime source and therefore requires that the Build Tools be installed on your system and in your executable search path.

Configuration

The behavior of the makefile can be affected by setting certain make variable parameters. For example, the following make invocation will change the value of the TOOLCHAIN and DEBUG variables when making:

cd stride\SDK\Windows\src
..\bin\make TOOLCHAIN=arm DEBUG=1

The following variable are intended to be specified or overridden as needed:

TOOLCHAIN

The default compiler toolchain when TOOLCHAIN is set to x86 which assumes a WinMobile x86 version of cl/link/lib to be in your path. For any other TOOLCHAIN value, the toolchain compiler is cl$(TOOLCHAIN) where $(TOOLCHAIN) is replaced by the specified TOOLCHAIN setting. If your toolchain does not fit this pattern, you will need to modify the makefile or explicitly override values for CC, CPP, LINK, and AR.

LIBRARYTYPE

The default behavior of the makefile is to build the STRIDE Runtime as a static library. If you prefer a dynamic library, set this value to '.dll'.

DEBUG

The default configuration compiles with optimization and NDEBUG defined. If you prefer debuggable binaries, set this value to 1.

RTSINGLEPROC

The default configuration, set to 1, compiles the runtime library with no multiprocess support. If you want multiprocess functionality, you can enable this by explicitly setting this value to 0.

STANDALONE_TESTAPP

The default configuration, set to 1, builds the TestApp as a standalone application. When set to 0 the TestApp is built as a multiprocess application.
The STANDALONE_TESTAPP variable is affected by the value of RTSINGLEPROC. If RTSINGLEPROC is 1 and STANDALONE_TESTAPP is 0, this is an invalid combination and STANDALONE_TESTAPP will automatically be set to 1.

S2SCOPTS

The STRIDE build process that produces the database and Intercept Module for the diagnostics tests relies on target settings. These settings are passed as options to the stride compiler and are most conveniently stored in an options file. We provide a default options file with target settings that are appropriate for x86 Windows targets with Microsoft compilers -- this file is SDK\Windows\settings\stride.s2scompile in the SDK distribution.

We recommend that you make a copy of this file and adjust the settings as appropriate for your target. You can then set this variable - S2SCOPTS to the path to your settings file. This will cause the make process to use the specified target settings options instead of the default one provided in the SDK. This same settings file should ultimately be used for the STRIDE build integration with your application source code.

S2 Build Flags

The target Makefile sets the following Build Tool flags:

S2_BIND_FLAGS = --starting_suid=7000
S2_IM_FLAGS = --disable_access_class

The s2sbind and s2sinstrument flags are combined so that the test application only registers for test message IDs that are created in a higher range so that it doesn't conflict with other application processes.

Makefile Targets

The makefile included with the SDK supports the following targets:

all

builds the runtime library and daemon

library

builds the runtime library

daemon

builds library and--if RTSINGLEPRC is not zero--the STRIDE daemon

im

builds the STRIDE database and generates IM files

testapp

builds library, im and instrumented test application

clean

removes all generated files

Target API (stride.h)

The Windows SDK provides a simplified application interface for initializing the STRIDE subsystem and starting STRIDE messaging and IM threads. The API includes the following routines:

srBOOL strideInit(const strideIO_t * io)

This function initializes the STRIDE subsystem. The IO configuration is passed in as an argument. If this argument is NULL, then the process will attempt to attach to an already running runtime application (daemon) using shared memory for IPC. This function should only be called once per application and should be match with a call to strideUninit().

srBOOL strideUninit(void)

Terminates any threads that have been started with this API and uninitializes the STRIDE subsystem.

srBOOL strideCreateThread(strideThreadFunc_t entry, const srCHAR * name, void* param)

Creates a thread to be managed by the STRIDE subsystem. Threads created using this routine will be sent a palSTOP_EVENT notification (available from palWait) and should respond promptly to this event. The name parameter is used primarily for logging purposes.

strideCreateIMThread(name)

This is a macro that wraps the invocation of strideCreateThread() for intercept module entry point functions. Only the IM name must be provided.

void strideStopThread(srDWORD id)

Signals a thread to stop (sends palSTOP_EVENT) and joins it.

void strideExWaitForExit(void)

This function can be called by the main application thread to block until the application is shutdown.

This function is optional - if you block some other way (e.g. create the application's message loop) do not call this function.

void strideExSetupMainWindow(const char* name, void* instance, int showCmd)

This function is called by applications to create the main window of the process. The first argument specifies a name of the window. The second argument specifies the handle to the current instance of the application. And the third specifies how the window is to be shown.

This function is optional - if you create the application's main window do not call this function.

Target Integration

Here are a few examples of how to integrate the stride API into your application.

Note: the following code assumes that the intercept module was generated with a name of myintercept. Change all references to that name in your code to the chosen intercept module name.

Standalone Application Integration

The following code demonstrates how to integrate your application with the STRIDE Runtime. Your application might require other logic at startup - you can integrate the following calls according to your needs. Note that this code initializes the STRIDE subsystem and assumes a single standalone process that creates the STRIDE system threads as well as application threads.

#include <windows.h>
#include <tchar.h>
#include <stride.h>
#include <myinterceptIMEntry.h>

#ifdef _CONSOLE
int _tmain(int argc, _TCHAR* argv[])
{
#else   /* _CONSOLE */
int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nShowCmd)
{
#endif  /* _CONSOLE */

    /* initialize the STRIDE subsytem using default I/O */
#ifdef __cplusplus
    strideIO_t io = {strideIO_t::strideDEFAULT};
#else
    strideIO_t io = {strideDEFAULT};
#endif
    if (strideInit(&io) != srTRUE)
        return -1;

    /* start all IM threads */
    if (strideCreateIMThread(myintercept) != srTRUE)
        return -1;

    /* application code here */
    ...

    /* stop all IM threads and uninitialize STRIDE subsystem */
    strideUninit();
    return 0;   
}

This sample code assumes you have generated your Intercept Module with a prefix name of myintercept.

NOTE: If you need to provide additional message processing threads, you can call strideCreateThread() for each additional thread that you wish to add (this must be called prior to your application code).

Multiprocess Application Integration

This code demonstrates how to integrate your application with the STRIDE Runtime in multiprocess mode. In this mode, the pre-packaged strideDaemon runs simultaneously with the application and provides the STRIDE IO and runtime thread initialization. The host communicates with the application process through the strideDaemon (or another STRIDE IO process). In this sample, the only difference with the preceding sample is the call to strideInit which, in this case, specifies no IO parameters which indicates to the API that the communication and runtime threads should not be started.

#include <windows.h>
#include <tchar.h>
#include <stride.h>
#include <myinterceptIMEntry.h>

#ifdef _CONSOLE
int _tmain(int argc, _TCHAR* argv[])
{
#else   /* _CONSOLE */
int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nShowCmd)
{
#endif  /* _CONSOLE */

    if (strideInit(NULL) != srTRUE)
        return -1;

    if (strideCreateIMThread(myintercept) != srTRUE)
        return -1;

    /* application code here */
    ...

    strideUninit();
    return 0;   
}

Kernel Module Integration

The following code demonstrates how to integrate your kernel space module with the STRIDE Runtime. Your module might require other logic at startup - you can integrate the following calls according to your needs.

NOTE: You need to also have an active user space STRIDE enabled application (see above) that runs the core STRIDE Runtime and IO services. That application must also link to the STRIDE Runtime built with -DPAL_KERNEL_SHM_SIZE=nnnn, where the "nnnn" matches the value defined below.

#include <Wdm.h>

#if defined(STRIDE_ENABLED) && STRIDE_ENABLED
#define PAL_KERNEL_SHM_SIZE 0x100000 /* value should match whatever is defined in the "user" STRIDE Runtime */
#define __KERNEL__
#include <stride.c> /* that's right, directly include the source file */ 
#undef __KERNEL__
#endif /* STRIDE_ENABLED */

NTSTATUS DriverEntry(
  __in  struct _DRIVER_OBJECT *DriverObject,
  __in  PUNICODE_STRING RegistryPath
  )
{
...
#if defined(STRIDE_ENABLED) && STRIDE_ENABLED
    strideInit(NULL);
#endif /* STRIDE_ENABLED */
...
    return status;
}

VOID DriverUnload(
  __in  struct _DRIVER_OBJECT *DriverObject
  )
{
#if defined(STRIDE_ENABLED) && STRIDE_ENABLED
    strideUninit();
#endif /* STRIDE_ENABLED */
    ...
}

You don't need to compile any other source nor to link to any other library. Just make sure you pass the following extra flags to your compiler:

C_DEFINES = $(C_DEFINES) -DSTRIDE_ENABLED=1 -DSTRIDE_STATIC
INCLUDES = $(INCLUDES); $(STRIDE_DIR)\SDK\Windows\src; $(STRIDE_DIR)\SDK\Runtime

Windows PAL

PAL Configuration (palcfg.h)

The following parameters can be configured in palcfg.h to effect the behavior of the compiled pal source files.

PAL_DEFAULT_DEVICE_NAME

default IO device to use.

PAL_MAX_THREADS

max STRIDE integrated threads that can be managed by the STRIDE API.

PAL_MAX_TIMERS

max STRIDE timers that can be active in the system.