1. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
> -----Original Message-----
Sigh, this is getting kind of old...
> You saw the 3DEL, (3D Engines List) and think 'Hey!
> That's cool! Lemme download one!'...
> But then you figure 'Oh crap! I can't use these with
> Euphoria, for they are C libraries!!'...
> [Intermezzo; What do you nottice? That Euphoria should
> be able to link to C libraries, like I showed you with
> the translator and MTSECW.]
Why can't Euphoria link to C libs (as long as they've been compiled into
dll's or so's)? Actually, at this point you should be able to link them
fairly easily using the translator, as well.
> [Intermezzo; The reason for there being no engines is
> because of the fact that Euphoria is too slow to code
> one in, and you can't use special toolkits like Direct
> X or Glide to boost performance, because Eu don't
> support linking to COM and C libraries.]
I don't know too much about COM, but I don't see why Eu can't, unless it's
because COM is C++ based, rather than C. There should be no real reason why
Eu couldn't link up with anything with a C-based API. You just have to
figure out the API.
> You wanna make cash as a coder?
> Big cash?
> While working at home?
> You start coding a game.
We kinda had this discussion a few days ago. There are a lot of reasons why
no one has coded a Quake clone in Eu, the least of which is the lack of a
3-D engine.
> Now why is it that Euphoria is so damned bad at game
> coding?
Frankly, the only people I've heard say that are you and Ferdinand. Not
exactly the authoritative sources on programming.
> No, that's not a question...
> It's an awnser, see, this is why;
>
> - No COM support (DX? Nope, sorry...)
> - No portability (PSX? PS2? N64? Nope, sorry...)
> - No interfacing with C (Glide? Glut? Nope, sorry...)
Frankly, portability is just about the last thing I'm interested in (and I'm
sure there are a lot more out there). I can certainly see the benefits of
supporting Solaris or maybe Mac, but I can't see myself ever being
interested in the consoles.
And your continued ignorance of the ability of Eu to interface with C
continues to baffle me. What about ODBC? DDE? EuSDL (I think this was a
cross platform graphics lib in the archives)? etc...
If you want really fast 3-D graphics, you're probably going to have to use
ASM, just like everyone else. If you're like most coders, though, you'll
probably never need anything resembling a 3-D engine.
> And... And... (*shakes fist*) ...ah (w)hell, you get
> my drift...
No, not really....
Matt Lewis
2. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
--- Matthew Lewis <matthewwalkerlewis at YAHOO.COM>
wrote:
> > -----Original Message-----
>
> Sigh, this is getting kind of old...
>
> > You saw the 3DEL, (3D Engines List) and think
> 'Hey!
> > That's cool! Lemme download one!'...
> > But then you figure 'Oh crap! I can't use these
> with
> > Euphoria, for they are C libraries!!'...
>
> > [Intermezzo; What do you nottice? That Euphoria
> should
> > be able to link to C libraries, like I showed you
> with
> > the translator and MTSECW.]
>
> Why can't Euphoria link to C libs (as long as
> they've been compiled into
> dll's or so's)? Actually, at this point you should
> be able to link them
> fairly easily using the translator, as well.
Yeah right...
For one, you need to know C and own a C compiler, plus
you have to know how to create DLLs and SO's, you have
to edit the existing source code, etc.
For two, what about DOS?
Oh, and yeah, what are you gonna do when version x.x
of a library is released?
Repeat the proccess and start all over, building your
DLL?
And BTW, DLLs and SOs suck.
They're a pain in the neck to ship with a commercial
program, while it could have being Stand Alone.
> > [Intermezzo; The reason for there being no engines
> is
> > because of the fact that Euphoria is too slow to
> code
> > one in, and you can't use special toolkits like
> Direct
> > X or Glide to boost performance, because Eu don't
> > support linking to COM and C libraries.]
>
> I don't know too much about COM, but I don't see why
> Eu can't, unless it's
> because COM is C++ based, rather than C. There
> should be no real reason why
> Eu couldn't link up with anything with a C-based
> API. You just have to
> figure out the API.
Err....
no...
COM/OLE/ActiveX in Euphoria?
No way pal, no can do...
That's impossible...
If I can't do it, probably no one can...
>
> > You wanna make cash as a coder?
> > Big cash?
> > While working at home?
> > You start coding a game.
>
> We kinda had this discussion a few days ago. There
> are a lot of reasons why
> no one has coded a Quake clone in Eu, the least of
> which is the lack of a
> 3-D engine.
Exactly...
> > Now why is it that Euphoria is so damned bad at
> game
> > coding?
>
> Frankly, the only people I've heard say that are you
> and Ferdinand. Not
> exactly the authoritative sources on programming.
Atleast we tend to know WTH is going on out there...
No, writing a 3D game does not include coding a Super
Mario Brothers, or Wolfenstein 3D clone, you'll have
to do Waaaaay better than that.
Hardware Acceleration is a *must*, for example.
All HA libraries out there are virtually impossible to
use from Euphoria, without having to write a C wrapper
DLL to interface everything (slow, ugly, proprietary,
etc. ).
> > No, that's not a question...
> > It's an awnser, see, this is why;
> >
> > - No COM support (DX? Nope, sorry...)
> > - No portability (PSX? PS2? N64? Nope, sorry...)
> > - No interfacing with C (Glide? Glut? Nope,
> sorry...)
>
> Frankly, portability is just about the last thing
> I'm interested in (and I'm
> sure there are a lot more out there). I can
> certainly see the benefits of
> supporting Solaris or maybe Mac, but I can't see
> myself ever being
> interested in the consoles.
That's what you say, but the rest of us would like to
code an app, burn it to a CD and slap it into our PSX,
stun our friends, and maybe even show to a publisher.
I'm not going into the marketing/financial benefits
for RDS, otherwise I'd be repeating myself... ;)
> And your continued ignorance of the ability of Eu to
> interface with C
> continues to baffle me. What about ODBC? DDE? EuSDL
> (I think this was a
> cross platform graphics lib in the archives)? etc...
Ditto man.
Lemme see...
ODBC?
Don't make me laugh...
What about ADO, DBASE, DAO, etc?
Wait, they're COM!
Oh my!
DDE?
Muhahaha...
The same...
EuSDL?
Come one, SDL???
Name one commercial game/app that uses it...
Who cares about SDL?
Especially when there is no way to use the BeOS
version with Euphoria.
SDL is suck...
Give me DirectX 8.0 anyday...
> If you want really fast 3-D graphics, you're
> probably going to have to use
> ASM, just like everyone else. If you're like most
> coders, though, you'll
> probably never need anything resembling a 3-D
> engine.
Ahem...
ASM for a 3D Engine?
When, in the Dark Ages?
Today you don't need ASM because A. your average
PSX/PS2/DC/N64 don't support it and B. you use a 3DAPI
wich does things for you.... Well, unless you code in
Euphoria...
> > And... And... (*shakes fist*) ...ah (w)hell, you
> get
> > my drift...
>
> No, not really....
>
> Matt Lewis
3. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
> -----Original Message-----
> From: Mike The Spike [mailto:mtsreborn at yahoo.com]
> > I don't know too much about COM, but I don't see why
> > Eu can't, unless it's
> > because COM is C++ based, rather than C. There
> > should be no real reason why
> > Eu couldn't link up with anything with a C-based
> > API. You just have to
> > figure out the API.
>
> Err....
> no...
> COM/OLE/ActiveX in Euphoria?
> No way pal, no can do...
> That's impossible...
> If I can't do it, probably no one can...
Well, I don't know about that. But first, let me ask you, have you used COM
in any other language? I pulled down the COM specs:
and took a look at them. It's certainly not _easy_, but I doubt it's
impossible. There are a few hurdles to be overcome, of course. I haven't
gotten my hands on any COM object with the docs for it (to get the GUID's,
interface details, etc), but that would be the first step, I think. The
only real hurdle would be figuring out how to call the interfaces. Building
the pointer table would be easy.
(To explain, to call the functions in a COM object, you have to build a
virtual function pointer table, which turns out to be what C++ does for
object methods. But it's a binary standard, so any language that supports
calling functions by pointer can theoretically interface with COM.)
In theory, you could use call() to call the interfaces, but that wouldn't
handle the arguments. It should be fairly easy for someone to write a
little ASM routine that pushed the arguments on the stack and called the
routine, right? I don't really know ASM, so that probably won't be me any
time too soon, but here's how I suspect it would work.
You could have a memory location that holds a pointer to the arguments in
memory, and another that tells you how many there are. The ASM looks at
that and pushes them on the stack. Then there's also a pointer stored in
memory that tells the ASM where to jmp to. Depending on the calling
convention (stdcall/cdecl--COM defaults to stdcall, but it's legal to have
cdecl routines), you might also need to clean the stack.
Then in Eu you write the code to wrap that stuff, and an app calls those
routines.
After that, it's all figuring out the COM API, which you'd pretty much have
to do with any other language interfacing with COM. How far did you get?
Can you post what you did? Maybe we can figure out how to wrap COM so it's
easy to use with Eu.
Matt Lewis
4. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
> Well, I don't know about that. But first, let me
> ask you, have you used COM
> in any other language? I pulled down the COM specs:
>
> http://www.microsoft.com/com/resources/comdocs.asp
I have several Object & Embedding degrees...
I was 15 when I got my first, so yeah, I know what I'm
talking about...
I coded DX in C exclusively for two years back in 98',
untill last year, so yep, I know my COM ...
> and took a look at them. It's certainly not _easy_,
> but I doubt it's
> impossible. There are a few hurdles to be overcome,
> of course. I haven't
> gotten my hands on any COM object with the docs for
> it (to get the GUID's,
> interface details, etc), but that would be the first
> step, I think. The
> only real hurdle would be figuring out how to call
> the interfaces. Building
> the pointer table would be easy.
>
> (To explain, to call the functions in a COM object,
> you have to build a
> virtual function pointer table, which turns out to
> be what C++ does for
> object methods. But it's a binary standard, so any
> language that supports
> calling functions by pointer can theoretically
> interface with COM.)
>
> In theory, you could use call() to call the
> interfaces, but that wouldn't
> handle the arguments. It should be fairly easy for
> someone to write a
> little ASM routine that pushed the arguments on the
> stack and called the
> routine, right? I don't really know ASM, so that
> probably won't be me any
> time too soon, but here's how I suspect it would
> work.
>
> You could have a memory location that holds a
> pointer to the arguments in
> memory, and another that tells you how many there
> are. The ASM looks at
> that and pushes them on the stack. Then there's
> also a pointer stored in
> memory that tells the ASM where to jmp to.
> Depending on the calling
> convention (stdcall/cdecl--COM defaults to stdcall,
> but it's legal to have
> cdecl routines), you might also need to clean the
> stack.
>
> Then in Eu you write the code to wrap that stuff,
> and an app calls those
> routines.
>
> After that, it's all figuring out the COM API, which
> you'd pretty much have
> to do with any other language interfacing with COM.
> How far did you get?
> Can you post what you did? Maybe we can figure out
> how to wrap COM so it's
> easy to use with Eu.
>
> Matt Lewis
I thought it was as easy as that too man, but the
problem is simple.
You need to be able to use COM, to use routines that
allow you to use COM.
Your compiler should support COM, otherwise, you're
stuck at doing it like this;
push(args)
call(offset + 4)
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?
In computing, everything is possible, but equally
impossible at the same time.
In conclusion, your compiler should support by-name
refferencing of structure/class/interface members
intsead of by-offset for COM to work.
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.
Mike The Spike
5. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
> Well, I don't know about that. But first, let me
> ask you, have you used COM
> in any other language? I pulled down the COM specs:
>
> http://www.microsoft.com/com/resources/comdocs.asp
I have several Object & Embedding degrees...
I was 15 when I got my first, so yeah, I know what I'm
talking about...
I coded DX in C exclusively for two years back in 98',
untill last year, so yep, I know my COM ...
> and took a look at them. It's certainly not _easy_,
> but I doubt it's
> impossible. There are a few hurdles to be overcome,
> of course. I haven't
> gotten my hands on any COM object with the docs for
> it (to get the GUID's,
> interface details, etc), but that would be the first
> step, I think. The
> only real hurdle would be figuring out how to call
> the interfaces. Building
> the pointer table would be easy.
>
> (To explain, to call the functions in a COM object,
> you have to build a
> virtual function pointer table, which turns out to
> be what C++ does for
> object methods. But it's a binary standard, so any
> language that supports
> calling functions by pointer can theoretically
> interface with COM.)
>
> In theory, you could use call() to call the
> interfaces, but that wouldn't
> handle the arguments. It should be fairly easy for
> someone to write a
> little ASM routine that pushed the arguments on the
> stack and called the
> routine, right? I don't really know ASM, so that
> probably won't be me any
> time too soon, but here's how I suspect it would
> work.
>
> You could have a memory location that holds a
> pointer to the arguments in
> memory, and another that tells you how many there
> are. The ASM looks at
> that and pushes them on the stack. Then there's
> also a pointer stored in
> memory that tells the ASM where to jmp to.
> Depending on the calling
> convention (stdcall/cdecl--COM defaults to stdcall,
> but it's legal to have
> cdecl routines), you might also need to clean the
> stack.
>
> Then in Eu you write the code to wrap that stuff,
> and an app calls those
> routines.
>
> After that, it's all figuring out the COM API, which
> you'd pretty much have
> to do with any other language interfacing with COM.
> How far did you get?
> Can you post what you did? Maybe we can figure out
> how to wrap COM so it's
> easy to use with Eu.
>
> Matt Lewis
I thought it was as easy as that too man, but the
problem is simple.
You need to be able to use COM, to use routines that
allow you to use COM.
Your compiler should support COM, otherwise, you're
stuck at doing it like this;
push(args)
call(offset + 4)
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?
In computing, everything is possible, but equally
impossible at the same time.
In conclusion, your compiler should support by-name
refferncing of structure/class/interface members for
COM to work.
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.
Mike The Spike
6. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
> -----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
7. 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
>
8. RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
> -----Original Message-----
> From: Mike The Spike [mailto:mtsreborn at yahoo.com]
> 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.
I'll let you know.
> 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...
I can appreciate that. But where did you actually stop? Were you
successful in hooking up to COM, and just didn't want to wrap the DX
interfaces? Or did you give up before you figured out how to use COM?
> 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.
In the meantime, I'll look forward to this, and keep working on my COM
wrappers.
> - 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?
Off the top of my head? No. But that doesn't really mean anything. I
*think* I can get the details on an interface using IDispatch, which is
documented on MSDN. It's still up to you to figure out what to do with with
interface, but that's nothing new (you'd have to do this in C++).
I found a couple of interesting COM tools (d/l'd from cnet or somewhere).
One generates a .chm file that documents all the properties and methods of a
COM object, and one is usefull in looking up CLSID's and IID's and such.
This leads me to believe that it's very possible to write an automatic
wrapper for virtually any COM object, and right now, I think that the
IDispatch interface is the way to do it.
> 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.
Well, it seems to me there are lots of things that COM allows you to do.
For instance, OLE. Maybe this isn't very useful in games, but if I could
use Eu to do things with Access or Excel, for instance, I would be very very
happy. <flamesuit on>Not to mention that we could use ActiveX
objects.</flamesuit on>
I don't know how much overhead things like Exotica really add to using DX,
but as for shipping DLL's with an app, I can't remember the last thing I
installed that didn't have a few of those. If you don't like 'em, that's
OK, but I don't think anyone will be upset with you if you do. And unless
they're really large, it's unlikely that anyone would complain about the
disk space taken up by something like that.
Matt Lewis
