We're passing a pointer as 4th argument to WinHelp. Do not cast it to
DWORD which would truncate the pointer. Instead use UINT_PTR as that
is what WinHelp expects.
called load_system32_dll() which constructs a full pathname for the
DLL using GetSystemDirectory.
The only DLL load not covered by this change is the one for
gssapi32.dll, because that one's not in the system32 directory.
[originally from svn r8993]
putting HTML Help into "single-threaded" mode. Furthermore, this requires
extra work from the application (message pumping via HH_PRETRANSLATEMESSAGE).
Thus, remove them and run Help in a secondary thread. This means that keyboard
input into the Index and Search tabs now works.
[originally from svn r7285]
since even the latest version of w32api (3.6) shows no sign of HTMLHelp
support.
(This touches mkfiles.pl because that's where the details of what Cygwin
doesn't support are kept currently. This may be deliberate, so I haven't
changed it.)
[originally from svn r7032]
and various calls to WinHelp() have been centralised into a new file
winhelp.c, which in turn has been modified to detect a .CHM file as
well as .HLP and select between them as appropriate. It explicitly
tries to load HHCTRL.OCX and use GetProcAddress, meaning that it
_should_ still work correctly on pre-HTML-Help platforms, falling
gracefully back to WinHelp, but although I tested this by
temporarily renaming my own HHCTRL.OCX I haven't yet been able to
test it on a real HTML-Help-free platform.
Also in this checkin: a new .but file and docs makefile changes to
make it convenient to build the sources for a .CHM. As yet, owing to
limitations of Halibut's CHM support, I'm not able to write a .CHM
directly, more's the pity.
[originally from svn r7000]
