News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Windows Help 3

Started by TimoVJL, October 04, 2018, 01:29:48 AM

Previous topic - Next topic

TimoVJL

I want to open an open discussion about of Windows Help 3 files.

mshc are zipped html-files
mshi is index-file for it or just a fragment of it.

As i have already a working viewer for it, i have some info for that, but this topic is not for a that special case.

So how about reveal secrets from those as all those help experts give up in year 2014, you remember those Help 3 experts after 2014 didn't believe it any more and blogs was closed.

May the source be with you

Vortex

Hi Timo,

You are doing a nice job, thanks. It's about the mentality of M$. Why they feel the need of creating such complicated help systems? They are probably poorly documented. A complicated help file system does not help people and this what those $$$ guys cannot understand.
 

TimoVJL

Original idea was good, but M$ ruined it in two years, i read the history.
For example why M$ give up with internal hashed fixed size links that was expanded to localized links to follow user language? They still works today.
If a small fixed size string works, so why using a very long strings is anyway better?
Is a .Net languages or drugs reason for blind eyed programmers?
Who really want to know their internal long strings if it takes an unnecessary space in files?

The last good offline version was vs2012 documents, after that kids throw they food around to walls  :P
May the source be with you

LiaoMi

Here is an example of how other programs did it through original Microsoft Help Viewer api

C:\Program Files\Microsoft Help Viewer\v2.0\Microsoft.VisualStudio.Help.Runtime.dll
C:\Program Files\Microsoft Help Viewer\v2.0\Microsoft.VisualStudio.Help.dll

Microsoft.VisualStudio.Help.Runtime.dll -- This is the HV2 core API which allows you to open catalogs and read catalog data.
Microsoft.VisualStudio.Help.dll -- This API allows you to correctly render VS help topics. For non-VS topics you can ignore this and just use the renderer code provided in HV2Lib DLL.

http://hv2.helpmvp.com/code/viewer Demonstrates coding a standard Help Viewer window with TOC/Index/Search for viewing HV2 catalogs.
http://hv2.helpmvp.com/doc/api This page documents the MS Help Viewer 2.0 API calls. Eventually there will be official Microsoft documentation available but until then I hope this ties you over.

QuoteIndex
Again this is very simple. The VS catalog can contain over a million keywords so we are using a ListView control in Virtual mode.

We get a collection of Keywords by passing the _catalog object into GetKeywords() method.

IKeywordCollection keywords = _catalogRead.GetKeywords(_catalog, true);

    The true parameter enables some caching to speed up loading.

Now we have the 2.3 version of the helper, but the principles have not changed ...

TimoVJL

#4
I usually don't need .Net for reading normal files.
Usually a just one beer-can is possible to transport without using a 10-wheels truck, especially as in a truck situation driver have to be sober to do that  :eusa_naughty:
Doing C# code there ain't such a limitation as we have seen in M$ help system;)
May the source be with you

hutch--

 :biggrin:

Now you know why I did my own, I just got tired of Microsoft changing the rules on help files and trying to force everyone to use MSDN to get any technical data. I still use WIN32.HLP as it is in C and most of it works fine if you know your data size conversions. For later stuff I have a Microsoft help system dated about 2..5 which breaks when Microsoft force yet another update on Win10 and thank God I have the Intel manuals.

jj2007

Quote from: hutch-- on October 04, 2018, 03:57:25 PMI still use WIN32.HLP

It's old and outdated but in 99% of all cases it works just fine. And it has one great advantage: If you hit F1 and send it a partial string like CreateW, you don't get a 404 as in the modern crappy help versions (chm, VS help) but rather the index box (see below), where CreateWindowEx appears just two lines below the partial string. I have always wondered which level of incompetence was required to dump .hlp in favour of .chm.

For my everyday needs, hovering over CreateWin produces a yellow bubble help, which is often sufficient:
CreateWindowExA(
__in DWORD dwExStyle,
__in_opt LPCSTR lpClassName,
__in_opt LPCSTR lpWindowName,
__in DWORD dwStyle,
__in int X,
__in int Y,
__in int nWidth,
__in int nHeight,
__in_opt HWND hWndParent,
__in_opt HMENU hMenu,
__in_opt HINSTANCE hInstance,
__in_opt LPVOID lpParam)

TimoVJL

In HelpMVP you see faces who don't give low level help details, maybe MVP stands for it ;)
M$ concept of help collection make things complicated, as a big help system have a lot of same keywords and free text and that count is huge.
I also like that bubble help feature as poide have it, only problem in that ide is that ANSI/UNICODE (A/W) thing that breaks it.
WinHlp32 was converted to chm, so it is still usable.
A public help index file could be usable too. M$ tends to force user/programmer for their current technology, at this time the .Net.
A current xhtml files was targeted to help server and need some special formatting.

That COM/.Net makes keywords difficult as the keyword depends of context, like CHString::Find method.

