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

They have a beta already? Damn, that was fast...

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

Actually, MSDN does a surprisingly good job of documenting this 
information, yes.

>> - 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 other words, it's a shared library. I more or less knew they before. ;-)

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

I just meant I haven't found the actual function call for getting access 
to the exposed symbols yet.

(According to Wikipedia, seems to be GetProcAddress()...)

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

Sure. But in this case, I'm talking about Microsoft RPC. As in, that 
service that if it stops running, your entire PC shuts down for some 
reason... (MS Blaster, anyone?)

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

I'm not quite following.

According to the documentation, you write an MIDL file, and the compiler 
generates a header file and two C source code files. You link one into 
the client, and one into the server. (I haven't tried it, so I don't 
know what's actually *in* these C files, mind you...)

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

Because the MIDL compiler generates this code, so technically you don't 
need to know how it actually works. (Also, I couldn't find any functions 
anywhere which looked likely.)

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

I'm reasonably sure NT 4 has DCOM, but possibly with NTLM authentication 
only. Windows 2000 is where they added Kerberos, for sure.

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

...you mean the object can be doing other stuff by itself before you 
specifically ask it to do something?

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

Heh. I had always assumed that such tasks are simply impossible, because 
I've never come across a programming language that can do them. (Well, 
except VB. And who the hell understands that?)

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

But, uh, isn't IDispatch::Invoke *itself* a COM method??

Seriously, I see CoInitialise() and CoUninitialise() to start/stop the 
COM library. I see CoGetClassObject() and CoCreateInstanceEx(), but I 
can't see a CoCallMethod() or similar anywhere.

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

Well, maybe I need to sit down and spend some time creating "COM 
support" for Haskell, and then everything will become trivial. :-P

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

Post a reply to this message