nxExportInterfaceWrapped

Wraps and exports a named symbol externally.

Library:LibC
Classification:Novell
Service:NetWare Platform

Syntax

  #include <nks/netware.h>
   
  int nxExportInterfaceWrapped (
     void        *funcAddr,
     int          stackWords,
     const char  *funcName,
     void       **reference);
  

Parameters

funcAddr

(IN) Points to the address of the function that is to be exported.

stackWords

(IN) Specifies the number of DWORDs that will be used by parameters to the exported function. For example, double arg would need two.

funcName

(IN) Points to the name for the exported function. If it points to a non zero-length string, the resulting wrapper pointer will be exported publicly by that name.

reference

(OUT) Points to a cookie for the exported function. A pointer to the wrapped function will be returned on success.

Return Values

Returns zero upon success or an error on failure:

Decimal

Hex

Constant

Description

5

0x05

NX_ENOMEM

Insufficient memory was available to wrap the function.

9

0x09

NX_EINVAL

The context is invalid.

66

0x42

NX_ENOSYS

Function cannot be exported due to an error from NetWare ExportPublicSymbol.

105

0x69

NX_ENOCONTEXT

No NKS context is present. Perhaps the function was called at interrupt time.

Remarks

The nxExportInterfaceWrapped function wraps the function passed as funcAddr and returns a pointer to that wrapper in reference.

At unload time, the library or service that exported the function must clean up the export by calling nxUnexportInterfaceWrapped. Otherwise, NetWare returns a leaked memory message.

On NetWare, when a function is to be used by outside callers, you must set up the function to ensure proper NKS virtual machine (VM) context as the code is executed. For example, you should not register callback code with a service so that when NKS file I/O functions are called on a thread they go looking for a file descriptor. (It would be even worse if the function found that its file descriptor corresponds to a completely different file in the VM to which the calling thread belongs.)

If funcName is nonzero and not of zero length, the address of the wrapper function (as specified by funcAddr) will be exported by using ExportPublicSymbol. When called, the execution thread is fixed up, or adopted into, the registering VM. When the thread exits, the fix is properly reversed.

If you wish to register a callback with another service (such as TCP/IP), call nxExportInterfaceWrapped and use reference as the function pointer to the callback to be registered. In this instance, you would pass zero to funcName because other VMs will not need to call your callback function.

If you want callers to have access to your application or library-like body of code (to allocate memory, open files, or perform I/O exclusively to the library or application), call nxExportInterfaceWrapped by passing a string to be exported into the NetWare loader tables. The passed string can be prefixed.

When you allow your function to be publicly known, an application cannot autoload another application or a library that will provide the first symbols, because the loader cannot know of the symbol before the second symbol is loaded. If an import file statement is made on a symbol that results in an explicit symbol dependency, the code that provides the dependency to the system must be successfully loaded before it encounters the dependency. The second application or library cannot explicitly export the symbol using the link export file because NKS must create the wrapper around it before it can be used. NKS will not use the symbol name to replace what is already in the symbol table.

The function wrapper is machine code that saves the calling thread's VM pointer, replaces the VM pointer with the VM of the wrapper service or library that is calling nxExportInterfaceWrapped, and calls the function. Upon return, the original VM is restored to the thread.

See Also