POV-Ray : Newsgroups : povray.off-topic : Inspect DLL Server Time
13 Oct 2026 14:43:01 EDT (-0400)
  Inspect DLL (Message 1 to 50 of 61)  
Goto Latest 50 Messages Next 11 Messages >>>
From: Invisible
Subject: Inspect DLL
Date: 12 Oct 2009 05:44:16
Message: <4ad2fa70@news.povray.org>
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?


Post a reply to this message

From: scott
Subject: Re: Inspect DLL
Date: 12 Oct 2009 06:43:43
Message: <4ad3085f@news.povray.org>
> 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?

Google "list dll functions"?  First result is this: 
http://www.nirsoft.net/utils/dll_export_viewer.html

> Can you get an argument list? How about type information?

No. No.


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 06:51:42
Message: <4ad30a3e@news.povray.org>
>> 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?
> 
> Google "list dll functions"?  First result is this: 
> http://www.nirsoft.net/utils/dll_export_viewer.html

Well, it seems to work anyway...

>> Can you get an argument list? How about type information?
> 
> No. No.

I had a feeling that would be the case. The symbols have to be in the 
DLL so you can look them up, but nothing else is required...


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 07:06:56
Message: <4ad30dd0$1@news.povray.org>
C:\WINDOWS\system32\Audio3D.dll

0x100018F0 (0x02) DllGetObjectClass
0x10001A10 (0x03) DllCanUnloadNow
0x10001370 (0x04) _A3d@Create@12

Fascinating stuff, eh?


Post a reply to this message

From: Le Forgeron
Subject: Re: Inspect DLL
Date: 12 Oct 2009 07:13:20
Message: <4ad30f50$1@news.povray.org>
Invisible a écrit :
> 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?

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.


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 08:13:40
Message: <4ad31d74$1@news.povray.org>
Along with a DLL inspector, I find a tool which lists every registered 
COM object in the system.

OK, do you have ANY FRIGGIN IDEA how many COM objects are registered on 
my PC?! Not counting the DLLs registered for that program I already 
uninstalled. Acrobat Reader alone registers about 12 classes. o_O

God only knows what MS Office registers...


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 08:23:32
Message: <4ad31fc4$1@news.povray.org>
Invisible wrote:

> God only knows what MS Office registers...

C:\Program Files\Common Files\Microsoft Shared\Visual Database 
Tools\DVT70.DLL

This single DLL registers exactly 50 ClassIDs. For example:

{03CB9467-FD9D-42A8-82F9-8615B4223E6E}	Microsoft Visual Database Tools 
Database Designer V7.0	MSVDTDatabaseDesigner7

{133E2230-74AF-4A79-8226-7AA2EBC018DA}	DBNamespace Class 
DBNamespace.DBNamespace.7

{1912B299-D07C-45DF-99DF-139D7F6FC4E8}	Primer Class	Primer.Primer.7

{1AECB7EC-4CFB-4866-8E08-8D6961E5C095}	PrimerMgr Class	PrimerMgr.PrimerMgr.7

{2C10A98F-D64F-43B4-BED6-DD0E1BF2074C}	Microsoft Visual Database Tools 
Query Designer V7.0	MSVDTQueryDesigner7

{31E4841B-9B7A-4EF2-8A83-8F1F70D7B0D7}	Microsoft Visual Database Tools 
Query Designer V7.0 Data property page

{3AABDBBA-9C39-400C-BA5A-0186866F8D25}	Microsoft Visual Database Tools 
Query Designer V7.0 Join Line property page

{43872FA3-D283-4CCD-9FC9-281AB33F5D01}	Microsoft Visual Database Tools 
Query Designer V7.0 Procedure Designer property page

I could go on... and that's just one DLL.


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 08:33:51
Message: <4ad3222f$1@news.povray.org>
Invisible wrote:

> This single DLL registers exactly 50 ClassIDs.

Topped that.

C:\Program Files\Java\jre1.5.0_11\bin\ssv.dll

This DLL registers *one hundred and three* ClassIDs:

{CAFEEFAC-0013-0000-0003-ABCDEFFEDCBA}	Java Plug-in 1.3.0_03
{CAFEEFAC-0013-0000-0004-ABCDEFFEDCBA}	Java Plug-in 1.3.0_04
{CAFEEFAC-0013-0000-0005-ABCDEFFEDCBA}	Java Plug-in 1.3.0_05
{CAFEEFAC-0013-0001-0000-ABCDEFFEDCBA}	Java Plug-in 1.3.1
{CAFEEFAC-0013-0001-0001-ABCDEFFEDCBA}	Java Plug-in 1.3.1_01

