[AppDB] Re: appdb/include filter.php

[Jonathan Ernst]

Le jeudi 06 juillet 2006 à 23:49 -0500, WineHQ a écrit :
 ChangeSet ID: 26258
 CVSROOT:  /opt/cvs-commit
 Module name:  appdb
 Changes by:   [EMAIL PROTECTED]   2006/07/06 23:49:32
 
 Modified files:
   include: filter.php 
 
 Log message:
   Tony Lambregts [EMAIL PROTECTED]
   filter_gpc() should ignore any bugzilla parameters to avoid errors when 
 these cookies are set
 
 Patch: http://cvs.winehq.org/patch.py?id=26258
 
 Old revision  New revision  Changes Path
  1.3   1.4   +12 -1  appdb/include/filter.php
 
 Index: appdb/include/filter.php
 diff -u -p appdb/include/filter.php:1.3 appdb/include/filter.php:1.4
 --- appdb/include/filter.php:1.3  7 Jul 2006  4:49:32 -
 +++ appdb/include/filter.php  7 Jul 2006  4:49:32 -
 @@ -42,8 +42,19 @@ function filter_gpc()
  util_show_error_page_and_exit(Fatal error: 
 .$aKeys[$i]. should be an array.);
  break;
  default:
 -if($aKeys[$i]!=whq_appdb  $aKeys[$i]!=MAX_FILE_SIZE) 
 // whq_appdb is the name of the session cookie
 +if($aKeys[$i]!=whq_appdb  // don't filter the appdb 
 session cookie
 +
 +   // or any bugzilla cookies
 +   $aKeys[$i]!=BUGLIST 
 +   $aKeys[$i]!=DEFAULTFORMAT 
 +   $aKeys[$i]!=Bugzilla_login 
 +   $aKeys[$i]!=LASTORDER 
 +   $aKeys[$i]!=Bugzilla_logincookie 
 +   $aKeys[$i]!=DEFAULTFORMAT 
 +   $aKeys[$i]!=MAX_FILE_SIZE)

These cookies cannot be accessible in the real AppDB as bugzilla and
AppDB are in separate hosts... I don't think this patch makes any sense
in AppDB.

A better fix would be to don't clear $_COOKIES in filter.php and have a
unit test that checks that $_COOKIES is not used anywhere in the code
(only in filter.php).


signature.asc
Description: Ceci est une partie de message	numériquement signée

[AppDB] Re: appdb/include incl.php

[Jonathan Ernst]

Le jeudi 06 juillet 2006 à 21:36 -0500, WineHQ a écrit :
[...]
  
 +/**
 + * rename $_REQUEST variables to preserve backwards compatibility
 + * with bugzilla links and urls in emails and on google from before our
 + * mass rename of GPC variables to use our coding standard prefixing
 + *
 + * NOTE: we may be able to remove these backwareds compatibility changes
 + *   in a few years, check in mid 2007 to see how many old
 + *   links are still poping up in google then
 + */
 +if(isset($_REQUEST['versionId']))
 +{
 +   $_REQUEST['iVersionId'] = $_REQUEST['versionId'];
 +   unset($_REQUEST['versionId']);
 +}
 +if(isset($_REQUEST['appId']))
 +{
 +   $_REQUEST['iAppId'] = $_REQUEST['appId'];
 +   unset($_REQUEST['appId']);
 +}

This (+catId) is enough IMHO, looking at the results of google when you
search for site:appdb.winehq.org, you'll see than only pages with catId,
versionId and appId are indexed and I can't think of any reason that
would make someone link to the AppDb with buglinkId or sub for example.

 +if(isset($_REQUEST['buglinkId']))
 +{
 +$_REQUEST['iBuglinkId'] = $_REQUEST['buglinkId'];
 +unset($_REQUEST['buglinkId']);
 +}
 +if(isset($_REQUEST['catId']))
 +{
 +$_REQUEST['iCatId'] = $_REQUEST['catId'];
 +unset($_REQUEST['catId']);
 +}
 +if(isset($_REQUEST['sub']))
 +{
 +$_REQUEST['sSub'] = $_REQUEST['sub'];
 +unset($_REQUEST['sub']);
 +}
 +if(isset($_REQUEST['topic']))
 +{
 +$_REQUEST['sTopic'] = $_REQUEST['topic'];
 +unset($_REQUEST['topic']);
 +}
 +/* End backwards compatibility code */
 +
 +
 +
  // create arrays
  $sidebar_func_list = array();
  $help_list = array();
 
 
 


signature.asc
Description: Ceci est une partie de message	numériquement signée

Debugging _CheckNotSysLevel() errors?

[Dan Kegel]

