🚀 go-pugleaf

Thanks for that, it is as I thought.

The function is absolutely fundamental, the support documentation states 
that it must be the first function called to get a handle to one or more 
embedded devices attached to the network.  All subsequent functions rely on 
this handle.  Without it no other function call can succeed.  I can get to 
all of the other functions in the normal ways.

I examined the .dll using a program called WinHex which provides a hex and 
an ascii dump of any file.  All of the functions within the dll are listed 
twice, once in what is obviously the export list, and again later I presume 
at the implementation.  This particular function is only listed once, not in 
the export list.

I think the dll supplied with this sdk must be broken, I just wanted to 
check that MS hadn't added some new mechanism that I wasn't aware of.

Thanks again for your time.

Denville.

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:4817ac85$1@newsgroups.borland.com...
>
> "Denville Longhurst" <denville@metco.co.uk> wrote in message 
> news:4817969d$1@newsgroups.borland.com...
>
>> I need to use this .dll in my app.  The thing is that it contains
>> an essential function that is not specifically exported (ie I run
>> impdef on the .dll and the func is not listed.  I run implib and
>> examine it (WinHex) and there is no trace of the function name.
>
> Then you will not be able to use it at all.
>
>> I have tried loading the dll both statically and dynamically but
>> I can't get to the function.
>
> You can't access something that is not exported
>
>> If I examine the actual .dll
>
> Examined how exactly?  Are you just looking at the raw binary data, or are 
> you using a PE explorer tool?
>
>> So question is, does vc++ have some other mechanism to access
>> this function, and can I tap into it?
>
> No.
>
>> the function is clearly intended to be exported
>
> Then it would be listed in the export table so GetProcAddress() could find 
> it.
>
>> it is published in the .h file
>
> That does not necessarily mean that the function was meant to be exported. 
> The DLL could have simply been compiled using the same .h file, where the 
> .h file contains declarations for its internal functions as well as its 
> public functions.
>
>> and is clearly doccumented, indeed it is essential to the application.
>
> Then it would have been exported from the DLL to begin with.
>
>
> Gambit
>