RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
I understand your enthousiasm Matt,
but I was just like you when I first started out
designing a COM wrapper for Eu...
"It's not that hard.. Can be done...", but you'll seee
that the more you work on it, the more you understand
that it's just way out of reach to add COM support to
a multiplatform interpreted functional language wich
doesn't support it natively.
The thing that I hated the most, was the issue of
having to create, once again, a crapload of wrapper
libraries for each COM service you want to use.
Setting up the GUIDs and declaring the interfaces for
something like Direct X is no easy task...
Expect porting some 6,000 lines of C++ code to
Euphoria for DX alone...
That's why I'm for better Eu-To-C interfacing, ie.,
you do this;
import d3d.h
And you're all set.
All the defines/constants are imported by Eu, and so
are all the function prototypes.
An example of the process of porting DX to Eu natively
(no extra DLLs and crap).
- You use open_dll() to open up the DX DLL you want.
- You define a C function for Euphoria, such as
Direct3DRMCreate, to create a D3DRM Interface.
- In C++, you use the pointer to an IDirect3DRM
interface passed to Direct3DRMCreate to access
interface members. Like so:
HRESULT h = Direct3DRMCreate(d3drm,...);
Then, you use that to access the members:
d3drm->CreateFrame();
or..
d3drm->CreateViewport();
- How will you do this in Eu?
Do you even know what the IDirect3DRM variable looks
like?
Wanna search through Microsoft's DX code-base trying
to figure out?
I'm a man that tells it how it is.
For example, I don't like crappy wrapper-DLLs.
Why?
Because they're crappy to ship with your product, you
didn't code it but some hobbiest did, and for
portability, it's a major blockage.
What if my code checks to see wich platform it runs
on, if DOS, use Software rendering, if Win32, use DX.
Should people that wanna run my code in DOS worry
about that DLL required for Windows?
I just don't like it all..
Otherwise, it would take me 3 hours to port DX8 to
Euphoria with a wrapper DLL.
I'd just turn the DX C macros to functions, and export
them.
No need for COM then, just raw function calls.
But I don't wanna do this, cos I don't like it.
Why am I talking about DX so much?
Because lets face it, who ever worried about COM or
even looked at it if it weren't for DX?
And nope, DX is not Windows-only.
The X-Box will use it, an extremely powerfull
videogame console from Microsoft.
Even the Dreamcast supports a Direct X version.
In short: Wanna code games?
Code DX.
Mike The Spike
--- Matthew Lewis <matthewwalkerlewis at YAHOO.COM>
wrote:
> > -----Original Message-----
> > From: Mike The Spike [mailto:mtsreborn at yahoo.com]
>
> <snip>
>
> > Now what is offset+4?
> > Is it IID_IDirect3DRM->CreateViewport?
> > You should do a lot of work figuring out at wich
> > offset members are, in theory it's all possible,
> but
> > for practical uses, it's not.
> > Just like it's theoretically possible to travel
> > through time, it don't mean we can go for a trip
> to
> > the middle ages for 29.95 pluss tax?
>
> I think you're being a bit over dramatic [again].
> If you know the layout of
> the interface, it's easy. You'd have to know this
> to use C++ to work with
> COM. You have to know this in _any_ language to
> work with COM. So what's
> the big deal?
>
> I've done some more poking around, and I think it's
> definitely possible.
> Even if you don't have the docs on the layout of an
> interface, using
> IDispatch, it should be possible to get the info
> that's needed. In fact, it
> should be able to spit out a bare bones wrapper for
> a COM object.
>
> As far as I can tell, there's no real need to use an
> actual pointer table in
> memory. We could simply use sequences to keep track
> of things, the same way
> we already use them to deal with routine_id's.
>
> I've looked a little harder at asm.e, and it's not
> quite as hard as I
> thought (I think :). I need to add support for CALL
> FAR, but that looks
> pretty straightforward. I should have Eu working
> with COM pretty shortly
> given that.
>
> > In conclusion, your compiler should support
> by-name
> > refferncing of structure/class/interface members
> for
> > COM to work.
>
> Maybe so, but that just means a little extra work if
> you want to support
> COM. Certainly doesn't make anything _impossible_,
> as you say. Here's what
> I envision use of my wrappers might look like:
>
> -- file: com.ew
> global constant
> iid_iunknown =
> "00000000-0000-0000-C000-000000000046"
> -- end com.ew
>
> constant
> myobj = new_com_object( clsid ),
> myobj_queryinterface = define_com_func( clsid,
> iid_iunknown,
> "QueryInterface")
>
> object ok
>
> ok = com_func( myobj, myobj_queryinterface, {} )
>
> Basically, I want to make it operate as close to
> Eu's c_proc/c_func as
> possible, although it will handle string conversions
> automatically, since
> all COM strings need to be unicode. Then it makes
> sense to write wrappers
> for individual COM objects using the COM wrappers.
>
> > Besides, you talk about GUIDs, look up how you
> have to
> > work with GUIDs, and you'll see that it's by using
> > some COM interfaces. It's the whole
> chicken-and-egg
> > thing.
>
> Yeah, I have. But I don't understand what you're
> talking about. The issue
> of GUID's is there no matter what language you use.
> It's not _that_
> difficult to use them. Here's a proc for converting
> a GUID from a string to
> a proper GUID structure:
>
> procedure poke_guid( sequence guid, atom ptr )
> object ok
>
> -- struct GUID
> -- DWORD Data1
> -- WORD Data2
> -- WORD Data3
> -- BYTE Data4[8]
>
> ok = value( "#" & guid[1..8] )
> ok = ok[2]
> poke4( ptr, ok )
> ptr += 4
>
> guid = guid[10..length(guid)]
>
> for i = 1 to 2 do
> ok = value( "#" & guid[1..4] )
> ok = ok[2]
> poke4(ptr, ok)
> ptr += 2
> guid = guid[6..length(guid)]
> end for
>
> for i = 1 to 2 do
> ok = value( "#" & guid[1..2] )
> ok = ok[2]
> poke(ptr,ok)
> ptr += 1
> guid = guid[3..length(guid)]
> end for
>
> guid = guid[2..length(guid)]
>
> for i = 1 to 6 do
> ok = value( "#" & guid[1..2] )
> ok = ok[2]
> poke(ptr,ok)
> ptr += 1
> guid = guid[3..length(guid)]
> end for
>
> end procedure
>
> There. That wasn't so hard, was it?
>
> Matt Lewis
>
|
Not Categorized, Please Help
|
|
