tiny-cobol-users

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

[Nilo <nil...@gm...>]

>> David, I suppose the main environment for all the development of the
>> compiler is Linux.
>> Otherwise I would like to direct my work on the use of
>> MinGW under Windows.

>Great, I'm been waiting for a TC developer with Win32 experience for
>looong time.

I hope I can help... ;-)

>Generally speaking, compiler functionality is developed on UN*X mainly
>because it easier. Later equivalent functionality (if possible) is
>developed on Win32 using MinGW.

>The development setup I use, to keep the MinGW/UN*X TC versions in sync,
>is to have two machines on a (closed) network.
>Then using samba and Win32 shares with write access, I use the same file
>system directories.

Unfortunately I've no access to a Linux box now...

>> So I've look the portions of code related to it and have made some tests.
>>
>> During these tests I've discover that I can't call a DLL written in
TinyCobol
>> from another TinyCobol program.
>>
>> Please, could you shed me some light about the way TinyCobol generates
code
>> for Cobol written DLL's using switch '-m'? It seems to me that the
generated
>> DLL doesn't export any symbols.
>> Am I right? How should I use he compiler in order to do that?

>Have a look at the samples in the test.code/t25 and t33 directories, and
>the source code in 'htglobals.c'.
>
>Basically the export/import defines, and '.def' files are auto-generated
>by the MinGW compiler.

Well, that's the problem... a Cobol program doesn't have generated the GAS
directives that permits the exporting of symbols...

So, the MinGW compiler does not know what symbols to export...

>
>On Win32 calling a sub-program (function) in a DLL is problematic.
>
>The reason being that a DLL can contain many sub-programs (functions),
>and the name of the DLL may not have any relation to the name of the
>sub-program being called.
>
>On UN*X, there are functions calls you can use that will search the
>shared library paths and load that sub-program (function).
>On Win32 (MinGW) there is no equivalent functionality (that I am aware
>of), so you have to write your own.

Well, I made some tests and modifications on my local copy... when I call
DLL's written in C or something like that it works like a charm, without
'CALL-LOADLIB' extension. All my problems begins when I try to call DLL's
generated by TinyCobol... I'm able to find the DLL, but not the sub-programs
( functions ), just because there are no functions exported...

Maybe should the compiler export all PROGRAM-ID's identifiers as functions
names, i. e, put the '.section .drectve' and '.ascii "
-export:prog-id-name"' clauses on generated code?

Well, at least this is my first tough about... ;-)

>
>On TC version 0.63, I could not find a way to create that equivalent
>functionality. So you have to first load a specific DLL using the
>'CALL-LOADLIB identifier' extension.
>
>On TC CVS, I found a way which seams to work.
>Basically it finds, loads and checks DLL's in the 'TCOB_LD_LIBRARY_PATH'
>paths for that sub-program (function).
>See 'lib/dyncall.c' for details.

I saw your code. I would like to test it more, but the problem related to
exported symbols I told you persists....

>
>Hope this helps.
>If you have any further questions do not hesitate to ask.

Thanks, my friend. I'll try not to abuse... :-D

>
>David Essex

Nilo R C Paim
Porto Alegre - RS - Brazil

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

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

Nilo Paim wrote:

> ... 
> Unfortunately I've no access to a Linux box now...

You are aware that to use SF CVS you will require some package which has 
SSH available, such as Putty.


> ... 
>> Basically the export/import defines, and '.def' files are auto-generated
>> by the MinGW compiler.
> 
> Well, that's the problem... a Cobol program doesn't have generated the 
> GAS directives that permits the exporting of symbols...
> 
> So, the MinGW compiler does not know what symbols to export...
> ...
> Well, I made some tests and modifications on my local copy... when I 
> call DLL's written in C or something like that it works like a charm, 
> without 'CALL-LOADLIB' extension. All my problems begins when I try to 
> call DLL's generated by TinyCobol... I'm able to find the DLL, but not 
> the sub-programs ( functions ), just because there are no functions 
> exported...
> 
> Maybe should the compiler export all PROGRAM-ID's identifiers as 
> functions names, i. e, put the '.section .drectve' and '.ascii " 
> -export:prog-id-name"' clauses on generated code?
> 
> Well, at least this is my first tough about... ;-)

First we need to isolate the problem.

What version of GCC (MinGW) are you using ?

Have you tried to compile (using the Makefile.mingw) and run the 
examples found in t25 and t33 ?
If these examples do not work, then we have a problem because they do 
work on GCC 3.x (MinGW).

Regarding the export/import defines, the TC compiler does not generate 
any Win32 directives.
The TC front end will spawn a process and let GCC worry about the details.

So if you try using 'htcobol -v -m ...' command, TC should spawn a 
process with the equivalent command.
gcc -shared \
-Wl,--out-implib,${lib_name2}.dll.a,--output-def,${lib_name2}.def \
-o ${SHARED_LIB} $(OBJS) ${LIBS}

So the basic method for compile time linking is as follows.
1) Create the DLL(s) using the sub-programs.
2) Create the an object from the main-program.
3) Add the main object and library (DLL) to the link step
    using the '-ldll-name' GCC option.
4) Add the CWD to the path, and run the executable.

Normally I recommend using make files for DLL's because of these 
complexities.
And because when using the TC command line you can't create DLL's 
(modules) with multiple COBOL sources (htcobol -m s1.cob s2.cob).

Anyway, have a look and let me know what you think.

