"Bill Schwab" <
[hidden email]> wrote in message
news:bv36ud$nme89$
[hidden email]...
> > I do it manually.
> >
> > Blair apparently likes to generate MS IDL and then import that
> automatically,
> > but I don't know how he does it (it seems to involve VC++ somewhere,
> but...).
>
> It was/is documented on the Wiki, but the search engine for same is
hobbled
> at the moment. The technique offers the benefit of automatic computation
of
> element sizes. The bad news is that (IMHO) writing the required IDL is
> almost as bad as writing the methods manually. ....
Most of the time it isn't necessary to write the IDL. It either pre-exists,
or is easily constructed from the C header files. A case in point was the
first cut of the GDI+ libraries I created. This was just a raw import of the
API, and subsequently others have done sterling work in providing higher
level access to the facilities. Nevertheless if it had been necessary to
define 600+ functions, 20-odd structures, and 850+ enums/constants by hand
it would not only have taken many many hours of tedious work, but there
would have been a significant number of errors in the result. As it was an
hour or two with some editor macros had the GDI plus .h files converted to
IDL. From this the entire API could be generated repeatedly and without
errors. For less complex situations it is sometimes possible to just include
the .h file(s) into a shell idl file.
Another factor to consider is that constructing definitions by hand
typically requires a broader understanding of the FFI facilities in Dolphin.
One needs to know what field types to use when defining structures, and what
argument types to use when defining external library methods. One may also
have to enlist the services of a C compiler to work out the correct
structure packing and offsets in cases where non-standard packing is used.
Regardless of the relative efficiency of constructing definitions by hand vs
generating from a type library, the most important consideration is really
the reliability of the result. We still occassionally find errors in the
manually defined structures and consts that we did in the very early
versions of Dolphin of six or seven years vintage. When we first started
generating structures from type libraries we regenerated many of the
original structures/consts and found several consts such as error codes that
were defined with the wrong value, and a number of incorrectly defined
structures. On the other hand one sometimes find that the analyser generates
incorrect types, either due to incorrectly defined IDL, insufficient
information in the type library (not all of the information in the IDL is
carried forward into the type library), or occassionally due to bugs in the
analyser. However in my experience these errors are usually immediately
obvious, and not like the insidious "value" or buffer-size errors one gets
with manual definitions that can cause data corruption and unexplained
crashes.
> Also, there is a type library for much of the Window API; a search of the
> archives will turn up a URL, along with caveats about it being slightly
> warped in favor VB.
This is a good point - Dolphin is able to handle all the C datatypes, so one
can work with the API as originally intended. VB on the other hand does not
support (for example) unsigned integers, so type-libraries created
deliberately for use with VB are sometimes not completely correct. A
particularly extreme case, from our experience, was the type-library created
for Direct-X. We were quite excited by this originally, as we thought it
might allow us to revive our old Direct-X library, bringing it up to date to
incorporate the massive expansion of the API between DX3 and DX8. In
practice however it wasn't a description of the complete COM API as one
might use it from C++ (or Dolphin), but a bastardised mess that exposed
reduced functionality through inefficient Automation types. This might have
been the only way to make DX accessible from VB, but we judged it not worth
pursuing for Dolphin.
Regards
Blair
Locked
