Re: [Tiny-cobol-users] TC updates (was: changes in accept ...)

[David E. <de...@us...>]

Nilo Paim wrote:

 > ...
 > Well, that way the DLL is not dynamic as it could be... What's the
 > advantage of using DLL's if I need link it together (except for the
 > resulting size of the animal, of course)?

Actually that was just an example similar that found in 't25'.
An example of run-time linking can be found in 't33'.

It all depends on what kind of COBOL CALL is made.

CALL { indenfier-1 | literal-1 } ...

If 'indenfier-1' is used, then run-time linking is used. Meaning
load-library, and link to function.

If 'literal-1' is used, then compile-time linking is used. Both static
libraries and DLL's can be used in the link. With GCC the default is a
DLL if the export library 'lib_name.dll.a' is present.


 > ...

The TC command line does not accept multiple input sources for any
option. That was done by design, otherwise the interface becomes too
complex.

 > That's the point. I suggest that TC should do it, using as
 > export'ed functions all the PROGRAM-ID's names from the Cobol
 > sources.
 > The result I expect is the same as I would if I code the
 > equivalent using '__declspec(dllexport)' in C, if you
 > understand me...
 > And I think we could emit Win32 directives to the assembly
 > code...

Yes, I'm aware of the '__declspec(dllexport)' C macros.
I'm no Win32 expert, but these macros define only the functions which 
need to be exported.
As I understand it, this means only functions which are called by other 
functions outside the DLL. Not all functions in the DLL must be exported.

The COBOL language does not have these 'macros'.
But you can define which functions to export in the export defines 
'lib_name.def' file. And then use the MinGW-GCC tool-chain to create the 
export library (in MinGW it is usually called 'lib_name.dll.a') and DLL.

If TC generates Win32 directives in the assembly code, then all
COBOL functions are exported. You still have create a export defines
'lib_name.def' file, and you still have use the MinGW-GCC tool-chain to 
create the export library and DLL.

So what is the advantage ?

Also when you create a Win32 DLL in C, you must define a Win32 API
function 'DLL_Entry ...' (I think is called).
I'm NOT positive, but I think GCC (MinGW) does include that code segment
in the DLL.

Frankly, I have no objection to TC generating Win32 DLL directives in
the assembly code.
However, I think letting the MinGW-GCC tool-chain do the work is a 
better approach.

Anyway, as I mentioned above, I'm no Win32 expert.
So as always, all comments, suggestions and pizza coupons are welcomed.

David Essex