...see a pattern yet?

Yep, there's a COM registration for every point-releast from 1.3.0_03 up 
to 1.5.0_11. Which is pretty crazy, no?

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!


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 08:59:20
Message: <4ad32828$1@news.povray.org>
C:\Program Files\Windows Media Player\mpvis.dll

Exports the following functions:

0x4B0D7EA0 (0x01) DllCanUnloadNow
0x4B0D8A71 (0x02) DllGetClassObject
0x4B0D8A28 (0x03) DllMain
0x4B0D93C0 (0x04) DllRegisterServer
0x4B0D93D4 (0x05) DllUnregisterServer

Also the COM methods:

(0xC9) IToleranceVis::GetProperty
(0xCA) IToleranceVis::SetProperty

and the COM property:

(0xC8) IToleranceVis::foregroundColor

What this means, I have no idea...


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 09:11:49
Message: <4ad32b15$1@news.povray.org>
Now this is really quite interesting.

I found a DLL called autodisk.dll which exports half a dozen functions 
and hundreds of COM methods and properties. I found several other DLLs 
which apparently export... absolutely nothing. (Why do they exist then?)

Some DLLs for highly complex tasks appear to export a tiny amount of 
stuff, so clearly there's something I'm not seeing. And then there are 
huge, huge numbers of DLLs on the system which aren't registered anywhere.

And who says that staring into a screen full of code numbers is a good 
way to learn stuff? ;-)


Post a reply to this message

From: Warp
Subject: Re: Inspect DLL
Date: 12 Oct 2009 09:34:57
Message: <4ad33081@news.povray.org>
Invisible <voi### [at] devnull> 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?

  That's what headers are for.

-- 
                                                          - Warp


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 09:44:52
Message: <4ad332d4$1@news.povray.org>
>> 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?
> 
>   That's what headers are for.

Or documentation, for that matter.

OTOH, if you don't have either of these...


Post a reply to this message

From: Fredrik Eriksson
Subject: Re: Inspect DLL
Date: 12 Oct 2009 10:05:00
Message: <op.u1oxemzu7bxctx@e6600>
On Mon, 12 Oct 2009 15:11:47 +0200, Invisible <voi### [at] devnull> wrote:
> I found several other DLLs which apparently export... absolutely
> nothing. (Why do they exist then?)

A DLL need not export its functions by name.



> Some DLLs for highly complex tasks appear to export a tiny amount of  
> stuff, so clearly there's something I'm not seeing.

A COM-based DLL need only expose a single function, one that returns a COM  
interface pointer. The complex stuff is then reached through that  
interface.



> And then there are huge, huge numbers of DLLs on the system which aren't  
> registered anywhere.

Not all DLLs are COM servers.



> And who says that staring into a screen full of code numbers is a good  
> way to learn stuff? ;-)

I don’t even see the code anymore; all I see now is blonde, brunette,  
redhead...



-- 
FE


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 10:09:13
Message: <4ad33889$1@news.povray.org>
>> I found several other DLLs which apparently export... absolutely
>> nothing. (Why do they exist then?)
> 
> A DLL need not export its functions by name.

But wouldn't that mean that there's no way to reach its functions? 
(Unless you happen to know the exact base address - which will change in 
the next version of the DLL...)

>> Some DLLs for highly complex tasks appear to export a tiny amount of 
>> stuff, so clearly there's something I'm not seeing.
> 
> A COM-based DLL need only expose a single function, one that returns a 
> COM interface pointer. The complex stuff is then reached through that 
> interface.

I was under the (mistaken?) impression that COM methods are exported as 
DLL functions, and the COM system runs on top of the underlying DLL 
infrastructure.

> Not all DLLs are COM servers.

Indeed.

And even the ones that are don't actually need to be registered; just 
the ones that lots of people might want to find by ClassID. You can 
access a COM server by its file path instead...

> I don’t even see the code anymore; all I see now is blonde, brunette, 
> redhead...

WIN!


Post a reply to this message

From: Fredrik Eriksson
Subject: Re: Inspect DLL
Date: 12 Oct 2009 10:46:35
Message: <op.u1ozbwxg7bxctx@e6600>
On Mon, 12 Oct 2009 16:09:14 +0200, Invisible <voi### [at] devnull> wrote:
>>  A DLL need not export its functions by name.
>
> But wouldn't that mean that there's no way to reach its functions?  
> (Unless you happen to know the exact base address - which will change in  
> the next version of the DLL...)

