On Thu, 27 May 2010, Szak�ts Viktor wrote: Hi Viktor,
> > Alternatively we can move WinMain() to separate library or remove strict > > binding to HVM (hb_forceLinkMainWin()) and add some code to HBMK2 which > > will force linking with WinMain() if necessary (GUI application is created). > > hb_forceLinkMainWin reference was added to HVM code for quite old OpenWatcom > > versions and maybe can be eliminated now or maybe it's enough to add some > > commands to link script by HBMK2. Removing hb_forceLinkMainWin() reference > > from watcom builds should resolve the problem. You only have to check if > > HBMK2 can still create static GUI binaries for using OW. > I'd appreciate if you could find some to make > some patches, I'll try to follow it with hbmk2. 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. > > 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. > 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. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
