 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Yeah, MS asserts that COM is usable on other platforms as well.
I think what they mean is that COM, in *theory*, can be ported to other
platforms. In much the same way that .NET can be reimplemented on other
platforms.
> Anybody know how you actually do this?
We had to write dcom libraries to link to Tcl to do this. It was pretty
ugly, and very fragile.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah, MS asserts that COM is usable on other platforms as well.
>
> I think what they mean is that COM, in *theory*, can be ported to other
> platforms. In much the same way that .NET can be reimplemented on other
> platforms.
The documentation seems to suggest that MS COM is based on some
open-standard COM with a few extensions, and that it's *supposed* to
interoperate with other implementations of that standard.
(Admittedly, if it's anything like IE and its "standards", this won't be
much fun...)
>> Anybody know how you actually do this?
>
> We had to write dcom libraries to link to Tcl to do this. It was pretty
> ugly, and very fragile.
Heh. Fun.
Give me ARexx any day. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The documentation seems to suggest that MS COM is based on some
> open-standard COM with a few extensions, and that it's *supposed* to
> interoperate with other implementations of that standard.
I see. The number of "standard" implementations of the same idea is tremendous.
> (Admittedly, if it's anything like IE and its "standards", this won't be
> much fun...)
To be fair, a lot of what IE does was done before the post-hoc standards
were written. Backward compatibility is a bitch.
> Give me ARexx any day. :-P
Agreed. That was pretty cool.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
