Maurizio: The only important outputs of the Windows build process are nsd.exe and all modules *.dll files.
If this is the case, the windows build is incomplete. In an installation including nsproxy, there should be three binaries in the ns/bin directory:
- ns/bin/nsd.exe
- ns/bin/nsproxy.exe
- ns/bin/nsthreadtest.exe
On unixoid platforms the filename do not contain the .exe suffix. The last one is for testing.
It should not be complicated to produce an nsproxy executable under windows. As a reference, the nsproxy executable program is linked as follows:
gcc -L../nsthread -L../nsd -L../nsdb -o nsproxy nsproxy.o libnsproxy.dylib -lnsthread -lnsd -L/usr/local/ns/lib -ltcl8.6 -prebind -headerpad_max_install_names -Wl,-search_paths_first -L/usr/local/ns/lib -L/opt/local/lib -lssl -lcrypto
The nmake-file for windows should be extended to contain a similar build rule.
Concerning the "renaming" issues: Where are windows-procs.tcl coming from? This is not part of OpenACS. I was talking about OpenACS, where "exec" is redefined in acs-tcl/tcl/proxy-procs.tcl
There are certainly many ways to address to "exec" problem in Frank's case. My recommendation is to stay away from renaming and to aim for a solution, which is as close as possible to the maintained part of OpenACS. The advantages of nsproxy (probably incomplete)
- when nsproxy workers are started early, no memory bloat on execs (important, when running on machines with little memory)
- address the race-conditions, when a tcl script changes the working directory and issues a command in this directory
- allows to specify environment variables for the exec environment that can be different to those of the main process
- allows to set timeouts and many more to improve resiliance
But maybe, it is not worth the effort to get nsproxy running under windows.
