Re: [PATCH] HOOK_CallHook
This kind of begs the question: how many more places in Wine should the volatile keyword be used? I find it hard to believe that this is the only spot in a large very low-level project like Wine. You're comment is absolutely right. The thing is, those bugs are especially hard to find out and require very careful code examination. IMHO, performing code review of the whole tree for missing volatile keywords would be a waste of time compared to do it on a case by case basis. Simply keep in mind that those bugs may happen - especially with "aggressive" compilers such as gcc 2.96. If a bug didn't happen with the previous compiler and does show up with the latest release, it might be a good candidate. Now try to don't go paranoid about compiler issues when WINE crashes with your new Linux installations ;) Francois
Re: [PATCH] HOOK_CallHook
IMHO, performing code review of the whole tree for missing volatile keywords would be a waste of time compared to do it on a case by case basis. Simply keep in mind that those bugs may happen - especially with "aggressive" compilers such as gcc 2.96. If a bug didn't happen with the previous compiler and does show up with the latest release, it might be a good candidate. But the point is, this is *not* a Wine bug that was just exposed by a new compiler -- this is a compiler bug, plain and simple. Did I write it was a WINE bug? No. It is very clear for me that it *is* a compiler issue. I had three choices a) find a workaround and have people comment on it; b) disable the optimize phase for gcc 2.96 and have the whole community on my back; c) fix gcc. I went for the easy one. Making these variables 'volatile' is not required at all -- 'volatile' tells the compiler that the variables might be changed behind the compiler's back, e.g. due to being asynchroneously modified by a signal handler or something like that. In this particular case, however, the variables are not only not changed behind the compiler's back, they are *never* changed at all! 100% agree. Again, it's a quick-yet-efficient workaround to the compiler problem that just happened to work. While volatile is for variables that are modified by external factors, it was a good way to prevent all the optimization - which was just what I wanted. Instead of circumventing the compiler bug in this particular case, it might be preferable to find out which optimization phase contains the bug, and write a configure check that switches that phase off if it detects the bug (like we did with the 2.95.2 strength-reduce bug). We'll do some research on the optimization phase. Once we found it, can anybody help us with that autoconf kungfu? Ciao! Francois
Re: [PATCH] typelib.c - ITypeInfo::Invoke
If the network is not lying to me again,
[EMAIL PROTECTED] wrote on Thu, Dec 21, 2000 at 01:37:39PM -0800:
Francois Jacques [EMAIL PROTECTED] writes:
+static HRESULT
+INVOKE_InvokeStdCallFunction(IUnknown* pIUnk,
+ FUNCDESC* pFuncDesc,
+ VARIANTARG* paArgsCoerced,
+ VARIANT*pVarResult,
+ EXCEPINFO* pExcepInfo)
+{
+typedef DWORD (__stdcall *pDWORDRetFunc) (IUnknown*);
+typedef double (__stdcall *pDoubleRetFunc)(IUnknown*);
+
+HRESULT hr = E_FAIL;
+
+/* retrieve current stack pointer, keep a copy */
+#ifdef __GNUC__
+#ifdef __i386__
+register DWORD esp asm("esp");
+#endif
+#endif
You absolutely cannot manipulate the stack behind gcc's back. There is
no way this can work except by pure blind luck.
OK, now could you explain us why?
You should build the
arguments into a DWORD array and then use a switch statement to pass
the right number of parameters, like we do in relay32/relay386.c.
We were thinking about implementing it that way, but implementing it
like it is (no limitation about the number of parameters) appeared at
the time a more efficient approach. I like the relay implementation
since it's 100% portable while this one isn't. However, and I repeat
myself here, I'd like to know why the code can't work.
Later
--
Francois Jacques, Software Designer
Macadamian Technologies Inc.
Hack in mmsystem... need more info
Folks,
While adding asynchronous recording, I needed the following hack to make
things work with the application I'm working on. If someone could give
me a quick explanation, that would be great.
Thanks in advance,
Francois
--
Francois Jacques, Software Designer
Macadamian Technologies Inc.
index: dlls/winmm/mmsystem.c
===
rcs file: /home/wine/wine/dlls/winmm/mmsystem.c,v
retrieving revision 1.16
diff -u -r1.16 mmsystem.c
--- dlls/winmm/mmsystem.c 2000/08/14 14:29:22 1.16
+++ dlls/winmm/mmsystem.c 2000/09/21 19:48:24
@@ -4461,8 +4461,10 @@
{ \
lpwine_mld wmld; \
trace("(%04x);\n", hwavein); \
-if ((wmld=mmdrv_get(hwavein,mmdrv_wavein,false)) == null) \
+if ((wmld=mmdrv_get(hwavein,mmdrv_wavein,true)) == null) \
+ { \
return mmsyserr_invalhandle;\
+ } \
return mmdrv_message(wmld,widm_##xx,0l,0l,true); \
} \
uint16 winapi wavein##xx##16(hwavein16 hwavein16) \
Re: WorkArea
On Sat, Sep 09, 2000 at 07:23:39PM -0700, Alexandre Julliard wrote: I think your GetWorkAreaRect function belongs in USER_DRIVER, not in WND_DRIVER, since it doesn't apply to a specific window. Right. I wasn't aware of the USER_DRIVER (wine knowledge gets better every day!) Also when adding new functions to x11drv, please make sure to add a corresponding stub in ttydrv. I thought that ttydrv went away, but now I see (grep -r ttydrv) that it's now in dlls/ttydrv. Fair enough, I'll make the changes! Francois -- Francois Jacques, Software Designer Macadamian Technologies Inc.
Re: [PATCH] QueryPathOfRegTypeLib
Arg !
Alexandre, please forget that patch ! I'll repost it soon with yet
another update...
Sorry guys for the inconvenience.
Francois
Francois Jacques wrote:
Description :
If typelib path cannot be found with neither primary language ID or
secondary language ID, use system ID (0)
Francois Jacques
Macadamian Technologies Inc.
Index: dlls/oleaut32/typelib.c
===
RCS file: /home/wine/wine/dlls/oleaut32/typelib.c,v
retrieving revision 1.17
diff -u -u -r1.17 typelib.c
--- dlls/oleaut32/typelib.c 2000/08/08 20:49:16 1.17
+++ dlls/oleaut32/typelib.c 2000/08/09 21:27:52
@@ -119,6 +119,10 @@
/* try again without lang specific id */
if (SUBLANGID(lcid))
return
QueryPathOfRegTypeLib(guid,wMaj,wMin,PRIMARYLANGID(lcid),path);
+/* try again with system lang id */
+else
+ return QueryPathOfRegTypeLib(guid,wMaj,wMin,0,path);
+
FIXME("key %s not found\n",typelibkey);
return E_FAIL;
}
QueryPathOfRegTypeLib.diff
Content-Type:
text/plain
Content-Encoding:
7bit
[PATCH] ITypeLib2_Constructor - another bug
Description : Problem while reading type description.
When reading a VT_PTR type (td[0] == 1a, for typelib hackers...) and the
being non-standard (td[3] 0) then it would assign the pointed type
description as the type stored at index td[3]/8 in the type description
table.
The problem is that for non-standard pointed types, td[3] is always 0
(duh!). I observed that the type is stored at td[2]/8 and not td[3]/8.
This would cause TLB_GetTdesc to return the wrong type when processing
non-standard types.
The problem has been observed against Microsoft's stdole2.tlb.
Francois Jacques
Macadamian Technologies Inc.
Index: dlls/oleaut32/typelib.c
===
RCS file: /home/wine/wine/dlls/oleaut32/typelib.c,v
retrieving revision 1.17
diff -u -u -r1.17 typelib.c
--- dlls/oleaut32/typelib.c 2000/08/08 20:49:16 1.17
+++ dlls/oleaut32/typelib.c 2000/08/09 16:23:51
@@ -1257,7 +1263,7 @@
if(td[3] 0)
V_UNION((pTypeLibImpl-pTypeDesc[i]),lptdesc)=
stndTypeDesc[td[2]];
else
-V_UNION((pTypeLibImpl-pTypeDesc[i]),lptdesc)=
pTypeLibImpl-pTypeDesc[td[3]/8];
+V_UNION((pTypeLibImpl-pTypeDesc[i]),lptdesc)=
+pTypeLibImpl-pTypeDesc[td[2]/8];
}
else if(td[0] == VT_CARRAY)
{
Re: Initialize hrgnWnd
Hi Huw,
Nope I didn't see it.
Thanks a lot for the tip!
F.
Huw D M Davies wrote:
On Mon, Jul 31, 2000 at 10:15:14AM -0400, Francois Jacques wrote:
huw,
Thanks for this update... After a while, I thought that my WindowRgn
patch wouldn't make it into the tree. I have an updated version which
had this fix along with other XShape--WindowRgns issues. Look for an
update later this week...
Hi Francois
Have you got this one too?
Changelog:
WINPOS_WindowFromPoint should care about hrgnWnd.
Huw.
--
Dr. Huw D M Davies | Clarendon Laboratory
[EMAIL PROTECTED] | Parks Road
Tel: +44 1865 272390| Oxford OX1 3PU
Fax: +44 1865 272400| UK
Index: windows/winpos.c
===
RCS file: /home/wine/wine/windows/winpos.c,v
retrieving revision 1.67
diff -u -r1.67 winpos.c
--- windows/winpos.c 2000/07/28 23:04:55 1.67
+++ windows/winpos.c 2000/08/01 09:23:22
@@ -466,13 +466,16 @@
/* is enabled (or it's a top-level window), then explore */
/* its children. Otherwise, go to the next window. */
-if ((wndPtr-dwStyle WS_VISIBLE)
+ if ((wndPtr-dwStyle WS_VISIBLE)
(!(wndPtr-dwStyle WS_DISABLED) ||
((wndPtr-dwStyle (WS_POPUP | WS_CHILD)) != WS_CHILD))
-(xy.x = wndPtr-rectWindow.left)
-(xy.x wndPtr-rectWindow.right)
-(xy.y = wndPtr-rectWindow.top)
-(xy.y wndPtr-rectWindow.bottom))
+ wndPtr-hrgnWnd ?
+ PtInRegion(wndPtr-hrgnWnd, xy.x - wndPtr-rectWindow.left,
+xy.y - wndPtr-rectWindow.top) :
+((xy.x = wndPtr-rectWindow.left)
+ (xy.x wndPtr-rectWindow.right)
+ (xy.y = wndPtr-rectWindow.top)
+ (xy.y wndPtr-rectWindow.bottom)))
{
*ppWnd = wndPtr; /* Got a suitable window */
@@ -517,7 +520,7 @@
{
retvalue = hittest; /* Found the window */
goto end;
- }
+ }
}
else
{
Re: Initialize hrgnWnd
huw, Thanks for this update... After a while, I thought that my WindowRgn patch wouldn't make it into the tree. I have an updated version which had this fix along with other XShape--WindowRgns issues. Look for an update later this week... Francois Huw D M Davies wrote: Huw D M Davies [EMAIL PROTECTED] Initialize hrgnWnd. -- Dr. Huw D M Davies | Clarendon Laboratory [EMAIL PROTECTED] | Parks Road Tel: +44 1865 272390| Oxford OX1 3PU Fax: +44 1865 272400| UK Index: windows/win.c === RCS file: /home/wine/wine/windows/win.c,v retrieving revision 1.95 diff -u -r1.95 win.c --- windows/win.c 2000/07/15 19:42:52 1.95 +++ windows/win.c 2000/07/29 16:45:39 @@ -810,6 +810,7 @@ wndPtr-text = NULL; wndPtr-hmemTaskQ = GetFastQueue16(); wndPtr-hrgnUpdate = 0; +wndPtr-hrgnWnd= 0; wndPtr-hwndLastActive = hwnd; wndPtr-dwStyle= cs-style ~WS_VISIBLE; wndPtr-dwExStyle = cs-dwExStyle;
Re: wine.conf graphical front-end development
Hi Martin, A few ideas thrown in... 1. you can choose if you want to generate new or edit existing wine.conf file. Generating new wine.conf would have default value? The generated wine.conf should have comments in it... 2. choose a location of your wine.conf file hmmm... that depends of the installation directory, eg. you install it under /usr or /usr/local (...) IMHO, the default value should be /usr/local/etc since default install directory should be /usr/local this way we would get binaries in /usr/local/bin libraries in /usr/local/lib .conf file in /usr/local/etc Moreover, keep in mind each user can have a .winerc which overrides wine.conf value. The wizard could have a "site" mode, where you change settings in wine.conf (as root, typically) and a user mode where you can change only the .winerc settings. I would be possible to switch in site mode by prompting for root password... 4. where the windows/profile/temp directory is ([wine] section of wine.conf file) I haven't read the WINE Admin book but, if I were a sysadmin, I would setup WINE this way (keep in mind it's not a devel sandbox...) Sysadmins comments are welcomed here... $TEMP (%temp%, in Windows) being assigned to /tmp (/tmp being a different drive or partition) $PROFILE being assigned to $HOME/.wine and it's where we would store user.reg wine.conf, system.reg and other system wide settings in /usr/local/etc (or /usr/local/etc/wine) 4.5 default wine look ([tweak.layout] section) 5. you can choose if you want to answer more questions, or if it is enough and you want save it and finish configuration. if you choosed more questions: 6. dll load order 7. things like "managed windows" ([x11drv] section) 8. ports ([serialports] [parallelports] [spooler] sections) 9. registry ([registry] section) 10. complete screen, where you can see and edit everything Ultimate wine hacker dream feature... The editor screen splits in two. Upper pane is for wine.conf/.winerc editing. The bottom pane updates itself with information for each setting, as you cursor move from line to line (some OS/2 config.sys editors behaved like this) Cheers, Francois
Re: typelib
Juergen Schmied wrote: What I would suggest is a merge between your new implementation and Rein Klases' original code. The code could go like this... I removed this code because when starting hh.exe it finds something what is not a typelib and crashes. We would need a more safe way here... See also the documentation for load typelib: - first it is tried if the file is a stand-alone typelib - if that fails, then if it is a executable load the typelib from resource - if that fails parse the file into a moniker. Sounds good let's impement like this. Should I go for if? MapFile if(Signature = MSFT) ReadTypelib(BaseAdress) Unmap else if(Signature = MZ) LoadLibrary() GetResource() ReadTypelib(ResourceAdress) else FIXME: case3 juergen That sounds good to me!
Re: typelib
Rein Klazes wrote: On Thu, 6 Jul 2000 20:31:13 +0200, you wrote: Sounds good let's impement like this. Should I go for if? If I understand correctly, Francois Jacques has been assigned to fix this and others issues with regard to ole automation. True. But if Juergen feels like implementing it, I don't see any problem! This way I could concentrate my efforts on a few other issues. Cheers, Francois
Re: More typelib fixes
Huw, By the way can anybody point me to the spec of a typelib file format? There is no MS typelib file format specification out there :-( The thing being public about their file format is what's in it, and that's documented in MSDN, especially inside Books/Inside OLE (yes, the whole Inside OLE book is in MSDN!) Francois Jacques Macadamian Technologies Inc.
[PATCH] Set/GetWindowRgn
Hello world! Here's a implementation for Set/GetWindowRgn. Notice that it modifies configure.in and make_X11wrappers, so a few additional steps are needed to apply the patch. Here is the procedure cd your_wine_sandbox_here patch -p0 WindowRgn.diff autoconf configure.in configure ; chmod u+x configure cd include autoheader ../configure.in config.h.in cd .. ./configure ./tools/make_X11wrappers make depend ; make --- Adds non-rectangular windows support to WINE. Functionality permits support for skin-enabled applications such as WinAMP, RealJukebox and any type of non-rectangular window you can think of. Changelog : - implementations of SetWindowsRgn and GetWindowRgn - GetDCEx updated with a fixme that shows up when applying a window region to a non-native window - X11DRV and TTYDRV updated with new API SetWindowRgn Modified file(s): - configure.in - tools/make_X11wrappers - tsx11/Makefile.in - tsx11/X11_calls - dlls/x11drv/x11drv_main.c - include/acconfig.h - include/ttydrv.h - include/x11drv.h - include/win.h - windows/winpos.c - windows/dce.c - windows/x11drv/init.c - windows/x11drv/wnd.c - windows/ttydrv/init.c - windows/ttydrv/wnd.c François Jacques Macadamian Technologies Inc.
[PATCH] Set/GetWindowRgn, take 2
(same as previous, but with the patch attached!) Hello world! Here's a implementation for Set/GetWindowRgn. Notice that it modifies configure.in and make_X11wrappers, so a few additional steps are needed to apply the patch. Here is the procedure cd your_wine_sandbox_here patch -p0 WindowRgn.diff autoconf configure.in configure ; chmod u+x configure cd include autoheader ../configure.in config.h.in cd .. ./configure ./tools/make_X11wrappers make depend ; make --- Adds non-rectangular windows support to WINE. Functionality permits support for skin-enabled applications such as WinAMP, RealJukebox and any type of non-rectangular window you can think of. Changelog : - implementations of SetWindowsRgn and GetWindowRgn - GetDCEx updated with a fixme that shows up when applying a window region to a non-native window - X11DRV and TTYDRV updated with new API SetWindowRgn Modified file(s): - configure.in - tools/make_X11wrappers - tsx11/Makefile.in - tsx11/X11_calls - dlls/x11drv/x11drv_main.c - include/acconfig.h - include/ttydrv.h - include/x11drv.h - include/win.h - windows/winpos.c - windows/dce.c - windows/x11drv/init.c - windows/x11drv/wnd.c - windows/ttydrv/init.c - windows/ttydrv/wnd.c François Jacques Macadamian Technologies Inc. Index: configure.in === RCS file: /home/wine/wine/configure.in,v retrieving revision 1.130 diff -u -u -r1.130 configure.in --- configure.in2000/06/23 20:15:35 1.130 +++ configure.in2000/06/27 06:23:20 @@ -1,4 +1,4 @@ -dnl Process this file with autoconf to produce a configure script. +\dnl Process this file with autoconf to produce a configure script. dnl Author: Michael Patra [EMAIL PROTECTED] dnl [EMAIL PROTECTED] AC_REVISION([configure.in 1.00]) @@ -169,7 +169,17 @@ AC_MSG_WARN([Xshm extension not found!!]) ) -dnl *** Check for XFree86 DGA / DGA 2.0 extension +dnl *** Check for X shape extension +AC_CHECK_HEADERS(X11/Xlib.h X11/extensions/shape.h, +[ dnl *** If X11/extensions/shape.h exists... + AC_CHECK_LIB(Xext,XShapeQueryExtension, + AC_DEFINE(HAVE_LIBXSHAPE),, + $X_LIBS -lXext -lX11 $X_EXTRA_LIBS) + ], + AC_MSG_WARN([XShape extension found!!]) + ) + + dnl *** Check for XFree86 DGA / DGA 2.0 extension AC_CHECK_HEADERS(X11/extensions/xf86dga.h, [ dnl *** If X11/extensions/xf86dga.h exists, check dnl *** for XDGAQueryExtension()... Index: dlls/x11drv/x11drv_main.c === RCS file: /home/wine/wine/dlls/x11drv/x11drv_main.c,v retrieving revision 1.16 diff -u -u -r1.16 x11drv_main.c --- dlls/x11drv/x11drv_main.c 2000/06/23 16:49:46 1.16 +++ dlls/x11drv/x11drv_main.c 2000/06/27 06:23:20 @@ -13,6 +13,7 @@ #include X11/cursorfont.h #include "ts_xlib.h" #include "ts_xutil.h" +#include "ts_shape.h" #include "winbase.h" #include "wine/winbase16.h" Index: include/acconfig.h === RCS file: /home/wine/wine/include/acconfig.h,v retrieving revision 1.22 diff -u -u -r1.22 acconfig.h --- include/acconfig.h 2000/05/12 20:18:16 1.22 +++ include/acconfig.h 2000/06/27 06:23:20 @@ -24,6 +24,9 @@ /* Define if you have the X Shm extension */ #undef HAVE_LIBXXSHM +/* Define if you have the X Shape extension */ +#undef HAVE_LIBXSHAPE + /* Define if you have the Xxf86vm library */ #undef HAVE_LIBXXF86VM Index: include/ttydrv.h === RCS file: /home/wine/wine/include/ttydrv.h,v retrieving revision 1.30 diff -u -u -r1.30 ttydrv.h --- include/ttydrv.h2000/06/08 04:57:23 1.30 +++ include/ttydrv.h2000/06/27 06:23:20 @@ -201,5 +201,6 @@ extern void TTYDRV_WND_SetDrawable(struct tagWND *wndPtr, struct tagDC *dc, WORD flags, BOOL bSetClipOrigin); extern BOOL TTYDRV_WND_SetHostAttr(struct tagWND *wndPtr, INT haKey, INT value); extern BOOL TTYDRV_WND_IsSelfClipping(struct tagWND *wndPtr); +extern void TTYDRV_WND_SetWindowRgn(struct tagWND *wndPtr, HRGN hrgnWnd); #endif /* !defined(__WINE_TTYDRV_H) */ Index: include/win.h === RCS file: /home/wine/wine/include/win.h,v retrieving revision 1.27 diff -u -u -r1.27 win.h --- include/win.h 2000/05/23 04:12:23 1.27 +++ include/win.h 2000/06/27 06:23:20 @@ -78,6 +78,7 @@ struct tagDCE *dce; /* Window DCE (if CS_OWNDC or CS_CLASSDC) */ HGLOBAL16 hmemTaskQ; /* Task queue global memory handle */ HRGN16 hrgnUpdate;/* Update region */ +HRGN hrgnWnd; /* window's region */ HWND
