wine-devel January 2010

wine-devel@winehq.org

96 participants
209 discussions

Re: [2/4] avifil32/tests: Initial-test-data-and-simple-test-for-avifil32-depends
by Paul Vriens 10 Jan '10

10 Jan '10

On 01/10/2010 03:15 AM, Julius Schwartzenberg wrote: > +static void create_avi_file(const COMMON_AVI_HEADERS *cah, char *filename) > +{ > + HANDLE hFile; > + DWORD written; > + > + hFile = CreateFile(filename, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); > + > + ok(hFile != INVALID_HANDLE_VALUE, "Couldn't create file\n"); // GetTempFileName and GetTempPath Hi Julius, No C++ comment style please. -- Cheers, Paul.

1 0

Re: [PATCH] shell32: handle bad menu handle (Coverity)
by Nikolay Sivov 09 Jan '10

09 Jan '10

On 1/9/2010 16:59, Marcus Meissner wrote: > Hi, > > handle "invalid menu" return -1. > > Ciao, Marcus > --- > dlls/shell32/shlmenu.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > nItem = GetMenuItemCount(hmDst); > + if (nItem == -1) > + return uIDMax; > Hi, Marcus. Could you please add a test for that? It seems trivial.

1 0

Re: [PATCH 1/2] mmdevapi: Add code to enumerate NOTPRESENT devices
by Alexandre Julliard 09 Jan '10

09 Jan '10

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > @@ -33,6 +35,13 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(mmdevapi); > > +static const WCHAR software_wine_mmdevapi[] = > + { 'S','o','f','t','w','a','r','e','\\','W','i','n','e','\\','m','m','d','e','v','a','p','i',0}; This looks suspicious. Why do you need a Wine-specific config for this? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [d3d9/tests] Fix size parameter for memcmp (Coccinelle)
by Henri Verbeet 09 Jan '10

09 Jan '10

2010/1/8 Paul Vriens <paul.vriens.wine(a)gmail.com>: > - i = memcmp(decl, vertex_decl, sizeof(vertex_decl)); > + i = memcmp(decl, vertex_decl, sizeof(*vertex_decl)); I think that should be "num_elements * sizeof(*vertex_decl)" even.

1 0

Less than 300 Coverity errors !!
by Paul Vriens 08 Jan '10

08 Jan '10

Hi, Just wanted to mention the fact that Marcus (almost single-handedly for the last months) got the number of issues below 300. Only 11 of those are marked as either a bug or are pending. The rest is either false (Coverity thinks there is an error, but we don't) or to be ignored (for example: windows bug-for-bug compatibility or some deliberate tests). -- Cheers, Paul.

3 2

How should AVI files be detected in avifile?
by Julius Schwartzenberg 08 Jan '10

08 Jan '10

Hi, Maybe you know, I hope to submit several fixes and tests for avifile soon. Vitaliy Margolen pointed out I should be create proper temporary files in the system's tmp directory so I implemented this. This actually showed a new bug in Wine's avifile: Wine's avifile does not handle normal avi files with an filename extension different than avi (f.e. tmp), while Windows XP's avifile has no problems with those at all. The problem is in this part of the code: http://source.winehq.org/source/dlls/avifil32/api.c#L244 I discussed it with Roderick a bit on IRC and he said the whole registry check is flawed and there should be detection for AVI files based on the content of the file. I then did some tests and replaced line 247 (return AVIERR_UNSUPPORTED;) with "clsidHandler = CLSID_AVIFile;" which always forces the correct handler for AVI files. With that change I get the exact same behaviour as on Windows: Proper AVI files always work, irregardless of their filename extension. Files in which I replaced "AVI LIST" (the magic with which AVI files can be detected) with "AV2 LIST" in a hex editor fail on both Windows and Wine. On both they immediately fail with the error that my file is not an AVI file. So this means that there already is proper detection in Wine based on the content of the file! There is just one extra obstacle in front now. I'm not very familiar (yet) with COM, CLASS IDs and how files are generally handled in Wine. Also I don't really know much about VFW, I especially cannot imagine what other files than AVI files would need to be read using avifile (but from the code I except this is possible). So my question is: What do you think would be an appropriate way to solve this? Should I just remove the obstacle or add my change? Or do something completely different? Also if anyone can shed more light on the current idea behind the code, this would be welcome! Thanks a lot in advance, Julius

2 2

Re: Wine release 1.1.36
by James Hawkins 08 Jan '10

08 Jan '10

On Fri, Jan 8, 2010 at 11:28 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > The Wine development release 1.1.36 is now available. > > What's new in this release (see below for details): > - Completion of the 16-bit separation. Congrats Alexandre and co.! -- James Hawkins

1 0

IHlink::Navigate mystery value
by Andrew Eikum 08 Jan '10

08 Jan '10

I've been working the past few days on cleaning up low-hanging-fruit bugs relating to MSOffice. I've run into one bug for which I have a solution, but I have no explanation as to why the solution is correct. It's what Windows does, but I don't know why! This email's a bit long, but it describes the problem and various things I've tried to understand the solution. Hopefully someone reading this list has some ideas :) The bug is in PowerPoint. On native, when a slideshow is exited (i.e. go out of 'presentation mode'), the currently-displayed slide should become activated in the main 'editor' PowerPoint window. In Wine, however, the main window shows the slide that was active when the slideshow began. This makes resuming the slideshow from where you left off a big pain. The problem is in the hlink module, specifically with IHlink::Navigate (implemented in Wine as IHlink_fnNavigate around dlls/hlink/link.c:436). IHlink objects can contain an IHlinkSite reference, which the Navigate function makes calls to as it proceeds through navigation, as a sort of callback. The last call in IHlink::Navigate is to IHlinkSite::OnNavigationComplete. This function takes an HRESULT argument which, according to MSDN, should contain the final result of the navigation. Again, according to MSDN, IHlink::Navigate should return S_OK on success, error otherwise. Of course, reality is different from what MSDN claims. On native, IHlinkSite::OnNavigationComplete is consistently called by IHlink::Navigate with its HRESULT argument set to 0x40100. I have no idea what this value is supposed to represent. Every Windows version with an hlink DLL, on both x86 and x86_64, passes 0x40100 to the IHlinkSite when IHlink::Navigate is called. It doesn't seem to matter what the target of the navigation is (website, file on filesystem). See the tests linked below. Currently in Wine our IHlink::Navigate passes S_OK, as you'd expect from both the documentation and common sense. For whatever bizarre reason, however, PowerPoint requires that this HRESULT value be greater than zero. If zero (S_OK) is passed, then PowerPoint fails to restore the proper slide and just does nothing. If an error code is passed, PowerPoint pops up an error message, as you'd expect. But if a value greater than zero is passed (it's not picky about 0x40100), PowerPoint correctly opens the proper slide. So unfortunately, we need to do this "right" for PowerPoint to behave. Interpreted as an HRESULT, 0x40100 is DRAGDROP_S_DROP, a successful DND operation, as returned by DoDragDrop. Is it possible that Windows navigates to items by drag-dropping into the appropriate application? IHlink _does_ also implement IOleObject, which is the "object" passed by DoDragDrop. This interpretation seems unlikely, though, since all programs that are associated with a filetype (i.e. open with ShellExecute) must then implement IDropTarget. I'm not ruling this interpretation out, but I can't make sense of it. You'll note that the value looks something like a set of two bitflags. File access permissions were the first thing to come to mind, but Julliard said it looks nothing like permission flags that he's seen. I've looked at every constant in include with the value 0x40000 and seen nothing that looks relevant. I sent a hack implementation off to wine-patches, but it was rejected. Alexandre said he'd like a better investigation of where 0x40100 comes from. I've exhausted my knowledge and can think of no place to derive this value from. I'm here asking if the value stands out to anyone, or if there are any suggestions of things to probe or functions to poke to get some meaning attached to this number. Any ideas? My hackish fix, with tests: http://www.winehq.org/pipermail/wine-patches/2010-January/083470.html MSDN IHlink documentation: http://msdn.microsoft.com/en-us/library/aa767974%28VS.85%29.aspx MSDN IHlinkSite documentation: http://msdn.microsoft.com/en-us/library/aa767933%28VS.85%29.aspx Andrew

