Hi Ibrahim, that's a very good hint: AFIKT, all the modules used already the same /M* options. However, i've changed the runtime library option from /MT* to MD* (multi-threaded version) and a quick test (fildes to windows handle conversion) indicates that the strange behavior is gone. Nevertheless, using the ns_ prefix for the OS-interface is still beneficial for handling of different prototypes on different operating systems and leads to a better abstraction than the macros, which were a mere measure to reduce windows compiler warning (to use ISO names _open, _close etc.).
This small change will certainly help people to keep their hair on their head, when they try to adapt more naviserver modules for windows.... all the best -g [1] https://bitbucket.org/naviserver/naviserver/commits/08680db31a71a6c8d512a6f7e7de64303c5ac262 On 17.11.14 10:52, Ibrahim Tannir wrote: > Hi Gustaf, > > Just a hint: it is absolutely essential that all the > modules on Windows be compiled with the same model. I use > -MD or -MDd. Otherwise, each of the modules compiled with > a different model will have it's own global variables, > environment and memory segment and the two modules will > not interact even if they share the same global variables. > It goes even further with whether the modules use MFC and > common runtime or not, which Microsoft libraries they will > include. That is why I avoid using make files and let > Visual Studio do all the work and I make sure that all the > modules have the same setup (see attached file). (I have > shared my project files, all of which I created myself, > with someone from the community recently). > > Hope this helps, > Ibrahim > > > > On 17-Nov-14 10:36, Gustaf Neumann wrote: >> Dear Andrew and all, >> >> Over the weekend, I invested some more time into the windows >> port and got a better understanding of the logging issue >> (a write() >> operation succeeds inside nslog.c, but the identically >> operations >> inside driver.c does not work; "not work" means, that the >> write >> operation succeeds (i.e. reports the written number of >> bytes), >> but the file is always empty, even after a close()). >> >> The problem is not a argument-passing or memory problem, >> but seems to be a linking problem. When a file is opened >> in a >> module (here nslog) only this module can write successfully >> to this file. Under Windows other dlls can't write to it, >> even >> when they write to the same fd. It seems to me as if the >> nslog dll is linked to a private runtime environment. >> Looking up the windows handle same file descriptor >> (e.g. 3) leads to a different results when performed in >> nslog.c >> or in driver.c (or somewhere else in a function in libnsd). >> >> The current solution is to define for windows stub-functions >> ns_open, ns_close, ns_write, ns_read which are defined in >> libnsd. >> These functions are called from ns_log instead of the native >> OS functions (under windows _open, _close, _write, _read), >> which have btw different prototypes, so this abstraction >> seems beneficial for several reasons. >> >> The essential change is in [1], which add the ns_* >> functions and >> reverts the previous _MSV_VER bypass in nslog.c. For >> completeness, ns_tell should be added as well. >> >> Andrew, can you compare the linking options for nslog >> with these >> from Maurizio? Although the problem for nslog seems to be >> solved, >> i would not be surprised if other weirdnesses lurch around >> from other modules. >> >> -g > ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