http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
on exit from a VB6 app due to a _CheckNotSysLevel() error.
What typically causes these - are they a bug in the windows
program?  And is there a good reference from understanding
the whole syslevel thing in gdi?
Thanks!

Re: wine's fullscreen code has no effect on metacity

[Dmitry Timoshkov]

Havoc Pennington [EMAIL PROTECTED] wrote:


Anyway, few WM bugs can be resolved by appeal to specifications alone...


Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and
doesn't in GNOME :-) If you could point out what Wine is doing in wrong way
I'm all ears.


Don't get defensive, everyone is completely willing to change metacity.
All I'm saying is that there's no point trying to appeal to specs in 
this case.


That's completely understood.

There's no question that we need some heuristic try to detect legacy 
apps code which the spec in no way covers. KDE also has some heuristic 
code for this sort of thing, as does any reasonable window manager. As 
with any heuristic it's a little touch-and-go/trial-and-error.


I believe several WMs including KDE and metacity have code something like:
 - if a window resizes itself to fullscreen,
   assume fullscreen state was intended

This heuristic can have various tweaks, such as only assuming fullscreen 
if the window is undecorated.


From other posts, I gather that WINE pretty much has this same 
heuristic internally, because the windows API doesn't have a fullscreen 
state, just screen sized + on top


That's correct, except that window size may not match the screen size
accurately, window size may be larger that screen, because applications
sometimes instead of removing window decorations (caption and borders)
simply resize a window so that client window area covers the screen.

An algorithm in Wine which asks a WM to activate fullscreen state for
a window is quite simple: it checks the size of a just resized visible
window and if it's equal or larger than screen size sends an event to
a WM. We are trying to understand at the moment why metacity sometimes
ignores such a request: window size and visibility should not be a reason
for it (except if metacity expects a window to have exactly same size as
the screen has, not larger than that), probably window decorations or
something else do.

On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window
makes it cover the GNOME dock, but GNOME top panel still remains on the top?

Thanks for your help.

--
Dmitry.

Re: Debugging _CheckNotSysLevel() errors?

[Dmitry Timoshkov]

Dan Kegel [EMAIL PROTECTED] wrote:


http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
on exit from a VB6 app due to a _CheckNotSysLevel() error.
What typically causes these - are they a bug in the windows
program?  And is there a good reference from understanding
the whole syslevel thing in gdi?


Does it help if you undefine STRETCH_VIA_DIB before MFDRV_StretchBlt
in dlls/gdi/mfdrv/bitblt.c ?

--
Dmitry.

Re: include/msvcrt: Make sure size_t is properly defined for 64-bit.

[Alexandre Julliard]

Ge van Geldorp [EMAIL PROTECTED] writes:

 In file included from data.c:21:
 ./../msvcrt.h:625: error: conflicting types for _strnset
 ../../../include/msvcrt/string.h:62: error: previous declaration of _strnset
 was here

 The patch I submitted fixes the problem by moving the include of windef.h
 a bit up:

We really shouldn't be including string.h here. Does this work for
you?

diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h
index fc330ce..dcba4ae 100644
--- a/dlls/msvcrt/msvcrt.h
+++ b/dlls/msvcrt/msvcrt.h
@@ -37,8 +37,6 @@ #ifndef __WINE_MSVCRT_H
 #define __WINE_MSVCRT_H
 
 #include stdarg.h
-#include ctype.h
-#include string.h
 
 #include windef.h
 #include winbase.h

-- 
Alexandre Julliard
[EMAIL PROTECTED]

RE: include/msvcrt: Make sure size_t is properly defined for 64-bit.

[Ge van Geldorp]

 From: Alexandre Julliard
 
 We really shouldn't be including string.h here. Does this work for
 you?
 
 diff --git a/dlls/msvcrt/msvcrt.h b/dlls/msvcrt/msvcrt.h
 index fc330ce..dcba4ae 100644
 --- a/dlls/msvcrt/msvcrt.h
 +++ b/dlls/msvcrt/msvcrt.h
 @@ -37,8 +37,6 @@
  #ifndef __WINE_MSVCRT_H
  #define __WINE_MSVCRT_H
  
  #include stdarg.h
 -#include ctype.h
 -#include string.h
  
  #include windef.h
  #include winbase.h

Yes, this works fine, both with and without the change to
include/msvcrt/string.h.

Best regards, Ge van Geldorp.

RE: include/msvcrt: Make sure size_t is properly defined for 64-bit.