You can export functions by ordinal (i.e. number).



> I was under the (mistaken?) impression that COM methods are exported as  
> DLL functions, and the COM system runs on top of the underlying DLL  
> infrastructure.

http://msdn.microsoft.com/en-us/library/ms694363(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms682305(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms686615(VS.85).aspx



-- 
FE


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 11:09:07
Message: <4ad34693$1@news.povray.org>
>>>  A DLL need not export its functions by name.
>>
>> But wouldn't that mean that there's no way to reach its functions? 
>> (Unless you happen to know the exact base address - which will change 
>> in the next version of the DLL...)
> 
> You can export functions by ordinal (i.e. number).

And, indeed, a few DLLs show unamed functions exported (i.e., a number, 
but no name).

But some DLLs appear to export *nothing*. Not even unamed functions. I 
suppose they could contain "resouces", but...

>> I was under the (mistaken?) impression that COM methods are exported 
>> as DLL functions, and the COM system runs on top of the underlying DLL 
>> infrastructure.
> 
> http://msdn.microsoft.com/en-us/library/ms694363(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms682305(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms686615(VS.85).aspx

That explains what some of the function calls are, but still doesn't 
really say how it *works* internally.

Still, I guess you don't really need to know. I'm just curious about 
such things.

More puzzling: CoGetClassObject() allows you to get hold of any class by 
its ClassID. CoCreateInstance() creates any object given a ClassID and 
an InterfaceID. This gives you a pointer to the object's interface. But 
I cannot find any way of actually calling methods. If you have a DLL, 
you can do GetProcAddress() to look up a function and call it. But if 
you have an interface pointer, there doesn't seem to be any way to call 
methods of the interface...


Post a reply to this message

From: Warp
Subject: Re: Inspect DLL
Date: 12 Oct 2009 11:14:07
Message: <4ad347bf@news.povray.org>
Invisible <voi### [at] devnull> wrote:
> Or documentation, for that matter.

> OTOH, if you don't have either of these...

  If someone releases a dll but not headers or documentation for it, you'll
probably better avoid using that dll. You can't expect for its interface to
not to change in the future.

-- 
                                                          - Warp


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 11:17:12
Message: <4ad34878$1@news.povray.org>
Warp wrote:

>   If someone releases a dll but not headers or documentation for it, you'll
> probably better avoid using that dll. You can't expect for its interface to
> not to change in the future.

I'm thinking more about writing plugins, but where I don't have any 
documentation that says what functions it's supposed to export. If you 
can find a working plugin, you can find out what it exports.

Of course, with no clue what parameters each such function takes, or 
what the hell it's supposed to do, it's still pretty hopeless I guess...


Post a reply to this message

From: Warp
Subject: Re: Inspect DLL
Date: 12 Oct 2009 11:18:07
Message: <4ad348af@news.povray.org>
Invisible <voi### [at] devnull> wrote:
> I'm thinking more about writing plugins, but where I don't have any 
> documentation that says what functions it's supposed to export.

  Do you really want to write a plugin for a completely undocumented system?

-- 
                                                          - Warp


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 12 Oct 2009 11:33:59
Message: <4ad34c67@news.povray.org>
Warp wrote:

>   Do you really want to write a plugin for a completely undocumented system?

Well, in the case of VST, it's not that it's undocumented, just that you 
have to pay money for the documentation...

...but yeah, I guess it's pretty much a non-starter.


Post a reply to this message

From: Fredrik Eriksson
Subject: Re: Inspect DLL
Date: 12 Oct 2009 12:09:27
Message: <op.u1o251a97bxctx@e6600>
On Mon, 12 Oct 2009 17:09:06 +0200, Invisible <voi### [at] devnull> wrote:
> More puzzling: CoGetClassObject() allows you to get hold of any class by  
> its ClassID. CoCreateInstance() creates any object given a ClassID and  
> an InterfaceID. This gives you a pointer to the object's interface. But  
> I cannot find any way of actually calling methods. If you have a DLL,  
> you can do GetProcAddress() to look up a function and call it. But if  
> you have an interface pointer, there doesn't seem to be any way to call  
> methods of the interface...

An "interface" is a list of function pointers. In C and C++ the layout of  
an interface is typically described in a header file.



-- 
FE


Post a reply to this message

From: Darren New
Subject: Re: Inspect DLL
Date: 12 Oct 2009 12:32:23
Message: <4ad35a17$1@news.povray.org>
Invisible wrote:
> ...see a pattern yet?

