Orchid XP v8 wrote:
> 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).

Of course it's available. Not the release version, but the betas.

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

It's not *that* hard to figure out which 2% of the features in the OS are 
new to Windows 7 and which are the same stuff that's been around for 5+ years.

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

Yes. It's a dynamically-linked library. Says it right there in the name. :-)

In the beginning of the file is a table of names and pointers. You can look 
up the name to get the pointer, or you can just branch indirectly thru the 
pointer if you know at compile time its offset.

http://en.wikipedia.org/wiki/Dynamic-link_library

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

Well, RPC is a generic term, meaning to invoke a procedure in someone else's 
address space. Sun took the term and used it to refer to their particular 
implementation. Ever since, "RPC" has been like "PC" - do you mean Personal 
Computer or an IBM compatible machine running MS-DOS?

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

Right. Actually, not quite right. What it spits out is a description of the 
COM interface. Then your compiler takes that description and generates the 
actual code to call it. It's not some secret code. It's a well-defined 
interface that any compiler can implement. Heck, I can call it from Tcl.

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

Yes. Because the best way to promote everyone to use your technology is to 
not document how to incorporate it into your code.

Sheesh.

Even *wikipedia* documents what the calls are. Why would you think it's secret?

> The data is then sent either via local IPC or network RPC packets to the 
> server side.

Yes.

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

Basically, yes.

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

Everything from Windows 2000 on, which I believe is where they introduced 
DCOM.  Regular COM, where you're calling a different process on the same 
machine, obviously doesn't need authentication, encryption, etc.

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

Exactly. Plus, it's an active object, i.e., what people call an "Actor". A 
process running Excel is basically one big COM object, with methods like 
"open a spreadsheet" and "return the value of column B row 27." That's how 
people do these automation tasks.

> Again, I haven't actually figured out how to *call* a COM method.

You can use IDispatch::Invoke for dynamically linked stuff.

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

http://en.wikipedia.org/wiki/IDispatch

http://msdn.microsoft.com/en-us/library/ms221479.aspx

I'll grant you, that one was a bit ugly. :-)


> ...it all seems like a hell of a lot of work just to write a PNG file. 

Only because your language doesn't already have COM in it. Once you get the 
basics worked out, then you can say "How do I convert an Excel spreadsheet 
to a pie chart as a GIF file" and do it with the same code.

Most programming languages have the COM stuff already built for them (which 
is kind of the poing of making it standard, see) so it's just a matter of 
invoking the component.

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

Post a reply to this message