Created: March 20, 1992
ABSTRACT
This article contains common programming questions received from MicrosoftÒ LAN Manager developers.
Question:
I am trying to use the NetShareAdd API function from MS-DOSÒ to add a share on a remote server. The structure I pass to NetShareAdd includes pointers to ASCIIZ strings. To keep all the data in one place, I appended the data for these strings to the end of the structure. (That is, the structure and the strings it addresses are in one physical buffer.)
When I call NetShareAdd, the buffer length I supply is the length of the structure plus the length of the appended strings because my buffer includes both the strings and the passed structure. However, the call returns ERROR_INVALID_PARAMETER (number 87).
Answer:
This characteristic applies to all OS/2Ò LAN Manager Add or SetInfo functions. OS/2 LAN Manager uses an optimizing technique to minimize the amount of data actually sent on a remote API call (a call that is performed on the server).
Any pointers in a passed structure that point to data within the structure itself are set to NULL. Because the code that transfers the API function handles many APIs, OS/2 LAN Manager determines whether to set the pointers to NULL by checking whether any pointers point to an area within the beginning and the end of the structure, as determined by the passed structure pointer and the buffer length field. Because your buffer length includes more than the structure length, OS/2 LAN Manager believes that the pointers within the structure are pointing into the structure itself and therefore sets them to NULL. This causes the parameters to become invalid. Other errors may also occur.
The proper value to supply for the buffer length parameter of Add and SetInfo API functions is:
sizeof(struct xxxxx)
where xxxxx is the name of the structure whose pointer is being passed.
Note:
This applies to remote API functions only. For more information, see Chapter 1 of the Microsoft LAN Manager Programmer’s Reference.
Question:
In LAN Manager version 2.0, all LAN Manager API functions are included in the MS-DOS DOSNET.LIB programming library and in the Microsoft WindowsÔ NETAPI.LIB programming library. Does this mean that all API functions are now supported by MS DOS?
Answer:
All API functions now appear in a listing taken from the MS-DOS libraries to ensure that all programs link without unresolved external errors and that the program runs correctly. Functions that MS-DOS LAN Manager does not support link in stub code to return error code 50, ERROR_NOT_SUPPORTED. The API functions that are not supported on MS-DOS workstations are listed below. In addition to these, stub code has been added for the OS/2 functions DosClose, DosOpen, DosRead, and DosWrite.
Functions that are not supported by MS-DOS in LAN Manager version 2.0 include the following:
NetAccessCheck
NetAlertRaise
NetAlertStart
NetAlertStop
NetAuditWrite
NetErrorLogWrite
NetRemoteExec
NetServiceStatus
NetUserValidate2
NetBiosClose
NetBiosEnum
NetBiosGetInfo
NetBiosOpen
NetBiosSubmit
The Microsoft LAN Manager Programmer’s Reference is the definitive reference regarding which functions MS-DOS supports. Each API description lists the operating systems that support the function and explains whether the function is supported locally or remotely or both locally and remotely.
Stub code was added because in past versions customers simply received “unresolved external” references from these functions. In many cases, rather than replacing the function with its MS-DOS equivalent, they got rid of the error by linking in API.LIB, the OS/2 BIND library. This resolves the error, and the program runs; however, the functions return inconsistent and ambiguous error messages. Including the stub code in the libraries gets rid of this problem and returns a clear error from the function.
Question:
I have written a LAN Manager version 2.0 service that tries to launch a second process (that is, run another EXE file). However, the DosExecPgm call returns ERROR_FILE_NOT_FOUND, even though the EXE I’m trying to start exists in the same directory as my service EXE. Why isn’t my second EXE found?
Answer:
When LAN Manager version 2.0 launches a service (for example, in response to the net start command), it passes to the service no explicit arguments and no environment variables (the argument and environment pointers in the DosExecPgm call are both set to NULL). Thus, the new process inherits the environment established by CONFIG.SYS. If the EXE for your new process cannot be found in the path entry in CONFIG.SYS, your DosExecPgm call fails. The following are four possible solutions:
1.Insist that users place your EXEs in the same directory and hard code the full path.
2.As part of the installation of your service, have the user add the location of your EXEs to the CONFIG.SYS path entry.
3.Extract from the argv[0] variable, passed to your service by OS/2, the path of your first EXE and use it to build the full path for the EXE you’re attempting to launch. This works only if all of your EXEs exist in the same directory.
4.Add a keyword to LANMAN.INI that supplies the necessary path for your service.
Of these solutions, 1 and 2 place unreasonable restrictions on the user. The second solution can also cause problems if other EXEs in the path have the same name as yours. The fourth solution is good if your service needs to create temporary files or other files that the user may not want in the same directory as the EXEs (because the user may have read-only or execute-only privileges on that directory). Although keeping all your EXEs together is probably best, doing so is not the best solution when attempting to start child processes.
The third solution is the best and is used for standard LAN Manager version 2.0 services to launch child processes. You can safely use argv[0] to determine your service’s “home” directory because it always contains the full path of the EXE that was started. The way LAN Manager issues the DosExecPgm call guarantees this. Because the user must keep all EXEs in a single directory, this places the least number of restrictions on the user.