On 10/12/2009 6:06 AM, Invisible wrote:
> C:\WINDOWS\system32\Audio3D.dll
>
> 0x100018F0 (0x02) DllGetObjectClass
> 0x10001A10 (0x03) DllCanUnloadNow
> 0x10001370 (0x04) _A3d@Create@12
>
> Fascinating stuff, eh?

That looks like a COM Dll... See if there's a .tlb file somewhere, or if 
there's a type library embedded. Use oleview.exe:

http://www.microsoft.com/DownLoads/details.aspx?FamilyID=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en

-- 
~Mike

Post a reply to this message

> That looks like a COM Dll... See if there's a .tlb file somewhere, or if 
> there's a type library embedded. Use oleview.exe:
> 
>
http://www.microsoft.com/DownLoads/details.aspx?FamilyID=5233b70d-d9b2-4cb5-aeb6-45664be858b6&displaylang=en


Ooo... shiny.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 10/12/2009 6:13 AM, Le_Forgeron wrote:

> Worse, How do you find which DLL are needed by a DLL ?
> There is a "dependancy walker" (from  steve P. Miller) but that might
> not provide the argument list.

It won't. If you're lucky, the DLL will have C++ mangled names. That 
will give you the types of parameters, provided you can decode the name 
mangling. Good luck with that.

You'll notice some C functions often have an @ followed by a number. 
IIRC, that's the number of bytes that should be on the stack when the 
function is called. But, that's about as informative as it gets. No 
names for the parameters, especially no description of what they do. 
You're playing blind. Better be good at reading assembly to find out how 
the parameters are being used. ;)

-- 
~Mike

Post a reply to this message

Orchid XP v8 wrote:
> Nice of them to include the link to part 2. :-P

I have noticed that virtually nobody actually goes back and fixes earlier 
blog links to link to subsequent parts.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Invisible wrote:
> OK, so here's a question: I think I understand how to load a DLL and 
> call the functions it exports, but... how do you find out what functions 
> a DLL exports?
> 
> I mean, one way would be to find some documentation. But if you don't 
> have any... is there some way to inspect the symbol list somehow? Can 
> you get an argument list? How about type information?
Depends. Are we talking a COM supporting one? There are three flavors of 
dll, one has internal entry points that you need a linking table to get 
at. I.e., there is no stored internal data on what is there. Full COM 
supporting ones (one ones using any such variation on the concept) 
include an internal table and some standard method of "asking" what all 
the calls, variables, types, etc. are. The third is a kind of hybred, 
where "some" of the internals are exposed via the interface, but others 
have been intentionally designed to only allow linking using the 
header/table used to inform a compiler what they are.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Orchid XP v8 wrote:
>>> ...see a pattern yet?
>>
>> Yes. It means Sun is too stupid to even know what a "GUID" is.
> 
> This was my conclusion also.
> 
> Surely the correct behaviour would be to register a single interface and 
> give it a "do you support this API version?" method...
> 
>>> Next time you install some program and it says "registering 
>>> components" or "writing registry keys", this is what it's doing. It's 
>>> registering millions of COM ClassIDs!
>>
>> Yes.
> 
> Heh. I lost count of how many Office-related DLLs are in there. There's, 
> like, A LOT!
> 
You sure you don't have "older" versions still installed too? When you 
update the JRE it tends to leave prior versions, as a "just in case your 
program requires some bug that was only in 1.3.0_03, but got fixed 
later. I had to go back and manual uninstall like 4-5 of these, to free 
up space on my HD. I stupidly installed them in C:, and didn't realize 
at the time that the small size of that was going to produce bad 
results, or that Sun didn't "replace" the install, instead of just 
installing a new one.

Still, you get a bit of some of that with MS too, just not as much. In 
principle, the version isn't relevant, only if the function is there, 
and yes, if you do need a version, the sane solution is to ask if there 
is an interface that is backward compatible to it in there some place.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:

> You sure you don't have "older" versions still installed too?

Yes. I disabled autoupdates. Where I work, I have to document exactly 
which version of the JRE I'm running. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> I have noticed that virtually nobody actually goes back and fixes 
> earlier blog links to link to subsequent parts.

Indeed, part 2 links to part 1, but not the other way around...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Patrick Elliott wrote:

> Depends. Are we talking a COM supporting one? There are three flavors of 
> dll, one has internal entry points that you need a linking table to get 
> at. I.e., there is no stored internal data on what is there. Full COM 
> supporting ones (one ones using any such variation on the concept) 
> include an internal table and some standard method of "asking" what all 
> the calls, variables, types, etc. are. The third is a kind of hybred, 
> where "some" of the internals are exposed via the interface, but others 
> have been intentionally designed to only allow linking using the 
> header/table used to inform a compiler what they are.

The situation is far more complex than I imagined.

Apparently it is notionally possible to construct a DLL which actually 
contains no executable code at all, only data. (Although I highly doubt 
anybody *does* this...)

Man, the more you look, the more complex it gets! :-}

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

My head hurts from reading about the wild zoo of possibilities here. 
Damn, I wonder if I'll ever actually figure this stuff out? :-/

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message