yes, it might be a good time. as wrote in the other thread, i was able to compile an start nsd with very little windows experience. Be aware, that runnning "nsd.exe -c" does not mean that all of nsd is really running.
-g PS: my own time budget will be reduced significantly for the next weeks. Am 08.10.14 18:50, schrieb Maurizio Martignano: > Dear Andrew and Gustaf, > In due time, when you both are confident on the status of Naviserver > on Windows, I would try it inside my Windows-OpenACS distribution. > > First of all I would try it in few installations running on the machines I > have in my offices, then once I see it they are running fine and everything > I have now still behave the same, I would make the new version of the > distribution available. > > Is that OK with you? > > Maurizio > > > -----Original Message----- > From: Andrew Piskorski [mailto:a...@piskorski.com] > Sent: 08 October 2014 18:39 > To: naviserver-devel@lists.sourceforge.net > Subject: Re: [naviserver-devel] Naviserver hangs on Windows > > On Wed, Oct 08, 2014 at 09:32:56AM +0200, Gustaf Neumann wrote: > >> the advantage of approach 2 (disable mutex timings, use ) is that >> this works for 32bit and 64 bit, while (1) works most likely only for >> 64bit (if i look at the constant). > No, I'm confident that the approach using EPOCH_BIAS works just fine on > 32-bit Windows, because in AOLserver 4.0.7 and 4.0.8 that is the ONLY > implementation of Ns_GetTime on Windows, and I ran those versions of > AOLserver for years on Windows XP 32-bit. > > Calls to Ns_GetTime() are very common, so AFAICT, for those AOLservers to > work at all, that EPOCH_BIAS code had to be working fine on 32-bit Windows > XP. The only other alternative is that AOLserver was somehow magically > calling an entirely different function instead of Ns_GetTime(), which I > judge as very unlikely. > >> The mutex timings is an additional feature in naviserver, so at least >> for the time being, one can life without that.... and with the deeper >> knowledge, we might be able to activate this later again. > Ah, I didn't realize that. I should turn them back off for Windows in my > fork then? > >> The problem seems to be: DllMain() calls certain functions before the >> normal entry point main() is called, which initializes tcl etc. The >> Windows man page [1] says: > Interesting. And of course DllMain() only exists on Windows. But, why do > we need DllMain() at all? I assume we DO need it of course, I just don't > understand the design differences between Naviserver's pthread and winthread > support. Both Posix and Windows use Nsthreads_LibInit(), but DllMain() > seems to be an extra layer not present for Posix. > >> > changing the Ns_Time.sec (in nsthread.h) to be time_t rather than >> long > fixes nearly everything. >> >> The reason, naviserver uses 2x long in Ns_Time is probably due to Tcl, >> using: > AFAICT, using long is just wrong, and Tcl and Naviserver both should have > been using time_t for many years now. I'm not sure when time_t was invented > and standardized, but since then it's been what Unix and Windows both use. > > So what am I missing? Why did the Tcl maintainers stick with long for > Tcl_Time.sec? It could just be a holdover from before time_t existed or > really mattered, but perhaps they had a better for keeping it as a long. > >> So at least, when using Tcl_GetTime(), which returns the time as >> Tcl_Time, everything should be fine. Note, that in your native time >> implementation, you assign to timePtr->sec with (time_t), which might >> be part of the problem you are experiencing. > Could be. I will try the no-mutex-timings and Ns_GetTimeFromTcl() approach > again, this time with Ns_Time.sec changed back to type long rather than > time_t. > >> Probably, i should get a windows installation running, but the setup >> costs are quite high in terms of time and lack on windows-knowlege on >> my side. > Yeah. Maybe the Docker stuff Stephen showed us would make it easier? > > Definitely see the notes I sent a while back on exactly what Microsoft > software to install. All the main stuff you need is available for free but > figuring out WHAT you're supposed to install is not easy. > > Btw, if you do go that route, be aware that I am using > nmake -f Makefile.win32 > for building and cleaning, but NOT for installing Naviserver. I have not > debugged the install commands of those two *.win32 makefiles at all, because > I have my own old Tcl script ("win32-install-nsd.tcl") for intalling on > Windows, which I was able to quickly adapt to Naviserver. > > If you want that install script let me know. I haven't added it to > Mercurial yet because it is in CVS, and I'd like to nicely retain its full > history it, but haven't looked up how to best do that yet. > > -- > Andrew Piskorski <a...@piskorski.com> > ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
