winhelp mapping

[Eric Pouech]

this patch is an attempt to solve the issue of passing 
contextual information to winhlp32

it simply passes the data block required by the "WM_WINHELP"
(in quotes, because it's a registered window message) thru
the server, and reallocates it on the win32 size

it's a bit ugly because of the registration stuff

Alexandre, will you accept a patch of this kind (it still 
can be enhanced, like storing the message id) ?

A+

Name:          winhlp
ChangeLog:     implemented interprocess WM_WINHELP message passing
License:       X11
GenDate:       2002/05/21 19:51:19 UTC
ModifiedFiles: dlls/user/message.c windows/winhelp.c
AddedFiles:    
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/dlls/user/message.c,v
retrieving revision 1.17
diff -u -u -r1.17 message.c
--- dlls/user/message.c	26 Apr 2002 19:05:17 -0000	1.17
+++ dlls/user/message.c	19 May 2002 06:54:18 -0000
@@ -564,6 +564,18 @@
         data->count = -1;
         return 0;
     }
+    if (message == RegisterWindowMessageA("WM_WINHELP"))
+    {
+        HGLOBAL16       hMem;
+        char*           ptr;
+        hMem = LOWORD(lparam);
+        ptr = GlobalLock16(hMem);
+        push_data(data, ptr, *(WORD*)ptr);
+        GlobalUnlock16(hMem);
+        /* FIXME: it's likely that this memory block 
+         * (and more important, the associated selector) will be leaked... */
+        return 0;
+    }
     return 0;
 }

@@ -803,6 +815,23 @@
         return FALSE;

default:
+        if (message == RegisterWindowMessageA("WM_WINHELP"))
+        {
+            HGLOBAL16       hMem;
+            WORD            sz;
+            char*           dst;
+
+            if (size < sizeof(WORD)) return FALSE;
+            sz = *(WORD*)*buffer;
+            if (size != sz) return FALSE;
+            hMem = GlobalAlloc16(0,sz);
+            dst = GlobalLock16(hMem);
+            memcpy(dst, *buffer, sz);
+            GlobalUnlock16(hMem);
+            *lparam = hMem;
+            return TRUE;
+        }
+
         return TRUE; /* message doesn't need any unpacking */
     }

@@ -1622,7 +1651,7 @@
                 SetLastError( ERROR_INVALID_THREAD_ID );
             else
                 SetLastError( RtlNtStatusToDosError(res) );
-        }
+        }   
     }
     SERVER_END_REQ;
     return !res;
Index: windows/winhelp.c
===================================================================
RCS file: /home/cvs/cvsroot/wine/wine/windows/winhelp.c,v
retrieving revision 1.22
diff -u -u -r1.22 winhelp.c
--- windows/winhelp.c	10 Mar 2002 00:18:37 -0000	1.22
+++ windows/winhelp.c	19 May 2002 06:56:45 -0000
@@ -82,7 +82,6 @@
    HGLOBAL16 hwh;
    int size,dsize,nlen;

-
    if(!WM_WINHELP) 
      {
        WM_WINHELP=RegisterWindowMessageA("WM_WINHELP");
@@ -103,7 +102,6 @@
      }
         }

-
    switch(wCommand)
    {
    	case HELP_CONTEXT:
@@ -152,7 +150,8 @@
    } else
    	lpwh->ofsData = 0;
    GlobalUnlock16(hwh);
-	return SendMessage16(hDest,WM_WINHELP,hWnd,hwh);
+
+	return SendMessageA(hDest,WM_WINHELP,hWnd,hwh);
 }

[Alexandre Julliard]

Eric Pouech  writes:
> Alexandre, will you accept a patch of this kind (it still 
> can be enhanced, like storing the message id) ?

Only if there is evidence that Windows does it this way.

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Eric Pouech  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

[Rizsanyi Zsolt]

On Wednesday 22 May 2002 11:00, Uwe Bonnes wrote:
> > > > > > "Alexandre" == Alexandre Julliard  writes:
> Alexandre> Eric Pouech <[e-mail]> 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.

The SafeDisc patch (submitted by Laurent Pinchart) has a basic support for 
that page, but it was not committed to cvs.