Documentation SDK signature mismatch

[fpefpe]

Hello –

There seems to be a signature mismatch with some of the memory functions in
TakeCmd.h and TakeCmd.lib SDK

void WINAPI FreeMem( LPVOID lpMemory );
?FreeMem@@YGXPAX@Z (void __stdcall FreeMem(void *))

LPVOID WINAPI AllocMem( unsigned int * puSize );
?AllocMem@@YGPAXI@Z (void * __stdcall AllocMem(unsigned int))

LPVOID WINAPI CallocMem( unsigned int * puSize );
?CallocMem@@YGPAXII@Z (void * __stdcall CallocMem(unsigned int,unsigned int))

LPVOID WINAPI ReallocMem( LPVOID lpMemory, ULONG_PTR uSize ); ?ReallocMem@@YGPAXPAXK@Z (void * __stdcall ReallocMem(void *,unsigned long))

In the case of CallocMem it seems to require 2 arguments – is one the fill byte?

 

[rconn]

Why are you trying to use the internal takecmd.dll memory routines instead of the Windows or RTL ones?

The ones in takecmd.dll are not general purpose; they're intended for preallocating very large buffers (i.e., a minimum of 1Mb, and usually much more).

 

[vefatica]

If HeapAlloc() is told to raise exceptions, will TCC catch them?

 

[Josef Schroettle]

There are lots of discrepancies between TakeCmd.h and TakeCmd.lib, but I was able to solve that by editing the header-file. At least the lib and dll match in the x86 architecture.
Right now I got stuck in x64 world as there is a difference between TakeCmdx64.lib and the dll: The function QueryPluginPathname() has a LPCTSTR argument in the lib and a LPTSTR argument in the dll. This I cannot resolve.
It is sad that the SDK is not properly maintained...

Josef

 

[fpefpe]

Hello -- thanks for the reply ... I thought that all the function in the header were free to use .. I thought that
the internal memory routines would make sense since the plugin would be using the same memory as the the (base) code itself ... OK I will stick to the win RTL calls -- thanks for clearing this up

 

[rconn]

If HeapAlloc() is told to raise exceptions, will TCC catch them?

TCC wraps the plugin calls inside an exception handler.

However, I don't know *why* you'd want to tell HeapAlloc to raise exceptions, or why if you did you wouldn't handle them yourself.

 

[rconn]

There are lots of discrepancies between TakeCmd.h and TakeCmd.lib, but I was able to solve that by editing the header-file. At least the lib and dll match in the x86 architecture.
Right now I got stuck in x64 world as there is a difference between TakeCmdx64.lib and the dll: The function QueryPluginPathname() has a LPCTSTR argument in the lib and a LPTSTR argument in the dll. This I cannot resolve.

QueryPluginPathname has an LPCTSTR argument in the .h, .lib and the .dll, unless you're using an older (pre-v17) version of takecmd.dll. (There is no difference in the .h files between x86 & x64.)

 

[rconn]

Hello -- thanks for the reply ... I thought that all the function in the header were free to use .. I thought that
the internal memory routines would make sense since the plugin would be using the same memory as the the (base) code itself

Well -- no, they wouldn't. The AllocMem / CallocMem / ReallocMem routines are wrappers for Window's VirtualAlloc routines. (And optimized for very large allocations.)

When allocating anything less than 1Mb, TCC & TCMD use the RTL functions.

 

[rconn]

I fixed the three incorrect function defs in takecmd.h, removed a couple of obsolete definitions, and added a few new v17 functions, and uploaded the new sdk.zip to the web site.