[Ge van Geldorp]

 From: Ge van Geldorp [mailto:[EMAIL PROTECTED] 
 
 Yes, this works fine, both with and without the change to 
 include/msvcrt/string.h.

Sorry, I only tested dlls/msvcrt. When doing a full rebuild I get errors,
will investigate and let you know.

Ge.

Re: Cursor patches

[Robert Shearman]

H. Verbeet wrote:


Attached to this mail are a couple of patches that should fix some
issues with mouse cursors. It would be nice if some people could have
a look and see if the patches break anything. Patches 1-4 move cursors
into the server, 5 adds support for Xcursor cursors, 6  7 are
cleanups, 8 fixes loading of .cur cursors, 9 adds support for animated
cursors and 10 adds support for 32bpp cursors.



Overall, I'm very impressed with the patch set.

However, I did find two things that I think need consideration or 
improvement:


From 01_server_cursoricon.diff.txt:


+/* Destroy a cursor */
+DECL_HANDLER(destroy_cursor)
+{
+unsigned int i;
+cursor_t *cursor = free_user_handle( req-handle );
+
+if (!cursor) return;
+
+for (i = 0; i  cursor-num_frames; ++i)
+{
+if (cursor-frames[i].bits) free( cursor-frames[i].bits );
+}
+
+free( cursor-frames );
+}



This appears to be the only place where a cursor is destroyed. Thus, a 
bad application could end up wineserver to leak memory. I think you need 
to investigate when Windows frees cursors that have not had 
DestroyCursor called on them. My guess is that it frees them on process 
destruction.



From 09_user_ani_cursor.diff.txt:


--- a/dlls/user/Makefile.in
+++ b/dlls/user/Makefile.in
@@ -6,7 +6,7 @@ VPATH = @srcdir@
 MODULE= user32.dll
 IMPORTLIB = libuser32.$(IMPLIBEXT)
 IMPORTS   = gdi32 advapi32 kernel32 ntdll
-DELAYIMPORTS = imm32
+DELAYIMPORTS = imm32 winmm
 EXTRALIBS = $(LIBUNICODE)
 
 SPEC_SRCS16 = \



I'm not sure it is acceptable to import winmm from user32, even if it is 
a delay import.


--
Rob Shearman

Re: ole32: Get the threading model value for inproc classes and output a fixme if we should create it in an apartment of another type.

[Alexandre Julliard]

Robert Shearman [EMAIL PROTECTED] writes:

  dlls/ole32/compobj.c |   45 +
  1 files changed, 45 insertions(+), 0 deletions(-)

This one crashes the urlmon tests:

../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p 
urlmon_test.exe.so url.c  touch url.ok
wine: Unhandled page fault on read access to 0x000c at address 0x407536a9 
(thread 0323), starting debugger...
WineDbg starting on pid 0x322
Unhandled exception: page fault on read access to 0x000c in 32-bit code 
(0x407536a9).
Register dump:
 CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
 EIP:407536a9 ESP:406cf6b0 EBP:406cfb58 EFLAGS:00010202(   - 00  - -RI1)
 EAX: EBX:407ab11c ECX:40380020 EDX:40380024
 ESI:40034000 EDI:005c
Stack dump:
0x406cf6b0:  4038 0008 0010 406cfb44
0x406cf6c0:  406cfb2c 406cfb48 406cf6d8 406cf71c
0x406cf6d0:  0040 406cf82c 004a 401cdc5e
0x406cf6e0:  403ce208 406cf704 406cf718 0498
0x406cf6f0:  406cfb48 406cfb44 401ed0eb 406f9df0
0x406cf700:  406cfc80 406cf75c 406cf798 401f18ed
Backtrace:
=1 0x407536a9 get_inproc_class_object+0xa9(hkeydll=0x5c, rclsid=0x406cfc80, 
riid=0x406f9df0, ppv=0x406cfd64) 
[/home/julliard/wine/wine/dlls/ole32/compobj.c:1593] in ole32 (0x407536a9)
  2 0x4075407e CoGetClassObject+0x1fe(rclsid=0x406cfc80, dwClsContext=0x1, 
pServerInfo=0x0, iid=0x406f9df0, ppv=0x406cfd64) 
[/home/julliard/wine/wine/dlls/ole32/compobj.c:1710] in ole32 (0x4075407e)
  3 0x406ed5b6 get_protocol_iface+0x1a6(schema=0x406cfce0, schema_len=register 
not in topmost frame, ret=0x406cfd64) 
[/home/julliard/wine/wine/dlls/urlmon/session.c:95] in urlmon (0x406ed5b6)
  4 0x406ed88f get_protocol_info+0xff(url=0x403ce460) 
[/home/julliard/wine/wine/dlls/urlmon/session.c:124] in urlmon (0x406ed88f)
  5 0x406e9c12 CoInternetCombineUrl+0x32(pwzBaseUrl=0x403ce460, 
pwzRelativeUrl=0x405b8cf6, dwCombineFlags=0x0, pwzResult=0x403ce3a0, 
cchResult=0x3d, pcchResult=0x406cfe10, dwReserved=0x0) 
[/home/julliard/wine/wine/dlls/urlmon/internet.c:197] in urlmon (0x406e9c12)
  6 0x406f1ef6 CreateURLMoniker+0x166(pmkContext=0x403ce320, szURL=0x405b8cf6, 
ppmk=0x406cfe94) [/home/julliard/wine/wine/dlls/urlmon/umon.c:1077] in urlmon 
(0x406f1ef6)
  7 0x405b4881 func_url+0xa1 
[/home/julliard/wine/wine/dlls/urlmon/tests/url.c:109] in urlmon_test 
(0x405b4881)
  8 0x405b58c1 run_test+0x121(name=0x403804a7) 
[/home/julliard/wine/wine/dlls/urlmon/tests/../../../include/wine/test.h:365] 
in urlmon_test (0x405b58c1)
  9 0x405b5be9 __wine_spec_exe_entry+0x99(peb=0x40219820) 
[/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in urlmon_test 
(0x405b5be9)
  10 0x405000bb start_process+0xeb(arg=0x0) 
[/home/julliard/wine/wine/dlls/kernel/process.c:832] in kernel32 (0x405000bb)
  11 0x4001da77 wine_switch_to_stack+0x17 in libwine.so.1 (0x4001da77)
0x407536a9 get_inproc_class_object+0xa9 
[/home/julliard/wine/wine/dlls/ole32/compobj.c:1593] in ole32: movl 
0xc(%eax),%eax
1593if (apt-multi_threaded)
Wine-dbg

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: Cursor patches

[Dmitry Timoshkov]

Robert Shearman [EMAIL PROTECTED] wrote:


-DELAYIMPORTS = imm32
+DELAYIMPORTS = imm32 winmm
 EXTRALIBS = $(LIBUNICODE)
 
 SPEC_SRCS16 = \



I'm not sure it is acceptable to import winmm from user32, even if it is 
a delay import.


Rob is right, native user32 doesn't import winmm by any means. Looking
at user32 in a viewer it's easy to find chunk names such as RIFF, LIST,
rate, anih although. That means that user32 has an internal implementation
of mmioDescend which should be enough to parse animated cursor files.

--
Dmitry.

Re: wine packages for Fedora Extras

[Mike Hearn]

That's great, thanks!

Re: Debugging _CheckNotSysLevel() errors?

[Mike Hearn]

On Fri, 07 Jul 2006 00:24:49 -0700, Dan Kegel wrote:
 http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
 on exit from a VB6 app due to a _CheckNotSysLevel() error.
 What typically causes these - are they a bug in the windows
 program?  And is there a good reference from understanding
 the whole syslevel thing in gdi?
 Thanks!

The developers guide talks about this, because I once asked exactly the
same questions :)

Syslevels are an internal mutex that understands ordering constraints, if
a syslevel violation occurs it's always a bug in Wine and a backtrace can
be useful to see how Wine got into the invalid state.

thanks -mike

Re: winecfg: Shift Graphics page up to fill the empty place.

[Ivan Gyurdiev]

Speaking of the graphics page...

1. Is there a reason why we allow the user to choose software vs 
hardware shaders?

   (i.e. why isn't this a developers' option, or no option at all)

2. Is there a reason  why we allow the user to disable vertex and/or 
pixel shaders?

Re: Debugging _CheckNotSysLevel() errors?

[Dan Kegel]

On 7/6/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote:

 http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
 on exit from a VB6 app due to a _CheckNotSysLevel() error.
 What typically causes these - are they a bug in the windows
 program?  And is there a good reference from understanding
 the whole syslevel thing in gdi?

Does it help if you undefine STRETCH_VIA_DIB before MFDRV_StretchBlt
in dlls/gdi/mfdrv/bitblt.c ?


Nope.

Re: wine's fullscreen code has no effect on metacity

[Havoc Pennington]

Dmitry Timoshkov wrote:

An algorithm in Wine which asks a WM to activate fullscreen state for
a window is quite simple: it checks the size of a just resized visible
window and if it's equal or larger than screen size sends an event to
a WM. We are trying to understand at the moment why metacity sometimes
ignores such a request: window size and visibility should not be a reason
for it (except if metacity expects a window to have exactly same size as
the screen has, not larger than that), probably window decorations or
something else do.


Currently what appears to be triggering the issue in metacity is that 
the window's minimum and maximum size are also changed, such that the 
window is not resizable. There's an exception to this rule if the window 
is already fullscreen-size, but the exception kicks in only for 
undecorated windows.


I'd try just removing the !decorated line from metacity, or testing this 
theory by building a version of WINE that disables decorations in this 
case, just to see if it helps.



On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window
makes it cover the GNOME dock, but GNOME top panel still remains on the 
top?


afaik the top and bottom panels should always be in the same layer (so 
both above or both below). Elijah would know better though.


ABOVE windows can be below the panels if they don't have focus iirc.

Havoc

Re: wine's fullscreen code has no effect on metacity

[Elijah Newren]

On 7/6/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote:

From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html

_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire
screen and have no window decorations. Additionally the Window Manager is
responsible for restoring the original geometry after a switch from fullscreen
back to normal window.

As I understand the above quote it's the WM's responsibility on application's
request to remove window decorations and resize a window to fill the screen,
then restore its previous state when switching from a fullscreen state.


Yes, if it ever switches to a fullscreen state.


So, all the checks metacity does for window decorations and window size are
contradicting the spec IMO.


No, the window would have to be in the fullscreen state in order for
checks on window decorations or window size to even have the
possibility of breaking the spec.  Those checks in src/stack.c were
basically meant as a workaround to help legacy applications who don't
correctly put themselves into fullscreen mode still get into that
mode.  Yes, the checks appeared buggy (and we will fix them if I can
find some time to verify), but it shouldn't adversely affect any well
behaving application.


Also the fact that a window isn't resizeable means only that it's not supposed
to be resizeable by a user, still allowing to resize it programmatically.


Feel free to point to anywhere in the ICCCM or EWMH that says so.  Of
course apps can be resized programmatically -- because the
not-resizable hints can be modified programmatically.  I disagree with
allowing the app or other utilities to modify the size of an
unresizable window unless the unresizable'ness is first modified.

My $0.02,
Elijah

Re: Cursor patches

[H. Verbeet]

On 07/07/06, Robert Shearman [EMAIL PROTECTED] wrote:

This appears to be the only place where a cursor is destroyed. Thus, a
bad application could end up wineserver to leak memory. I think you need
to investigate when Windows frees cursors that have not had
DestroyCursor called on them. My guess is that it frees them on process
destruction.

It does look like that's the case.

On 07/07/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote:

Rob is right, native user32 doesn't import winmm by any means. Looking
at user32 in a viewer it's easy to find chunk names such as RIFF, LIST,
rate, anih although. That means that user32 has an internal implementation
of mmioDescend which should be enough to parse animated cursor files.

That's a bit unfortunate. I guess that means there's no way around
duplicating a significant part of that code into user32 then?

Re: ole32: Get the threading model value for inproc classes and output a fixme if we should create it in an apartment of another type.

[Robert Shearman]

Alexandre Julliard wrote:


Robert Shearman [EMAIL PROTECTED] writes:

 


dlls/ole32/compobj.c |   45 +
1 files changed, 45 insertions(+), 0 deletions(-)
   



This one crashes the urlmon tests:

../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c 
 touch url.ok
wine: Unhandled page fault on read access to 0x000c at address 0x407536a9 
(thread 0323), starting debugger...
WineDbg starting on pid 0x322
Unhandled exception: page fault on read access to 0x000c in 32-bit code 
(0x407536a9).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:407536a9 ESP:406cf6b0 EBP:406cfb58 EFLAGS:00010202(   - 00  - -RI1)
EAX: EBX:407ab11c ECX:40380020 EDX:40380024
ESI:40034000 EDI:005c
Stack dump:
0x406cf6b0:  4038 0008 0010 406cfb44
0x406cf6c0:  406cfb2c 406cfb48 406cf6d8 406cf71c
0x406cf6d0:  0040 406cf82c 004a 401cdc5e
0x406cf6e0:  403ce208 406cf704 406cf718 0498
0x406cf6f0:  406cfb48 406cfb44 401ed0eb 406f9df0
0x406cf700:  406cfc80 406cf75c 406cf798 401f18ed
Backtrace:
=1 0x407536a9 get_inproc_class_object+0xa9(hkeydll=0x5c, rclsid=0x406cfc80, 
riid=0x406f9df0, ppv=0x406cfd64) 
[/home/julliard/wine/wine/dlls/ole32/compobj.c:1593] in ole32 (0x407536a9)
 2 0x4075407e CoGetClassObject+0x1fe(rclsid=0x406cfc80, dwClsContext=0x1, 
pServerInfo=0x0, iid=0x406f9df0, ppv=0x406cfd64) 
[/home/julliard/wine/wine/dlls/ole32/compobj.c:1710] in ole32 (0x4075407e)
 3 0x406ed5b6 get_protocol_iface+0x1a6(schema=0x406cfce0, schema_len=register not 
in topmost frame, ret=0x406cfd64) 
[/home/julliard/wine/wine/dlls/urlmon/session.c:95] in urlmon (0x406ed5b6)
 4 0x406ed88f get_protocol_info+0xff(url=0x403ce460) 
[/home/julliard/wine/wine/dlls/urlmon/session.c:124] in urlmon (0x406ed88f)
 5 0x406e9c12 CoInternetCombineUrl+0x32(pwzBaseUrl=0x403ce460, 
pwzRelativeUrl=0x405b8cf6, dwCombineFlags=0x0, pwzResult=0x403ce3a0, 
cchResult=0x3d, pcchResult=0x406cfe10, dwReserved=0x0) 
[/home/julliard/wine/wine/dlls/urlmon/internet.c:197] in urlmon (0x406e9c12)
 6 0x406f1ef6 CreateURLMoniker+0x166(pmkContext=0x403ce320, szURL=0x405b8cf6, 
ppmk=0x406cfe94) [/home/julliard/wine/wine/dlls/urlmon/umon.c:1077] in urlmon 
(0x406f1ef6)
 7 0x405b4881 func_url+0xa1 
[/home/julliard/wine/wine/dlls/urlmon/tests/url.c:109] in urlmon_test 
(0x405b4881)
 8 0x405b58c1 run_test+0x121(name=0x403804a7) 
[/home/julliard/wine/wine/dlls/urlmon/tests/../../../include/wine/test.h:365] 
in urlmon_test (0x405b58c1)
 9 0x405b5be9 __wine_spec_exe_entry+0x99(peb=0x40219820) 
[/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in urlmon_test 
(0x405b5be9)
 10 0x405000bb start_process+0xeb(arg=0x0) 
[/home/julliard/wine/wine/dlls/kernel/process.c:832] in kernel32 (0x405000bb)
 11 0x4001da77 wine_switch_to_stack+0x17 in libwine.so.1 (0x4001da77)
0x407536a9 get_inproc_class_object+0xa9 
[/home/julliard/wine/wine/dlls/ole32/compobj.c:1593] in ole32: movl 
0xc(%eax),%eax
1593if (apt-multi_threaded)
Wine-dbg



Jacek,

I have a patch that fixes the crash by validating the conditions on 
entry to CoGetClassObject (attached). However, this test still fails:


err:ole:CoGetClassObject apartment not initialised
url.c:768:http test...
url.c:424: Test failed: unexpexted code 34
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - don't 
know what to do!

url.c:667: Test failed: istr should be NULL
url.c:690: Test failed: expected OnProgress_MIMETYPEAVAILABLE
url.c:773:about test...
fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE
url.c:779:emulated about test...
url.c:784:file test...
err:ole:CoGetClassObject apartment not initialised
url.c:662: Test failed: IMoniker_BindToStorage failed: 800401f0
url.c:791:emulated file test...
url: 253 tests executed, 0 marked as todo, 4 failures.

It looks to me as though CoGetClassObject should be called by urlmon in 
certain circumstances (hence the CoInitialize calls in some of the 
tests), but not in this case.  The test fails with the same error when 
run with native ole32 and rpcrt4.


Thanks,

--
Rob Shearman

From beda0132fda8f06b11e305f5a56c491f4a310260 Mon Sep 17 00:00:00 2001
From: Robert Shearman [EMAIL PROTECTED]
Date: Fri, 7 Jul 2006 16:34:59 +0100
Subject: [PATCH] Add validation of parameters to CoGetClassObject and make sure 
to initialise ppv to NULL.
To: wine-patches [EMAIL PROTECTED]
---
 dlls/ole32/compobj.c   |   54 ++--
 dlls/ole32/tests/compobj.c |   12 ++
 2 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c
index f115658..06f4936 100644
--- a/dlls/ole32/compobj.c
+++ b/dlls/ole32/compobj.c
@@ -1736,6 +1736,17 @@ HRESULT WINAPI CoGetClassObject(
 
 TRACE(\n\tCLSID:\t%s,\n\tIID:\t%s\n, debugstr_guid(rclsid), 
debugstr_guid(iid));
 
+if (!ppv)
+return E_INVALIDARG;
+
+*ppv = NULL;
+
+if (!COM_CurrentApt())
+{
+

Re: Testing help needed: Pixel format whitelisting

[Jason Green]

On 7/7/06, Jason Green [EMAIL PROTECTED] wrote:

On 7/1/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Half Life 2, on the other hand, won't launch the level after the patch
(at least with pixel shaders enabled).  I've attached the d3d_caps
logs grepped for CheckDeviceFormat from before and after for
comparison.  The game launches, but it gets about half-way through the
status bar loading the first level (Point Insertion), and then
crashes.


Reporting that we support V8U8 and V16U16 (like the old code did)
fixes Half Life 2.  Apparently it needs to have at least one bump
mapping format available.

Re: [ntdll/tests] Added some NULL testing

[Alexandre Julliard]

Paul Vriens [EMAIL PROTECTED] writes:

 Hi,

 added some tests with NULL parameters.

 Changelog
   Added some NULL testing

I appreciate your willingness to write tests, but please don't spend
too much effort on testing NULL inputs, it's not an interesting case
unless there's a specific app that depends on it. Otherwise we end up
adding NULL checks all over the place for no good reason. It's much
more interesting to test valid inputs.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: [AppDB] - move getMaintainersUserIds...() to version::getMaintainersUserIds()

[Jonathan Ernst]

Le vendredi 07 juillet 2006 à 01:21 -0400, Chris Morgan a écrit :
 Move getMaintainersUserIds...() to version::getMaintainersUserIds() and fixup 
 callers of this function.
 
 Chris
 
 
 

This one looks fine to me.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: [AppDB] - preferences.php cleanups

[Jonathan Ernst]

Le vendredi 07 juillet 2006 à 01:06 -0400, Chris Morgan a écrit :
 Stop using global variables in preferences.php.  Reorder functions so we 
 don't 
 have php code running and functions in the middle of it. Rename a couple of 
 variables to match our current variable naming convention.
 
 Chris
 

This one will conflict with the filter.php enabling in this file, can
you redo it afterwards ?

Thanks.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: [ntdll/tests] Added some NULL testing

[Paul Vriens]

On Fri, 2006-07-07 at 18:24 +0200, Alexandre Julliard wrote:
 Paul Vriens [EMAIL PROTECTED] writes:
 
  Hi,
 
  added some tests with NULL parameters.
 
  Changelog
Added some NULL testing
 
 I appreciate your willingness to write tests, but please don't spend
 too much effort on testing NULL inputs, it's not an interesting case
 unless there's a specific app that depends on it. Otherwise we end up
 adding NULL checks all over the place for no good reason. It's much
 more interesting to test valid inputs.
 
It's just that I'm going through a lot of the Coverity reports. A great
deal of them mention NULL parameters passed. That why I started writing
these checks and found that we're not always a 100% in line with M$.

I will try and not change 'real' code to check that much for NULLs but
couldn't we leave the test cases (with todo_wine of course) for
documentation sake?

Cheers,

Paul.

Re: [ntdll/tests] Added some NULL testing

[Alexandre Julliard]

Paul Vriens [EMAIL PROTECTED] writes:

 It's just that I'm going through a lot of the Coverity reports. A great
 deal of them mention NULL parameters passed. That why I started writing
 these checks and found that we're not always a 100% in line with M$.

Yes, but that's deliberate, we don't want to add too many
checks. Windows in many cases uses exception handlers, but that's
quite expensive without compiler support.

 I will try and not change 'real' code to check that much for NULLs but
 couldn't we leave the test cases (with todo_wine of course) for
 documentation sake?

If you have written them already, sure, but we don't want to
systematically add test cases for NULL.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: [AppDB] - cleanup require/require_once()/include()

[Jonathan Ernst]

Le vendredi 07 juillet 2006 à 00:37 -0400, Chris Morgan a écrit :
 Use require() for path.php and include/incl.php.  We can't proceed without 
 these files.  Use require_once() for all include/*.php files.  To simplify 
 inclusion each file includes the other files it needs.  In this manner we 
 don't have to include mail.php when we include application.php, something 
 that was done all over the place in the appdb.  Remove unnecessary includes 
 of mail.php and other classes that weren't being used.  Add missing includes 
 for some classes that were being used but not being included.
 
 Chris
 

That makes sense to me.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: oleaut32: Copying a NULL BSTR should result in an empty BSTR in VariantCopy

[Robert Shearman]

qingdoa daoo wrote:


Hi,

This patch should fix Bug 4141

Changelog:
Copying a NULL BSTR should result in an empty BSTR in VariantCopy



--- dlls/oleaut32/variant.c.cvs 2006-07-05 17:23:04.0 +0800
+++ dlls/oleaut32/variant.c 2006-07-05 17:31:53.0 +0800
@@ -719,13 +719,16 @@ HRESULT WINAPI VariantCopy(VARIANTARG* p
  else if (V_VT(pvargSrc) == VT_BSTR)
  {
if (V_BSTR(pvargSrc))
-{
  V_BSTR(pvargDest) = SysAllocStringByteLen((char*)V_BSTR(pvargSrc), 
SysStringByteLen(V_BSTR(pvargSrc)));
-  if (!V_BSTR(pvargDest))
- {
-   TRACE(!V_BSTR(pvargDest), SysAllocStringByteLen() failed to allocate %d 
bytes\n, SysStringByteLen(V_BSTR(pvargSrc)));
-hres = E_OUTOFMEMORY;
- }
+else
+{
+  OLECHAR c = 0;
+  V_BSTR(pvargDest) = SysAllocString(c);
+}
+if (!V_BSTR(pvargDest))
+{
+  TRACE(Allocation failed for destination BSTR\n);
+  hres = E_OUTOFMEMORY;
}
  }
  else if (V_VT(pvargSrc) == VT_RECORD)
 



I think you could get the same result by just removing the if 
(V_BSTR(pvargSrc) check. This should result in simpler code.


--
Rob Shearman

Issue with French Canadian Keyboard Under SLED 10

[Michael Lessard]

Hi everybody !

 We still have an issue with wine 0.9.16 and french canadian keyboard
accent, we use locale fr_FR.UTF-8 ...
in terminal, accent working great but in appz who use wine, only é and ç
working, all other accent (è,ê,à,ô) are replace by ç.

 Where can modify the config of keyboard under wine ?  Or how could
resolv this issue ...

 Is very important to work for us, many our of clients will use Wine to
help migration to Linux.
 
Thanks

-- 
Michael Lessard
Chargé de projet / Project Manager
Techno Centre Logiciels Libres, http://www.tc2l.ca/
Téléphone : (418) 681-2929 poste 121

Re: DDraw: Split up the ddraw refcount

[Alexandre Julliard]

Stefan Dösinger [EMAIL PROTECTED] writes:

 +if(ref == 0) InterlockedDecrement(This-numIfaces);
  
 -/* This is for the dll cleanup code in DllMain() */
 -if(!This-DoNotDestroy)
 -IDirectDrawImpl_Destroy(This);
 -}
 +/* Checks the refcount before actually destroying the object */
 +IDirectDrawImpl_Destroy(This);

This isn't thread safe, you should only call Destroy when the
InterlockedDecrement returns 0, otherwise there's no point in using
interlocked functions at all. Also you should get rid of the
DoNotDestroy flag and use the refcount for that.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: ole32: Get the threading model value for inproc classes and output a fixme if we should create it in an apartment of another type.

[Jacek Caban]

Robert Shearman wrote:


Jacek,

I have a patch that fixes the crash by validating the conditions on 
entry to CoGetClassObject (attached). However, this test still fails:


err:ole:CoGetClassObject apartment not initialised
url.c:768:http test...
url.c:424: Test failed: unexpexted code 34
fixme:wininet:CommitUrlCacheEntryInternal entry already in cache - 
don't know what to do!

url.c:667: Test failed: istr should be NULL
url.c:690: Test failed: expected OnProgress_MIMETYPEAVAILABLE
url.c:773:about test...
fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE
url.c:779:emulated about test...
url.c:784:file test...
err:ole:CoGetClassObject apartment not initialised
url.c:662: Test failed: IMoniker_BindToStorage failed: 800401f0
url.c:791:emulated file test...
url: 253 tests executed, 0 marked as todo, 4 failures.

It looks to me as though CoGetClassObject should be called by urlmon 
in certain circumstances (hence the CoInitialize calls in some of the 
tests), but not in this case.  The test fails with the same error when 
run with native ole32 and rpcrt4.


CoGetClassObject shouldn't be called in a place that causes the crash at 
all. It calls CoGetClassObject to get protocol handler, but it shouldn't 
be needed for urlmon builtin handlers. I've sent patches that should fix 
it (but without your second patch the other test will crash so they have 
to be applied in one shot).


Thanks,
   Jacek

Re: msi: appsearch

[Juan Lang]

Just add an entry to wine.inf for the dll it's failing on, and the existing 
code should find it and do the version checks.
--Juan

- Original Message 
From: Aric Stewart [EMAIL PROTECTED]
To: Juan Lang [EMAIL PROTECTED]
Cc: wine-devel@winehq.org
Sent: Wednesday, July 5, 2006 10:43:23 AM
Subject: Re: msi: appsearch

Maybe, i am unclear about how a fake dll in wine.inf would work. the 
problem is that previously we where doing a FindFile on the given 
directory and of course there is no file there so the process stopped.

-aric

Juan Lang wrote:

if trying to find a DLL that is located in the system directory, also check 
for
a builtin version



Can't this be done by putting a fake dll entry in wine.inf?
--Juan



  

Re: SetLastError in CreateWindowEx

[James Hawkins]

On 7/7/06, Dan Hipschman [EMAIL PROTECTED] wrote:

I noticed that sometimes when CreateWindowEx fails and the app tries to
display a helpful error message, you get something like Couldn't create
window: Success.  These are the error codes that XP sets for the given
failures.

ChangeLog:
* Correctly call SetLastError in a few places where CreateWindowEx fails.


This is a great candidate for a conformance test.

--
James Hawkins