Included in this directory is a set of programs that allow a Windows NT
POSIX process to be able to make RPC requests to a WIN32 server. This is to
allow access to system facilities such as command execution that is not
available in the native Windows NT POSIX environment.

These programs can be used to run the compiler from a make or shell program,
start and wait for WIN16, DOS, WIN32 or OS/2 applications, or provide an
interface to the WINSOCK API in order to send remote communications requests
to an X-server. These functions could be used as a transport to allow the
X Windows Client libraries to be supported under the POSIX subsystem. The
X-server could be on a remote UNIX workstation over WINSOCK, or could be a
local WIN32 X-server implementation.

Users are encouraged to extend the functions and feed back client and server
libraries that expose WIN32 API's to POSIX client applications. I do
recommend implementing RPC's that mimic existing UNIX functionality that is
missing from the POSIX subsystem, as opposed to just 'exposing' native WIN32
services to POSIX applications. This will be in keeping with Windows NT
guidelines in not mixing the API's of different programming environments.

An example of this approach would be to implement the X-libraries and have
the RPC's send X-wire protocol requests to an X-server running on WIN32. This
is much more preferable than exposing WIN32 GDI routines to the POSIX subsystem
through RPC's. This will allow a program that conforms to the UNIX API
environment to talk to its graphics display in its native manner, and not
be developed into a 'mutant' that is half UNIX, half WIN32. I have attempted
to demonstrate this by emulating the functionality of the UNIX 'system()'
function, as opposed to exposing WIN32 'CreateProcess()', as an RPC. The
WIN32 server implements this using CreateProcess(), but this should be
as transparent as possible to the UNIX program.

Compiling and using the programs:

  In order to compile the programs, you must install the Micrsoft Windows NT
SDK from October 1992. You have to setup the POSIX environment as documented
in the release notes. Once that has been done, doit.bat will run nmake on
all of the supplied makefiles for each program. A list of each program and
what it does follows:

win32srv.c:	Main WIN32 server program. It automaticly starts the
		psxagent program.

psxagent.c:	POSIX 'agent' program that passes RPC requests received from
		POSIX named pipes to the WIN32 server.

rpcclt.c:	Library of functions that is linked with POSIX client programs
		to request RPC services of the WIN32 server. It knows how
		to establish a connection with the psxagent process.

psxclt.c:	Example POSIX client that does a NULL RPC and runs a command
		line.

rpctime.c:	Example POSIX client that measures RPC performance.


In order to have the WIN32 server and the POSIX client output to the same
console window, start the win32srv program with "start /b win32srv". This
will return the prompt to you with the win32srv and psxagent programs running
in the background. POSIX client applications may now be run from the command
line and execute DOS, WIN16, WIN32 or OS/2, (or even POSIX) applications
through the RPC facility. Output from these subprograms will go to the current
console. If you do not use the /b parameter to start, console output from
applications started by the WIN32 server will go to a new window separate
from the POSIX client. You can also just run win32srv without start, but
will have to switch to a new window in order to run POSIX client applications.


Concerns:

One area of concern is performance. I get 104 round trip NULL RPC's
per second on my 33MHz 80386. This is approx. 10 ms per RPC round trip.
For remote command execution, or even X-Lib requests, this is not too bad.
But for other more timing sensitive system services, this might be to slow.

A last area of concern is that only WIN32 calls that return results to the
program, or perform some visible action such as launching a command line
can be run. Any WIN32 calls that effect the calling process such as
FileMapping() would only effect the WIN32 servers address space, and not
the POSIX programs.

Possible Improvements:

 Once possible improvment is to implement the run time transport library
for MS (DCE) RPC so that a more standard client-server application may be
developed. I have not had the time to tackle this right now, and this could
also be limited by not having select() or poll() available to the POSIX
agent process who must pass the data between the POSIX client and WIN32
server. Unless this program knows the amount of data in a given request, it
could block waiting to send more data while ignoring the reply. This could
possibly be handled by having the POSIX agent use fork() to have a read-side
and a write-side process.

 A final improvment would be to support multiple named pipes so that more
than one POSIX client may make requests at any given time.


Please send comments to:

			John Richardson
			CompuServe 70541,672
			Internet jr@sni-usa.com

Also keep me abreast of any UNIX functions others have written for the
Windows NT POSIX subsystem.