@CAPI question

[Gisle Vanem]

I experimented with the @CAPI function and found it quite
annoying. E.g. a echo %@capi[libcurl.dll,curl_easy_init] works OK.
But all the handles to libcurl.dll (and all sub DLLs and .PDB-files) are not freed.
So e.g. a subsequent make install of one of those sub DLLs fails.

How are these handles supposed to get freed? I found no specifics on this in the help.

 

[Joe Caverly]

When compiling and testing plugins/dlls, I first launch a new shell by doing;

E:\Utils>echo %_cmdspec
C:\Program Files\JPSoft\TCMD30\TCC.EXE

E:\Utils>"%_cmdspec"

To tell me what _shell level I am at, I have this in my prompt;

%@repeat[@,0%_shell]

Thus, when my _shell is 1,
my prompt displays E:\Utils>@

When _shell is 1,
and I want to release my DLL in development,
I type exit to leave the shell.

This puts me back at _shell = 0,
from where I can compile the DLL,
as it has been released from memory.

Joe

 

[vefatica]

I experimented with the @CAPI function and found it quite
annoying. E.g. a echo %@capi[libcurl.dll,curl_easy_init] works OK.
But all the handles to libcurl.dll (and all sub DLLs and .PDB-files) are not freed.
So e.g. a subsequent make install of one of those sub DLLs fails.

How are these handles supposed to get freed? I found no specifics on this in the help.

That's probably a design choice. And, for performance reasons, I think not freeing the library after every use of @CAPI is the best choice. Imagine calling @CAPI may times, hopefully fast, say in a loop.

I have the same problem developing/installing TCC plugins. I have a "Plug" button in DevStudio which copies a newly-built DLL to TCC's plugins directory and starts a new instance of TCC. It fails if TCC is already running with the plugin DLL loaded. I just live with it.

I also suppose that for the great majority of users, replacing DLLs is just not done often.

 

[rconn]

The module handles (from the LoadLibrary call) are not freed -- for performance reasons, as Vince suggested. The reasoning is that if you call @CAPI or @WINAPI once, you're likely to call it again and there isn't much point in the (substantial) overhead of loading / unloading / reloading the dll.. Your case of calling it for your own under-development dll's is an edge case - you would probably be better off writing a little plugin to do that.

 

[Gisle Vanem]

Thank you all for clearing up my question.