A private help files may work, but i prefer of public formats.
Everyone can make a compressed help-file in different methods.
For example:
A header with count of ids, records of ids with id,size,offset to compressed block and compressed blocks after header.
May the source be with you

TimoVJL

#8
Quote from: jj2007 on October 04, 2018, 05:05:07 PM

It's old and outdated but in 99% of all cases it works just fine. And it has one great advantage: If you hit F1 and send it a partial string like CreateW, you don't get a 404 as in the modern crappy help versions (chm, VS help) but rather the index box (see below), where CreateWindowEx appears just two lines below the partial string. I have always wondered which level of incompetence was required to dump .hlp in favour of .chm.
Sadly TLWHView can't do same, as it show a bit more keywords ;)
A minimal test file for .mshc<?xml version="1.0" encoding="utf-8"?><html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <Title>Index</Title>
    <meta name="Microsoft.Help.TopicLocale" content="en-us" />
    <meta name="Microsoft.Help.Id" content="HelpId0" />
    <meta name="Microsoft.Help.TocParent" content="-1" />
    <meta name="Title" content="Index" />
  </head>
  <body>
  Index
  </body>
</html>

EDIT 2018-10-11: WHelpIndexOL64_WS_a1, a project to index online links.
May the source be with you

TimoVJL

#9
A small test result from mshi page titles:C:\code\MSDN-2018\msh\*.mshi
v2Programming reference for Windows API_en-us__0.mshi 31 ms
v2Programming reference for Windows API_en-us__1.mshi 16 ms
v2Programming reference for Windows API_en-us__2.mshi 15 ms
v2Programming reference for Windows API_en-us__3.mshi 32 ms
v2Programming reference for Windows API_en-us__4.mshi 15 ms
v2Programming reference for Windows API_en-us__5.mshi 16 ms
v2Programming reference for Windows API_en-us__6.mshi 15 ms
v2Programming reference for Windows API_en-us__7.mshi 0 ms
v2Windows Desktop App Development_en-us_vs.85_0.mshi 16 ms
v2Windows Desktop App Development_en-us_vs.85_1.mshi 16 ms
v2Windows Desktop App Development_en-us_vs.85_2.mshi 0 ms
v2Windows Desktop App Development_en-us_vs.85_3.mshi 15 ms
v2Windows Desktop App Development_en-us_vs.85_4.mshi 0 ms
v2Windows Desktop App Development_en-us_vs.85_5.mshi 16 ms
v2Windows Desktop App Development_en-us_vs.85_6.mshi 0 ms
v2Windows Desktop App Development_en-us_vs.85_7.mshi 15 ms
v2Windows Desktop App Development_en-us_vs.85_8.mshi 16 ms
234 ms
functions: 26643
structs:   10364
enums:     4206
macros:    1690
total:     42903
WHelp3IndexMshiTest2 was used for that.
ToolLibs zip was not needed to this example, but maybe later...

EDIT: for older files than 2018, 2015 ?int CheckTitle(char *pTitle, int nLen)
{ // function structure enumeration Enumeration macro (Windows)
int rc = 0;
char *pEnd = pTitle+nLen; // enn of title
if (*(DWORD*)(pEnd-4) == *(DWORD*)"ows)") pEnd -= 10; // (Windows)
if (nLen > 10 && *(DWORD*)(pEnd-8) == *(DWORD*)"func"
&& *(pEnd-10) != ')' && *(pEnd-10) != ']') {
nCntFuncs++;
rc = 1;
}
else if (nLen > 10 && *(DWORD*)(pEnd-9) == *(DWORD*)"stru") {
nCntStructs++;
rc = 2;
}
else if (nLen > 10 && *(DWORD*)(pEnd-10) == *(DWORD*)"nume") {
nCntEnums++;
rc = 3;
}
else if (nLen > 10 && *(DWORD*)(pEnd-5) == *(DWORD*)"macr") {
nCntMacros++;
rc = 4;
}
else if (nLen > 10 && *(DWORD*)(pEnd-7) == *(DWORD*)"mess") {
nCntMsgs++;
rc = 5;
}
return rc;
}
With PkgDownloadCabs someone can download a some 2015 help-cabs. (339MB)
EDIT: a lot of missing keywords, maybe that B4248 means 42/48 hit rate :P
EDIT: WH3_Search search test from mshi-file of folder, F=file D=folder
May the source be with you

TimoVJL

#10
WHelp3View1 is a small example to look help page html source.
In sys menu is a Open mshc... to open a mshc/mshi file pair.
At first it read mshi file for titles to listbox.
Double clicking title it opens page to editbox and shows file number in titlebar.

EDIT 2018-10-24: So now there is quite many examples to work with those help files, so why not to use that format  ;) :icon_confused:

EDIT 2021-01-28: MS help 3 files

May the source be with you