Board index » delphi » Calling TP4 generated code from BC5++

Calling TP4 generated code from BC5++

Hi Group,

my personal nightmare finally came true: write stuff for 16-bit DOS.
Some months ago I cleared my office from all DOS-related material, threw

out all the old manuals etc. etc save the installation disks for TP4 and

TP6. Now it's back to the good ol' times. Luckily I got all the required

code for the project done in Delphi. So I introduced lot of conditional
compiling into the Delphi sources, result: sources that can be compiled
by Delphi and TP4/TP6. Then there is a tool that will convert tpu's to
obj's. It works only with TP4-tpu's, but OK. Now I can link the obj into

the target C-Code, which may be Borland C, C++ or even MS-C.

You all with me? That sounds weird? It sure is, but it works! Al least
it works too well to be impossible in the first place. There are no
problems but one: from a certain development stage on I got subtle
errors when passing parameters fom the calling C-code to the
Pascal-Code. I dug out TD32 and found out that pointers to data areas
passed in the call get clobbered in the very moment when the Pascal-Code

returns control to the C-Code. I suspect the Pascal-Code allocating too
much memory along the way and corrupting the stack.

Well, quite a challenge, isn't it? If there's anybody out there who
knows a lot about calling mechanisms of procedures, memory allocation
and using TD32 efficiently, may be s/he can give me a tip. It would be
very helpful to know how to nail the bug with TD32 without stepping
through the whole code.

TIA Ralph

 

Re:Calling TP4 generated code from BC5++


Quote
>my personal nightmare finally came true: write stuff for 16-bit DOS.
>Some months ago I cleared my office from all DOS-related material, threw
>out all the old manuals etc. etc save the installation disks for TP4 and
>TP6. Now it's back to the good ol' times. Luckily I got all the required
>code for the project done in Delphi. So I introduced lot of conditional
>compiling into the Delphi sources, result: sources that can be compiled
>by Delphi and TP4/TP6. Then there is a tool that will convert tpu's to
>obj's. It works only with TP4-tpu's, but OK. Now I can link the obj into

What is the requirement? If running using a 32-bit dosextender is good
enough, try one of the free compilers (like FPC www.freepascal.org, which
can understand a subset of Delphi (no interfaces, no dynamic arrays))

You are talking about TPU's. What do you have to do with them? Do you just
disassemble them to get the asm source for the program, or do you don't have
their source?

Quote
>the target C-Code, which may be Borland C, C++ or even MS-C.
>You all with me? That sounds weird? It sure is, but it works!

It links, yes. But I can also link it a picture, but that doesn't mean I
have it on screen :-)

Quote
>Al least
>it works too well to be impossible in the first place. There are no
>problems but one: from a certain development stage on I got subtle
>errors when passing parameters fom the calling C-code to the
>Pascal-Code. I dug out TD32 and found out that pointers to data areas
>passed in the call get clobbered in the very moment when the Pascal-Code
>returns control to the C-Code. I suspect the Pascal-Code allocating too
>much memory along the way and corrupting the stack.

Afaik it would be easier to load the 16-bit code in 16-bits space, and then
establish some link to the 32-bit part of the program?
But that might not be possible.

Quote
>Well, quite a challenge, isn't it? If there's anybody out there who
>knows a lot about calling mechanisms of procedures, memory allocation
>and using TD32 efficiently, may be s/he can give me a tip. It would be
>very helpful to know how to nail the bug with TD32 without stepping
>through the whole code.

Rewrite the code to 32-bit. There are probably constantly segments being loaded
and changed, which isn't a good idea in 32-bit mode.

Re:Calling TP4 generated code from BC5++


Quote
Ralph Hofmann wrote:

> sources that can be compiled by Delphi and TP4/TP6. Then there is a
> tool that will convert tpu's to obj's. It works only with TP4-tpu's,
> but OK. Now I can link the obj into the target C-Code, which may be
> Borland C, C++ or even MS-C.

