Hi Przemek, > It's hard for me to test current OpenWatcom behavior using WINE > because some results can be strictly bound with Linux and WINE > emulation so I cannot say if they are correct or not, i.e. the > things I should test like detaching from terminal and allocating > console windows works differently in WINE then in native Windows. > I'll try but I cannot say I will have any valuable results.
I understand. [ my offer for remotely accessible Windows environment still stands though. Just tell me. ] >>> The problem is only for users who will want to use harbour.dll >>> created by Open Watcom with some other C languages so it's not >>> very common. Probably we should ignore it now switch to register >>> calling convention and then if possible look for some solutions >>> which can force using C calling convention for exported Harbour >>> functions. >> It also causes that watcom builds cannot utilized >> harbour.dll created with non-watcom compiler, which >> is a problem, because in windows unified build I >> include harbour.dll built with mingw, so in effect >> watcom -shared mode doesn't work by default. > > For me it's a feature because OpenWatcom harbour.dll used with > other C compiler GPFs immediately. I strongly prefer such behavior > instead of some strange bug reports for which I invest time looking > the reason of problem and then I'm finding that it's caused by some > small differences between used C compilers, i.e. BCC uses 8bytes > alignment and most of other MS-Windows C compilers 4 bytes alignment > what can cause corruption of some HVM structures. So I strongly > suggest to never mix DLLs created by different compilers and > I would like to know about such situation when anyone reports > bugs. To me such approach seems to defeat the almost whole point of having .dlls. I think .dlls should be able to interoperate, otherwise we lose one of their basic features. IMO when creating a .dll we should provide a standard and documented ABI, which means a standard set of available functions and a standard calling convention (and aligment). So far we're doing good and only bcc stands off from the pack, but bcc isn't such important (plus it very much seems impossible to bend it right) so it's okay. But, if there is any way to juggle settings to make this "dream" possible for as much targets we support, we should IMO try it. F.e. this feature makes it possible to ship the "unified" Windows binary package in proper way. The shipped .dlls are mingw built which in turn works well with msvc, pocc and watcom. Same is true if .dlls are built with msvc. And the same is true for x64 .dlls (currently built with msvc64, but by now also mingw64 works). >> Do you see any notion or chance to fix the issue >> by using __cdelc for watcom? > > This seems to be quite easy to introduce by small modification > in HB_EXPORT macro so we can make some experiments when we restore > original OpenWatcom calling convention. That would be very nice. I reached a dead-end with my experiments, hopefully you can breath some fresh air into the matter :) Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
