On Fri, Jan 2, 2009 at 9:17 PM, Rob Shearman robertshearman@gmail.com wrote:
2009/1/1 Luke Kenneth Casson Leighton lkcl@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:
- 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.
- What language are you writing the application in?
as little c as possible to get as quickly as possible into python.
- 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.