I don't have huge recruiting experiences, so cannot tell, but maybe someone in our crew (Mindaugas :) could find it interesting in the future and even find time for it.
Of course everyone is welcome and you can try getting ppl interested, I seem to recall there is some infrastructure for that on sf.net even. Brgds, Viktor On Tue, Jun 2, 2009 at 9:26 PM, Massimo Belgrano <[email protected]> wrote: > How recruit c developer for the best xbase compiler? > what about add an invitation on harbour website? > something like (and sorry for my bad english) > "A global tool with people around all word , know as the best xbase compiler > search c developer (and why not english documenter) for a special mission > made a batter product starting from the best product" > i can post an official messages (from one guru Przemek, Viktor , Pritpal ) > also in other website > > 2009/6/2 Szakáts Viktor <[email protected]> >> >> Hi Przemek, >> >> Thanks for these ideas, exactly what I wanted to know. >> >> For me it's too complicated to convert to actual code >> (plus I'm not using .dlls), but I hope someone can implement >> it in a future Harbour version. >> >> Brgds, >> Viktor >> >> On 2009.06.02., at 17:30, Przemyslaw Czerpak wrote: >> >>> On Tue, 02 Jun 2009, Szak�ts Viktor wrote: >>> >>> Hi, >>> >>>> We still have some non-portable code to support DLL calls on Windows. >>>> The problem with this is that it only works on x86 Windows systems >>>> (this means it isn't available on WinCE, x64 and IA64) and the >>>> implementation >>>> uses inline ASM to solve the problem. >>>> Is it possible to replace DynaCall() function with a portable, >>>> pure C solution? >>> >>> AFAIK no but it can be hacked to use pure C code for chosen platforms >>> if you know well used ABI (calling convention). >>> F.e. for x64 1-st 10 parameters are passed in registers without touching >>> stack (AFAIR RAX, RCX, R1, R2, ..., R8). These are 64bit registers so >>> they can be used to hold most of data types without any casting or >>> dividing >>> (except long double and some structures). It means that it should be >>> enough >>> to introduce pseudo function with 10 parameters and cast real function >>> to this one before calling, f.e. sth like: >>> >>> typedef LONGLONG ( CALLBACK * _DLL_FUNC_ ) >>> ( LONGLONG p1, LONGLONG p2, LONGLONG p3, LONGLONG p4, LONGLONG p5, >>> LONGLONG p6, LONGLONG p7, LONGLONG p8, LONGLONG p9, LONGLONG p10 >>> ); >>> >>> LONGLONG p[ 10 ], llresult; >>> _DLL_FUNC_ lpFunc; >>> >>> /* initalize params casting them to LONGLONG: */ >>> p[ 0 ] = ( LONGLONG ) ...; >>> p[ 1 ] = ( LONGLONG ) ...; >>> ... >>> >>> /* initialie function address: */ >>> lpFunc = ( _DLL_FUNC_ ) GetProcAddress; >>> >>> /* call function */ >>> llresult = (lpFunc)( p[ 0 ], p[ 1 ], p[ 2 ], p[ 3 ], p[ 4 ], >>> p[ 5 ], p[ 6 ], p[ 7 ], p[ 8 ], p[ 9 ] ); >>> >>> I cannot test it but it should work though it's possible that some >>> types are not returned in RAX and in such case we will have to introduce >>> second version of such function declared with different return type. >>> Similar hacks can be introduced also for other calling conventions >>> but some of them force strict number of parameters so the caller >>> has to use casting to 10 different functions depending on number of >>> passed parameters and some parameters like 64bit integers or double >>> values should be divided into two ones if parameter holder is not large >>> enough f.e. on 32 bit systems. Some types may also need special handling >>> for returned values and repeated function declaration. >>> AFAIR maximum number of DLL function parameters on x...@32 is 16. >>> We have two calling conventions C and STD and 3 methods of returning >>> parameters: LONGLONG, double, float. So finally we will need 16 * 2 * 3 >>> pseudo functions which will be used in pure C code with strict number >>> of normalized parameters. >>> Someone who use windows, knows assembler and calling convention used >>> in this OS should be able to create such code and test it. Current ASM >>> code can be used as source for parameters conversion and types of >>> functions. >>> Sorry but due to limited access to this system I cannot make it myself. >>> It's possible that such code written for x...@32 will also work with >>> wi...@arm without any modifications or with some small ones in parameter >>> encoding or additional exceptions for returned values. >>> >>> best regards, >>> Przemek >>> _______________________________________________ >>> Harbour mailing list >>> [email protected] >>> http://lists.harbour-project.org/mailman/listinfo/harbour >> >> _______________________________________________ >> Harbour mailing list >> [email protected] >> http://lists.harbour-project.org/mailman/listinfo/harbour > > > > -- > Massimo Belgrano > > > > _______________________________________________ > Harbour mailing list > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour > > _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
