Re: [PATCH 09/13] shdocvw: Added more navigation tests.
On 03/13/2010 04:44 PM, Jacek Caban wrote: --- dlls/shdocvw/tests/webbrowser.c | 293 +-- 1 files changed, 218 insertions(+), 75 deletions(-) Hi Jacek, This one has introduced several test failures on a variety of platforms (or IE versions): http://test.winehq.org/data/tests/shdocvw:webbrowser.html Could you have a look? -- Cheers, Paul.
Re: usbd.sys: add usbd.sys (try 4)
Damjan Jovanovic damjan@gmail.com writes: Changelog: * usbd.sys: add usbd.sys Try 4 is the shortest possible patch. Copyright assigned to both me and Alexandre Morozov, since his patch is the basis of this one. The proper way to assign credit is not by adding copyright lines in the source, but by making sure every commit is credited to the right author. If a patch was not written by you it needs a From: line specifying the real author, and preferably it needs to be submitted by the original author himself. -- Alexandre Julliard julli...@winehq.org
Re: mmdevapi: Implement IMMDeviceEnumerator::GetDevice. patch
Hoi Joris,
On 16-03-10 21:31, Joris Huizer wrote:
Hello, Maarten Lankhorst,
I was browsing through the recent patches in git, I noticed some possible issue
in this code:
+for (i = 0; i MMDevice_count; ++i)
+{
+WCHAR *str;
+dev = (IMMDevice*)MMDevice_head[i];
+IMMDevice_GetId(dev,str);
+
+if (str !lstrcmpW(str, name))
+{
+CoTaskMemFree(str);
+break;
+}
+CoTaskMemFree(str);
+}
+if (dev)
+{
+IUnknown_AddRef(dev);
+*device = dev;
+return S_OK;
+}
I'm not sure whether this can happen, but in case the name isn't found at all,
this will assign the last device in the MMDevice_head[] array (as far as I can
see?)
In case this is an issue, a simple fix would be, to make the check look like
this instead:
You're right, it's a bug. But don't worry about fixing it, at the moment
it's not an issue, since nobody is creating a device, unless you create
the registry keys for it manually.
I have a real fix, where I'm starting to implement IMMDevice by
populating it with the results from OpenAL library, but I'm waiting with
implementing mmdevapi until the next wine release is out. There will
likely be some fallout from merging that code. :)
Please CC wine-devel in the future
Cheers,
Maarten
Re: [patch] DNS_SD bridge, v2
On Tue, Mar 16, 2010 at 04:41:02PM -0600, C.W. Betts wrote: Excuse my ignorance, but what would happen if it didn't find the library dynamically? You would check this condition (like NULL handle or NULL function pointer) in every wrapped function and return an error condition in that case. Or if there is a central startup function for the whole library, just in that one function (if this leads to the others not called). ciao, Marcus
Re: Add VRGB/VBGR render modes for subpixel aliasing as new FontOrientation to enable capabilities that are already in xrender.c:UploadGlyph and subsequently freetype.c:WineEngGetGlyphOutline
Clemens Fruhwirth clem...@endorphin.org writes: @@ -3090,8 +3090,10 @@ typedef struct tagCBTACTIVATESTRUCT #define FE_FONTSMOOTHINGCLEARTYPE 0x0002 #define FE_FONTSMOOTHINGDOCKING0x8000 -#define FE_FONTSMOOTHINGORIENTATIONBGR 0x -#define FE_FONTSMOOTHINGORIENTATIONRGB 0x0001 +#define FE_FONTSMOOTHINGORIENTATIONBGR 0x +#define FE_FONTSMOOTHINGORIENTATIONRGB 0x0001 +#define FE_FONTSMOOTHINGORIENTATIONVBGR 0x0002 +#define FE_FONTSMOOTHINGORIENTATIONVRGB 0x0003 These don't seem to exist in the PSDK. Where do they come from? -- Alexandre Julliard julli...@winehq.org
Re[2]: shell32/tests: add tests for the parser of SHELLEXECUTEINFO.lpFile [try 7]
There's a block of code in dlls/shell32/shlexec.c
http://source.winehq.org/git/wine.git/?a=blob;f=dlls/shell32/shlexec.c;h=a81cada91fed264816a0946c06e83a00b7fb6484;hb=HEAD#l1681
It specially handles lpFile with '' or containing spaces. Does anyone
know a real situation when you need this handling? If I disable this
block:
/* separate out command line arguments from executable file name */
if (0 !*sei_tmp.lpParameters !appKnownSingular) {
my tests succeed, but there may be others, that I'm currently trying
to find.
Re: [1/4] d3d9: Remove old debug messages from the tests
On 17 March 2010 11:22, Stefan Dösinger ste...@codeweavers.com wrote: Adding a Sleep() instead isn't much of an improvement.
Re: [3/4] d3d9: Remove the double unlock test
On 17 March 2010 11:56, Stefan Dösinger ste...@codeweavers.com wrote: Windows 7 returns a different value than the test expects, and since its a todo_wine it seems no game depends on it. http://bugs.winehq.org/show_bug.cgi?id=19862 depends on that.
Re: [PATCH 2/2] cmd: Adds shlwapi library to cmd.exe's Makefile.in
Alright--I'll update and resubmit when I get home from work. The patch submission guidelines mentioned something about not including Makefile or Makefile.in in patches and splitting them out instead. Should I be worried about that submission guideline? --Original Message-- From: Dan Kegel Sender: daniel.r.ke...@gmail.com To: wine-devel@winehq.org Cc: John Gilik Subject: Re: [PATCH 2/2] cmd: Adds shlwapi library to cmd.exe's Makefile.in Sent: Mar 16, 2010 5:51 PM Each patch in a series must compile and pass all tests, so if you need shlwapi for patch 1, then you have to include it in patch 1 (and then you just have one patch, not a series).
Re: usbd.sys: add usbd.sys (try 4)
On Wed, Mar 17, 2010 at 11:10 AM, Alexandre Julliard julli...@winehq.org wrote: Damjan Jovanovic damjan@gmail.com writes: Changelog: * usbd.sys: add usbd.sys Try 4 is the shortest possible patch. Copyright assigned to both me and Alexandre Morozov, since his patch is the basis of this one. The proper way to assign credit is not by adding copyright lines in the source, but by making sure every commit is credited to the right author. If a patch was not written by you it needs a From: line specifying the real author, and preferably it needs to be submitted by the original author himself. -- Alexandre Julliard julli...@winehq.org The real author doesn't want to send those patches, but has allowed me to send them instead (http://www.winehq.org/pipermail/wine-devel/2010-February/081654.html). I will be sending it with a different From: next time. Thank you Damjan Jovanovic
Re: [PATCH 1/3] d3dx9_36: Implement ID3DXConstantTableImpl_GetDesc + tests (try 2)
On 17 March 2010 12:20, Christian Costa titan.co...@wanadoo.fr wrote: +error: + +if (object) +HeapFree(GetProcessHeap(), 0, object-ctab); +HeapFree(GetProcessHeap(), 0, object); object should never be NULL, all jumps to error are after the NULL check.
Re: [PATCH 1/2] d3dx9: Add d3dx9effect.h include file
On 17 March 2010 12:21, Christian Costa titan.co...@wanadoo.fr wrote:
+typedef struct _D3DXPASS_DESC {
+LPCSTR Name;
+UINT Annotations;
+DWORD VSVersion;
+DWORD PSVersion;
+UINT VSSemanticsUsed;
+D3DXSEMANTIC VSSemantics[MAXD3DDECLLENGTH];
+UINT PSSemanticsUsed;
+D3DXSEMANTIC PSSemantics[MAXD3DDECLLENGTH];
+UINT PSSamplersUsed;
+LPCSTR PSSamplers[16];
+} D3DXPASS_DESC;
Which version of the SDK is this supposed to match? It doesn't match
mine or MSDN.
+#define ID3DXBaseEffect_GetDesc(p,a)
(p)-GetDesc(p,a)
...
+#define ID3DXBaseEffect_SetArrayRange(p,a,b,c)
(p)-SetArrayRange(p,a,b,c)
Those don't like right for C++. The other interfaces have similar
issues, including:
+#define ID3DXEffect_CommitChanges()
(p)-lpVtbl-CommitChanges(p)
and
+#define ID3DXEffect_GetVertexShader(p,a,b)
(p)-GetVertexShader(p,a,b)
However, my SDK doesn't have C object macros for any of the
interfaces in d3dx9effect.h.
Re: [PATCH 2/3] d3dx9_36: Add missing GetSamplerIndex method to ID3DXConstantTable
On 17 March 2010 12:20, Christian Costa titan.co...@wanadoo.fr wrote: +#define ID3DXConstantTable_GetSamplerIndex(p,a) (p)-lpVtbl-GetConstantDesc(p,a) +#define ID3DXConstantTable_GetSamplerIndex(p,a) (p)-GetConstantDesc(p,a) Looks wrong.
Re: [PATCH] d3dx9_36: Add stub for D3DXCreateTextureFromFileInMemoryE
On 17 March 2010 12:21, Christian Costa titan.co...@wanadoo.fr wrote: +FIXME((%p, %p, %d, %d, %d, %d, %x, %x, %x, %d, %d, %x, %p, %p, %p): stub\n, device, srcdata, srcdatasize, width, +height, miplevels, usage, format, pool, filter, mipfilter, colorkey, srcinfo, palette, texture); Those integers are all unsigned.
Re: [PATCH 09/13] shdocvw: Added more navigation tests.
Hi Paul, On 3/17/10 8:40 AM, Paul Vriens wrote: Hi Jacek, This one has introduced several test failures on a variety of platforms (or IE versions): http://test.winehq.org/data/tests/shdocvw:webbrowser.html Could you have a look? Sure, I've already sent a patch for most common failure. Thanks, Jacek
Re: [PATCH] cmd: removed %CD% test.
On 3/16/10 5:42 PM, Yann Droneaud wrote: Le mardi 16 mars 2010 à 11:25 -0500, Austin English a écrit : On Tue, Mar 16, 2010 at 4:53 AM, Yann Droneaudy...@droneaud.fr wrote: %CD% seems not supported on Windows NT 4. The patch which introduce this test was based on MSDN documentation and only tested on Windows XP Instead of removing it, perhaps the cmd test framework needs to understand the broken() macro... As %CD% was added in a batch file (test_builtins.cmd) so it's easier to remove it. Not really, I've sent a patch: http://source.winehq.org/patches/data/59373 Jacek
Re: cmd: Added @or_broken@ handling to test templates and use it to fix tests on win2k.
On 3/17/10 2:14 PM, Paul Vriens wrote: On 03/17/2010 02:10 PM, Jacek Caban wrote: --- programs/cmd/tests/batch.c | 39 - programs/cmd/tests/test_builtins.cmd.exp | 2 +- 2 files changed, 33 insertions(+), 8 deletions(-) Hi Jacek, Wasn't this test removed (for NT4 btw)? Right, I must have forgotten to rebase my tree. Let's add it back then:-) Thanks, Jacek
Re: [PATCH try2] cmd: Added @or_broken@ handling to test templates and use it to fix tests on win2k.
On 03/17/2010 02:22 PM, Jacek Caban wrote: --- a/programs/cmd/tests/test_builtins.cmd.exp +++ b/programs/cmd/tests/test_builtins.cmd.exp @@ -16,6 +16,7 @@ bar ~dp0 should be directory containing batch file @p...@\ @p...@\ +...@pwd@@or_bro...@echo is off. Won't this fail on non English locales? In this case it will only fail on non English NT4 boxes, but still. -- Cheers, Paul.
lstrcmpW on Windows ignores some special unicode characters
Hi, I already mentioned this in my last shlwapi patch. lstrcmpW (and CompareStringW for that matter) ignore some special unicode characters like 0x200e (and also loads of others). Do we care? I.o.w. is there a need for implementing this? I only tested these characters at the start of the strings btw. -- Cheers, Paul.
Re: 1/3 wined3d: disable hw accelerated 8-bit blits in BltOverride
On 17 March 2010 14:48, Roderick Colenbrander thunderbir...@gmail.com wrote: This first patch disables hardware accelerated 8-bit blitting. This code will completely use the shader backend later on and won't require hacks like 'paletteOverride'. I'm not sure breaking things is the right approach?
Re: 1/3 wined3d: disable hw accelerated 8-bit blits in BltOverride
On Wed, Mar 17, 2010 at 2:54 PM, Henri Verbeet hverb...@gmail.com wrote: On 17 March 2010 14:48, Roderick Colenbrander thunderbir...@gmail.com wrote: This first patch disables hardware accelerated 8-bit blitting. This code will completely use the shader backend later on and won't require hacks like 'paletteOverride'. I'm not sure breaking things is the right approach? Well, I discussed the situation with Stefan last weekend. He preferred if I would make BltOverride a little bit nicer before I improved the p8 stuff. He considered it a safe move to disable this for now. Within a few patches I can fix this (after the 'offscreen surface - render target' code has been cleaned up). The main thing which basically needs to happen is that during blit-set_shader the palette needs to be loaded. Those patches are mostly done but have to be brought over to latest git and some might need some minor cleanups but I didn't have time for those (I have been quite sick this week). Roderick
Re: 2/3 wined3d: add a helper function for drawing a textured quad
On 17 March 2010 14:53, Roderick Colenbrander thunderbir...@gmail.com wrote: This patch introduces a helper function for drawing a textured quad. A future patch will also make use of it for the quad drawing part of 'offscreen surface - render target' in BltOverride (actually that part will become two functions later on: one for color keying to be called from Blt/BltFast and one without any color keying) The idea of making this a separate function is probably ok, but that function has more GL state dependencies than just locking and context activation, and also invalidates some GL states. Ultimately drawing a quad is something that should be internal to a blitter implementation. A shader based blitter for example wouldn't have to invalidate lots of fixed function state because it simply replaces those parts of the GL pipeline. A FBO blit based implementation doesn't have to draw a quad at all. Perhaps this is an acceptable step in that direction, but it's probably a good idea to think about what the blitter interface should look like first. Also, const correctness.
Re: 1/3 wined3d: disable hw accelerated 8-bit blits in BltOverride
On 17 March 2010 15:08, Roderick Colenbrander thunderbir...@gmail.com wrote: Well, I discussed the situation with Stefan last weekend. He preferred if I would make BltOverride a little bit nicer before I improved the p8 stuff. He considered it a safe move to disable this for now. Within Cleaning things up is ok, but you should avoid breaking things if it can be reasonably avoided.
Re: Add VRGB/VBGR render modes for subpixel aliasing as new FontOrientation to enable capabilities that are already in xrender.c:UploadGlyph and subsequently freetype.c:WineEngGetGlyphOutline
Clemens Fruhwirth clem...@endorphin.org writes: Would it be ok to add some override to Software\\Wine\\Fonts*? I'm using a rotated monitor and at least in Wine I would like to have properly rendered fonts. The first step would be to investigate how Windows handles that case. -- Alexandre Julliard julli...@winehq.org
Re: winemp3.acm: support mp3 decoding on Mac OS/X systems
Aric Stewart a...@codeweavers.com writes: uses CoreAudio's AudioConverter, AudioFile and AudioFileStream. uses prefered systems for either (Snow) Leopard or Tiger deciding at runtime. I don't think we have to care about Tiger compatibility here, especially since it involves so much extra code. -- Alexandre Julliard julli...@winehq.org
Re: shell32: remove unneeded parsing of SHELLEXECUTEINFO.lpFile
On 03/17/2010 04:21 PM, Ilya Basin wrote:
@@ -1013,7 +1011,7 @@ static void test_filename(void)
%s failed: rc=%d err=%d\n, shell_call,
rc, GetLastError());
}
-else todo_wine
+else
{
ok(rc==test-rc, %s failed: rc=%d err=%d\n, shell_call,
rc, GetLastError());
Hi Ilya,
If this is no longer a todo_wine you should change the filename_tests
struct:
/* Test file masked due to space */
{NULL, %s\\masked file.shlexec, 0x1, 33},
to
/* Test file masked due to space */
{NULL, %s\\masked file.shlexec, 0x0, 33},
You can even consider removing the if ((test-todo 0x1)==0) as now
there are no more of those tests.
On the one hand it's nice to have these todo constructs, removing them
however is a greater incentive to get the implementation right ;)
--
Cheers,
Paul.
Re: [PATCH 2/2] cmd: Adds shlwapi library to cmd.exe's Makefile.in
On Tue, Mar 16, 2010 at 7:57 PM, jgi...@ucla.edu wrote: Alright--I'll update and resubmit when I get home from work. The patch submission guidelines mentioned something about not including Makefile or Makefile.in in patches and splitting them out instead. Should I be worried about that submission guideline? Please bottom post. You're probably referring to: -- Files to include Include a single diff of all the files you changed. You don't need to include diffs for the following automatically generated files: configure include/config.h dlls/Makefile.in programs/Makefile.in */Makefile -- programs/cmd/Makefile.in isn't in that list ;-). -- -Austin
Measuring game FPS in wine/windows?
Howdy, I've been testing some games lately on Windows/Wine, and wanted to see the difference in framerates. On windows, I've been using Fraps, which works decently well, but not under wine (and it doesn't work for Assassin's creed). I found D3DGears online, which supposedly works for Assassin's creed on Windows (haven't checked), but doesn't work under wine. Does anyone know of a standalone application that works under wine? Thanks! -Austin
Re: Measuring game FPS in wine/windows?
On Wed, Mar 17, 2010 at 5:27 PM, Austin English austinengl...@gmail.com wrote: Howdy, I've been testing some games lately on Windows/Wine, and wanted to see the difference in framerates. On windows, I've been using Fraps, which works decently well, but not under wine (and it doesn't work for Assassin's creed). I found D3DGears online, which supposedly works for Assassin's creed on Windows (haven't checked), but doesn't work under wine. Does anyone know of a standalone application that works under wine? Thanks! -Austin The easiest thing you can do on Wine is run using WINEDEBUG=+fps :) (assuming the game uses double buffering which all modern games do) There are also other ways but I'm not sure if they work with Wine at this point. Basically tools like Fraps inject themselves into the Direct3D/OpenGL call which is responsible for showing a new frame. In case of Linux apps the best you can do is hook into glXSwapBuffers but Wine loads opengl at run-time, so that doesn't work. The +fps channel calculates the framerate around that call in the Wine code. If you want to more detailed measurements also try to use WineD3D on Windows. It could give you an indication how big the impact of the drivers is and perhaps Wine is. If you are using Nvidia the OpenGL drivers should be the same (perhaps there would be a difference of a few percent but you could ignore that), so in that case the performance we are losing is due to Wine/Linux. Roderick
Re: Small spelling fixes.
Thanks for sending a patch for this. It seems it was not committed,
probably because your mailer added line-breaks, making it difficult to
apply.
Could you resend as an attachment, or without the line breaks if you
can configure your mailer to do that?
Or, if you prefer, I can send this with fixed formatting on your behalf.
2010/3/12 Julian Rüger j...@gmx.net:
---
dlls/windowscodecs/pngformat.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/windowscodecs/pngformat.c
b/dlls/windowscodecs/pngformat.c
index 22b37b0..5af680e 100644
--- a/dlls/windowscodecs/pngformat.c
+++ b/dlls/windowscodecs/pngformat.c
@@ -1320,13 +1320,13 @@ HRESULT PngEncoder_CreateInstance(IUnknown
*pUnkOuter, REFIID iid, void** ppv)
HRESULT PngDecoder_CreateInstance(IUnknown *pUnkOuter, REFIID iid,
void** ppv)
{
- ERR(Trying to load PNG picture, but PNG supported not compiled
in.\n);
+ ERR(Trying to load PNG picture, but PNG support is not compiled
in.\n);
return E_FAIL;
}
HRESULT PngEncoder_CreateInstance(IUnknown *pUnkOuter, REFIID iid,
void** ppv)
{
- ERR(Trying to save PNG picture, but PNG supported not compiled
in.\n);
+ ERR(Trying to save PNG picture, but PNG support is not compiled
in.\n);
return E_FAIL;
}
--
1.5.6.3
Re: [PATCH] attrib.exe: Add stubbed command
On Mi, 2010-03-17 at 12:22 +0100, Christian Costa wrote: +printf(attrib.exe is currently only a stub command\n); +printf(cmdline:); UNICODE would be better, even for a stub. -- By by ... Detlef
Re: Add VRGB/VBGR render modes for subpixel aliasing as new FontOrientation to enable capabilities that are already in xrender.c:UploadGlyph and subsequently freetype.c:WineEngGetGlyphOutline
On Wed, Mar 17, 2010 at 11:03 AM, Alexandre Julliard julli...@winehq.org wrote: Clemens Fruhwirth clem...@endorphin.org writes: @@ -3090,8 +3090,10 @@ typedef struct tagCBTACTIVATESTRUCT #define FE_FONTSMOOTHINGCLEARTYPE 0x0002 #define FE_FONTSMOOTHINGDOCKING 0x8000 -#define FE_FONTSMOOTHINGORIENTATIONBGR 0x -#define FE_FONTSMOOTHINGORIENTATIONRGB 0x0001 +#define FE_FONTSMOOTHINGORIENTATIONBGR 0x +#define FE_FONTSMOOTHINGORIENTATIONRGB 0x0001 +#define FE_FONTSMOOTHINGORIENTATIONVBGR 0x0002 +#define FE_FONTSMOOTHINGORIENTATIONVRGB 0x0003 These don't seem to exist in the PSDK. Where do they come from? I doubled check my assumption that those are wine-specific #defines. This is obviously false (I should have guessed that from the .h file-name). Assuming this would be wine specific, I invented the two additional defines. Sorry, discard the patch. Would it be ok to add some override to Software\\Wine\\Fonts*? I'm using a rotated monitor and at least in Wine I would like to have properly rendered fonts. -- Fruhwirth Clemens http://clemens.endorphin.org
Re: Add VRGB/VBGR render modes for subpixel aliasing as new FontOrientation to enable capabilities that are already in xrender.c:UploadGlyph and subsequently freetype.c:WineEngGetGlyphOutline
On Wed, Mar 17, 2010 at 3:17 PM, Alexandre Julliard julli...@winehq.org wrote: Clemens Fruhwirth clem...@endorphin.org writes: Would it be ok to add some override to Software\\Wine\\Fonts*? I'm using a rotated monitor and at least in Wine I would like to have properly rendered fonts. The first step would be to investigate how Windows handles that case. There are no vertical rendering modes for ClearType under Windows (7). There are some interfaces to do vertical rendering with DirectWrite, but there are no ways to enable it generally for the whole interface. I googled that some time ago and all resources come to the same conclusion, ClearType=disabled for rotated monitors. http://typophile.com/node/35168 My proposal would extend Wine beyond the capabilities of Windows. I assumed that with Windows 7 they'd fix this long outstanding missing feature, but I was wrong obviously. -- Fruhwirth Clemens http://clemens.endorphin.org
Re: [1/2] urlmon: Add stub IUriBuilder interface (try2)
On 3/18/2010 04:16, Nikolay Sivov wrote: I know comdlg32 doesn't seem to be very close to urlmon, but stub I added shows a problems in included headers order. SetPort method from IUriBuilder collides with SetPort define from winspool.h and a build error comes up saying I'm using unprefixed call (without A or W). Hm, next conflict is in programs/clock. Chain is windows.h - ole2.h - objbase.h - urlmon.h In windows.h there's include winspool.h before ole2.h, and this causes conflict. Not sure how to fix it now, any comments are welcome. Second patch should apply cleanly.
