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? 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. l.
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: 1. Is it OK for the application to be a winelib one (i.e. invoked via or linked to wine, rather than being "native")? 2. What language are you writing the application in? 3. Pretty much all interaction with mshtml happens through COM interfaces, so which interfaces are you interested in?
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, so it "should" work, but I fail to see the need for it at the moment.
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, but that comes second place to getting the C generator as close to perfect as possible at the moment.
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.
quick question: is there any progress on implementing COM, in wine, or is it necessary to grab dcom98.exe and to find the headers and the .libs from visual studio? and have you seen these - IDL files defined by wez, for DCOM?
http://freedce.cvs.sourceforge.net/viewvc/freedce/freedce/dcom/
l.
p.s. nice to hear from you again, rob :)
p.p.s. below is "background" behind where i'm coming from with the python mshtml "thing".
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, so it "should" work, but I fail to see the need for it at the moment.
you have to jump through a series of hoops to get there - being honest i'm not that good at expressing some of my leaps of multi-hoop-jumping but i'll try to give some pointers.
1) making python apps that rely on features of the win32 platform possible under unix as well. winreg and dcom are two that _really_ spring to mind.
win32 developers are writing applications that use e.g. the registry. i tried compiling pywin32 on linux and _instantly_ ran into a difficulty: import _winreg.
so, i would have to go into the python 2.5 / 2.6 tarball and look at a way of adding --enable-wine=yes and see what happens.
2) "ActiveScripting" of web pages - DOM manipulation through other programming languages.
this is an _incredibly_ powerful concept that microsoft must have had for what... ten to fifteen years, and nobody really noticed its significance?? :) the reason for _that_ is because the main available programming languages were utterly dire (Visual Basic).
to give you an idea of how powerful scripted DOM manipulation is, i've implemented a project called Pyjamas-Desktop - http://pyjd.org. it's a Desktop Widget Set UI framework. thanks to webkit-glib and pywebkitgtk, is actually _more_ feature-capable than PyQT4 and PyGTK2 put together!
i'd just... _really_ like to see Pyjamas-Desktop be capable of running on top of MSHTML, on windows. especially because then it would be possible to _just_ install python (and pyjd) and, thanks to I.E. being de-facto already _on_ windows, pyjd would just... _work_.
i wouldn't have to ask people to download a 30mb bundle of GTK.DLL, CAIRO.DLL, PANGO.DLL, GDK.DLL, WEBKIT.DLL, ICU38.DLL plus supporting infrastructure. the "dll hell" burden, for gtk appplications on win32, is _immense_.
btw whilst i use pyjamas-desktop as an example, anything that has _remotely_ a subset of the features that pyjd covers would of course benefit from the same features [that python bindings to mshtml.dll would bring]. pyjd is a bit of a "path-finder" as it absolutely _hammers_ the underlying DOM model technology. [i had enormous difficulty finding suitable technology: pykde didn't work; pygtk2 was useless; pyqt4 was only slightly better - in the end i had to go for webkit.]
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'm on the first step - getting python compiled. so i'm in the middle of an experiment to compile python with wine, and it looks like i _have_ to make it an "invoked via wine" one. in fact, stunningly, that actually succeeded! using winegcc, a script called python and a dll called python.exe.so were created. of course, make install only copied over the script not the .so duh.
the mistake i've made however is in not compiling with -DMS_WINDOWS. the issue that i have is that there _is_ no Makefile or Makefile.in for win32 python, there _is_ no configure script: it's all damn well done with visual studio .proj files on a hard-coded basis argh.
i had the same difficulty i ran into when cross-compiling with a mingw32 cross-compiler.
anyway - the first step is going reasonably well. i'm running into a bit of bother with python modules (.so extension) - i'll have to investigate the .proj files a bit more because the only things being built are _winreg.o, _md5.o and _not_ _winreg.so or _winreg.dll or wine equivalent. whoops.
but - this is the first step. the next step would be to, i assume, add mshtml as a module? or perhaps see if someone's already done it, somewhere, with windows.
-
Luke Kenneth Casson Leighton -
Rob Shearman