Wine folks interested in a CHM spec?

[Pabs3]

Hi wine peeps,

Just wondering if Wine folks are implementing a chm viewer and if you would be 
interested in a specification on the internal files of CHMs and even 
relicencing some of the code for my chm decompiler.

all at http://bonedaddy.net/pabs3/hhm/

BTW; please cc me in replies since, while i'm subscribed i don't want to get 
heaps of other wine discussion & so i've turned off mail delivery.

Bye,
Pabs

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

[Ender]

I've already written the major chuck of a CHM viewer - to the point I have
a native Windows viewer using nothing but the WebBrowser ActiveX control.

The secondary problem is how to display the HTML + JavaScript needed for a
CHM viewer. I've started work on this several times, and so far the *best*
(in terms of existing compatability with IE's CSS/JS/HTML 'features') has
been KJs and KHtml from the KDE project.

Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict
on standards compliance. Nothing you want in a Windows system component.
Well, not the last one anyway :)

However KHTML and KJS -are- tied to the QT library. It's quite possible to
decouple them (the embedded konq suite already does this to some extent,
as does WebCore from Apple's Safari project)... however it is somewhat
time consuming. Using WebCore can probably greatly speed this up of
course.

I ran into two other problems. First, I have gotten a Windows-native
KHTML/KJS viewer running - however splitting it into an API mapping to the
existing dll structure is complicated... and I know next to nothing about
writing ActiveX objects.

The second is that I never could get an answer from Alexandre as to adding
C++ code to WINE itself. It would be possible to write it as a seperate
non-core implementation, but many of these DLLs also have non-browser
related APIs that need to be in WINE itself. Again, diverting api calls
between the versions in WINE and our browser versions is complicated and
in this case plain ugly.

Anyway, that's all rather off-topic... we can already build a CHM viewer,
it's displaying the HTML/JS that's the problem :)

- Ender

http://www.scummvm.org/   | "Amen! Attempts to eradicate humour from
   http://www.quakesrc.org/  |  our distribution should be ignored with
   http://www.enderboi.com/  |  extreme prejudice" - [e-mail]

On Wed, 28 May 2003, Pabs3 wrote:
> Date: Wed, 28 May 2003 03:07:52 -0400
> From: Pabs3 
> To: [e-mail]
> Subject: Wine folks interested in a CHM spec?
>
> Hi wine peeps,
>
> Just wondering if Wine folks are implementing a chm viewer and if you would be
> interested in a specification on the internal files of CHMs and even
> relicencing some of the code for my chm decompiler.
>
> all at http://bonedaddy.net/pabs3/hhm/
>
> BTW; please cc me in replies since, while i'm subscribed i don't want to get
> heaps of other wine discussion & so i've turned off mail delivery.
>
> Bye,
> Pabs
>
> This mail sent through IMP: http://horde.org/imp/

[Mike Hearn]

On Wed, 2003-05-28 at 11:56, Ender wrote:
> I've already written the major chuck of a CHM viewer - to the point I have
> a native Windows viewer using nothing but the WebBrowser ActiveX control.

This would be a good thing to submit anyway. It's been possible (though
not easy) to install IE into Wine for some time now. If this is all it
takes to get CHM support up and running then this is cool - we don't
want to block CHM help on needing a webbrowser control.
> The secondary problem is how to display the HTML + JavaScript needed for a
> CHM viewer. I've started work on this several times, and so far the *best*
> (in terms of existing compatability with IE's CSS/JS/HTML 'features') has
> been KJs and KHtml from the KDE project.
> Gecko doesn't cut it - it's quite slow, bulky and worst of all too strict
> on standards compliance. Nothing you want in a Windows system component.
> Well, not the last one anyway :)

