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