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

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

Nilo Paim wrote:

 > David Essex wrote:
>>
>> Is Nilo aware that the 'test_suite' must be run before and after the
>> changes without any errors, or change in the results ?
> 
> Yes, certainly I am.

Some information about the 'test_suite'.

It will not fully test the compiler or run-time, but it does a fair job 
of trapping many problems.

One of the things it does not do is check any CURSES based programs, as 
STDIN/STDOUT/STDERR are not displayed.
On UN*X you can use pseudo-terminals (X-Win) in combination with GDB to 
debug and test CURSES based programs.
On Win32 I'm not aware of any way to test and debug CURSES based programs.

One final note, the 'test_suite' will run on Win32, but you need the DTK 
and MSYS (if I remember correctly).
Actually, the version of Perl which came with the DTK, is the only 
version I could ever get to run properly on Win32.


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

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.


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

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.

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.

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

David Essex