🚀 go-pugleaf

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
>