I've been reconsidering this lately. Originally I argued for KHTML, for
the above reasons. They are still valid, but we overlooked the issue of
editing support. My recent work with IE in Java (where IE is used as an
embedded html-enabled word processor) has made me realise that this
feature is used a lot in corporate scenarios. You'd be surprised at the
number of IE-specific web apps that utilise the contentEditable feature
of the rendering engine. KHTML simply does not support this as far as I
know, and I have no idea how easy it'd be to make it support it. Gecko
does. This is a significant + in favour of Gecko.

On the other hand, I'm not doing the work, and forking KHTML is probably
easier than Gecko. Adding editing support to KHTML would be quite a bit
of work, but still maybe less over all.
> However KHTML and KJS -are- tied to the QT library. It's quite possible to
> decouple them (the embedded konq suite already does this to some extent,
> as does WebCore from Apple's Safari project)... however it is somewhat
> time consuming. Using WebCore can probably greatly speed this up of
> course.
>
> I ran into two other problems. First, I have gotten a Windows-native
> KHTML/KJS viewer running - however splitting it into an API mapping to the
> existing dll structure is complicated... and I know next to nothing about
> writing ActiveX objects.

Simply getting KHTML/KJS working under Win32 is a great start. Are the
patches for this available anywhere online?
> The second is that I never could get an answer from Alexandre as to adding
> C++ code to WINE itself. It would be possible to write it as a seperate
> non-core implementation, but many of these DLLs also have non-browser
> related APIs that need to be in WINE itself. Again, diverting api calls
> between the versions in WINE and our browser versions is complicated and
> in this case plain ugly.

I think if it was a choice between accepting C++ into the tree, and not
having a large set of crucial APIs in Wine, AJ would accept C++. But I
don't speak for him.

For some of the DLLs/objects that IE provides I guess C could be used,
that isn't really a problem, IE provides a load of stuff that pure
KHTML/KJS doesn't and that would probably be provided by core Wine in C.

If it comes down to it, a WineTrident installer that is tested against
and known to work with Wine would be possible. It'd be highly annoying
for users to install it separately, but that's something good packaging
can take care of.
> Anyway, that's all rather off-topic... we can already build a CHM viewer,
> it's displaying the HTML/JS that's the problem :)

Good to know you're still around! Simply getting a super-basic
WebBrowser implementation up and running, in Wine, no matter how it's
built/installed would be a good first step.

Writing COM objects in C is a PITA but not all that hard, although if I
remember correctly ActiveX controls have to implement about a gazillion
interfaces which could get painful. Anyway, I think Wine supports COM
objects written in C++, it's in the documentation somewhere.

[Paul McNett]

Mike Hearn writes:
> > Anyway, that's all rather off-topic... we can already build a CHM
> > viewer, it's displaying the HTML/JS that's the problem :)
>
> Good to know you're still around! Simply getting a super-basic
> WebBrowser implementation up and running, in Wine, no matter how it's
> built/installed would be a good first step.

Yes, even if its just plain-text for the time being, any CHM viewer is 
better than no CHM viewer.

[Ender]

I'll try and remember to dig up the source and post it somewhere. But
regardless, most helpfiles that people actually -need- to read do use
htmlhelp elements that require CSS/JS to actually navigate.

*wanders off to reply to other e-mails, and curses himself for starting a
thread just before bed last night :)

- Ender

http://www.scummvm.org/   | "Amen! Attempts to eradicate humour from
   http://www.quakesrc.org/  |  our distribution should be ignored with
   http://www.enderboi.com/  |  extreme prejudice" - [e-mail]

On Wed, 28 May 2003, Paul McNett wrote:
> Date: Wed, 28 May 2003 14:46:36 -0700
> From: Paul McNett 
> To: [e-mail]
> Subject: Re: Wine folks interested in a CHM spec?
>
> Mike Hearn writes:
> > > Anyway, that's all rather off-topic... we can already build a CHM
> > > viewer, it's displaying the HTML/JS that's the problem :)
> >
> > Good to know you're still around! Simply getting a super-basic
> > WebBrowser implementation up and running, in Wine, no matter how it's
> > built/installed would be a good first step.
>
> Yes, even if its just plain-text for the time being, any CHM viewer is
> better than no CHM viewer.
>
> --
> Paul McNett

