August 2009 - Wine-Devel - list.winehq.org

Re: [1/2] mshtml: Implement IHTMLDocument2_put/get_bgColor
by Alistair Leslie-Hughes Aug. 23, 2009

Aug. 23, 2009

Hi Vladimir, On 08/23/2009 05:17 PM, Vladimir Pankratov wrote: >+ hres = IHTMLDocument2_get_body(iface, &elem); You need to Release "elem" when you have finished with it. Best Regards Alistair Leslie-Hughes

1 0

Re: programs/services: sign compare fixes
by Kai Blin Aug. 23, 2009

Aug. 23, 2009

On Sunday 23 August 2009 10:55:39 Austin English wrote: > -- > -Austin No patch and no attachment. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

profile.c (kernel32): API broken
by Claudio Fontana Aug. 22, 2009

Aug. 22, 2009

Just a reminder to everyone involved with profile.c: I have watched the git log of the somewhat recent changes to kernel32/profile.c. The profile API does not work that way. The current situation is even worse than before, when the undocumented empty string section and empty keys were not implemented at all. The current situation leads to consistent INI file corruption when the applications use the undocumented empty string section and empty keys. I tried to explain how the API works under Windows many times. This is another casual attempt at giving you a reality check. If you are interested, you can contact me for further details, or look at the testcases in my last patch (search for profile.c / Claudio Fontana). A good fix in profile.c is difficult because of the unfortunate use of the empty string as sentinel in the implementation. Probably rewriting the module would be a better idea. In short again: empty string section is just another (valid) section under Windows. Depending on the windows version the section is represented in the saved file after []\r\n at the beginning of the INI file or with no header at all. The empty key can be requested and saved in a named section. The empty key in a named section is just another (valid) key under Windows. The empty key value is represented in the saved file after the header of the appropriate section in this way, just as logic would suggest: [header] =value Those "empty string" sections and "empty string" keys should be found when querying using the profile API. Currently it does not happen, leading to INI corruption (multiple repeated empty sections' values, none of which are found by the API). Regards, Claudio Fontana

2 7

Re: mshtml(2/2): Support getting the proxy settings from the environment
by Jacek Caban Aug. 22, 2009

Aug. 22, 2009

Hi Juan, Your patch looks good (although I'd suggest splitting set_proxy to two function instead of doing it by gotos), but I've just sent a patch that makes mshtml use wininet for networking (via urlmon), so your patch is no longer needed. My patch is a major step forward in MSHTML/shdocvw implementation, but it's very risky, so I will not immediately remove set_proxy from the tree and wait for things to stabilize, but I don't think we want to extend it. Thanks, Jacek

2 1

AF_Irda.h header file
by Thomas Trummer Aug. 22, 2009

Aug. 22, 2009

Hi, Wine was missing the AF_Irda.h header file so I decided to write one. Unfortunately someone else had the same idea and the result was commited 3 days ago... :) Nonetheless, I attached my version, it contains all definitons of the Windows SDK 7 header though is not WS_tified. Thomas

2 3

Re: [1/4] d3dx9: Add D3DXAssembleShader and related declarations
by Stefan Dösinger Aug. 22, 2009

Aug. 22, 2009

Am 21.08.2009 um 23:06 schrieb Matteo Bruni: > I'm trying to follow Juan Lang suggestions on how to structure the D3D > assembler patches. I'm not yet sure on how to proceed with the bulk of > the assembler, however these preparatory patches should be safe. > <0001-d3dx9-Add-D3DXAssembleShader-and-related-declarations.txt> A part of the header seems a bit close to the DX SDK header to me

1 0

Re: CPPCheck Run for Friday August 21
by chris ahrendt Aug. 22, 2009

Aug. 22, 2009

Mike Kaplinskiy wrote: > On Fri, Aug 21, 2009 at 9:21 PM, chris ahrendt<celticht32(a)yahoo.com> wrote: > >> [../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 >> [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a >> deallocated pointer: stream2 >> [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 >> [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 >> [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a >> deallocated pointer: mem >> [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd >> [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of >> bounds >> > > False positive. Doesn't like the FIELD_OFFSET macro for alloc. > > >> [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries >> > > This is probably the only one here that sticks out, but afaict, it's > not a leak. There's somewhat convoluted logic involved (if > count==table->count, we don't reallocate; if reallocation fails...the > previous pointer shouldn't be deallocated, and new_entries=NULL > anyway). Its a false positive. This seems like something it shouldn't > catch though, so might want to report this bug to cppcheck devs. > > >> [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd >> [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens >> [../wine-git/tools/makedep.c:953]: (error) Resource leak: file >> [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a >> deallocated pointer: fd >> [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map >> >> >> Chris >> >> >> > > Thanks for running these, keeps the code nicely in check. > > Mike. > > > I reran it on 1.1.28 and the result is the same so will report the false positive to cpp guys... Your welcome ... its something to do for the devs =D chris

1 0

CPPCheck Run for Friday August 21
by chris ahrendt Aug. 22, 2009

Aug. 22, 2009

[../wine-git/dlls/msvcrt/tests/file.c:997]: (error) Resource leak: stream1 [../wine-git/dlls/msvcrt/tests/file.c:982]: (error) Deallocating a deallocated pointer: stream2 [../wine-git/dlls/msvcrt/tests/file.c:966]: (error) Resource leak: stream3 [../wine-git/dlls/msvcrt/tests/file.c:973]: (error) Resource leak: stream4 [../wine-git/dlls/msvcrt/tests/heap.c:424]: (error) Deallocating a deallocated pointer: mem [../wine-git/dlls/ntdll/server.c:802]: (error) Resource leak: fd [../wine-git/dlls/rpcrt4/tests/server.c:1189]: (all) Array index out of bounds [../wine-git/server/handle.c:201]: (error) Memory leak: new_entries [../wine-git/tools/fnt2bdf.c:656]: (error) Resource leak: fd [../wine-git/tools/fnt2fon.c:303]: (error) Memory leak: file_lens [../wine-git/tools/makedep.c:953]: (error) Resource leak: file [../wine-git/tools/widl/write_msft.c:2540]: (error) Deallocating a deallocated pointer: fd [../wine-git/tools/winedump/pe.c:1549]: (all) Memory leak: map Chris

2 1

Appinstall strikes again!
by Austin English Aug. 22, 2009

Aug. 22, 2009

So, I've been on vacation this past week. Before leaving, I ran 'daily ; daily ; daily ; daily ; daily' to make sure they daily build scripts still ran while I was gone. Looking at the logs, I found something interesting: wordviewer03-result.txt:wordview_en-us.exe didn't crash. Bug 19185 TODO_FIXED. wordviewer03-result.txt:C:\users\austin\Application Data\Microsoft\Installer\{90850409-6000-11D3-8CFE-0150048383C9} doesn't exist. Bug 19318 TODO_FIXED. Some TODO_FIXED...investigate! (from http://austinenglish.com/logs/appinstall-2009-08-21/summary.txt) Looking at the git log, there were only a couple msxml commits, so I tried reverting them to see which one fixed it. Apparently this one did: http://source.winehq.org/git/wine.git/?a=commitdiff;h=38c0667334d7b929607a3… So thanks Jacek, you fixed a 1.2.0 bug and probably didn't even know it ;-). Now, everyone write some tests for your favorite downloadable application! :-) -- -Austin

1 0

Re: oleaut32: Dynamic invocation for x86
by Henri Verbeet Aug. 21, 2009

Aug. 21, 2009

2009/8/21 Juan Lang <juan.lang(a)gmail.com>: > Personally, I don't think the cut-and-paste approach we've been taking > to fix this works all that well for a 126-argument function, so it > seems like an assembly approach is the only tenable method. I'm not > certain whether Jon's approach is the correct one, but since it didn't > get any comment before, I'd like to know: if it isn't acceptable, why > not? > I don't know if there's a reason the general approach couldn't work, but the code in the patch is gcc specific, so I think it should at least be protected by __GNUC__ in addition to __i386__. This won't work on OS X either, it requires 16 byte alignment for the stack. Also: > + "subl %eax, %esp\n\t" \ ... > + "0:\n\t" \ > + "pushl (%ecx, %eax)\n\t" \ > + "subl $4, %eax\n\t" \ > + "jns 0b\n\t" \ ... > + "leal (%esp, %ecx, " #pop_size "), %esp\n\t" \ This look like a somewhat questionable way to handle both cdecl and stdcall with the same code to me. You should probably look at call_entry_point() in dlls/ntdll/relay.c for an example, although I also guess an argument could be made that something like this should be in libwine. (That would probably break functions that check their return address, not sure if that's an issue here.)

3 4