 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ...it all seems like a hell of a lot of work just to write a PNG file.
>
> Why not just go grab libpng? That's how POV-Ray does it.
Isn't that a DLL?
So... I'd *still* need to figure out how DLLs work. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> ...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.
>
> Well, maybe I need to sit down and spend some time creating "COM
> support" for Haskell, and then everything will become trivial. :-P
Well well, it appears there's already a library on Hackage that's
supposed to provide COM support.
Oh, would you look at that? It won't compile. What a *big* surprise...
They really, really need to make it so that packages that call C will
actually compile on Windoze. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 20 Sep 2009 16:24:57 +0200, Orchid XP v8 <voi### [at] dev null> 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.
>
> They have a beta already? Damn, that was fast...
Actually, the RTM (Release-To-Market) version was finished a couple of
months ago and was made available through MSDN and the like on August 6th.
It is scheduled to hit stores on October 22nd.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> (According to Wikipedia, seems to be GetProcAddress()...)
>
> 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.
That's because from C, you call the methods directly via their procedure
addresses - which, as Wikipedia correctly claims, you get via
GetProcAddress().
So you'd need to declare a function pointer to whatever type it should
be according to the COM object's interface definition, assign it a value
via GetProcAddress(), and then invoke that function pointer just like
you would invoke any other function.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> They really, really need to make it so that packages that call C will
> actually compile on Windoze. :-P
... especially if that package is intended to provide COM support, which
doesn't make much sense on other platforms anyway :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>> Why not just go grab libpng? That's how POV-Ray does it.
>
> Isn't that a DLL?
>
> So... I'd *still* need to figure out how DLLs work. ;-)
Here's good news for you: You can compile libpng as a static lib, too -
POV-Ray actually does that (at least on Windows).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> They have a beta already? Damn, that was fast...
No, the beta is already *expired*. :-)
>> 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. ;-)
Not necessarily shared. Just dynamically linked. It happens that on Windows
(and Linux, as far as I know) that such libraries are indeed shared. But you
can have dynmamic linking without sharing and you can have sharing without
dynamic linking.
> (According to Wikipedia, seems to be GetProcAddress()...)
Yes.
> 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?)
It shuts down because huge amounts of the OS are built premised on the
availability of COM. It doesn't completely shut down, of course, but
everything *interesting* does.
> According to the documentation, you write an MIDL file, and the compiler
> generates a header file and two C source code files.
It generates a TBL file, which your tool then reads to generate whatever
language-specific bindings you want.
> Because the MIDL compiler generates this code, so technically you don't
> need to know how it actually works.
A) No it doesn't. It also generates a TBL file.
B) You'd have to know how it works to interface it to any language not
written in C.
> I'm reasonably sure NT 4 has DCOM,
Could be, could be.
>> 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?
Yes. As I said, "Excel" is a COM object. It's running in a separate process.
That's why it's not just a DLL.
>> 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?)
*Every* language can do it. I've done it from Tcl (as well as writing COM
servers). It's trivial from C# and as trivial as anything is in C, and VB,
and WSH. Like I said, WSH is basically a shell designed to do nothing but
COM calls.
> 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.
Hmmm. Well, ship me the two C files from your MIDL, and I'll tell you what
the call it. :-)
> Well, maybe I need to sit down and spend some time creating "COM
> support" for Haskell, and then everything will become trivial. :-P
That's the general idea, yes.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> ... especially if that package is intended to provide COM support, which
> doesn't make much sense on other platforms anyway :-P
Cross-OS DCOM is actually pretty handy. I did that once to parse Excel
spreadsheets from Linux servers.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Cross-OS DCOM is actually pretty handy. I did that once to parse Excel
> spreadsheets from Linux servers.
Yeah, MS asserts that COM is usable on other platforms as well. Anybody
know how you actually do this?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