3 3

Re: advapi32/security: Free descriptor if it isn't returned from GetSecurityInfo()
by James Hawkins 08 Jan '10

08 Jan '10

On Fri, Jan 8, 2010 at 10:08 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Free descriptor if it isn't returned from GetSecurityInfo() (Valgrind). > This is very wrong :-) You should read the comment above the test that causes the leak. Dan has notice to suppress this valgrind error, so it shouldn't show up in the logs after he adds the suppression. Thanks, James Hawkins

2 1

Re: [2/3] ntdll: fill unused tails of heap blocks if HEAP_FREE_CHECKING_ENABLED (take 3)
by Alexandre Julliard 08 Jan '10

08 Jan '10

Dan Kegel <dank(a)kegel.com> writes: > To check whether we're too early in process setup to > check global flags, I compare the arguments of RtlCreateHeap > with the ones used by the call in virtual_init(). This is > not especially clean, but I couldn't think of anything > better. I can hear Alexandre hitting the 'd' key already, > so if anyone has a better idea, please let me know. That's a sure hint that you shouldn't have submitted the patch. As I told you on IRC, you have to make the patch the best you possibly can *before* showing it to me. That's doubly true for a patch that has already seen several rounds. If you truly can't find a better way you can always ask for suggestions on IRC or wine-devel. Submitting broken patches (worse, that you already know are broken) is only going to make it harder for you to get anything in. -- Alexandre Julliard julliard(a)winehq.org

2 4

← Newer
1
...
13
14
15
16
17
18
19
20
21
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel January 2010