wine-devel July 2010

wine-devel@winehq.org

114 participants
459 discussions

Re: [PATCH 1/7] msvcp90: Added stub dll
by Alexandre Julliard 20 Jul '10

20 Jul '10

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -0,0 +1,3189 @@ > +#stub ??$?5DU?$char_traits@D@std@@@std@@YAAAV?$basic_istream@DU?$char_traits@D@std@@@0@AAV10@AAD@Z > +#stub ??$?5DU?$char_traits@D@std@@@std@@YAAAV?$basic_istream@DU?$char_traits@D@std@@@0@AAV10@PAD@Z > +#stub ??$?5DU?$char_traits@D@std@@V?$allocator@D@1@@std@@YAAAV?$basic_istream@DU?$char_traits@D@std@@@0@AAV10@AAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@@Z > +#stub ??$?5GU?$char_traits@G@std@@@std@@YAAAV?$basic_istream@GU?$char_traits@G@std@@@0@AAV10@AAG@Z > +#stub ??$?5GU?$char_traits@G@std@@@std@@YAAAV?$basic_istream@GU?$char_traits@G@std@@@0@AAV10@PAG@Z > +#stub ??$?5GU?$char_traits@G@std@@V?$allocator@G@1@@std@@YAAAV?$basic_istream@GU?$char_traits@G@std@@@0@AAV10@AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@0@@Z Why are they commented out? Why not define real stubs? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: ole32: Implement cross-process drag and drop.
by Huw Davies 20 Jul '10

20 Jul '10

On Mon, Jul 19, 2010 at 04:42:40PM +0100, Huw Davies wrote: > Fix a typo in a comment spotted by Detlef. > --- > dlls/ole32/ole2.c | 199 ++++++++++++++++++++++++++++++++++++++++++++-------- > 1 files changed, 168 insertions(+), 31 deletions(-) Sorry, this is still broken, please ignore. Huw.

1 0

Re: [PATCH 4/9] include: Add INameSpaceTreeControl, INameSpaceTreeControl2 and INameSpaceTreeControlEvents interface declarations.
by Alexandre Julliard 20 Jul '10

20 Jul '10

David Hedberg <david.hedberg(a)gmail.com> writes: > + HRESULT OnItemClick( > + [in, annotation("__in")] IShellItem *psi, > + [in, annotation("__in")] NSTCEHITTEST nstceHitTest, > + [in, annotation("__in")] NSTCECLICKTYPE nstceClickType); > + > + HRESULT OnPropertyItemCommit( > + [in, annotation("__in")] IShellItem *psi); Please don't add these annotations, that's redundant. If we want that sort of things in the generated headers one day we can make widl generate them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] winemenubuilder: use windowscodecs for some ICO to PNG conversion
by Alexandre Julliard 20 Jul '10

20 Jul '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > + dosPNGFileName = wine_get_dos_file_name(pngFileName); > + if (dosPNGFileName == NULL) > + { > + WINE_ERR("error converting %s to DOS file name\n", pngFileName); > + goto end; > + } You can't rely on having a valid DOS name here. You should use the \\?\unix format, or maybe better fix wine_get_dos_file_name() to do that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Add an error code
by Alexandre Julliard 20 Jul '10

20 Jul '10

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -670,7 +670,7 @@ static const DWORD table_c0000001[411] = > 0, /* c0000116 (STATUS_ABIOS_INVALID_SELECTOR) */ > ERROR_INVALID_THREAD_ID, /* c0000117 (STATUS_NO_LDT) */ > 0, /* c0000118 (STATUS_INVALID_LDT_SIZE) */ > - 0, /* c0000119 (STATUS_INVALID_LDT_OFFSET) */ > + ERROR_INVALID_LDT_OFFSET, /* c0000119 (STATUS_INVALID_LDT_OFFSET) */ > 0, /* c000011a (STATUS_INVALID_LDT_DESCRIPTOR) */ > ERROR_BAD_EXE_FORMAT, /* c000011b (STATUS_INVALID_IMAGE_NE_FORMAT) */ > ERROR_RXACT_INVALID_STATE, /* c000011c (STATUS_RXACT_INVALID_STATE) */ You should add the other LDT ones while you are at it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] shlwapi/ordinal: Partially implement SHGetShellKey
by Alexandre Julliard 20 Jul '10

20 Jul '10

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -2398,6 +2457,7 @@ START_TEST(ordinal) > { > hShlwapi = GetModuleHandleA("shlwapi.dll"); > is_win2k_and_lower = GetProcAddress(hShlwapi, "StrChrNW") == 0; > + is_win9x = (GetVersion() & 0x80000000); You should never check the version, check for features instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] include/shell32: Shell_MergeMenus should be declared in shlobj.h and exported by name. (try 2)
by testbot＠testbot.winehq.org 20 Jul '10

20 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3576 Your paranoid android. === WNT4WSSP6 (32 bit shlfileop) === shlfileop.c:2195: Test failed: SHGetNewLinkInfoA succeeded

2 1

Fwd: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]
by Dan Kegel 20 Jul '10

20 Jul '10

