[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Dlls and tradestation



PureBytes Links

Trading Reference Links


> -----Original Message-----
> From: Mark Smeets [mailto:mark@xxxxxxxxxxx]

> Ok, I did that, but the problem remains. I've edited the def file to
> read
> 
> LIBRARY     SIMPLE.DLL
> 
> EXPORTS
>     FROT                       @1   ; FROT
>     ___CPPdebugHook                @2   ; ___CPPdebugHook
> 
> I guess I'll need to run a tool to modify the dll now. Tradestation
> probably doesn't read the DEF file directly. Can't find anything in the

TradeStation doesn't read the .def, that's used by the linker to tell
it what functions to export, add copyright text, etc.

> help files to achieve this though. Maybe I should switch to Visual C++?

Does Borland have a tool to create a .lib file from a .dll and then
to list the contents of the .lib?  You might want to try that.

My recollection from 4y ago was that Borland (and Watcom) did not
implement the name mangling of __stdcall (they implemented the parm
passing and return semantics, just not the name mangling) .  In most
cases this wasn't a problem (if the app was doing a simple
GetProcAddress(hdl, "Foo")) but it's a possibility.  At the time it
was because they were still implementing the older 32-bit object
format (which name I can't recall now) and not COFF (Common Object
File Format).

I don't know about Borland but for Watcom I got around this by
creating aliases e.g.  if I created int Foo(int) Watcom would export
'Foo' and I'd also export '_Foo@x' as an alias for 'Foo'.  Borland
might have a similar capability.  This would allow an import lib for
a Watcom generated DLL to be used by Visual C++ and Watcom / Borland.

I'm not sure that this is your problem - as I said I think that
GetProcAddress() will try to user either signature.

Generating a .lib from the .dll and then doing a list will tell you
what symbols are being expored by the DLL and what they look like
(their signatures)

As I mentioned in one of the msgs I posted to MrEasyLanguage you need
to do two things when debugging getting a DLL running under TS:

1) first determine if your DLL is getting loaded (i.e. that DllMain()
is being entered)

2) determine if your API is being called.

The error message generated by TS I believe don't distinguish between
a failure to find / load the DLL and a failure to get the requested
entry point.

If you verified #1 but not #2 this might point you to the name
mangling problem...

Cheers,
Brendan
---
Brendan B. Boerner
brendan@xxxxxxxxxxxxxx
Karakhorum Ventures, Inc.
www.Karakhorum.com