POV-Ray : Newsgroups : povray.off-topic : Low-level fun : Re: Low-level fun Server Time
28 Sep 2024 19:21:05 EDT (-0400)
  Re: Low-level fun  
From: Orchid XP v8
Date: 19 Sep 2009 14:52:22
Message: <4ab52866$1@news.povray.org>
>> (Gotta love the way half the stuff on MSDN turns out only to be 
>> applicable to Windows 7. 
> 
> That is the one problem with Microsoft's online documentation. They 
> don't put the old stuff online in a way that's easy to find. If you 
> don't stay on the upgrade treadmill, you need to buy copies of the 
> documentation if you want to keep working.

But of *course*, if you're writing new software, you will only be 
interested in making it work for Windows 7 (which, I add, isn't even 
available yet). Why would you want to target the OS that 99% of your 
market is still using when you could target some brand new unreleased 
one and thus force everybody to actually buy it?

>> ...so now I'm trying to figure out what the hell COM is. :-/
> 
> Object-oriented remote procedure calls. You know what object-oriented 
> is? You know what remote procedure calls are? Slap the two together. 
> That's COM. It's typed and reflexive. It's basically one step up from 
> DLL, in that it can be a DLL running in a separate process or even a 
> separate machine (via "DCOM"). You're probably linking in a file that 
> takes your local procedure calls, packages up (aka "marshalls") the 
> arguments, and then sends them to the COM subsystem which delivers them 
> to the appropriate task for execution.
> 
> It's basically how all software talks to other software on Windows if 
> you don't want to be hard-coding stuff in at compile time like function 
> offsets. It's how Word talks to Excel, how the help subsystem talks to 
> IE, how ActiveX talks to IE, and how Windows Scripting Host talks to 
> everything. Pretty much every line using an "object" in WSH is talking 
> to that object via COM.

After spending a couple of hours on this, here's what I managed to 
figure out:

- A DLL is a file containing a set of procedures. You can dynamically 
load it into memory and call these procedures. (I'm not precisely sure 
how...)

- RPC is both a network protocol and a system for calling procedures in 
another running program. This program may or may not be running on the 
same computer.

As best as I can tell, you write a list of procedures that you want to 
be able to call remotely, and run this through the MIDL compiler. This 
spits out two blobs of code. You link one into your client, and it 
enables you to call these procedures just like any other procedure. 
However, what the generated code actually does is scoop up the 
parameters passed, serialise them somehow, and then presumably call some 
secret undocumented Win32 function to actually send this data somewhere. 
The data is then sent either via local IPC or network RPC packets to the 
server side.

The code blob linked into the server then unserialises the data and 
calls the actual procedure inside the server. Then the procedure's 
return value (if any) goes through the same process in reverse, ending 
up at the client end just like a normal procedure call.

Oh, and there's optional authentication, encryption, asynchronous 
messaging, message queues (but only in Windows 2000, no other OS), and a 
bunch of other stuff that didn't make sense.

- COM allows you to create objects, find out what interfaces they 
support, and call the functions in those interfaces. These objects can 
be provided by a DLL loaded into your program, an EXE running on the 
same computer, or (hypothetically) a program running on some remote 
computer. So it's like a system that can DLL procedure calls or RPC 
calls - and you don't have to care which.

Again, I haven't actually figured out how to *call* a COM method. I have 
however figured out how to create an object, find out what interfaces it 
has, and get hold of the one you want. What I can't find anything about 
is how you get from having the interface to calling one of the methods 
it contains...

...it all seems like a hell of a lot of work just to write a PNG file. 
Maybe it would be quicker (and more portable) to just read the PNG file 
spec and write my own encoder? (Except that, well, have you *seen* the 
algorithm?! Complicated, much??)

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


Post a reply to this message

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