Is a prototype for a function that enables a low level component to execute its own startup code.
#include <netware.h>
int _NonAppStart (
void *NLMHandle,
void *errorScreen,
const char *commandLine,
const char *loadDirPath,
size_t uninitializedDataLength,
void *NLMFileHandle,
int (*readRoutineP)(
int conn,
void *fileHandle,
size_t offset,
size_t nbytes,
size_t *bytesRead,
void *buffer),
size_t customDataOffset,
size_t customDataSize,
int messageCount,
const char **messages);
(OUT) Points to a load definition structure, which the NetWare Loader maintains for each NLM. It contains essential pieces of information such as the NLM name, type, address space, and memory locations for code and data. It should never be accessed for read operations because its definition must be free to change.
(OUT) Points to the screen that the NLM can write messages about any problems that it encounters while loading. In NetWare 5x, this is the System Console screen. In NetWare 6x, this is the Console Logger screen.
(OUT) Points to the string with which the NLM was loaded. It is a string, not an argument list such as argv from main, and it remains constant through out the existence of the NLM.
(OUT) Points to the initial current working directory of the NLM. This is the path to the directory containing the NLM that is being loaded.
(IN) Specifies length you need for the data which is static or global for your NML. If you need the memory zeroed out, you can
Link to LibC libcpre.o
Use a switch (such as the CodeWarrior mwldnlm.exe) to zero it out.
Discover the starting offset of the address with a global variable from the compiler and zero it out yourself.
NLM start-up code rarely uses this parameter.
(OUT) Points to the NetWare file handle that was used to open the NLM binary file. If you use the readRoutineP function to read data from your NLM, you use this parameter for the fileHandle parameter.
(OUT) Points to the read function that an NLM should use to read any data directly out of the binary file. LibC uses this function to read NLM information such as description, stack size, thread name, screen name, and other information placed in the NLM at link time.
The parameters for the readRoutineP function are described in the Remarks section.
(OUT) Specifies the start of the custom data area.
(IN) Specifies the size of the custom data area. Any kind of custom data can be placed in this area. Most NLM applications do not use the customDataSize and customDataOffset parameters.
(IN) Specifies the number of messages.
(OUT) Points to the messages. Most NLM applications do not use the messageCount and messages parameters. They use ReturnMessageInformation to retrieve their messages.
If the load is successful, returns 0; otherwise, returns nonzero to signal the NetWare Loader that its initialization sequence has failed.
The _NonAppStart function provides a driver, protocol stack, library, or other low-level component with the ability to write its own startup code. In other words, if the component links libcpre.o and configures the linker via options START, EXIT and CHECK to use the LibC entry points (_LibCPrelude, _LibCPostlude and _LibCCheckUnload), the driver’s _NonAppStart and other functions will be called just as if supplied directly to the linker.
You should specify _LibCPrelude to the linker via the START option.
Typically, you will not use any but the first four arguments to this function.
The readRoutineP function has the following parameters:
(IN) Specifies the connection ID of the NLM. Most NLM applications run on connection 0 unless they have used create_identity to establish a different connection ID.
(IN) Points to the NetWare file handle that was used to open the NLM binary file. The NLMFileHandle parameter of the _NonAppStart function returns this value.
(IN) Specifies the place to start the read operation.
(IN) Specifies the maximum number of bytes to read.
(OUT) Points to the number of bytes read.
(OUT) Points to the buffer that receives the data.