question on how to do language bindings to MSHTML's COM interface

[Luke Kenneth Casson Leighton]

On Fri, Jan 2, 2009 at 9:17 PM, Rob Shearman <robertshearman at gmail.com> wrote:
> 2009/1/1 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
>> folks, hi,
>> i have a rather intriguing issue i'd like to look at, which takes
>> quite a bit of explaining as to why i'd like to go about it - if
>> people are interested i can answer that, but for now i'll leave it at
>> this:
>> how, under linux, would i go about making an application that made
>> _use_ of MSHTML.DLL's functionality, via its COM / DCE/RPC / MSRPC
>> interface?
>> in other words, if you are familiar with gecko / XUL, how would i go
>> about making a gecko / XUL style of application, using MSHTML as the
>> basis, and, once that was achieved, would it stand a chance of
>> successfully running under vanilla windows, using MS's own version of
>> MSHTML?
>
> There are a number of parts to your question:
> 1. Is it OK for the application to be a winelib one (i.e. invoked via
> or linked to wine, rather than being "native")?

 i'd much prefer native, as then two platforms would be supported
rather than one.

> 2. What language are you writing the application in?

 as little c as possible to get as quickly as possible into python.

> 3. Pretty much all interaction with mshtml happens through COM
> interfaces, so which interfaces are you interested in?

 i don't know (and would appreciate some pointers!) - i can define it
as follows: everything that will give me sufficient complete control
of the DOM such that i can duplicate - 100% - the XUL / Gecko project
- but through MSHTML _not_ XUL / Gecko (i.e. ignore the fact that
mshtml uses XUL / Gecko underneath).

 if you've seen Hulahop, that's what i'm ultimately after - running on
both linux and windows.

 also, if you've seen WebKit, i'm the person who's responsible for
webkit now having glib / gobject bindings to its DOM model, and i also
added python bindings to _those_ bindings, such that pywebkitgtk can
now be used to manipulate the DOM model.

 basically, i want to be able to do platform-independent "scripting"
on top of MSHTML, in exactly the same way that
pywebkitgtk allows platform-independent python scripting on top of
webkit, and in exactly the same way that hulahop allows
platform-independent python scripting on top of Gecko / XUL.

 that's the goal.

>> yes i _am_ fully aware that, underneath, according to the wiki page on
>> mshtml's implementation, mshtml underneath uses Gecko - but i don't
>> _want_ to use the Gecko / XUL interface (mostly because it already
>> exists!  i don't like challenges that have already been done :)
>> specifically, i'd _really_ like to have python bindings to the COM
>> bindings to MSHTML - all under linux.
>> so there are some _really_ weird esoteric "sub-questions" involved, such as:
>> "what are the chances of porting pywin32 - specifically pywin32's COM
>> bindings - to linux, thanks to widl and friends"?
>> see http://sourceforge.net/projects/pywin32
>> many thanks for any advice and information.
>
> We already build a typelib for mshtml using widl and pywin32 can use
> that to make bindings for use at runtime,

 _great_.

> so it "should" work,

 :)

> but I fail to see the need for it at the moment.

 now buried in that statement is a question and a half :)
 as you know, i don't really take on under-ambitious projects ha ha :)



> At some point I'd like to see a Python output generator for widl so
> that it can directly generate Python code that will communicate to a
> remote process using DCE/RPC,

 that would be _fantastic_.  it's something i've wanted to see happen
for about six years.  however, the lessons from my involvement in big
free software projects are that i will do significant work either for
my own personal benefit or if someone pays me money.  i've had enough
people spongeing off of my expertise, time and energy.

 so - if you find anyone who needs python dce/rpc, who's willing to
pay for it, you know where to reach me :)


> but that comes second place to getting
> the C generator as close to perfect as possible at the moment.

 tsk, tsk -  rob, rob, it's been _years_ since wine began the process
of duplicating FreeDCE, a BSD-licensed _freely available_ reference
implementation of DCE/RPC, which took only a few weeks of effort, back
in about 2000/2001, to turn it into MSRPC (adding support for [range]
and other minor details).

 as you're aware, i began the task of porting FreeDCE to win32 back in
2005.  it was successful: however i went a bit too far with the
removal of the dcethreads library (which was done with #define macros)
so that is easily reverted.  ncacn_ip_udp worked absolutely fine, and
without that screw-up, ncacn_ip_tcp would have been working too.  the
issue was, i believe, that removing the posix draft 4 semantics left
some thread-cancellation-blocking semantics (probably on select) that
were suuubtly different from posix final 7 semantics.

anyway.

 you should by now be able to rip out the 70,000 lines of
marshalling/unmarshalling from FreeDCE and drop it into wine: last
time i checked, every single function i looked at, the code that _was_
implemented in wine's DCE/RPC handling was near-identical to the same
lines of code in FreeDCE (except for the
CamelIsAtionOfFunctionAndVariableNames of course).

 that would at least give you a _big_ leap forward.

 l.