Another on for the 0.9 TODO: -- launching Help from apps This does not work now, IIRC. It's rather 'simple', and visible from the user POV, so needs fixing IMO. -- Dimi.
I think the problem with that (last time I checked) was that nobody had completely reverse engineered the message protocol between the WinHelp api calls and the winhelp app. I think there is an exchange of undocumented messages, but this is just going from what I've read on bugzilla and the lists. BTW, how would Wine get WinHelp? Is help something that would only work if you had a real windows installation to get the exe from? Or is building a winhelp interpreter on the todo list? thanks -mike On Fri, 2002-11-08 at 12:43, Dimitrie O. Paun wrote:
Another on for the 0.9 TODO: -- launching Help from apps
This does not work now, IIRC. It's rather 'simple', and visible from the user POV, so needs fixing IMO.
-- Dimi.
WINE already comes with a very very basic WinHelp program, but it needs several large pieces of work done before it'd be useful: - Implementation of HLP95EN, or at least Dynalink support in HLPFILE_AddParagraph to call and process results from a native HLP95EN.dll - Basic MACRO support - CHM support, which is what most recent method of bundling help. CHM is basically a bundle of HTML files, which makes things slightly easier... Basic CHM format is documented here, along with a GPL'ed extraction program (Which didn't work last time I tried it, but looks sound in theory): http://www.speakeasy.org/~russotto/chm/ Again, like the external dependency on CabExtract, this would rely on either someone managing to get a relicensed version of a LZX decompressor... or writing one of their own. - Ender On 8 Nov 2002, Mike Hearn wrote:
Date: 08 Nov 2002 13:19:28 +0000 From: Mike Hearn <m.hearn(a)signal.qinetiq.com> To: dpaun(a)rogers.com Cc: Wine Devel <wine-devel(a)winehq.com> Subject: Re: Help support
I think the problem with that (last time I checked) was that nobody had completely reverse engineered the message protocol between the WinHelp api calls and the winhelp app. I think there is an exchange of undocumented messages, but this is just going from what I've read on bugzilla and the lists.
BTW, how would Wine get WinHelp? Is help something that would only work if you had a real windows installation to get the exe from? Or is building a winhelp interpreter on the todo list?
thanks -mike
On Fri, 2002-11-08 at 12:43, Dimitrie O. Paun wrote:
Another on for the 0.9 TODO: -- launching Help from apps
This does not work now, IIRC. It's rather 'simple', and visible from the user POV, so needs fixing IMO.
-- Dimi.
Ender a écrit :
WINE already comes with a very very basic WinHelp program, but it needs several large pieces of work done before it'd be useful:
- Implementation of HLP95EN, or at least Dynalink support in HLPFILE_AddParagraph to call and process results from a native HLP95EN.dll
- Basic MACRO support
I have this on my todo list. it would be possible to implement a wine specific message passing between WinHelp API and wine's builtin winhlp32 however, it would be rather difficult to support all the ways windows handles this (it does it differently in Win9x, NT...), so support of native winhlp32 (and winhelp) will not be provided
- CHM support, which is what most recent method of bundling help. CHM is basically a bundle of HTML files, which makes things slightly easier... CHM is not supported by winhelp but by a specific OCX (hh the regular chm help viewer is basically: 1/ a decompressor 2/ an interface to an html viewer, that we don't have either) so, chm support is far from sight
A+
On November 8, 2002 01:00 pm, Eric Pouech wrote:
I have this on my todo list. it would be possible to implement a wine specific message passing between WinHelp API and wine's builtin winhlp32 however, it would be rather difficult to support all the ways windows handles this (it does it differently in Win9x, NT...), so support of native winhlp32 (and winhelp) will not be provided
Well, it's better to have support for our winhlp32, than no help at all. And besides, it makes even more sense in the light of the 0.9 release where we should be able to run apps out-of-the-box without requiring additional MS code. So yeah, if we at least can get builtin winhlp32 running, it will be good enough for 0.9 IMO.
- CHM support, which is what most recent method of bundling help. CHM is basically a bundle of HTML files, which makes things slightly easier...
CHM is not supported by winhelp but by a specific OCX (hh the regular chm help viewer is basically: 1/ a decompressor 2/ an interface to an html viewer, that we don't have either) so, chm support is far from sight
I don't know. The decompressor can't be too big of a deal, given that there is already a GPLed on. The html viewer is a problem, but according to a recent thread, Mozilla-win32 runs just fine under Wine, and it implements IWebBrowser & friends interfaces, which is exactly what we need here, don't we? -- Dimi.
The html viewer is a problem, but according to a recent thread, Mozilla-win32 runs just fine under Wine, and it implements IWebBrowser & friends interfaces, which is exactly what we need here, don't we? yup, but I fear we'll discover more issues as far we go on (way too early to know, until we dig a bit more into it)
it also creates a dependency on Wine & Mozilla-win32. I don't feel like requiring users to have Mozilla-win32 on their boxes A+
--- Eric Pouech <eric.pouech(a)wanadoo.fr> a écrit : > > The html viewer is a problem, but according
to a recent thread, Mozilla-win32 runs just fine under Wine, and it implements IWebBrowser & friends interfaces, which is exactly what we need here, don't we? yup, but I fear we'll discover more issues as far we go on (way too early to know, until we dig a bit more into it)
Eric, I think that Dmitirie wanted to say it would be easy to implement one, Mozilla ony being taken as an example.
it also creates a dependency on Wine & Mozilla-win32. I don't feel like requiring users to have Mozilla-win32 on their boxes
A+
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On November 8, 2002 03:01 pm, Eric Pouech wrote:
yup, but I fear we'll discover more issues as far we go on (way too early to know, until we dig a bit more into it)
True, but it's a good start. Right now we have Nothing (TM). :)
it also creates a dependency on Wine & Mozilla-win32. I don't feel like requiring users to have Mozilla-win32 on their boxes
I hope you're not suggesting we build our own browser :O ;) But you are right, the Mozilla-win32 situation is far for being satisfactory, but it's a good first approximation. Right now we have nothing, and those that rather have nothing than have Mozilla-win32 on their systems, will see nothing changed. Those that want the functionality, will install Mozilla-win32. So it's a win-win for the users. The ideal situation is if we can use a standard Mozilla installation, just like Galeon does. But this is non-trivial little project (just consider that IWebBrowser is implemented in C++ using ATL, and even if we translated in C, we'll be stuck maintaining it, instead of using the most up-to-date version from Mozilla, which is not very nice either). So IMO *if* we can get a solution working with Mozilla-win32 fairly easily, we should do it. It will be an immediate improvement for the users, and it will help developers work on the nicer solution by providing them with something that works, etc. Come to think of it, if Mozilla-win32 does not work out of the box, we have bugs that need fixing regardless, so in the end, we should get the Mozilla-win32 for free. -- Dimi.
True, but it's a good start. Right now we have Nothing (TM). :) another way (absolutely not tested), would be to: 1/ extract html files (+images...) into a temp dir 2/ direct any browser to browse (I have no idea whatsoever how links are handled in chm, but it wouldn't be to hard to change... if they're all relative that would be easy, for intra-CHM links. inter-CHM wouldn't work) that would be a poor's man CHM viewer, but not so bad for a beginning in other words, it might be easier to implement a CHM viewer from a standard brower (of course throwing away the IWebBrower iface) that could be even quickier and simpler (and more maintainable) than creating a CHM viewer with IWebBrowser iface
A+
On November 9, 2002 01:06 pm, Eric Pouech wrote:
another way (absolutely not tested), would be to: 1/ extract html files (+images...) into a temp dir 2/ direct any browser to browse
This is certainly possible, and it should work, to some extent. The problem with it is that it's a complete deadend, that can not be massaged into the final solution. We know (correct me here if I'm wrong), that ideally we want to end up using IWebBrowser to implement it. If we start with this, we can give people a good direction to hack on, and improve. Now, to be honest, I have never user IWebBrowser (or any COM/OLE object for that matter), but is it that hard to create, and use? Even if in the beginning it does very little, it'd be way cool to see if it works :) (not to mention a good starting point). -- Dimi.
This is certainly possible, and it should work, to some extent. The problem with it is that it's a complete deadend, that can not be massaged into the final solution. agreed, but I don't call installing mozilla-Win32 on linux to have CHM support a final solution either
We know (correct me here if I'm wrong), that ideally we want to end up using IWebBrowser to implement it. If we start with this, we can give people a good direction to hack on, and improve. the only issue is how long will it take ? A+
On November 10, 2002 04:18 am, Eric Pouech wrote:
agreed, but I don't call installing mozilla-Win32 on linux to have CHM support a final solution either
No, it's not. But it can be massaged in the right solution. That is, we can start using IWebBrower all over the plave were we needed, we enable a bunch of 3rd party apps that depend on it, etc. And all this independent of how IWebBrowser is implemented. True, initally we can start with Mozilla-win32 (which we all agree is not nice, but practical), and we can try to make it run using a standard Mozilla installation, just like Galeon. But in the meantime, we have a solution in place which works, even if with a bit more code than necessary (but hey, HD is cheap these days, who cares). Having a working version is a win-win for everybody: - for users, they can use their apps just fine - for developers, as it's much easier to start from a working version
the only issue is how long will it take ?
As I said, theoretically Mozilla-win32 should work right out of the box. If not, we have bugs that need solving regardless. We know Mozilla-win32 works just fine under Wine (fine, it has some menu problems, but these are irrelevant in this case). This is the big step. Now all we need to check is if their implementation of IWebBrowser works. -- Dimi.
I have this on my todo list. it would be possible to implement a wine specific message passing between WinHelp API and wine's builtin winhlp32 however, it would be rather difficult to support all the ways windows handles this (it does it differently in Win9x, NT...), so support of native winhlp32 (and winhelp) will not be provided question (at least) for Alexandre: I have a working version of this, but passing 16 bit GlobalAllocated blocks in a registered message this is ugly because: 1/ it uses 16 bit block 2/ requires quite a few hacks in message sending (because of the registered message) the only interesting part is that this behavior is compatible with Win9x implementation
so I'd rather re-implement it using DDE client/server (which will make it completely incompatible with all native winhlp32.exe and winhelp.exe executables) so do you prefer: 1/ hacky 16 bit block, still Win9x compatible 2/ DDE implementation, but incompatible with any native winhlp32/winhelp A+
Eric Pouech <eric.pouech(a)wanadoo.fr> writes:
so do you prefer: 1/ hacky 16 bit block, still Win9x compatible 2/ DDE implementation, but incompatible with any native winhlp32/winhelp
We definitely don't want 16-bit hacks in the messaging code, we should try to do things as NT-like as possible. Running Win9x winhlp32 is not really important IMO. -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard a écrit :
Eric Pouech <eric.pouech(a)wanadoo.fr> writes:
so do you prefer: 1/ hacky 16 bit block, still Win9x compatible 2/ DDE implementation, but incompatible with any native winhlp32/winhelp
We definitely don't want 16-bit hacks in the messaging code, we should try to do things as NT-like as possible. Running Win9x winhlp32 is not really important IMO.
I'm afraid the NT way is not possible. As Uwe stated, it includes writing message "body" to 0x7ffe0000 shared page. So, I don't think we're ready for it (especially as an IPC mechanism) so I'll go for dde A+
Just so people don't double up, I'll let everyone know I'm working on a CHM viewer. Although I still havn't worked out how I will do the actual HTML viewing, my first priority is to actually build code to parse the file :) I might even ponder implementing a simple IWebBrowser implementation based off of Konq-Embedded/khtml, which would be -extremely- easy... and best of all, light-weight (there is NO way I'm going to install Mozilla/Win32 to have large portions of WINE working, I can't afford the diskspace!) Of course the whole GPL vs LGPL thing is a bit of an annoyance. - Ender
On November 10, 2002 04:40 am, J.Brown (Ender/Amigo) wrote:
Just so people don't double up, I'll let everyone know I'm working on a CHM viewer.
Way cool! Noted in the TODO.
I might even ponder implementing a simple IWebBrowser implementation based off of Konq-Embedded/khtml, which would be -extremely- easy... and best of all, light-weight (there is NO way I'm going to install Mozilla/Win32 to have large portions of WINE working, I can't afford the diskspace!)
Well, a minimal Mozilla/Win32 installation is 6MB. How can you develop on Wine when you can't afford 6MB? I've just checked, and you need 400MB to compile Wine...
Of course the whole GPL vs LGPL thing is a bit of an annoyance.
It is, but make sure all your stuff is LGPL, or it will never go in the tree. -- Dimi.
On November 10, 2002 05:01 am, J.Brown (Ender/Amigo) wrote:
Which is why I can't afford the space :)
/dev/hdb1 10GB 9.1GB 415MB 96% /development
Oh, come on! :) You can't spare 6MB out of 415?!? It's <2%! :) BTW, if you feel like reimplementing IWebBrowser, why not do it so it calls Mozilla, like Galeon does. Mozilla is a better browser than Konqy (even if I like Konqy). Just my $0.02... -- Dimi.
On November 10, 2002 05:01 am, J.Brown (Ender/Amigo) wrote:
Which is why I can't afford the space :)
/dev/hdb1 10GB 9.1GB 415MB 96% /development
Oh, come on! :) You can't spare 6MB out of 415?!? It's <2%! :)
Yes, but remember, I need 400 of that 415 to compile WINE! :)
BTW, if you feel like reimplementing IWebBrowser, why not do it so it calls Mozilla, like Galeon does. Mozilla is a better browser than Konqy (even if I like Konqy). Just my $0.02...
Ugh, I don't want to start a browser war or anything, but my personal opinion is exactly the other way around. I detest Mozilla as a browser, and although it's rendering engine (eg, as used in Galeon) is okay, I find it annoying slow and unhelpful. The only time I ever run Mozilla is when I need to do some web development, and I always uninstall it afterwards. I have better things to waste disk space on :) - Ender
On November 10, 2002 05:14 am, Ender wrote:
Ugh, I don't want to start a browser war or anything, but my personal opinion is exactly the other way around. I detest Mozilla as a browser, and although it's rendering engine (eg, as used in Galeon) is okay, I find it annoying slow and unhelpful.
There is a bit of confusion here. When I said Mozilla, I was in fact referring to Gecko, the rendering engine (as you say, the one used in Galeon). And that one is faster, and nicer than Konqy, I used them every day side-by-side. But it is your call. Just make sure Kongy is LGPL-ed, or the patch can't go in. -- Dimi.
Hi, Please make sure you try whatever rendering engine you choose with a wide sample of CHM pages. From what I remember of my Windows days, CHM help often contains lots of IEisms, from VBScript to IE specific DHTML, ie they're not standard HTML despite the name. Whatever renderer is chosen then should be one we can easily fork and massage into a relatively IE compatible one. Here is a quick roundup of the options based on what I know of the available engines: - Gecko: the best (in terms of features/compatability/speed) rendering engine around. Also benefits from being very widely deployed at least on Linux. Note that soon Mozilla will be splitting into a GRE (gecko runtime environment), then an XRE (xul runtime) layered on top, with Mozilla being an "application" on top of that framework. When this happens, making the GRE a dependancy of Wine would not be such a big deal IMHO, it's only a few megs at the moment. * Pros: We get a high quality rendering engine that we know is powerful enough to do what we need, and when the GRE thing happens it'll be relatively easy to embed too. Already has IWebBrowser interfaces (bitrotted afaik). * Cons: Gecko codebase is huge and complex, adding whatever IEisms are necessary may be hard. Overhead of XPCOM etc. * Notes: why would Wine require the Windows version of Gecko?? Why not simply embed Gecko into the X window constructed by Wine? I'm pretty sure this can be done. I know a lot of people wouldn't want a win32 and a linux version of gecko installed at once, even if one was in their fake windows drive. If it's a case of Wine windows can't easily embed others via XEMBED then maybe this functionality could be worked on first. - KHTML: designed for embedding since the start, KHTML is used in the KDE Help system, so we know it's got good enough performance for that, but it also does quite a good job as a web browser (though not as compatible with the web as gecko). Written in pure C++ so no object model overhead. Codebase is (fairly) simple for a rendering engine from what I hear, so could be easily adapted to add any IE specific html. Cons: not as widely deployed as Gecko, though I don't think it's far behind. Would start easily depending on other parts of KDE however, like KJS for JavaScript (does wine needs its own javascript interpreter anyway?) - GtkHTML: I'd guess a lot of machines have GTK on in one form or another, hence a high likelyhood of this being present. Having wine depend on GTK is not such a big deal either. GtkHTML is probably the weakest renderer of the bunch, for instance I don't think it has script support, but is pretty fast and easily embedded. Although Gecko is a nicer renderer, I think it's wise to go with KHTML here. If necessary the code can be statically linked into a Wine DLL. I don't know what the policy is on including C++ code in Wine, but I can't see why this would be a problem. KHTML has relatively good support for web standards, and should be easily extendable (though you'd need to do a proper evaluation) to support the IE level zero dom. Esp startup time is to be considered, gecko requires initialization of XPCOM and other stuff, also the biggest problem with gecko is that the embedding interfaces tend to change with every major release of Mozilla. As Moz is often kept quite up to date, that means Wine would constantly break a la Galeon <yuck>. KHTML is far more stable, and could be bundled with Wine anyway. thanks -mike On Sun, 2002-11-10 at 09:40, J.Brown (Ender/Amigo) wrote:
Just so people don't double up, I'll let everyone know I'm working on a CHM viewer.
Although I still havn't worked out how I will do the actual HTML viewing, my first priority is to actually build code to parse the file :)
I might even ponder implementing a simple IWebBrowser implementation based off of Konq-Embedded/khtml, which would be -extremely- easy... and best of all, light-weight (there is NO way I'm going to install Mozilla/Win32 to have large portions of WINE working, I can't afford the diskspace!)
Of course the whole GPL vs LGPL thing is a bit of an annoyance.
- Ender
Mike Hearn a écrit:
Esp startup time is to be considered, gecko requires initialization of XPCOM and other stuff, also the biggest problem with gecko is that the embedding interfaces tend to change with every major release of Mozilla. As Moz is often kept quite up to date, that means Wine would constantly break a la Galeon <yuck>. KHTML is far more stable, and could be bundled with Wine anyway.
That's what the 1.0 branch of Mozilla is for. Stability in API. Plus it's available under the LGPL (although not all of it; should be checked almost an a file by file basis). Vincent
That's what the 1.0 branch of Mozilla is for. Stability in API.
True
Plus it's available under the LGPL (although not all of it; should be checked almost an a file by file basis).
I've just got an email saying that the KDE libs might actually be under the lgpl. It's something to check On Mon, 2002-11-11 at 14:36, Vincent Béron wrote:
Mike Hearn a écrit:
Esp startup time is to be considered, gecko requires initialization of XPCOM and other stuff, also the biggest problem with gecko is that the embedding interfaces tend to change with every major release of Mozilla. As Moz is often kept quite up to date, that means Wine would constantly break a la Galeon <yuck>. KHTML is far more stable, and could be bundled with Wine anyway.
That's what the 1.0 branch of Mozilla is for. Stability in API. Plus it's available under the LGPL (although not all of it; should be checked almost an a file by file basis).
Vincent
"Dimitrie" == Dimitrie O Paun <dpaun(a)rogers.com> writes:
Dimitrie> Another on for the 0.9 TODO: -- launching Help from apps Dimitrie> This does not work now, IIRC. It's rather 'simple', and Dimitrie> visible from the user POV, so needs fixing IMO. Supporting native winhlp32 in this regards is not easy. I involved supporting the strange 0xfffexxxx page with it's shared system values. I thinks this page is alos used to pass the content of the winhelp messages used to start the application. PS: it might be another page then 0xfffexxxx, don't remember exactly. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
participants (9)
-
Alexandre Julliard -
Dimitrie O. Paun -
Ender -
Eric Pouech -
J.Brown (Ender/Amigo) -
Mike Hearn -
Sylvain Petreolle -
Uwe Bonnes -
Vincent Béron