Quoth Linus: "Ask the Wine people what strange open-function-from-hell they are interested in." Full message follows. Discussion archived at e.g. http://marc.info/?l=linux-kernel&m=127955270231189&w=2 ---------- Forwarded message ---------- From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Mon, Jul 19, 2010 at 8:17 AM Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6] To: David Howells <dhowells(a)redhat.com> Cc: linux-cifs(a)vger.kernel.org, linux-nfs(a)vger.kernel.org, samba-technical(a)lists.samba.org, linux-kernel(a)vger.kernel.org, viro(a)zeniv.linux.org.uk, linux-fsdevel(a)vger.kernel.org, linux-ext4(a)vger.kernel.org On Wed, Jul 14, 2010 at 7:17 PM, David Howells <dhowells(a)redhat.com> wrote: > > ssize_t ret = xstat(int dfd, > const char *filename, > unsigned flags, > const struct xstat_parameters *params, > struct xstat *buffer, > size_t buflen); Ugh. So I think this is pretty disgusting. For a few reasons: - that whole xstat buffer handling is just a mess. I think you already fixed the "xstat_parameters" crud and just made it a simple unsigned long and a direct argument, but the "buffer+buflen" thing is still disgusting. Why not just leave a few empty fields at the end, and make the rule be: "We don't just add random crap, so don't expect it to grow widely in the future". - you use "long long" all over the place. Don't do that. If you want a fixed size, say so, and use "u64/s64". That's the _real_ fixed size, and "long long" just _happens_ to be the same size on all current architectures. Put another way: "long" just _happened_ to be 32 bits way back when on pretty much all targets. That's where all the 64-bit compatibility mess came from. Don't make the same mistake. Besides, if the point is to make things be the same, _document_ that point by using a type that is explicitly sized. - why create that new kind of xstat() that realistically absolutely nobody will use outside of some very special cases, and that has no real advantages for 99.9% of all people? You could make it a "atomic stat+open" by replacing the useless "size" return value with a "fd" return value, add a flag saying "we're also interested in opening it" (in the same result set flags), and instead of that stupid "buflen" input, give the "mode" input that open needs. Tadaa! You now have something that more people might be interested in, if only because it avoids a system call and might be a performance win. Who knows. Ask the Wine people what strange open-function-from-hell they are interested in. > ssize_t ret = fxstat(unsigned fd, Quite frankly, my gut feel is that once you do "xstat(dfd, filename, ...)" then it's damn stupid to do a separate "fxstat()", when you might as well say that "xtstat(dfd, NULL, ...)" is the same as "fxstat(fd, ...)" Now, the difference between adding one or two system calls may not be huge, but just from a cleanliness angle, I really don't see the point of having another fstat variant when the extended xstat() already very naturally supports the thing. And let's face it, using a NULL path pointer just makes sense if you don't have a path. You already passed it a target file descriptor in the dfd. Anyway, I didn't look at whether the new xstat fields made any sense, but I hated the interface enough that I can't be bothered to. Don't make up baroque new things that will never be used. Make a better argument for why anybody would use them despite the lack of standardization etc. And make sure they are as simple as possible (which is why I hate that "buflen" thing etc). Linus

2 1

shell32_test64.exe shlexec: 5-6 DDE tests always fail on testbot W7PROX64
by Ilya Basin 20 Jul '10

20 Jul '10

M> VM Status Number of test failures M> WINEBUILD completed M> W98SE completed 0 M> WNT4WSSP6 completed 0 M> W2KPROSP4 completed 0 M> WXPPROSP3 completed 0 M> W2K3R2SESP2 completed 0 M> WVISTAADM completed 0 M> W2K8SE completed 0 M> W7PRO completed 0 M> W7PROX64 completed 0 M> W7PROX64 completed 5 M> === WINEBUILD (build) === M> No build failures found M> === W98SE (32 bit shlexec) === M> No test failures found M> === WNT4WSSP6 (32 bit shlexec) === M> No test failures found M> === W2KPROSP4 (32 bit shlexec) === M> No test failures found M> === WXPPROSP3 (32 bit shlexec) === M> No test failures found M> === W2K3R2SESP2 (32 bit shlexec) === M> No test failures found M> === WVISTAADM (32 bit shlexec) === M> No test failures found M> === W2K8SE (32 bit shlexec) === M> No test failures found M> === W7PRO (32 bit shlexec) === M> No test failures found M> === W7PROX64 (32 bit shlexec) === M> No test failures found M> === W7PROX64 (64 bit shlexec) === M> shell32: M> shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 M> shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 M> shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 M> shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 M> shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 Hi! I sent multiple different patches for shlexec and ever since W7PROX64 (64 bit shlexec) is used by testbot, 5 DDE tests always fail on it. I can't reproduce it on local W7PROX64: No shlexec tests fail. test.winehq.org has the same problem http://test.winehq.org/data/d494bda30f1b5b9bc37f094bd8874d3aeeaf8840/win7_w… Another question: winetest64-latest.exe extracts individual test binaries to the temp folder and runs them. How do you extract the binaries without running? --

3 2

Re: ddraw: Allow creating back buffer for pre-DirectX 7 interfaces.
by Henri Verbeet 20 Jul '10

20 Jul '10

2010/7/19 Oldřich Jedlička <oldium.pro(a)seznam.cz>: > This fixes bug #9008. Please provide a more descriptive log message, and consider writing a test. I'm also pretty sure this will conflict with http://source.winehq.org/patches/data/63676.

4 6

← Newer
1
...
20
21
22
23
24
25
26
...
46
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 July 2010