But you need some subroutines from the RTL (from System.TPU, I mean),
no? Like memory allocation, parameter copying or such things.
What did you: avoided them? rewriting them? using the TP4 system.TPU
turned to another .OBJ? using a thunking layer to call the C 32 bit
code where appropriate?

The first suspect to me are RTL calls embeeded inside the Pascal code.
Because I do not see what else can corrupt data when written in TP4!

Quote
> You all with me? That sounds weird? It sure is, but it works! Al least
> it works too well to be impossible in the first place. There are no
> problems but one: from a certain development stage on I got subtle
> errors when passing parameters fom the calling C-code to the
> Pascal-Code. I dug out TD32 and found out that pointers to data areas
> passed in the call get clobbered in the very moment when the Pascal-Code
> returns control to the C-Code. I suspect the Pascal-Code allocating too
> much memory along the way and corrupting the stack.

Did you trace though the Pascal code, or does it act as a black hole
with respect to TD32?
(I cannot easily see how you can use TD32 with 16-bit code. But OTOH
 I do not see at all how do you thunk from 32- to 16-bit and return).

If you did not trace though 16-bit, my idea would be to use either
extensive dumps of memory (stack, for example) at various points inside
the Pascal code, or either using an external de{*word*81} (looks after SWAT
for example <URL:http://www.sudleyplace.com/swat/swat.htm>) to get the
hand while entering the Pascal code. I consider 16-bit code to be easier
to trace, partly because the 16-bit compiler is not that smart.

Hope it helps, but I believe this will not be sufficient.
If a part of the code is visible, it would be perhaps easier to help you.

Antoine

Re:Calling TP4 generated code from BC5++


Quote
"Ralph Hofmann" <ralphhofm...@vossnet.de> wrote in message

news:39AAE925.84C218B2@vossnet.de...

Quote
> Hi Group,

> my personal nightmare finally came true: write stuff for 16-bit DOS.
> Some months ago I cleared my office from all DOS-related material, threw

> out all the old manuals etc. etc save the installation disks for TP4 and

> TP6. Now it's back to the good ol' times. Luckily I got all the required

> code for the project done in Delphi. So I introduced lot of conditional
> compiling into the Delphi sources, result: sources that can be compiled
> by Delphi and TP4/TP6. Then there is a tool that will convert tpu's to
> obj's. It works only with TP4-tpu's, but OK. Now I can link the obj into

> the target C-Code, which may be Borland C, C++ or even MS-C.

> You all with me? That sounds weird? It sure is, but it works! Al least
> it works too well to be impossible in the first place. There are no
> problems but one: from a certain development stage on I got subtle
> errors when passing parameters fom the calling C-code to the
> Pascal-Code. I dug out TD32 and found out that pointers to data areas
> passed in the call get clobbered in the very moment when the Pascal-Code

> returns control to the C-Code. I suspect the Pascal-Code allocating too
> much memory along the way and corrupting the stack.

> Well, quite a challenge, isn't it? If there's anybody out there who
> knows a lot about calling mechanisms of procedures, memory allocation
> and using TD32 efficiently, may be s/he can give me a tip. It would be
> very helpful to know how to nail the bug with TD32 without stepping
> through the whole code.

1. You may have a problem with calling conventions. C or C++ code typically
expects the caller to pop the parameters off the stack, while Pascal code
expects the callee will do the work. There should be a modifier in BC++
which changes the default. For 16-bit versions of BC++, it was __pascal,
used as follows:

    int __pascal Foo(int, double);

2. If you are calling 16-bit code from 32-bit code, be sure that the
definitions used by the thunking compiler are correct. Most important are
the attributes defining whether a variable is input or output!

3. Ensure that the Pascal code and the C code are making the same
assumptions about variable sizes. A 32-bit 'int' in C is equivalent to the
TP4 'LongInt'.

Hope that this helps,

Daniel Pfeffer

Other Threads