[Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Revision: 13894 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13894&view=rev Author: vszakats Date: 2010-02-17 02:09:17 + (Wed, 17 Feb 2010) Log Message: --- 2010-02-17 03:06 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/fstemp.c ! Using hb_fsTempDir() in HB_FTEMPCREATEEX() instead of old solution. This should fix it for some non-*nix platforms where *nix specific TEMPDIR envvar was used to determine temp directory. * contrib/hbwin/Makefile * include/Makefile * src/rtl/Makefile - contrib/hbwin/hbdyn.ch + include/hbdyn.ch - contrib/hbwin/hbdyn.c + src/rtl/hbdyn.c - contrib/hbwin/win_dllc.c + src/rtl/hbdynhb.c - contrib/hbwin/tests/testdll.c + tests/testdyn.c - contrib/hbwin/tests/testdll.prg + tests/testdyn.prg - contrib/hbwin/tests/testdll1.prg + tests/testdyn1.prg - contrib/hbwin/hbdyn.h * include/hbapi.h * Moved dynamic library call related functions to core (RTL). * Windows specific test code (currently all) guarded for platform. * Changed default calling convention to cdecl. Tests adaptd accordingly. * Terminology change: 'dll' -> 'dynamic library' ; HB_DYNCALL() is now part of core Harbour, and it's platform independent. It's platform (ABI) dependent though, and currently x64 and x86/stdcall/syscall/cdecl is supported and these were tested (except OS/2 syscall). * contrib/hbwin/hbwin.h * contrib/hbwin/win_misc.c * contrib/hbwin/legacycd.c * Low level hbwin_getprocaddress() function moved to legacy file and made static. * contrib/xpp/Makefile * contrib/xpp/dllx.c * contrib/xpp/xpp.hbc + Enabled DLL*() functions for all platforms. - Deleted dependence on hbwin library. * contrib/xpp/tests/testdll.prg * Windows specific parts (currently the whole test) guarded for platform. * contrib/hbct/Makefile - contrib/hbct/diskhb.prg * contrib/hbct/disk.c * contrib/xhb/Makefile + contrib/xhb/diskhb.prg * GETVOLINFO() moved from hbct to xhb. * ChangeLog * Marked some TODO/TOFIX items as DONE. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/Makefile trunk/harbour/contrib/hbct/disk.c trunk/harbour/contrib/hbwin/Makefile trunk/harbour/contrib/hbwin/hbwin.h trunk/harbour/contrib/hbwin/legacycd.c trunk/harbour/contrib/hbwin/win_misc.c trunk/harbour/contrib/xhb/Makefile trunk/harbour/contrib/xpp/Makefile trunk/harbour/contrib/xpp/dllx.c trunk/harbour/contrib/xpp/tests/testdll.prg trunk/harbour/contrib/xpp/xpp.hbc trunk/harbour/include/Makefile trunk/harbour/include/hbapi.h trunk/harbour/src/rtl/Makefile trunk/harbour/src/rtl/fstemp.c Added Paths: --- trunk/harbour/contrib/xhb/diskhb.prg trunk/harbour/include/hbdyn.ch trunk/harbour/src/rtl/hbdyn.c trunk/harbour/src/rtl/hbdynhb.c trunk/harbour/tests/testdyn.c trunk/harbour/tests/testdyn.prg trunk/harbour/tests/testdyn1.prg Removed Paths: - trunk/harbour/contrib/hbct/diskhb.prg trunk/harbour/contrib/hbwin/hbdyn.c trunk/harbour/contrib/hbwin/hbdyn.ch trunk/harbour/contrib/hbwin/hbdyn.h trunk/harbour/contrib/hbwin/tests/testdll.c trunk/harbour/contrib/hbwin/tests/testdll.prg trunk/harbour/contrib/hbwin/tests/testdll1.prg trunk/harbour/contrib/hbwin/win_dllc.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
On Wed, 17 Feb 2010, vszak...@users.sourceforge.net wrote: Hi Viktor, > 2010-02-17 03:06 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * src/rtl/fstemp.c > ! Using hb_fsTempDir() in HB_FTEMPCREATEEX() instead of > old solution. This should fix it for some non-*nix > platforms where *nix specific TEMPDIR envvar was used > to determine temp directory. It was "TMPDIR" and it's recognized also by many DOS programs. > * contrib/hbwin/Makefile > * include/Makefile > * src/rtl/Makefile > - contrib/hbwin/hbdyn.ch > + include/hbdyn.ch > - contrib/hbwin/hbdyn.c > + src/rtl/hbdyn.c > - contrib/hbwin/win_dllc.c > + src/rtl/hbdynhb.c > - contrib/hbwin/tests/testdll.c > + tests/testdyn.c > - contrib/hbwin/tests/testdll.prg > + tests/testdyn.prg > - contrib/hbwin/tests/testdll1.prg > + tests/testdyn1.prg > - contrib/hbwin/hbdyn.h > * include/hbapi.h > * Moved dynamic library call related functions to > core (RTL). > * Windows specific test code (currently all) guarded > for platform. > * Changed default calling convention to cdecl. > Tests adaptd accordingly. > * Terminology change: 'dll' -> 'dynamic library' > ; HB_DYNCALL() is now part of core Harbour, and it's > platform independent. It's platform (ABI) dependent though, > and currently x64 and x86/stdcall/syscall/cdecl > is supported and these were tested (except OS/2 syscall). There is one problem with above extension. Most of non windows compiler does not recognized _cdecl, _stdcall, _fastcall, _System (_pascal is the same as _stdcall in MS-Windows). Now this code can be compiled only in 64bit mode which does not use any calling convention attributes in function declarations and all other builds will fail so it has to be redesigned and we should have "default" calling convention without any forced by us ABI and then on platforms which supports explicit declaration add additional calls. I would also suggest to use macros to declare function types and call them. They should greatly reduce total code size and allow to add new calling convention in few lines. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Hi Przemek, >> 2010-02-17 03:06 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * src/rtl/fstemp.c >>! Using hb_fsTempDir() in HB_FTEMPCREATEEX() instead of >> old solution. This should fix it for some non-*nix >> platforms where *nix specific TEMPDIR envvar was used >> to determine temp directory. > > It was "TMPDIR" and it's recognized also by many DOS programs. I never new that, but in this case, would you mind modifying hb_fsTempDir()? It's an important function, so I'd appreciate it if you could make necessary adjustments. >> * contrib/hbwin/Makefile >> * include/Makefile >> * src/rtl/Makefile >> - contrib/hbwin/hbdyn.ch >> + include/hbdyn.ch >> - contrib/hbwin/hbdyn.c >> + src/rtl/hbdyn.c >> - contrib/hbwin/win_dllc.c >> + src/rtl/hbdynhb.c >> - contrib/hbwin/tests/testdll.c >> + tests/testdyn.c >> - contrib/hbwin/tests/testdll.prg >> + tests/testdyn.prg >> - contrib/hbwin/tests/testdll1.prg >> + tests/testdyn1.prg >> - contrib/hbwin/hbdyn.h >> * include/hbapi.h >>* Moved dynamic library call related functions to >> core (RTL). >>* Windows specific test code (currently all) guarded >> for platform. >>* Changed default calling convention to cdecl. >> Tests adaptd accordingly. >>* Terminology change: 'dll' -> 'dynamic library' >>; HB_DYNCALL() is now part of core Harbour, and it's >> platform independent. It's platform (ABI) dependent though, >> and currently x64 and x86/stdcall/syscall/cdecl >> is supported and these were tested (except OS/2 syscall). > > There is one problem with above extension. > Most of non windows compiler does not recognized _cdecl, _stdcall, _fastcall, > _System (_pascal is the same as _stdcall in MS-Windows). > Now this code can be compiled only in 64bit mode which does not use any > calling convention attributes in function declarations and all other > builds will fail so it has to be redesigned and we should have "default" > calling convention without any forced by us ABI and then on platforms > which supports explicit declaration add additional calls. > > I would also suggest to use macros to declare function types and call them. > They should greatly reduce total code size and allow to add new calling > convention in few lines. I did just that. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Hi Przemek, On 2010 Feb 17, at 13:39, Przemysław Czerpak wrote: > On Wed, 17 Feb 2010, Szak�ts Viktor wrote: > > Hi Viktor, > >>> I would also suggest to use macros to declare function types and call them. >>> They should greatly reduce total code size and allow to add new calling >>> convention in few lines. >> I did just that. > > Thank you very much. > I though about much wider macro usage. > I'm attaching hbdyn.c where declarations and calls are done using macros. > It strongly reduces total code size and IMO makes modificaitons and > extenssions easier. Very, very nice. I've copied it to my sandbox, so it will be committed in next session, though if you want to commit it, or will commit it faster, it's even better. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Viktor, It's nice. About Character Data. If the encode is UNICODE, ASCII, ANSI, NULL is the terminator: only RAW can be 0 in the data. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Hi Xavi, > It's nice. About Character Data. > If the encode is UNICODE, ASCII, ANSI, NULL is the terminator: only RAW can > be 0 in the data. Not necessarily. It may happen that a .c function expects human-readable data containing nul chars, even in the Windows API set. Dyn function engine should not pose extra limitation here. Maybe we will need extra translation modes, but simply switching encoded strings to nul terminated ones is not a complete solution. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Hi Viktor, even in the Windows API set. Dyn function engine should not pose extra limitation here. Well, I don't like limitations but in this case exist RAW type and I suppose is appropriate for structures and arrays type TCHAR**, seems a bit redundant. need extra translation modes, but simply switching encoded strings to nul terminated ones is not a complete solution. Maybe yes, I'm not sure, I just think that simplify use. Best regards, Xavi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13894] trunk/harbour
Hi Xavi, On 2010 Feb 17, at 16:00, Xavi wrote: > Hi Viktor, > >> even in the Windows API set. Dyn function engine >> should not pose extra limitation here. > > Well, I don't like limitations but in this case exist RAW type and I suppose > is appropriate for structures and arrays type TCHAR**, seems a bit redundant. > >> need extra translation modes, but simply switching >> encoded strings to nul terminated ones is not a >> complete solution. > > Maybe yes, I'm not sure, I just think that simplify use. IMO it's not simplification, it's just avoiding loss of information. In majority of cases you need to pass preallocated buffers to .c functions when you want to receive back values in these buffers. Usually you get back the length of such buffer in another parameter. If you're getting a length value, you can't assume that the buffer doesn't contain a zero char. Current behavior supports this case perfectly. When you're getting back strings as return value, they are usually zero terminated. Current implementation will return you a zero terminated string in this case, so it also matches the 'usual' case. Anyway it's very easy to create a function which discards the part of a string after the first leading zero (or cuts it to a given length), in case you need a zero terminated string. Current implementation makes this possible, but it doesn't cut off the case when you do need the rest of the data. We can implement such feature in the low-level engine, as an option. I've committed it to SVN. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
