🚀 go-pugleaf

"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 

"Denville Longhurst" <denville@metco.co.uk> wrote in message 
news:4817969d$1@newsgroups.borland.com...
>I have a .dll which was intended for use in a VC++ app.  I don't have vc++ 
>but I have to asume that it compiles ok.
>
> 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.  I have tried loading the dll 
> both statically and dynamically but I can't get to the function.  If I 
> examine the actual .dll I can see the required function name but only in 
> one place, whereas all the other function names occur twice (one in the 
> export list and once later).
>
> So question is, does vc++ have some other mechanism to access this 
> function, and can I tap into it?
>
> NB the function is clearly intended to be exported; it is published in the 
> .h file and is clearly doccumented, indeed it is essential to the 
> application.

The function may be just exported by number. Use Depends.exe to see a full 
listing of what is exported.

Leo Havm�ller. 

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
> 

Thanks for that, a very interesting tool.

No, my required function is not listed in the dll, so I guess they have 
supplied an old or broken dll with the sdk.

Thanks again.

Denville.

"Leo Havm�ller" <rtxleh@nospam.nospam> wrote in message 
news:4817f107$1@newsgroups.borland.com...
> "Denville Longhurst" <denville@metco.co.uk> wrote in message 
> news:4817969d$1@newsgroups.borland.com...
>>I have a .dll which was intended for use in a VC++ app.  I don't have vc++ 
>>but I have to asume that it compiles ok.
>>
>> 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.  I have tried 
>> loading the dll both statically and dynamically but I can't get to the 
>> function.  If I examine the actual .dll I can see the required function 
>> name but only in one place, whereas all the other function names occur 
>> twice (one in the export list and once later).
>>
>> So question is, does vc++ have some other mechanism to access this 
>> function, and can I tap into it?
>>
>> NB the function is clearly intended to be exported; it is published in 
>> the .h file and is clearly doccumented, indeed it is essential to the 
>> application.
>
> The function may be just exported by number. Use Depends.exe to see a full 
> listing of what is exported.
>
> Leo Havm�ller. 

"Denville Longhurst" <denville@metco.co.uk> wrote in message 
news:4818202a$1@newsgroups.borland.com...

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

Then it should be exported properly.  If it is not, then the DLL author 
likely goofed up when compiling it.

> I examined the .dll using a program called WinHex which
> provides a hex and an ascii dump of any file.

That is not the best way to examine executables.  I suggest you use an 
actual PE viewing tool instead.  That will show you the actual exports table 
(and imports, resources, etc).

> All of the functions within the dll are listed twice

Which means nothing without knowing what kind of tables they are actually 
listed in.

> once in what is obviously the export list, and again later I
> presume at the implementation

Implementation names are not stored anywhere in the DLL.  They are resolved 
to memory addresses by the compiler.  The exports table is a look-up table 
that maps the exported name to the cooreponding address within the DLL.

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

Which DLL specifically are you actually trying to use?  Which function?  Is 
this a Microsoft DLL, or a third-party DLL?


Gambit 

I am certain now that, as you say, the dll writer goofed up.  As well as 
looking 'inside' the dll with WinHex I have used IMPDEF, IMPLIB and 
DEPENDS.EXE, none of which include the function among those exported.

For info, the .dll comes from a firm called Digi, manufacturers of embedded 
network devices, some of which I have programmed for special functionality 
(all that is fine).  As part of the SDK they supply a .dll containing 
functions that a PC/Windows app can use to discover and list all units on 
the network, and it is this dll that is missing the essential function.  I 
can see that what has happened is that the dll has recently been modified by 
the addition of a new version of this function and that's where, somehow, it 
got gooed up.

Unfortunately the sample source using the dll is writen for VC++ which I 
don't have, but I bet if I did, it wouldn't compile.  I was just a bit 
worried that Microsoft might have sneaked some new access mechanism into 
VC++.

Following your previous reply I had the confidence to put the manufacturer 
on the spot and they are now (I hope) taking it seriously.

Tks again,
Denville.

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:48189e32$1@newsgroups.borland.com...
>
> "Denville Longhurst" <denville@metco.co.uk> wrote in message 
> news:4818202a$1@newsgroups.borland.com...
>
>> 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.
>
> Then it should be exported properly.  If it is not, then the DLL author 
> likely goofed up when compiling it.
>
>> I examined the .dll using a program called WinHex which
>> provides a hex and an ascii dump of any file.
>
> That is not the best way to examine executables.  I suggest you use an 
> actual PE viewing tool instead.  That will show you the actual exports 
> table (and imports, resources, etc).
>
>> All of the functions within the dll are listed twice
>
> Which means nothing without knowing what kind of tables they are actually 
> listed in.
>
>> once in what is obviously the export list, and again later I
>> presume at the implementation
>
> Implementation names are not stored anywhere in the DLL.  They are 
> resolved to memory addresses by the compiler.  The exports table is a 
> look-up table that maps the exported name to the cooreponding address 
> within the DLL.
>
>> 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.
>
> Which DLL specifically are you actually trying to use?  Which function? 
> Is this a Microsoft DLL, or a third-party DLL?
>
>
> Gambit
> 

"Denville Longhurst" <denville@metco.co.uk> wrote in message 
news:4818baa1$1@newsgroups.borland.com...

> I can see that what has happened is that the dll has recently
> been modified by the addition of a new version of this function
> and that's where, somehow, it got gooed up.

Or, maybe they simply removed the old function altogether, but did not 
update the documentation accordingly?  Assuming the new function is exported 
properly, that is.


Gambit 

No, the problem is that the new function -isn't- exported and the old 
function (which is) is depreciated and doesn't work any more.

Denville.

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:4818d034$1@newsgroups.borland.com...
>
> "Denville Longhurst" <denville@metco.co.uk> wrote in message 
> news:4818baa1$1@newsgroups.borland.com...
>
>> I can see that what has happened is that the dll has recently
>> been modified by the addition of a new version of this function
>> and that's where, somehow, it got gooed up.
>
> Or, maybe they simply removed the old function altogether, but did not 
> update the documentation accordingly?  Assuming the new function is 
> exported properly, that is.
>
>
> Gambit
>