Hi to all,

The other day I wrote my first DLL using PChars etc.
What I would like to know is if I want to use a DLL
in C++, should the DLL procedure or function contain
functions that are not native to Delphi?

In other words, can I use functions such as DateTimeToStr
etc in a DLL that will be used by a C++ program.

Apart from using PChars etc, how will I know that my
DLL will work in other languages?

Thanks
Steven Quail.

"Steven Quail" <squai...@yahoo.com> skrev i melding
news:3aabc57a.0108300844.6c681d4d@posting.google.com...

There are only two things to worry about: Data types (do only use data types
that the other module may handle) and Calling Conventions (How parameters are
passed and who cleans up the stack - see Delphi help on "Colling
conventions"). The two modules (the .exe and the .dll) are separate
applications, their internals don't interfere with each other's. Do also
remember that a running application is not a "Delphi application" - it's a
"Windows Executable". The very same code may be the result of compilers using
different languages.

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorge@takethisaway_itte.no (remve the obvious)

news:3aabc57a.0108300844.6c681d4d@posting.google.com...

You are the one writing translating the header files, so you will very
quickly come to realise what you can and can't do. For simple variables you
can use windows defined types since many of these will be defined in both
languages. In other words someone else has done the thinking for you.
Variants also provide you with a set of types which are defined in both
languages. Beyond this you have to proceed with caution, and be very
conservative in guessing how a particular compiler may work. For example you
can pass a record by var in Delphi and pick it up as a pointer to a
structure in C, but you can't make any assumptions about the byte packing
that will be used, and must use the <packed> keyword with record definition,
and the #pragma pack(1) with the structure type def.

Apart from simple variable types there are issues concerning the trapping of
errors and the interaction of Delphi's structured error handling, Windows
SEH and the C++ native structured error handling. There are also issues if
you want to open windows from within your DLL code. A search of the news
group is a good source of material on these more esoteric problems.

Hope this helps,

Dave

In article <3aabc57a.0108300844.6c681...@posting.google.com>,

In writing DLLs you are dealing with three issues ...

1 The executable interface - are the values passed to the DLL in a way which is
understood by every language and OS using it. Are theparameters placed on the
stack in the same order as the DLL is taking them off. Who clears the values
placed and returned on the stack, the caller or the callee.

2 Are the parameters passed to the DLL understood by every language and OS
using the DLL, for example certain integers and floats are understood because
they are in IEE standard form, PChars are understood by most languages, Delphi
strings are understood only by Delphi. Delphi 1 dates are not understood by VB,
later Delphi dates are. Variants will cover this issue, but use extra memory
and are slower because the multi-byte nature of variants take extra cycles to
construct.

3 Within the DLL, are API calls understood by every OS using the DLL, should OS
version numbers be checked and alternate code be provided.

4 Provided all the above are resolved then any function provided by the DLL
compiling program language can be used within the DLL. So for the DateToStr()
example if the date input from the calling OS and language was understood by
Delphi and if the DLL was displaying the string from the DateToStr() then OK to
use it. If you were passing the DateToStr() output back to a C program then you
would have to convert the string to a PChar to return it.

Alan Lloyd
alangll...@aol.com