INtime SDK Help
Local Node Configuration library
INtime SDK v6 > About INtime > Other system libraries > Local Node Configuration library

This section describes the Local Node Configuration (LNC) library revision 2.0, a set of functions that a Windows application can use to get and set INtime parameters on an INtime for Windows system. It is an enhancement to the original LNC implementation, which is still available for legacy application purposes.

Introduction

The parameters for INtime for Windows local nodes are spread out throughout the Windows registry and other locations. There are many dependencies between parameters and in some cases, changing a parameter requires restarting the INtime kernel or the Windows system. Wherever possible dependency is handled by LNC, so the client application does not need to remember that.

LNC initially offered a single interface for getting and setting parameters. In revision 2.0, sets of functions are introduced that deal with a group of parameters, as described in the following subsections. Setting a parameter may cause other parameters to be changed as well.

The change of one or more parameters may require a restart of the INtime kernel or of the whole system. LNC maintains the need for such restarting.

Because many parameters are contained in registry keys that require administrator rights to change, LNC assumes that the client has administrator rights.

LNC is used by the standard INtime Configuration Utility (inconfig.exe).

The LNC API is available in an ASCII and a Unicode version for Windows XP and later systems, both in an x86 and an x64 version.

Sections and parameters

Parameters are grouped in sections; in some cases these sections exist as recognizable parts in a file or in the registry, in other cases parameters in one section may be located in different places. Also there are parameters that have more dimensions than just sections and parameters.

Some of the sections and parameters that can be read and written by LNC have a symbolic name (implemented as a 32 bit number), others are defined by a string. When section and parameter names are compared, the case is ignored.

A multi string value is stored as one or more character strings, where each string is terminated by a zero character and an extra zero character is placed at the end.

System parameters (Sys functions, formerly section 1 = LNCS_SYSTEM)

A group of functions is dedicated to getting and setting system parameters; the function names include the term ‘Sys’. The parameters apply to the whole system. System parameters are identified by fixed numbers; there is only one section.

Kernel parameters (Ker functions, formerly section 2 = LNCS_KERNEL)

Kernel parameters are specific to the INtime kernel on a particular local node. The function names include the term ‘Ker’ and a node name must be specified. Kernel parameters are identified by fixed numbers. There is only one section.

Network parameters (Net and Nic functions)

Network parameters control the use of network hardware and TCP/IP options; they are node specific. The function names include the term ‘Net’ or ‘Nic’ and a node name must be specified. There are sets of functions to deal with general network parameters, with NIC parameters and with address and route information.

Advanced parameters (Adv functions)

Advanced parameters are intended for the expert user and are always node specific. The set of advanced sections and parameters is not fixed and can be extended. Advanced sections and contained parameters are identified by strings. Each parameter has a fixed set of properties which are identified by numbers; the value property must be present, the other ones are optional. The function names include the term ‘Adv’ and a node name must be specified.

Auto-load parameters (Load functions)

Auto load parameters define what applications are loaded automatically when the INtime kernel starts and are node specific. The set of auto-load applications can be extended and reduced. The function names include the term ‘Load’ and a node name must be specified. An auto-load application is identified by an application name. For each application a number of parameters can be manipulated.

Restart handling

Changing a parameter may require restarting the INtime kernel or the whole system. LNC records the need for such restarting in a volatile key of the registry (‘volatile’ means that the value is lost on system restart). Since the restart value is kept in the registry, it is carried from one LNC client to the next one.

The restart value is increased when a parameter change requires a higher level of restarting. The restart value is only reset when a restart is performed by LNC. Also, because the restart value is kept in a volatile key, system restart clears the restart value.

LNC does not perform a restart automatically but instead offers a function to do that. The restart bookkeeping is not intended to be most optimal, but instead tries to be safe. For example, changing a systems memory mode from excluded to non-paged pool, and then back again will indicate that a system restart is required.

Using the LNC library

All functions defined below require including the header file lnc.h and linking the library lnc.lib. At execution time, the file lnc.dll is required (which itself requires ntx.dll). The functions are described in alphabetical order.

If a function in this library is called by more than one thread at a time, the client should take care of mutual exclusion; none of these functions are safe for multi-threading.

For function parameters, the notation (in) means that value is an input parameter; (out) means the parameter is a pointer and the function may write into the variable pointed to; (in/out) means the parameter is a pointer to a variable that must have been set before the call and that may be written to by the function.

Some functions return a string by setting a pointer of which the caller passes the address; such a string is contained in an internal LNC buffer and is only valid until the next LNC call. For efficiency, it is allowed to pass such a pointer to another LNC call, so copying is not required in such a case.

Some functions are indicated as deprecated: these functions remain available for backwards compatibility, but are not recommended for new applications.

See Also