[Dimitrie O. Paun]

On May 28, 2003 06:56 am, Ender wrote:
> However KHTML and KJS -are- tied to the QT library. It's quite possible to
> decouple them (the embedded konq suite already does this to some extent,
> as does WebCore from Apple's Safari project)... however it is somewhat
> time consuming. Using WebCore can probably greatly speed this up of
> course.

Isn't the eventual goal of WebCore to de-QTfy them? QT is a show 
stopper due to licensing. I haven't followed this lately, but I 
thought WebCode will eventually get rid of QT, and that work will
find it's way into the mainline, no?

[Mike Hearn]

> Isn't the eventual goal of WebCore to de-QTfy them? QT is a show 
> stopper due to licensing

WebCore is a set of Qt stubs as far as I know, which map Qt onto the
MacOS APIs. It's like Wine, but for Qt.
> I haven't followed this lately, but I 
> thought WebCode will eventually get rid of QT, and that work will
> find it's way into the mainline, no?

I seriously doubt that. You know the KDE guys as well as I do - they
love Qt, and insist on using it for everything. Having Qt removed from
the mainline KHTML/KJS will probably never happen, so building stubs is
a rather lame, but unfortunately required prerequisite to using it.

[Dimitrie O. Paun]

On 28 May 2003, Mike Hearn wrote:
> > Isn't the eventual goal of WebCore to de-QTfy them? QT is a show 
> > stopper due to licensing
>
> WebCore is a set of Qt stubs as far as I know, which map Qt onto the
> MacOS APIs. It's like Wine, but for Qt.

Any current efforts to port WebCore to Win32? Or it's maybe easier
to create a WinCode? BTW, any idea how big this effort is?

[Mike Hearn]

> Any current efforts to port WebCore to Win32? Or it's maybe easier
> to create a WinCode? BTW, any idea how big this effort is?

Use Google power dimi! First hit for "khtml win32":

http://khtml-win32.sourceforge.net/

The project seems to have died around jan/feb of this year, but I think
he got most of the classes ported. I emailed the guy a few months ago
about it, can't quite remember the details of the exchange, but I think
he basically ran out of time/motivation.

Running through 3 translation layers is going to suck though.

KHTML -> KWQ -> Wine -> Linux

Bearing in mind KWQ would have to provide a pthreads wrapper around
win32, then have win32 mapped back onto pthreads - ouch!

[Mike Hearn]

> The project seems to have died around jan/feb of this year,

Correction, it seems despite first appearances the project was never
born. Its CVS tree is empty. Suckage.

Rereading Enders email I can't quite decide if he stubbed Qt out in
order to get it running on Win32 or not.... if we were to track KHTML
CVS, stubs would be the only solution, but as it might need to be forked
anyway actually de-Qt'ing is another possibility.

Ender, could you give more details about how you got it running on
win32?

[Dimitrie O. Paun]

On 28 May 2003, Mike Hearn wrote:
> Rereading Enders email I can't quite decide if he stubbed Qt out in
> order to get it running on Win32 or not.... if we were to track KHTML
> CVS, stubs would be the only solution, but as it might need to be forked

^^^^^^
You guys are nuts! :) Who is going to maintain all this. This is a
*large* project. Look at Mozilla for crying out loud, a full blown
HTML/JS/etc. engine will easily double the size/scope of Wine.

Stubbing is the only solution IMO. BTW, I knew about that project,
I email with the guy a bit, he didn't seem to understand some things,
even though I tried hard to explain. Like for example he wanted to
implement everything (controls, etc.) on top of GDI because the
standard controls are bloated and slow... Heh! I gave up. Obviously,
with that approach I didn't expect him to get too far.

[Mike Hearn]

