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 foreverwhich 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.
WJR In my case, I not creating a Starkit, I'm creating the service using the Tcl script. I understand how to include packages using when creating Starpacks, but I'd prefer not create a Starpack if I don't have to. I guess what I'm not understanding is how to correct the auto_path: Do I need to do this in httpd.tcl (as there is an auto_path setting there), or do I somehow do it within tclsvckit.exe?
WJR JH kindly supplied instructions that addressed the problems I was having: Use tclsvc84.exe instead of tclsvckit.exe (which is apparently going away in the next release of the Tcl Dev Kit). Here's what you need to do:
- Uninstall all services using the Tcl Service Manager.
- Remove tclsvckit.exe. I simply renamed it to tclsvckit.tmp.
- Reinstall services using the Tcl Service Manager.
JH TDK3 will use its tclsvc84.exe executable by default, so this will not be an issue. That means TDK Tcl services as scripts will have the same auto_path behave as the regular Tcl installation. Starpacks as services (using TDK's base tclsvc kit) will need to be sensitive to the restricted auto_path (they should be fully self-contained).As for the logs and such, this is something you have to correct over time.
WJR The log file path mentioned above was fixed by specifying an absolute path to the logfile directory in the TclHttpd config file.
MHo Take a look at Tclhttpd Winservice!
[JKM] has tclhttpd3.5.1 running as a service with instsrv.exe and srvany.exe and it has worked very well. Name the service with "instsrv NameOfYourService C:/Path/To/srvany.exe". Add "tclsh C:/Path/To/TclWebServer/tclhttpd3.5.1/bin/httpd.tcl –port 2010" to the registry. Start the service. See http://support.microsoft.com/kb/q137890/
for detailspd 2017/3/26 This still works on Windows 10. Download link for Resource Kit