Yes. It means Sun is too stupid to even know what a "GUID" is.

> Yep, there's a COM registration for every point-releast from 1.3.0_03 up 
> to 1.5.0_11. Which is pretty crazy, no?

No.

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

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


Post a reply to this message

From: Darren New
Subject: Re: Inspect DLL
Date: 12 Oct 2009 12:34:03
Message: <4ad35a7b$1@news.povray.org>
Invisible wrote:
>> I don’t even see the code anymore; all I see now is blonde, br
unette, 
>> redhead...
> 
> WIN!

For a minute there, I was honestly worried you might say "What?"


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


Post a reply to this message

From: Darren New
Subject: Re: Inspect DLL
Date: 12 Oct 2009 12:36:07
Message: <4ad35af7$1@news.povray.org>
Invisible wrote:
> Of course, with no clue what parameters each such function takes, or 
> what the hell it's supposed to do, it's still pretty hopeless I guess...

Avoid that crap. That's exactly why there's so much crap-ware out there. 
People release crap, and then (even worse) others battle to make it work for 
them in a crappy way instead of just saying "Forget it, this is crap."

(Can you tell I'm sick of crapware today?)

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 14:16:21
Message: <4ad37275$1@news.povray.org>
>> ...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!

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 14:17:23
Message: <4ad372b3$1@news.povray.org>
>>> I don’t even see the code anymore; all I see now is blonde, brunette, 
>>> redhead...
>>
>> WIN!
> 
> For a minute there, I was honestly worried you might say "What?"

Well, it's not as if I've memorised every scene and every line of dialog 
from The Matrix or anything like that...




...Mr Anderson.

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 14:21:15
Message: <4ad3739b@news.povray.org>
>> ...see a pattern yet?
> 
> Yes. It means Sun is too stupid to even know what a "GUID" is.

Did anybody else notice that, unlike every other GUIDE on the planet, 
these ones have a *pattern* in them?

CAFE-EFAC? Oh, that's cute. ABCDEF-FEDCBA? Come on, guys...

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 14:55:04
Message: <4ad37b88@news.povray.org>
Ooo... Gold Dust.

http://msdn.microsoft.com/en-us/magazine/cc301805.aspx

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


Post a reply to this message

From: Darren New
Subject: Re: Inspect DLL
Date: 12 Oct 2009 14:58:27
Message: <4ad37c53$1@news.povray.org>
Orchid XP v8 wrote:
> Surely the correct behaviour would be to register a single interface and 
> give it a "do you support this API version?" method...

Not necessarily. But I'm pretty sure you're not going to get good "globally 
unique identifiers" by manually including english words in them.

> Heh. I lost count of how many Office-related DLLs are in there. There's, 
> like, A LOT!

That's because you can program Office from outside of Office.

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


Post a reply to this message

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 15:23:34
Message: <4ad38236$1@news.povray.org>
Orchid XP v8 wrote:

> http://msdn.microsoft.com/en-us/magazine/cc301805.aspx

Nice of them to include the link to part 2. :-P

http://msdn.microsoft.com/en-us/magazine/cc301808.aspx

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


Post a reply to this message

From: Mike Raiford
Subject: Re: Inspect DLL
Date: 12 Oct 2009 15:40:09
Message: <4ad38619@news.povray.org>
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

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 15:46:57
Message: <4ad387b1$1@news.povray.org>
> 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

From: Mike Raiford
Subject: Re: Inspect DLL
Date: 12 Oct 2009 15:54:34
Message: <4ad3897a@news.povray.org>
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

From: Darren New
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:00:13
Message: <4ad38acd$1@news.povray.org>
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

From: Patrick Elliott
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:13:59
Message: <4ad38e07$1@news.povray.org>
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 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

From: Patrick Elliott
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:19:53
Message: <4ad38f69$1@news.povray.org>
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

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:26:27
Message: <4ad390f3@news.povray.org>
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

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:28:35
Message: <4ad39173$1@news.povray.org>
> 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

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:29:55
Message: <4ad391c3$1@news.povray.org>
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

From: Orchid XP v8
Subject: Re: Inspect DLL
Date: 12 Oct 2009 16:50:34
Message: <4ad3969a$1@news.povray.org>
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

From: clipka
Subject: Re: Inspect DLL
Date: 12 Oct 2009 18:18:37
Message: <4ad3ab3d$1@news.povray.org>
Darren New schrieb:

> Not necessarily. But I'm pretty sure you're not going to get good 
> "globally unique identifiers" by manually including english words in them.

Well, if you /know/ you're the /only/ one stupid enough to do that... :-P


Post a reply to this message

From: clipka
Subject: Re: Inspect DLL
Date: 12 Oct 2009 18:30:41
Message: <4ad3ae11$1@news.povray.org>
Orchid XP v8 schrieb:

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

I once actually did - for a collection of self-made icons I wanted to 
have displayed for certain files in Windows Explorer.


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 13 Oct 2009 04:18:34
Message: <4ad437da$1@news.povray.org>
Fredrik Eriksson wrote:

> An "interface" is a list of function pointers. In C and C++ the layout 
> of an interface is typically described in a header file.

I see. So without the magic table that tells you the index of each 
function pointer, you can't play with COM?


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 13 Oct 2009 04:19:26
Message: <4ad4380e@news.povray.org>
>> 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...)
> 
> I once actually did - for a collection of self-made icons I wanted to 
> have displayed for certain files in Windows Explorer.

