Re: winhelp mapping

Eric Pouech eric.pouech at
Wed May 22 05:43:39 CDT 2002

the "hack" in only valid in a Win31/Win9x atchitecture; it works well will win98 winhlp32, but will likely fail for any NT implementation

so, we cannot have at the same time:
1/ a unique message passing feature for all emulated windows version
2/ the ability to run all the native winhlp32 executables

it means that we should either:
1/ emulate in a different manner the message passing ability of a given version (win16, win9x use a 16 bit global handle ; it seems NT uses a shared page)
2/ implement our own winhlp32 executable (with the support of various help formats) in which case we could choose our unique message passing implementation

for seek of completness, I'd choose 1/
for seek of code clarity/maintainability, 2/


> >>>>> "Alexandre" == Alexandre Julliard <julliard at> writes:
>     Alexandre> Eric Pouech <eric.pouech at> writes:
>     >> Alexandre, will you accept a patch of this kind (it still can be
>     >> enhanced, like storing the message id) ?
>     Alexandre> Only if there is evidence that Windows does it this way.
> I tried to follow native NT user32.dll in the winhelp() call and I ended in
> that magic 0x7ffeXXXX page, which seems to be shared data.
> Do we have any plans for that page? NT File "explorer.exe" also crashes
> accessing that page.
> I plea for encluding some WinHelp Hack. Users expect Winhelp to work. Eric's
> hack doesn't change wine fundamentals, is only changes one case.
> Bye
> -- 
> Uwe Bonnes                bon at
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Eric Pouech 
The future will be better tomorrow, 
Vice President Dan Quayle

Faites un voeu et puis Voila ! 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

More information about the wine-devel mailing list