I'm looking at the possibility of turning [Tclhttpd] into a [Windows] (NT, 2000, etc.) service. Currently, I'm using [ActiveState]'s Tcl Dev Kit to facilitate this. Does anyone have experiences or advice to relate on this topic?

- [WJR]
----

[JH] This is possible starting with [Tcl Dev Kit].  You have to watch out for the various special handling that Windows services require.  If you have timeout startup issues, you need to look for bare

        vwait forever

which is typical in server scripts to start the event loop, but must not exist for NT Tcl services.  This is correct:

    if {![info exists tcl_service] && ![info exists tk_version]} {
        vwait forever
    }

For those wanting to create an actual starpack (single-file executable) out of tclhttpd on Windows, you will need [Tcl Dev Kit] 3.0, which includes a base kit designed for use as an NT service.

----
[WJR] For Tclhttpd 3.4.2, 'vwait forever' is line 328 in tclhttpd3.4.2/bin/httpd.tcl. After I made this change, the service worked like a charm. In my case, I'm using version 2.6.1 of the Tcl Dev Kit, using the httpd.tcl script as the service (I'm not using a Starkit). Some things to look into:

   * In bin/tclhttpd.rc, my logs should be written to ../logs, but for some reason they're being put into C:\WINDOWS\logs
   * I had to put the Tcllib dir on the same level as the Tclhttpd dir.
   * CGI scripts don't seem to work. Windows event log errors are generated.

----

[WJR] I seem to be having difficulties with [auto_path]. As I mentioned above, I had to put Tcllib in the same directory as Tclhttpd. The Tcllib libs are found OK, but I want to use other libraries like Tclx, etc. I try to append the appropriate directory in httpd.tcl's auto_path, but that doesn't seem to help. It seems that the Tcl Dev Kit Service component may set it's own auto_path, but I'm just guessing at this point.

I should also note that this problem doesn't occur when I run the same Tclhttpd through Tclsh or Wish.

----

[JH] All base kits set their own auto_path for system portability so that they only look inside themselves by default.  If you use TclApp, it creates a starpack that should allow you to simply ''package require mylib'' without any auto_path manipulation.  If you place the packages inside the starpack yourself, you will need to correct auto_path accordingly.  TclX is known for not liking being moved around though, and I am fairly sure this is an error in the way the package is created.  If it continues to cause problems, this must be examined in detail.