Why not just have a bunch of .ico files?


Post a reply to this message

From: Mike Raiford
Subject: Re: Inspect DLL
Date: 13 Oct 2009 11:39:46
Message: <4ad49f42@news.povray.org>
On 10/12/2009 10:34 AM, Invisible wrote:

> Well, in the case of VST, it's not that it's undocumented, just that you
> have to pay money for the documentation...

Naughty mascot. You don't have the license to create plugins. How much 
is the SDK?

-- 
~Mike


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 13 Oct 2009 11:44:38
Message: <4ad4a066$1@news.povray.org>
>> Well, in the case of VST, it's not that it's undocumented, just that you
>> have to pay money for the documentation...
> 
> Naughty mascot. You don't have the license to create plugins. How much 
> is the SDK?

I just object to paying money for somebody to tell me the code numbers 
of a set of functions, that's all.

(Kind of reminds me of that time my employer paid something like £900 
for an envelope containing a sheet of paper with a number printed on it. 
Like, WTF?)

It's not like I'm going to build a multi-million dollar software product 
and not pay Steinburg. I'm only tinkering. ;-)


Post a reply to this message

From: Fredrik Eriksson
Subject: Re: Inspect DLL
Date: 13 Oct 2009 11:45:03
Message: <op.u1qwpctc7bxctx@e6600>
On Tue, 13 Oct 2009 10:18:33 +0200, Invisible <voi### [at] devnull> wrote:
>> An "interface" is a list of function pointers. In C and C++ the layout  
>> of an interface is typically described in a header file.
>
> I see. So without the magic table that tells you the index of each  
> function pointer, you can't play with COM?

Pretty much.

Even if every function had been exposed directly in DLL export tables, you  
would be no better off because you would still need to know the function  
signatures. The bottom line is that you cannot reasonably expect to use an  
interface (of any kind, not just COM) without documentation.



-- 
FE


Post a reply to this message

From: Invisible
Subject: Re: Inspect DLL
Date: 13 Oct 2009 11:51:35
Message: <4ad4a207@news.povray.org>
Fredrik Eriksson wrote:

> The bottom line is that you cannot reasonably 
> expect to use an interface (of any kind, not just COM) without 
> documentation.

Yeah, figures.

Oh well, dream on...


Post a reply to this message

From: Patrick Elliott
Subject: Re: Inspect DLL
Date: 13 Oct 2009 15:24:01
Message: <4ad4d3d1$1@news.povray.org>
Invisible wrote:
>>> 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...)
>>
>> I once actually did - for a collection of self-made icons I wanted to 
>> have displayed for certain files in Windows Explorer.
> 
> Why not just have a bunch of .ico files?
Because it would be a bunch of .ico files? lol Sort of the same reason 
they make zipped files, or one sort or another, with games, for levels. 
You just download/update *one* file, not dozens. Though, unlike dlls, 
patchers will tend to use something similar to the "add to .zip/.rar" 
function when updating things. Even windows uses icons in a dll, keeping 
all the default ones in a single source file, which gets shown in cases 
like where you have a file that doesn't have its own internal icon, and 
you try to change the one being used.

But, yeah. I forgot that dlls can also just be sort of like resource 
forks too.

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

From: scott
Subject: Re: Inspect DLL
Date: 14 Oct 2009 03:05:22
Message: <4ad57832@news.povray.org>
> (Kind of reminds me of that time my employer paid something like £900 for 
> an envelope containing a sheet of paper with a number printed on it. Like, 
> WTF?)

Hehe, we just paid about 4000 pounds for a 46 byte text file :-)


Post a reply to this message

Goto Latest 50 Messages Next 11 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.