Warning report for wine-1.3.32
warning: variable ‘_qzz_res’ set but not used [-Wunused-but-set-variable] That's valgrind stuff. Apparently I might need a valgrind update or something, I'm not 100% sure what's going on. A few more can be fixed with FIXME()s instead of comments. J. Leclanche == 32-bit == ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../dlls/advpack -I. -I../../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o advpack.o ../../../dlls/advpack/advpack.c ../../../dlls/advpack/advpack.c: In function ‘RegisterOCX’: ../../../dlls/advpack/advpack.c:495:37: warning: variable ‘param’ set but not used [-Wunused-but-set-variable] ../../../dlls/advpack/advpack.c:495:26: warning: variable ‘str_flags’ set but not used [-Wunused-but-set-variable] -- ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../../dlls/gdi32/tests -I. -I../../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o pen.o ../../../../dlls/gdi32/tests/pen.c ../../../../dlls/gdi32/tests/pen.c: In function ‘func_pen’: ../../../../dlls/gdi32/tests/pen.c:299:132: warning: array subscript is above array bounds [-Warray-bounds] ../../../../dlls/gdi32/tests/pen.c:424:132: warning: array subscript is above array bounds [-Warray-bounds] -- ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../dlls/ntdll -I. -I../../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o heap.o ../../../dlls/ntdll/heap.c ../../../dlls/ntdll/heap.c: In function ‘notify_alloc’: ../../../dlls/ntdll/heap.c:254:19: warning: variable ‘_qzz_res’ set but not used [-Wunused-but-set-variable] ../../../dlls/ntdll/heap.c: In function ‘notify_free’: ../../../dlls/ntdll/heap.c:262:19: warning: variable ‘_qzz_res’ set but not used [-Wunused-but-set-variable] -- ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../dlls/ntdll -I. -I../../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o virtual.o ../../../dlls/ntdll/virtual.c ../../../dlls/ntdll/virtual.c: In function ‘map_image’: ../../../dlls/ntdll/virtual.c:1373:19: warning: variable ‘_qzz_res’ set but not used [-Wunused-but-set-variable] -- ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../dlls/setupapi -I. -I../../../include -I../../include -D__WINESRC__ -D_SETUPAPI_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o install.o ../../../dlls/setupapi/install.c ../../../dlls/setupapi/install.c: In function ‘InstallHinfSectionW’: ../../../dlls/setupapi/install.c:1203:10: warning: variable ‘mode’ set but not used [-Wunused-but-set-variable] -- ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../../dlls/shell32/tests -I. -I../../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -fno-omit-frame-pointer -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o shlfolder.o ../../../../dlls/shell32/tests/shlfolder.c ../../../../dlls/shell32/tests/shlfolder.c: In function ‘test_ITEMIDLIST_format’: ../../../../dlls/shell32/tests/shlfolder.c:1846:30: warning: array subscript is above array bounds [-Warray-bounds] ../../../../dlls/shell32/tests/shlfolder.c:1847:30: warning: array subscript is above array bounds [-Warray-bounds] -- ccache gcc -msse4 -O3 -Wall -m32 -c -I../../../dlls/spoolss -I. -I../../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statemen
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
On 11/4/2011 20:21, Jacek Caban wrote:
On 11/04/11 17:11, Nikolay Sivov wrote:
On 11/4/2011 20:00, Jacek Caban wrote:
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid,
wFlags, pdp, pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic
and typelib-based values, then you could simply return whatever
invoke returns.
I was thinking about additional call in vtable to use instead of
is_custom to check if dispid is supposed to be handled with custom
invoke. What do you think about it?
It really depends on how it's used in msxml3.
The only case I'm aware of so far is index based access of collection
elements, that's all. So I'll better go with DISP_E_UNKNOWNNAME for now
cause use of this thing is really limited in msxml.
The problem with this solution is that it means more code in every
object using custom dipids. If we can avoid it, even at cost of more
complicated code in dispex.c, that's probably better in terms of code
maintaining IMO.
Right, extra call is too much probably.
Jacek
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
On 11/04/11 17:11, Nikolay Sivov wrote:
On 11/4/2011 20:00, Jacek Caban wrote:
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid,
wFlags, pdp, pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic and
typelib-based values, then you could simply return whatever invoke
returns.
I was thinking about additional call in vtable to use instead of
is_custom to check if dispid is supposed to be handled with custom
invoke. What do you think about it?
It really depends on how it's used in msxml3. The problem with this
solution is that it means more code in every object using custom dipids.
If we can avoid it, even at cost of more complicated code in dispex.c,
that's probably better in terms of code maintaining IMO.
Jacek
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
On 11/4/2011 20:00, Jacek Caban wrote:
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid,
wFlags, pdp, pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic and
typelib-based values, then you could simply return whatever invoke
returns.
I was thinking about additional call in vtable to use instead of
is_custom to check if dispid is supposed to be handled with custom
invoke. What do you think about it?
Jacek
Re: [2/2] mscoree: Implement ICorDebug CreateProcess
I'm curious why you've chosen to work on this. Is there a program relying on this, or do you have some .NET debugging tools you'd like to use? Or are you thinking we'd implement our own debugging tool as well (perhaps extending winedbg)? Better debugging tools for wine/mono would definitely be nice, but there are a lot of things we need, and this is not the first one I'd pick. The current state of the art in Mono debugging is the soft debugger. >From what I've heard, all other debugger technologies in Mono have been deprecated. http://www.mono-project.com/Mono:Runtime:Documentation:SoftDebugger They have documentation on the wire protocol, which is probably what we'd end up using because .NET libraries are inconvenient to use. >From what I can tell, the soft debugger needs to be configured to listen for TCP connections on a particular port. Ideally, we would want to modify it by adding a new "transport" using something like a named pipe server named based on the process id (it looks straightforward to do so, but we'd have to modify the mono runtime). Otherwise, I'm not sure how we'd identify the socket server for the process we want, and having mono run a TCP server all the time seems like a bad idea. It may also be possible to configure mono to use the soft debugger in the "normal" way and attach to it with a Linux MonoDevelop, if you want a quicker solution. It seems like it's designed to remotely debug any mono process on any platform. If you figure out how to do this, wiki documentation would be appreciated.
Re: [3/4] msxml3: Add IDispatchEx support for IXMLDOMNamedNodeMap
Hi Nikolay,
On 11/04/11 16:46, Nikolay Sivov wrote:
+if(This->data->vtbl&& This->data->vtbl->invoke) {
+hres = This->data->vtbl->invoke(This->outer, id, lcid, wFlags, pdp,
pvarRes, pei);
+if (hres != E_NOTIMPL) return hres;
+}
Using E_NOTIMPL for special meaning here seems wrong to me.
DISP_E_UNKNOWNNAME could be a better choice. However, if you'd move
custom invoke implementation to be the last choice, after dynamic and
typelib-based values, then you could simply return whatever invoke returns.
Jacek
Re: [PATCH] userenv: GetUserProfileDirectoryW should fail with ERROR_INVALID_HANDLE if handle is NULL.
Christian Inci writes:
> @@ -149,6 +149,12 @@ BOOL WINAPI GetUserProfileDirectoryW( HANDLE hToken,
> LPWSTR lpProfileDir,
>
> TRACE( "%p %p %p\n", hToken, lpProfileDir, lpcchSize );
>
> +if (!hToken)
> +{
> +SetLastError( ERROR_INVALID_HANDLE );
> +return FALSE;
> +}
There's no reason to treat a 0 handle differently. Please stop adding
such special cases just to satisfy the tests. Parameter checking needs
to fall out of the implementation.
--
Alexandre Julliard
julli...@winehq.org
Re: winedevice taking up 100% after wine cmd
On Thu, Nov 3, 2011 at 10:05 PM, Hin-Tak Leung wrote: > I just had a rather odd incident earlier today when I just launched "wine > cmd", and saw that my process monitor max-out to 100% - and it continued, > until I finished what I intended to do and exited cmd, minutes later. I > wasn't doing anything else and no typing anything in the cmd console > either, so that was curious. It was winedevice taking up 100%. > > I tried wine cmd later but couldn't get that odd behavior any more. But is > there any reason why winedevice should go into a spin? > > This is fedora 15 x86_64 running 32-bit wine I built myself. > > > The winedevice process just loads a (Windows) device driver and runs it. What driver is being loaded?
winedevice taking up 100% after wine cmd
I just had a rather odd incident earlier today when I just launched "wine cmd", and saw that my process monitor max-out to 100% - and it continued, until I finished what I intended to do and exited cmd, minutes later. I wasn't doing anything else and no typing anything in the cmd console either, so that was curious. It was winedevice taking up 100%. I tried wine cmd later but couldn't get that odd behavior any more. But is there any reason why winedevice should go into a spin? This is fedora 15 x86_64 running 32-bit wine I built myself.