> You guys are nuts! :) Who is going to maintain all this. This is a
> *large* project. Look at Mozilla for crying out loud, a full blown
> HTML/JS/etc. engine will easily double the size/scope of Wine.

(broken my promise already <sigh> :)

I only said fork cos I don't think the KHTML team would accept
bug-for-bug compatability patches with IE. I guess they might, they seem
more liberal about it than the Gecko team (wrongly imho, but useful
here).

Anyway, as to maintainership, this is a good question. But how comes
adding a clone of IE is nuts, but the rest of Wine is sane, hmm? :) This
whole thing is completely crazy to some extent, but here we are in 2003
with two companies working on Wine and many volunteers.... it would
probably require a D3D style dedicated team to work on it though, which
so far doesn't exist.

And I don't think a web engine would be double the size/scope of Wine,
that's exagguration. Wine by definition has a massive scope.... there's
no denying that IE is a part of the APIs now, too many apps rely on it
being there.

Maybe when Red Hat try and sell to the corporate desktop and run into
this problem they will help.... wishful thinking perhaps.
> Stubbing is the only solution IMO.

Sure, it's either that or rewrite KHTML. And I think geckos code is too
big to use :(
> BTW, I knew about that project,
> I email with the guy a bit, he didn't seem to understand some things,
> even though I tried hard to explain. Like for example he wanted to
> implement everything (controls, etc.) on top of GDI because the
> standard controls are bloated and slow... Heh! I gave up. Obviously,
> with that approach I didn't expect him to get too far.

Hmm. Double suck. I guess we're back to square one then. Unless Ender
has done a lot more work than we are imagining.

[Shachar Shemesh]

Mike Hearn wrote:
> Anyway, as to maintainership, this is a good question. But how comes
> adding a clone of IE is nuts, but the rest of Wine is sane, hmm? :) This
> whole thing is completely crazy to some extent, but here we are in 2003
> with two companies working on Wine and many volunteers.... it would
> probably require a D3D style dedicated team to work on it though, which
> so far doesn't exist.

Oh no - you open software developers are off your head! Next thing you 
will be developing a .NET replacement! Wait, you are. Hmm, nobody will 
be crazy enough to work on an entire GUI shell, though. Two you said? 
Not including the small ones? Not a modern OS, though. HOW many? Surely 
none is enterprise ready! What precentage of web servers? PEOPLE! GET A 
LIFE!!!!

Good thing I'm not part of it.

What do you mean by "grep wine/AUTHORS"?

AAAAAARRRRRGGGGGHHHHH!!!!!!!!

P.S.
Yes, I spent the day working on a perl util to convert an MSSQL DB to 
postgres for a client (yes, I'm getting paid to do this, at least, I 
hope does anybody happen to know something that does that already?). I 
think expecting any USEFUL mails from me would be a total waste of time. 
Sorry for the OT posts.

[Dimitrie O. Paun]

On Wed, 28 May 2003, Shachar Shemesh wrote:
> Oh no - you open software developers are off your head! Next thing you

And yeah, that would be sadly true if we start yet another browser
project, when we already have Mozilla and KHTML... :/

[Mike Hearn]

> And yeah, that would be sadly true if we start yet another browser
> project, when we already have Mozilla and KHTML... :/

It's hardly a new browser project.

a) It wouldn't be about developing a browser. Who gives a monkeys about
browseui, favourites etc. We only care about the rendering engine, and
then only because there's a buttload of proprietary code out there that
relies on bizarre quicks and "features" of mshtml in order to operate.

b) it'd be based on either khtml or mozilla. not starting a new
rendering engine.

c) we have little choice. Well, that's slightly melodramatic, obviously
nobody has to work on it. But sooner or later somebody will find they
need it. Probably lots of people.

[Steven Edwards]

> b) it'd be based on either khtml or mozilla. not starting a new
> rendering engine.