David Essex

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

[Nilo <nil...@gm...>]

On 1/3/07, David Essex <de...@us...> wrote:
>
> Nilo Paim wrote:
>
> > ...
> > Unfortunately I've no access to a Linux box now...
>
> You are aware that to use SF CVS you will require some package which has
> SSH available, such as Putty.


Oh, yes. No problems here...

> ...
> >> Basically the export/import defines, and '.def' files are
> auto-generated
> >> by the MinGW compiler.
> >
> > Well, that's the problem... a Cobol program doesn't have generated the
> > GAS directives that permits the exporting of symbols...
> >
> > So, the MinGW compiler does not know what symbols to export...
> > ...
> > Well, I made some tests and modifications on my local copy... when I
> > call DLL's written in C or something like that it works like a charm,
> > without 'CALL-LOADLIB' extension. All my problems begins when I try to
> > call DLL's generated by TinyCobol... I'm able to find the DLL, but not
> > the sub-programs ( functions ), just because there are no functions
> > exported...
> >
> > Maybe should the compiler export all PROGRAM-ID's identifiers as
> > functions names, i. e, put the '.section .drectve' and '.ascii "
> > -export:prog-id-name"' clauses on generated code?
> >
> > Well, at least this is my first tough about... ;-)
>
> First we need to isolate the problem.
>
> What version of GCC (MinGW) are you using ?


 gcc 3.2.3

Have you tried to compile (using the Makefile.mingw) and run the
> examples found in t25 and t33 ?
> If these examples do not work, then we have a problem because they do
> work on GCC 3.x (MinGW).


Not yet. I'll do it tonight at home.

Regarding the export/import defines, the TC compiler does not generate
> any Win32 directives.
> The TC front end will spawn a process and let GCC worry about the details.


Well, that's exactly the point where I'm going to...

So if you try using 'htcobol -v -m ...' command, TC should spawn a
> process with the equivalent command.
> gcc -shared \
> -Wl,--out-implib,${lib_name2}.dll.a,--output-def,${lib_name2}.def \
> -o ${SHARED_LIB} $(OBJS) ${LIBS}


Yes, I've noted that...

So the basic method for compile time linking is as follows.
> 1) Create the DLL(s) using the sub-programs.
> 2) Create the an object from the main-program.
> 3) Add the main object and library (DLL) to the link step
>     using the '-ldll-name' GCC option.
> 4) Add the CWD to the path, and run the executable.


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)?

Normally I recommend using make files for DLL's because of these
> complexities.
> And because when using the TC command line you can't create DLL's
> (modules) with multiple COBOL sources (htcobol -m s1.cob s2.cob).


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...

Anyway, have a look and let me know what you think.
>
> David Essex


Thanks a lot for your responses.

Nilo R C Paim
Porto Alegre - RS - Brazil

[Tiny-cobol-users] Tiny Cobol Syntax and Language

[vince c. <vb...@bt...>]

Hi All;

Where is a list of Cobol Language and syntax as used in Tiny Cobol to be 
found?

This would help in knowing what changes I need to make to some old MF cobol 
sources.


Thanks,

Vince

Re: [Tiny-cobol-users] Tiny Cobol Syntax and Language

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

Vince Coen wrote:

 > Where is a list of Cobol Language and syntax as used
 > in TinyCobol to be found?
 >
 > This would help in knowing what changes I need to make
 > to some old MF cobol sources.

There is no COBOL syntax documentation for TC.

If you use COBOL-85 syntax and avoid MF specific extensions, most
programs should compile and run.

Some areas or problems you may encounter.

1) No report generator.
2) Limited support for curses based screen IO
3) Using very large/small numbers can be problematic.

I'm sure there are many others.

Hope this helps.

David Essex

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

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

[Nilo <nil...@gm...>]

On 1/3/07, David Essex <de...@us...> wrote:
>
> 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.


Yes, I agree.

> 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.


Yes. Just the entry point must be exported, i. e, the functions named as
PROGRAM-ID clause.

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.


That way I'll link the Cobol program with the export library. I would like
not to link the Cobol program anyway. Just call the functions of the DLL...


So what is the advantage ?


I was thinking that TC could be used to generate Win32 standard DLL's. That
way, it could be usable from another languages, like C,  Delphi, Lazarus,
etc... any language that can use DLL's...

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.


I think I really need to think more about...

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


Thanks for your hints and prompt responses, David.

Nilo R C Paim
Porto Alegre - RS - Brazil

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

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

Nilo,

If you wish, why not run some tests with these GAS directives that
permit the exporting of symbols.

When testing some assembler code, I usually generate an assembler file
using 'htcobol -S prog.cob'.
You can then modify the assembler file manually, and use it as the input
to GCC.


David Essex

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

[Nilo <nil...@gm...>]

Hi, David.

On 1/4/07, David Essex <de...@us...> wrote:
>
> Nilo,
>
> If you wish, why not run some tests with these GAS directives that
> permit the exporting of symbols.


These are exactly the tests I'm doing now. Wel, it's difficult to find docs
about it, and I'm not a GAS expert...

When testing some assembler code, I usually generate an assembler file
> using 'htcobol -S prog.cob'.
> You can then modify the assembler file manually, and use it as the input
> to GCC.


That's the way I'm trying to do... ;-)

David Essex


By the way... Just curious: where are you from?

Thanks.

Nilo R C Paim
Porto Alegre - RS - Brazil