On Fri, Jan 2, 2009 at 9:17 PM, Rob Shearman <robertshearman(a)gmail.com> wrote:
2009/1/1 Luke Kenneth Casson Leighton <lkcl(a)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.