Mozilla is going to be the way to go if Demi can get the gecko to build and work as a WINElib app
now that it can be built with Mingw. Once that is done we will know what needs to be fixed in WINE
to support it as either a elf or PE binary. Plus it will save us on the ReactOS side some work
when we go to do a explorer/browser clone. =)

Thanks
Steven

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

[Vincent Béron]

Le mer 28/05/2003 à 16:30, Steven Edwards a écrit :
> > b) it'd be based on either khtml or mozilla. not starting a new
> > rendering engine.
>
> Mozilla is going to be the way to go if Demi can get the gecko to build and work as a WINElib app
> now that it can be built with Mingw. Once that is done we will know what needs to be fixed in WINE
> to support it as either a elf or PE binary. Plus it will save us on the ReactOS side some work
> when we go to do a explorer/browser clone. =)

The problem with that approach is that many CHM files rely on some
IE-only extensions and/or quirks. Gecko seems to be too much
standards-compliant to be very useful in this form, at least without
some heavy modifications to the rendering engine.

Vincent

[Sylvain Petreolle]

Quoting Paul McNett :

"Yes, even if its just plain-text for the time being, any CHM viewer is

better than no CHM viewer."

We have some "NYI" in Wine code, no problem with that.
> The problem with that approach is that many CHM files rely on some
> IE-only extensions and/or quirks. Gecko seems to be too much
> standards-compliant to be very useful in this form, at least without
> some heavy modifications to the rendering engine.
>
> Vincent

=====
Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259
No more War !

"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".

For the Law of Oil and Fire, Im an European that lives in France.
For all my Brothers and friends, Im a human living on Earth.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

> Mozilla is going to be the way to go if Demi can get the gecko to build
> and work as a WINElib app now that it can be built with Mingw. Once that
> is done we will know what needs to be fixed in WINE to support it as
> either a elf or PE binary. Plus it will save us on the ReactOS side some
> work when we go to do a explorer/browser clone. =)

Well, anything is a start... but IMHO whilst Mozilla is a fair browser,
and Gecko is a fair rendering engine... neither of them are up to coping
with the stress of providing IE-compatible integration.

Also upstream tracking of Gecko would be very much impossible, and there
is ZERO chance that IE'isms would ever make it into upstream anyway...
KHTML has a far better chance in that respect :)

Also Geckos JavaScript engine is very so-so with a lot of the MS-formatted
JS I've tried feeding it :(

- Ender

[Ender]

> Correction, it seems despite first appearances the project was never
> born. Its CVS tree is empty. Suckage.
>
> Rereading Enders email I can't quite decide if he stubbed Qt out in
> order to get it running on Win32 or not.... if we were to track KHTML
> CVS, stubs would be the only solution, but as it might need to be forked
> anyway actually de-Qt'ing is another possibility.
>
> Ender, could you give more details about how you got it running on
> win32?

Well, if you look back through wine-devel's archives when this last came
up, I had a KHTML running natively without stubbing (much, there were a
few for simple heavily used classes like QString). We had this very same
discussion then too, that we really need to stub in order to keep track of
upstream. I started writing a wrapper, but then Safari was released and
people were talking about porting WebCore to Win32.

I paused my work about then, firstly because of the C++ in CVS issue
(writing stubs and wrappers is fairly easy but tedious, and if none of the
work could go into CVS anyway..)... But also because I was being lazy and
hoping that the WebCore port would get to point I could at least use it as
a base. Obviously that never happened :(

- Ender

http://www.scummvm.org/   | Where am I going...
   http://www.quakesrc.org/  |           ...and why am I in a handbasket?
   http://www.enderboi.com/  |

[Dimitrie O. Paun]

On 28 May 2003, Mike Hearn wrote:
> Running through 3 translation layers is going to suck though.
>
> KHTML -> KWQ -> Wine -> Linux

I don't think it's all that bad. Currently we have:

KHTML -> WebCore -> Cocoa

or

KHTML -> QT -> Linux

I don't think KWQ will add much overhead, it's going to be essentially:

KHTML -> Wine -> Linux

And I don't think QT/X11 is all that much faster than Wine.
> Bearing in mind KWQ would have to provide a pthreads wrapper around
> win32, then have win32 mapped back onto pthreads - ouch!

But we do integrate with pthreads right now, it should just work, no?

[Mike Hearn]

> Any current efforts to port WebCore to Win32? Or it's maybe easier
> to create a WinCode? BTW, any idea how big this effort is?

In a minute I'll get on with some work and stop spamming everyone. One
last thing, the WebCore framework isn't what we're interested in, we
want KWQ (pronounced quack apparently) which is what maps Qt -> MacOS.

Unfortunately, it seems KWQ is mostly MacOS specific. It's written in
Objective C++, a language I didn't even suspect the existance of until I
read the sources. Example:

QListBox::~QListBox()
{
    NSTableView *tableView = [(NSScrollView *)getView() documentView];
    [tableView setDelegate:nil];
    [tableView setDataSource:nil];
    [_items release];
}

As if C++ wasn't hard enough to read already! KWQ consists of 296 files,
might as well call it 300. These cover a part of the Qt classes and also
the KDE ones. Quite a few are simply stubs:

int QXmlParseException::lineNumber() const
{
    ERROR("not yet implemented");
    return 0;
}

Luckily, most of the files are small, in fact some are about 2-3k, of
which most is the boilerplate header (seems to be a pretty liberal
license).

Some parts, like KWKQURL (i kid you not, that is the name of the class)
look pretty reusable. Other parts are heavily reliant upon the NeXTStep
APIs.

Basically porting it to Win32 would be a major piece of work. KWQ itself
is a large effort. I'm not sure why Apple didn't simply license Qt for
its developers, then bind it into Objective-C in the traditional way.
That would surely have been simpler than duplicating all this code from
Qt. Perhaps the idea that the cost of Qt is insignificant next to
developer time, as espoused lately by some KDE devs, is flawed? Or maybe
it was needed to get good bindings into their Cocoa framework (sounds
unlikely but possible).

Anyway. I'm guessing that porting this would be the first step, if KHTML
was used.

thanks -mike
(goes back to work)

[Dimitrie O. Paun]

On 28 May 2003, Mike Hearn wrote:
> Unfortunately, it seems KWQ is mostly MacOS specific. It's written in
> Objective C++, a language I didn't even suspect the existance of until I
> read the sources. Example:
>
> QListBox::~QListBox()
> {
>     NSTableView *tableView = [(NSScrollView *)getView() documentView];
>     [tableView setDelegate:nil];
>     [tableView setDataSource:nil];
>     [_items release];
> }

Gee! I've heard about it before, people saying is so much easier than
C++. Yeah, right!
> Luckily, most of the files are small, in fact some are about 2-3k, of
> which most is the boilerplate header (seems to be a pretty liberal
> license).

Important point is if it's compatible with the LGPL. Can we use stuff
from it in Wine?

[Mark Westcott]

The AtheOS guy de Qt ised KTHML a while back:
http://www.atheos.cx/news.php3 search for KHTML.  I can't find the source at 
the moment though.  This is probably already widley out of date.

I agree with Dimi however that stubbs are gonna be the way to go however, 
maintaining a port isn't going to be much fun. Having said that KHTML/KJs is 
a lot neater/smaller code than mozilla/gecko.

Mark
(goes to have his hair cut)

[Shachar Shemesh]

Mike Hearn wrote:
> Unfortunately, it seems KWQ is mostly MacOS specific. It's written in
> Objective C++, a language I didn't even suspect the existance of until I
> read the sources. Example:

...
> As if C++ wasn't hard enough to read already!

On a 100% unrelated note, and since this list does not have LKML's 
faschist charter, I'll go really OT and mention that Objective-C was 
developed parallel to C++, so any attempts to claim that it was 
redundant are a little hind-site oriented. Major IIRC disclaimer here, 
of course.

Shachar