Re: user32: Resend: Move character conversion logic to dde_server.d remove todo's
Dmitry Timoshkov wrote: Jeff Latimer l...@yless4u.com.au wrote: The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too. Have you looked at the info returned DdeQueryConvInfo, particularly iCodePage in the conversation context? I have inserted DdeQueryConvInfo into dde.c for checking whether it would help in determining the Unicodeness of the passed data. The results are below. The tests are to pass two messages, the 1st is non Unicode and 2nd is Unicode. As can be seen, DdeQueryConvInfo does not help with determining if the data is Unicode as the codepage is determined by the Client initialisation not from the data. dde.c:2472: start end to end server ASCII dde.c:2403: Start end to end client ASCII dde.c:2275: server iCodePage=1004 dde.c:2440: client iCodePage=1004 dde.c:2275: server iCodePage=1004 dde.c:2452: client iCodePage=1004 dde: 15 tests executed (0 marked as todo, 0 failures), 0 skipped. dde.c:2472: start end to end server UNICODE dde.c:2403: Start end to end client UNICODE dde.c:2275: server iCodePage=1200 dde.c:2440: client iCodePage=1200 dde.c:2275: server iCodePage=1200 dde.c:2452: client iCodePage=1200 dde: 15 tests executed (0 marked as todo, 0 failures), 0 skipped. dde.c:2472: start end to end server UNICODE dde.c:2403: Start end to end client ASCII dde.c:2275: server iCodePage=1004 dde.c:2440: client iCodePage=1004 dde.c:2275: server iCodePage=1004 dde.c:2452: client iCodePage=1004 dde: 15 tests executed (0 marked as todo, 0 failures), 0 skipped. dde.c:2472: start end to end server ASCII dde.c:2403: Start end to end client UNICODE dde.c:2275: server iCodePage=1200 dde.c:2440: client iCodePage=1200 dde.c:2275: server iCodePage=1200 dde.c:2452: client iCodePage=1200 Server code issuing the query pConvInfo.cb = sizeof(pConvInfo); err = DdeQueryConvInfo(hconv, QID_SYNC, pConvInfo); ok(err == TRUE, should be the number of bytes not %d\n, err); err = DdeGetLastError(server_pid); ok(err == DMLERR_NO_ERROR, wrong dde error %x\n, err); trace(server iCodePage=%d\n, pConvInfo.ConvCtxt.iCodePage); Client code issuing the query pConvInfo.cb = sizeof(pConvInfo); err = DdeQueryConvInfo(hconv, QID_SYNC, pConvInfo); ok(err == TRUE, should be the number of bytes not %d\n, err); err = DdeGetLastError(client_pid); ok(err == DMLERR_NO_ERROR, wrong dde error %x\n, err); trace(Client iCodePage=%d\n, pConvInfo.ConvCtxt.iCodePage);
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/25 Claudio Ciccani k...@users.sf.net: +WORD vertexBlendSW : 1; /* vertexBlend software fallback used */ I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding.
Re: d3d8/tests: Make tests pass on W2K8
2009/1/26 Ge van Geldorp g...@gse.nl: Changelog: d3d8/tests: Make tests pass on W2K8 -ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL, IDirect3D8_CreateDevice failed with %#08x\n, hr); +ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL || hr == D3DERR_NOTAVAILABLE, IDirect3D8_CreateDevice failed with %#08x\n, hr); This looks more like something certain VMs would return than something specific to a particular Windows version.
Checking an empty CDROM drive
Hi,
I'm trying to come up with some test to show that GetDriveType returns
DRIVE_CDROM regardless whether there is or isn't a CD mounted.
I have the following:
diff --git a/dlls/kernel32/tests/drive.c b/dlls/kernel32/tests/drive.c
index a94cbdf..53b0262 100644
--- a/dlls/kernel32/tests/drive.c
+++ b/dlls/kernel32/tests/drive.c
@@ -46,6 +46,24 @@ static void test_GetDriveTypeA(void)
GetDriveTypeA should return DRIVE_NO_ROOT_DIR for inexistent
drive %c: but not %u\n,
drive[0], type);
+/* Check if type is still DRIVE_CDROM even when no CD is mounted */
+if (type == 5)
+{
+DWORD attrs;
+
+SetLastError(0xdeadbeef);
+attrs = GetFileAttributesA(drive);
+if (attrs == INVALID_FILE_ATTRIBUTES)
+{
+trace(Unmounted CDROM with type DRIVE_CDROM\n);
+ok(GetLastError() == ERROR_NOT_READY,
+ Expected ERROR_NOT_READY for an unmounted CDROM\n);
+}
+else
+ ok((attrs FILE_ATTRIBUTE_DIRECTORY) ==
FILE_ATTRIBUTE_DIRECTORY,
+ Expected FILE_ATTRIBUTE_DIRECTORY for a mounted CDROM\n);
+}
+
logical_drives = 1;
}
}
The idea however is to show that Wine is wrong in returning DRIVE_NO_ROOT_DIR
for an unmounted CD. The test above of course doesn't show that, it only proves
that Windows does it this way.
(All is related to bug http://bugs.winehq.org/show_bug.cgi?id=16592)
--
Cheers,
Paul.
Re: Checking an empty CDROM drive
Paul Vriens wrote:
Hi,
I'm trying to come up with some test to show that GetDriveType returns
DRIVE_CDROM regardless whether there is or isn't a CD mounted.
I have the following:
diff --git a/dlls/kernel32/tests/drive.c b/dlls/kernel32/tests/drive.c
index a94cbdf..53b0262 100644
--- a/dlls/kernel32/tests/drive.c
+++ b/dlls/kernel32/tests/drive.c
@@ -46,6 +46,24 @@ static void test_GetDriveTypeA(void)
GetDriveTypeA should return DRIVE_NO_ROOT_DIR for
inexistent drive %c: but not %u\n,
drive[0], type);
+/* Check if type is still DRIVE_CDROM even when no CD is
mounted */
+if (type == 5)
+{
+DWORD attrs;
+
+SetLastError(0xdeadbeef);
+attrs = GetFileAttributesA(drive);
+if (attrs == INVALID_FILE_ATTRIBUTES)
+{
+trace(Unmounted CDROM with type DRIVE_CDROM\n);
+ok(GetLastError() == ERROR_NOT_READY,
+ Expected ERROR_NOT_READY for an unmounted CDROM\n);
+}
+else
+ ok((attrs FILE_ATTRIBUTE_DIRECTORY) ==
FILE_ATTRIBUTE_DIRECTORY,
+ Expected FILE_ATTRIBUTE_DIRECTORY for a mounted
CDROM\n);
+}
+
logical_drives = 1;
}
}
The idea however is to show that Wine is wrong in returning
DRIVE_NO_ROOT_DIR for an unmounted CD. The test above of course doesn't
show that, it only proves that Windows does it this way.
(All is related to bug http://bugs.winehq.org/show_bug.cgi?id=16592)
Oh, and the same is true (of course) for floppy drives (GetDriveType should
always return DRIVE_REMOVABLE).
--
Cheers,
Paul.
Re: D3D: Implement vertex blending in drawStridedSlow
On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote: 2009/1/25 Claudio Ciccani k...@users.sf.net: +WORD vertexBlendSW : 1; /* vertexBlend software fallback used */ I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding. I can't speak towards the bitfield part, but implementing vertex blending in software will magically make a few games (two that I know of, Warhammer Online and Everquest) work without patching, and without passing through drawStridedSlow. This is because they don't actually use the vertex blending, but produce unrecognised (by Wine) vertex data if the capability isn't there. -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpEVVs3qKqpC.pgp Description: PGP signature
Re: Re: D3D: Implement vertex blending in drawStridedSlow
Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto: 2009/1/25 Claudio Ciccani k...@users.sf.net The patch implements a software fallback for vertex blending in drawStridedSlow, fixing Bug #6955. Although vertex blending is an old and outdated extension, there are still many applications(games) relying on it nowadays. This because the extension is generally supported by Direct3D, either directly in hardware (using vertex programs) or in software. This patch makes NOLF2 demo crashes. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 -RIZP1) EAX:00ec1b28 EBX:7e6bbc54 ECX:014c EDX: ESI:0048 EDI: Stack dump: 0x0033f0b4: 3f80 0x0033f0c4: 0033f110 7d05e000 7c03d008 7c7aa346 0x0033f0d4: 0003 7e6bc7a0 7e69ee95 0x0033f0e4: 7e69e648 0001 000c 0010 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 00ebd44c 0x0033f104: 00eba698 00ebd7a8 0007 Backtrace: =0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d (0x0033f1ec) 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=is not available, idxData=(nil), minIndex=0) [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d (0x0033f55c) 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive +0x96(iface=register ESI not in topmost frame, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] in d3d8 (0x0033f5fc) 0x7e6095c7 drawStridedSlow+0x697 [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds 0x0(%ecx) 307 m = stateBlock-transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : 0))].u.m[0][0]; Modules: Really strange! Tested the patch against other games and it worked. With NOLF2 I'm getting a crash too, but at a different location: 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4, NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2, idxData=0x3d871e0, minIndex=0) [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d (0x) 0x7d2b3771: movl0x0(%ecx),%edx 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask = 1, ++texture)
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/26 Paul TBBle Hampson paul.hamp...@pobox.com: On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote: 2009/1/25 Claudio Ciccani k...@users.sf.net: +WORD vertexBlendSW : 1; /* vertexBlend software fallback used */ I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding. I can't speak towards the bitfield part, but implementing vertex blending in software will magically make a few games (two that I know of, Warhammer Online and Everquest) work without patching, and without passing through drawStridedSlow. Sure, but so does just faking the device caps.
Re: d3d8/tests: Make tests pass on W2K8
Ge van Geldorp wrote: Hi Henri, From: Henri Verbeet 2009/1/26 Ge van Geldorp ge at gse.nl: Changelog: d3d8/tests: Make tests pass on W2K8 -ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL, IDirect3D8_CreateDevice failed with %#08x\n, hr); +ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL || hr == D3DERR_NOTAVAILABLE, IDirect3D8_CreateDevice failed with %#08x\n, hr); This looks more like something certain VMs would return than something specific to a particular Windows version. You're probably right, this was run on a VM. However, I don't see the same failure on other Windows versions. And I guess the test should still pass, even when it runs on a VM? Gé. I guess if it's a return value from a VM it's better to mark it as broken(). -- Cheers, Paul.
Bugzilla question with respect to .NET 1.1SP1
Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? Bug 9140 for example is a separate report with a dependence on 13995. And bug 14850 is marked as a duplicate of 13995. -- Cheers, Paul.
Re: Wine menu creation questions
Reece Dunn mscl...@googlemail.com writes: I have noticed that when wine creates a menu item (that for example, on Ubuntu gets put in the Applications Wine Programs menu), the command that gets written uses 'wine' as the program to run. This means that you need to have Wine in your PATH and cannot use more than one version of Wine. For example, if I wanted to use /opt/wine-1.0, /opt/crossover and /opt/wine for different applications I cannot access these correctly from the menu items created. Additionally, the user experience (yes, I have been watching Owen's Google talk :)) is that the application does not start (especially if the only version of Wine is not on the PATH). The solution to this is to add the full path to wine, e.g. '/opt/wine-1.0/bin/wine' when generating the menus. Are there any objections to this? It seems to me you are just trading one problem for another, now it will break if the wine binary is moved even if it's still in the PATH. I think this should be handled by the desktop environment; if the app specified in the menu isn't found it should offer a list of alternatives or something along those lines. This is not specific to Wine. -- Alexandre Julliard julli...@winehq.org
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/25 Claudio Ciccani k...@users.sf.net The patch implements a software fallback for vertex blending in drawStridedSlow, fixing Bug #6955. Although vertex blending is an old and outdated extension, there are still many applications(games) relying on it nowadays. This because the extension is generally supported by Direct3D, either directly in hardware (using vertex programs) or in software. This patch makes NOLF2 demo crashes. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 -RIZP1) EAX:00ec1b28 EBX:7e6bbc54 ECX:014c EDX: ESI:0048 EDI: Stack dump: 0x0033f0b4: 3f80 0x0033f0c4: 0033f110 7d05e000 7c03d008 7c7aa346 0x0033f0d4: 0003 7e6bc7a0 7e69ee95 0x0033f0e4: 7e69e648 0001 000c 0010 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 00ebd44c 0x0033f104: 00eba698 00ebd7a8 0007 Backtrace: =0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d (0x0033f1ec) 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=is not available, idxData=(nil), minIndex=0) [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d (0x0033f55c) 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive+0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive+0x96(iface=register ESI not in topmost frame, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] in d3d8 (0x0033f5fc) 0x7e6095c7 drawStridedSlow+0x697 [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds 0x0(%ecx) 307 m = stateBlock-transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : 0))].u.m[0][0]; Modules:
Re: Re: Re: D3D: Implement vertex blending in drawStridedSlow
I found that the reason of the crash was that VBOs were not removed when
using drawStridedSlow for vertex blending.
Attached is the modified patch, which doesn't make NOLF2 crash.
Il giorno lun, 26/01/2009 alle 12.12 +0100, Claudio Ciccani ha scritto:
Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto:
2009/1/25 Claudio Ciccani k...@users.sf.net
The patch implements a software fallback for vertex blending
in
drawStridedSlow, fixing Bug #6955.
Although vertex blending is an old and outdated extension,
there are
still many applications(games) relying on it nowadays. This
because the
extension is generally supported by Direct3D, either directly
in
hardware (using vertex programs) or in software.
This patch makes NOLF2 demo crashes.
Register
dump:
CS:0073 SS:007b DS:007b ES:007b FS:0033
GS:003b
EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00
-RIZP1)
EAX:00ec1b28 EBX:7e6bbc54 ECX:014c
EDX:
ESI:0048
EDI:
Stack
dump:
0x0033f0b4:
3f80
0x0033f0c4: 0033f110 7d05e000 7c03d008
7c7aa346
0x0033f0d4: 0003 7e6bc7a0
7e69ee95
0x0033f0e4: 7e69e648 0001 000c
0010
0x0033f0f4: 795a5f68 7d09c0ac 0002d008
00ebd44c
0x0033f104: 00eba698 00ebd7a8
0007
Backtrace:
=0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c,
NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2,
minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307]
in wined3d (0x0033f1ec)
1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4,
NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=is not
available, idxData=(nil), minIndex=0)
[/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d
(0x0033f55c)
2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive
+0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST,
minIndex=0, NumVertices=24, startIndex=0, primCount=24)
[/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc)
3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive
+0x96(iface=register ESI not in topmost frame,
PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24,
startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419]
in d3d8
(0x0033f5fc)
0x7e6095c7 drawStridedSlow+0x697
[/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds
0x0(%ecx)
307 m =
stateBlock-transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] :
0))].u.m[0][0];
Modules:
Really strange! Tested the patch against other games and it worked.
With NOLF2 I'm getting a crash too, but at a different location:
1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4,
NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2,
idxData=0x3d871e0, minIndex=0)
[/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d
(0x)
0x7d2b3771: movl0x0(%ecx),%edx
540 for (texture = 0; tmp_tex_mask; tmp_tex_mask = 1, ++texture)
--
Claudio Ciccani
k...@users.sf.net
k...@directfb.org
http://directfb.org
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 478c216..7b2a010 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -3387,8 +3387,13 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter,
pCaps-MaxUserClipPlanes = GL_LIMITS(clipplanes);
pCaps-MaxActiveLights = GL_LIMITS(lights);
-pCaps-MaxVertexBlendMatrices = GL_LIMITS(blends);
-pCaps-MaxVertexBlendMatrixIndex = 0;
+if (GL_SUPPORT(ARB_VERTEX_BLEND)) {
+pCaps-MaxVertexBlendMatrices= GL_LIMITS(blends);
+pCaps-MaxVertexBlendMatrixIndex = 0;
+} else {
+pCaps-MaxVertexBlendMatrices= 4;
+pCaps-MaxVertexBlendMatrixIndex = 255;
+}
pCaps-MaxAnisotropy = GL_LIMITS(anisotropy);
pCaps-MaxPointSize= GL_LIMITS(pointsize);
Re: [PATCH] wineps.drv: Add a simple implementation of PSDRV_SelectBitmap.
Lei Zhang thes...@google.com writes: Hi, This fixes bug 17103 for me. I'm not sure if PSDRV_SelectBitmap() need to do more, but this is a start and it's better than a stub. If it doesn't do more, then removing it completely should work just as well. There doesn't seem to be much point in just storing the bitmap, this is easy to retrieve when needed. -- Alexandre Julliard julli...@winehq.org
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens paul.vriens.w...@gmail.com Sent: Jan 26, 2009 4:45 AM To: wine-devel@winehq.org wine-devel@winehq.org Subject: Bugzilla question with respect to .NET 1.1SP1 Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. James McKenzie
Re: Bugzilla question with respect to .NET 1.1SP1
James Mckenzie wrote: Paul Vriens paul.vriens.w...@gmail.com Sent: Jan 26, 2009 4:45 AM To: wine-devel@winehq.org wine-devel@winehq.org Subject: Bugzilla question with respect to .NET 1.1SP1 Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. James McKenzie So that means bug 14850 needs to be reopened with a link to 13995? -- Cheers, Paul.
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens paul.vriens.w...@gmail.com wrote: Sent: Jan 26, 2009 7:10 AM To: James Mckenzie jjmckenzi...@earthlink.net Cc: wine-devel@winehq.org wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1 James Mckenzie wrote: Paul Vriens paul.vriens.w...@gmail.com Sent: Jan 26, 2009 4:45 AM To: wine-devel@winehq.org wine-devel@winehq.org Subject: Bugzilla question with respect to .NET 1.1SP1 Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995). Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. James McKenzie So that means bug 14850 needs to be reopened with a link to 13995? If the problem may be outside of .NET 1.1 SP1, yes. If not, then the answer is no. I'll have to look at the two bug reports and see if they are related and true duplicates. James McKenzie
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. -- Alexandre Julliard julli...@winehq.org
Re: Bugzilla question with respect to .NET 1.1SP1
Alexandre Julliard wrote: Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. Only a comment will not increase the 'popularity' of a bug though. How do we determine the priority of such a bug? (Or don't we deal with priorities anyway?). -- Cheers, Paul.
Re: Bugzilla question with respect to .NET 1.1SP1
Paul Vriens paul.vriens.w...@gmail.com writes: Alexandre Julliard wrote: Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. Only a comment will not increase the 'popularity' of a bug though. How do we determine the priority of such a bug? (Or don't we deal with priorities anyway?). We don't really, and a separate bug which will be closed as duplicate wouldn't help anyway. If there is evidence that it affects a lot of apps you can make the severity major. -- Alexandre Julliard julli...@winehq.org
Re: Bugzilla question with respect to .NET 1.1SP1
Alexandre Julliard wrote: Paul Vriens paul.vriens.w...@gmail.com writes: Alexandre Julliard wrote: Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. Only a comment will not increase the 'popularity' of a bug though. How do we determine the priority of such a bug? (Or don't we deal with priorities anyway?). We don't really, and a separate bug which will be closed as duplicate wouldn't help anyway. If there is evidence that it affects a lot of apps you can make the severity major. OK, fair enough. I'll just have this already existing bug linked to from the appdb then. -- Cheers, Paul.
Was: Fwd: wine-bugs Digest, Vol 42, Issue 330
It wasn't easy to fish out the Information in this one *hint* :) On Tue, Jan 13, 2009 at 10:07:42AM -0600, Austin English wrote: --- Comment #5 from Dmitry Timoshkov dmi...@codeweavers.com 2009-01-13 08:40:35 --- REMIND is not an appropriate resolution in Wine bugzilla. --- Comment #6 from Maki mak...@gmail.com 2009-01-13 08:45:36 --- Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. Resolutions (their displayed names) can be edited in bugzilla. New ones can be added. Some of them can also be deleted, REMIND and LATER are among them. Jan
Re: Bugzilla question with respect to .NET 1.1SP1
Alexandre Julliard julli...@winehq.org Sent: Jan 26, 2009 7:21 AM To: Paul Vriens paul.vriens.w...@gmail.com Cc: James Mckenzie jjmckenzi...@earthlink.net, wine-devel@winehq.org wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1 Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. What do you say about doing this? James McKenzie
Re: Bugzilla question with respect to .NET 1.1SP1
On Mon, Jan 26, 2009 at 12:34 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: Alexandre Julliard julli...@winehq.org Sent: Jan 26, 2009 7:21 AM To: Paul Vriens paul.vriens.w...@gmail.com Cc: James Mckenzie jjmckenzi...@earthlink.net, wine-devel@winehq.org wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1 Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. What do you say about doing this? James McKenzie That's messy. Have them cc themselves to the original bug, and when its fixed, retest. No need to file a bug only to close it immediately as a duplicate. If, however, you're able to workaround that bug, then make a new bug, and have the second depend on the first. E.g., program foo needs native gdiplus and native richedit to install. File bug for gdiplus problem, then file a second one for richedit, marking it as depending on the gdiplus bug. -- -Austin
Re: Bugzilla question with respect to .NET 1.1SP1
Austin English austinengl...@gmail.com wrote: Sent: Jan 26, 2009 11:48 AM To: James Mckenzie jjmckenzi...@earthlink.net Cc: Alexandre Julliard julli...@winehq.org, Paul Vriens paul.vriens.w...@gmail.com, wine-devel@winehq.org wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1 On Mon, Jan 26, 2009 at 12:34 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: Alexandre Julliard julli...@winehq.org Sent: Jan 26, 2009 7:21 AM To: Paul Vriens paul.vriens.w...@gmail.com Cc: James Mckenzie jjmckenzi...@earthlink.net, wine-devel@winehq.org wine-devel@winehq.org Subject: Re: Bugzilla question with respect to .NET 1.1SP1 Paul Vriens paul.vriens.w...@gmail.com writes: So that means bug 14850 needs to be reopened with a link to 13995? No, if it's the same bug it should be a single report. If .NET doesn't install then obviously all apps that try to install it will be broken, it doesn't make sense to create a separate bug for each app that suffers from the problem. Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. What do you say about doing this? James McKenzie That's messy. Have them cc themselves to the original bug, and when its fixed, retest. No need to file a bug only to close it immediately as a duplicate. I realize it's ugly, but I'm thinking like a software tester not a developer. If I found three bugs in a program, I opened three bugs. If I found the same bug in a different program, I opened a second bug and attached it to the first. If, however, you're able to workaround that bug, then make a new bug, and have the second depend on the first. E.g., program foo needs native gdiplus and native richedit to install. File bug for gdiplus problem, then file a second one for richedit, marking it as depending on the gdiplus bug. What if the richedit bug is fixed first? Would it be impossible to test to see if the bug is fixed? If that were the case, then this is a correct scenario. If the richedit bug can be tested independently of the gdiplus bug, then this scenario is incorrect. If the gdiplug bug depends on the richedit bug being fixed first, then the linkage should be reversed. Linking two separate bugs in this case may not pass the sense test. There has to be an added, simple mechanism where a user (not a developer, or triage) can add to a list of applications affected by a specific bug. See above for what I consider a bug, this is a single application affected by a single problem. Linking together independent bugs needs to be done in a rational manner. If three applications are affected by the same bug, then they either should be linked together, reported under one bug with additional votes for the added applications and users with an updated description, or held as separate bug reports. Sorry to be so long winded about this, but proper bug reporting was and still is my primary business. James McKenzie
re: advapi32: Fix potential NULL pointer dereference in LookupPrivilegeNameW [with test] (Saturn)
Cool, I didn't know about Saturn. I've updated http://wiki.winehq.org/StaticAnalysis with info about it. Offhand it looks like neither of these were caught by Coverity...?
Re: Bugzilla question with respect to .NET 1.1SP1
On Mon, Jan 26, 2009 at 1:03 PM, James Mckenzie jjmckenzi...@earthlink.net wrote: Austin English austinengl...@gmail.com wrote: That's messy. Have them cc themselves to the original bug, and when its fixed, retest. No need to file a bug only to close it immediately as a duplicate. I realize it's ugly, but I'm thinking like a software tester not a developer. If I found three bugs in a program, I opened three bugs. If I found the same bug in a different program, I opened a second bug and attached it to the first. Different bugs deserve different reports, yes. But the same bug in different program does not. Wine already has thousands of bugs, we don't need more frivolous ones. If, however, you're able to workaround that bug, then make a new bug, and have the second depend on the first. E.g., program foo needs native gdiplus and native richedit to install. File bug for gdiplus problem, then file a second one for richedit, marking it as depending on the gdiplus bug. What if the richedit bug is fixed first? Would it be impossible to test to see if the bug is fixed? If that were the case, then this is a correct scenario. If the richedit bug can be tested independently of the gdiplus bug, then this scenario is incorrect. If the gdiplug bug depends on the richedit bug being fixed first, then the linkage should be reversed. Linking two separate bugs in this case may not pass the sense test. Perhaps that was unclear. A bit better of an explanation: I go to install Adobe reader. Installer immediately exits because of a problem with gdiplus. I file a bug for gdiplus problem, then run 'winetricks -q gdiplus'. Next up, the EULA is blank. I see it's a problem with richedit, file a bug, and solve it with 'winetricks -q riched20'. Carry on with installer, and use the app for it's intended purpose. I'd then mark the richedit bug as depending on the gdiplus bug. There has to be an added, simple mechanism where a user (not a developer, or triage) can add to a list of applications affected by a specific bug. That's the purpose of the AppDB, for knowing what bugs affect a program, how to work around them, etc. Bugzilla is for reporting and fixing bugs. See above for what I consider a bug, this is a single application affected by a single problem. Linking together independent bugs needs to be done in a rational manner. If three applications are affected by the same bug, then they either should be linked together, reported under one bug with additional votes for the added applications and users with an updated description, or held as separate bug reports. Understandable, but keep in mind that few people triage most bugs. Dmitry, Vitaliy and myself seem to be ones most often triaging bugs. Dan, Juan, Hans, Lei and others (no offense to those left out) help quite a bit as well. I encourage you to subscribe to wine-bugs for a while and triage all the bug reports. Once you get a sense of all the duplicates, you'll understand my viewpoint better. Especially when something like the 1.1.12 regressions occur. Sorry to be so long winded about this, but proper bug reporting was and still is my primary business. Again, understandable, but this is Wine's Bugzilla, not crossover's. It's a volunteer project, and Bugzilla is not there to track every bug in every app, but rather to track each bug in Wine...a subtle, yet important, difference. The AppDB is great for these sorts of things. If a bug affects multiple apps, list it there. Most people search AppDB for getting their app to run, not Bugzilla. They can always add a comment to the bug saying it affect X app as well. For those bugs, the summary can (and usually is) adjusted accordingly. -- -Austin
Re: Two simple fixes for ListView
On Mon, Jan 26, 2009 at 4:29 PM, Michael James james...@gmail.com wrote: Here are two simple fixes before I attempt anything more complex here. Michael James From d978eb3c3eff3b44fce6257892749c2c1c34277d Mon Sep 17 00:00:00 2001 From: Michael James james...@gmail.com Date: Sun, 25 Jan 2009 20:09:33 -0800 Subject: [PATCH 1/2] Added logic to eliminate a valgrind warning in LISTVIEW_GetItemExtT The original code used correct but somewhat obscure logic. Added a test to avoid testing uninitialized pointer for pszText when LVIF_TEXT is not indicated in the flags. With this change, the code functions identically to what it was doing before but will not cause a warning from valgrind. --- dlls/comctl32/listview.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c index 172925f..f28a70e 100644 --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -5685,7 +5685,7 @@ static BOOL LISTVIEW_GetItemExtT(const LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVIte pszText = lpLVItem-pszText; bResult = LISTVIEW_GetItemT(infoPtr, lpLVItem, isW); -if (bResult lpLVItem-pszText != pszText) +if (bResult (lpLVItem-mask LVIF_TEXT) lpLVItem-pszText != pszText) textcpynT(pszText, isW, lpLVItem-pszText, isW, lpLVItem-cchTextMax); lpLVItem-pszText = pszText; -- 1.6.1 From 8f05ae1ceca1b787f09ede7e7ab0883ee38c63b9 Mon Sep 17 00:00:00 2001 From: Michael James james...@gmail.com Date: Sun, 25 Jan 2009 21:09:42 -0800 Subject: [PATCH 2/2] Defined missing macro ListView_GetCheckState --- include/commctrl.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/commctrl.h b/include/commctrl.h index 426d70a..9cea03c 100644 --- a/include/commctrl.h +++ b/include/commctrl.h @@ -3715,6 +3715,8 @@ typedef struct NMLVSCROLL SNDMSGA(hwnd, LVM_SETITEMSTATE, (WPARAM)(UINT)i, (LPARAM) (LPLVITEMA)_LVi);} #define ListView_GetItemState(hwnd,i,mask) \ (BOOL)SNDMSGA((hwnd),LVM_GETITEMSTATE,(WPARAM)(UINT)(i),(LPARAM)(UINT)(mask)) +#define ListView_GetCheckState(hwnd,i) \ +((ListView_GetItemState(hwnd,i,LVIS_STATEIMAGEMASK)12)-1) #define ListView_GetCountPerPage(hwnd) \ (BOOL)SNDMSGW((hwnd),LVM_GETCOUNTPERPAGE,0,0L) #define ListView_GetImageList(hwnd,iImageList) \ -- 1.6.1 One patch per e-mail please. -- -Austin
[RFC] msvcrt: Implement _mbcjistojms
Hello, This function is supposed to convert a jis-encoded (Japanese) character to sjis encoding. I think I botched my last attempt up in more than one way so I've now reworked it slightly and thought I'd try again, but perhaps I should first ask if there is anything else obviously wrong with it. For example, the implementation is a bit of a (as far as I can tell working) black box, and the test of it basically tests two different things depending on the codepage, which I am not sure is a good thing. A very insignificant patch perhaps, but all comments are welcome. :) -- David 0001-msvcrt-Implement-_mbcjistojms.patch Description: Binary data
Making the file dialog resizable(implementing OFN_ENABLESIZING)
Hi,
The attached patch fixes the bug at
http://bugs.winehq.org/show_bug.cgi?id=10394 , can you have a look at it.
It's pretty much done except for some nasty bug and the repainting problem.
--
Regards,
Diaa Sami
diff --git a/dlls/comdlg32/filedlg.c b/dlls/comdlg32/filedlg.c
index a2826c8..bdfe5fa 100644
--- a/dlls/comdlg32/filedlg.c
+++ b/dlls/comdlg32/filedlg.c
@@ -37,7 +37,7 @@
* FIXME: add to recent docs
*
* FIXME: flags not implemented: OFN_DONTADDTORECENT,
- * OFN_ENABLEINCLUDENOTIFY, OFN_ENABLESIZING,
+ * OFN_ENABLEINCLUDENOTIFY,
* OFN_NODEREFERENCELINKS, OFN_NOREADONLYRETURN,
* OFN_NOTESTFILECREATE, OFN_USEMONIKERS
*
@@ -83,7 +83,7 @@ WINE_DEFAULT_DEBUG_CHANNEL(commdlg);
#define UNIMPLEMENTED_FLAGS \
(OFN_DONTADDTORECENT |\
-OFN_ENABLEINCLUDENOTIFY | OFN_ENABLESIZING |\
+OFN_ENABLEINCLUDENOTIFY |\
OFN_NODEREFERENCELINKS | OFN_NOREADONLYRETURN |\
OFN_NOTESTFILECREATE /*| OFN_USEMONIKERS*/)
@@ -979,6 +979,84 @@ static INT_PTR FILEDLG95_HandleCustomDialogMessages(HWND hwnd, UINT uMsg, WPARAM
return TRUE;
}
+static BOOL ScreenToClientR(HWND hwnd, LPRECT r)
+{
+POINT tl = {r-left, r-top};
+POINT br = {r-right, r-bottom};
+
+const BOOL success1 = ScreenToClient(hwnd, tl);
+const BOOL success2 = ScreenToClient(hwnd, br);
+
+if (!success1 || !success2)
+return FALSE;
+
+r-left = tl.x;
+r-right = br.x;
+r-top = tl.y;
+r-bottom = br.y;
+
+return TRUE;
+}
+
+/* Resizing flags, similar in functionality to .NET anchors */
+static const UINT32 PIN_LEFT = (2 0);
+static const UINT32 PIN_RIGHT = (2 1);
+static const UINT32 PIN_TOP = (2 2);
+static const UINT32 PIN_BOTTOM= (2 3);
+
+static void Resize(HWND hwnd, HWND parent, const POINT *sizeDifference, UINT flags)
+{
+RECT curRect;
+RECT newRect;
+
+TRACE(Resizing %x with parent %x\n, hwnd, parent);
+
+GetWindowRect(hwnd, curRect);
+TRACE(curRect(screen) is %d %d %d %d\n, curRect.left, curRect.top, curRect.right, curRect.bottom);
+ScreenToClientR(parent, curRect);
+TRACE(curRect(client) is %d %d %d %d\n, curRect.left, curRect.top, curRect.right, curRect.bottom);
+
+newRect = curRect;
+
+if ((flags PIN_RIGHT) (flags PIN_LEFT))
+{
+newRect.right += sizeDifference-x;
+}
+else
+{
+if (flags PIN_RIGHT)
+{
+newRect.right += sizeDifference-x;
+newRect.left += sizeDifference-x;
+}
+
+if (flags PIN_LEFT)
+{
+}
+}
+
+if ((flags PIN_TOP) (flags PIN_BOTTOM))
+{
+newRect.bottom += sizeDifference-y;
+}
+else
+{
+if (flags PIN_BOTTOM)
+{
+newRect.bottom += sizeDifference-y;
+newRect.top += sizeDifference-y;
+}
+
+if (flags PIN_TOP)
+{
+}
+}
+
+TRACE(newRect is %d %d %d %d\n, newRect.left, newRect.top, newRect.right, newRect.bottom);
+
+MoveWindow(hwnd, newRect.left, newRect.top, newRect.right - newRect.left, newRect.bottom - newRect.top, TRUE);
+}
+
/***
* FileOpenDlgProc95
*
@@ -995,6 +1073,12 @@ INT_PTR CALLBACK FileOpenDlgProc95(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM l
case WM_INITDIALOG:
{
FileOpenDlgInfos * fodInfos = (FileOpenDlgInfos *)lParam;
+
+ if (fodInfos-ofnInfos-Flags OFN_ENABLESIZING)
+ {
+ SetWindowLongW(hwnd, GWL_STYLE, GetWindowLongW(hwnd, GWL_STYLE) | WS_SIZEBOX);
+ FIXME(Draw the grip which indicates that the file dialog is resizable\n);
+ }
/* Adds the FileOpenDlgInfos in the property list of the dialog
so it will be easily accessible through a GetPropA(...) */
@@ -1011,6 +1095,19 @@ INT_PTR CALLBACK FileOpenDlgProc95(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM l
SendCustomDlgNotificationMessage(hwnd,CDN_INITDONE);
SendCustomDlgNotificationMessage(hwnd,CDN_FOLDERCHANGE);
SendCustomDlgNotificationMessage(hwnd,CDN_SELCHANGE);
+
+ if (fodInfos-DlgInfos.currentClientSize.x == 0 ||
+ fodInfos-DlgInfos.currentClientSize.y == 0)
+ {
+ RECT r;
+ GetClientRect(hwnd, r);
+
+ fodInfos-DlgInfos.currentClientSize.x = r.right;
+ fodInfos-DlgInfos.currentClientSize.y = r.bottom;
+
+ TRACE(Initial size is %d %d\n, fodInfos-DlgInfos.currentClientSize.y, fodInfos-DlgInfos.currentClientSize.x);
+ }
+
return 0;
}
case WM_COMMAND:
@@ -1072,6 +1169,68 @@ INT_PTR CALLBACK FileOpenDlgProc95(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM l
}
return FALSE;
}
+
+case WM_SIZE:
+{
+FileOpenDlgInfos *const fodInfos = GetPropA(hwnd,FileOpenDlgInfosStr);
+const POINT prevDlgClientSize =
Re: Re: Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/26 Claudio Ciccani k...@users.sf.net I found that the reason of the crash was that VBOs were not removed when using drawStridedSlow for vertex blending. Attached is the modified patch, which doesn't make NOLF2 crash. Il giorno lun, 26/01/2009 alle 12.12 +0100, Claudio Ciccani ha scritto: Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto: 2009/1/25 Claudio Ciccani k...@users.sf.net The patch implements a software fallback for vertex blending in drawStridedSlow, fixing Bug #6955. Although vertex blending is an old and outdated extension, there are still many applications(games) relying on it nowadays. This because the extension is generally supported by Direct3D, either directly in hardware (using vertex programs) or in software. This patch makes NOLF2 demo crashes. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 -RIZP1) EAX:00ec1b28 EBX:7e6bbc54 ECX:014c EDX: ESI:0048 EDI: Stack dump: 0x0033f0b4: 3f80 0x0033f0c4: 0033f110 7d05e000 7c03d008 7c7aa346 0x0033f0d4: 0003 7e6bc7a0 7e69ee95 0x0033f0e4: 7e69e648 0001 000c 0010 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 00ebd44c 0x0033f104: 00eba698 00ebd7a8 0007 Backtrace: =0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d (0x0033f1ec) 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=is not available, idxData=(nil), minIndex=0) [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d (0x0033f55c) 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive +0x96(iface=register ESI not in topmost frame, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] in d3d8 (0x0033f5fc) 0x7e6095c7 drawStridedSlow+0x697 [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds 0x0(%ecx) 307 m = stateBlock-transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : 0))].u.m[0][0]; Modules: Really strange! Tested the patch against other games and it worked. With NOLF2 I'm getting a crash too, but at a different location: 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4, NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2, idxData=0x3d871e0, minIndex=0) [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d (0x) 0x7d2b3771: movl0x0(%ecx),%edx 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask = 1, ++texture) -- Claudio Ciccani k...@users.sf.net k...@directfb.org http://directfb.org Great, the patch works like a charm. I hope that it will bw accepted by D3D gurus and Alexandre . David
Making the file dialog resizable(implementing OFN_ENABLESIZING)
Hi, Can you please have a look at the patch at http://bugs.winehq.org/show_bug.cgi?id=10394 ? It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami
Making the file dialog resizable(implementing OFN_ENABLESIZING)
Hi, Can you please have a look at the patch at http://bugs.winehq.org/show_bug.cgi?id=10394 ? It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami
Re: gdi32: Implement QueryFontAssocStatus
Again... What's the problem? 2009-01-20 (Tue), 06:39 +0900, Byeongsik Jeon wrote: 2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: QueryFontAssocStatus() is the undocumented function. This is a base patch for bug#16325. http://bugs.winehq.org/show_bug.cgi?id=16325 Hmm... What is the problem of this patch? --- dlls/gdi32/font.c| 12 +++ dlls/gdi32/freetype.c| 66 ++ dlls/gdi32/gdi32.spec|2 +- dlls/gdi32/gdi_private.h |1 + dlls/gdi32/tests/Makefile.in |2 +- dlls/gdi32/tests/font.c | 63 include/wingdi.h |1 + 7 files changed, 145 insertions(+), 2 deletions(-)
Re: Making the file dialog resizable(implementing OFN_ENABLESIZING)
Sorry for the multiple posts, happened by mistake.
Re: [REGRESSION] Fix dlls/iphlpapi/ipstats.c on FreeBSD 6.4/i386
On Mon, Jan 26, 2009 at 5:43 PM, Gerald Pfeifer ger...@pfeifer.com wrote: After Austin's recent changes (that were committed in the last 24h), Wine no longer builds for me on FreeBSD 6.4/i386 with the following failure mode. In file included from ipstats.c:71: /usr/include/netinet/ip.h:160: error: expected specifier-qualifier-list before 'n_long' gmake[2]: *** [ipstats.o] Error 1 gmake[2]: Leaving directory `/sw/test/Wine/dlls/iphlpapi' gmake[1]: *** [iphlpapi] Error 2 gmake[1]: Leaving directory `/sw/test/Wine/dlls' gmake: *** [dlls] Error 2 The patch below fixes this. Gerald ChangeLog: Move #include netinet/in_systm.h before #include netinet/ip.h to fix FreeBSD 6.4. Index: dlls/iphlpapi/ipstats.c === RCS file: /home/wine/wine/dlls/iphlpapi/ipstats.c,v retrieving revision 1.43 diff -u -3 -p -r1.43 ipstats.c --- dlls/iphlpapi/ipstats.c 23 Jan 2009 16:07:29 - 1.43 +++ dlls/iphlpapi/ipstats.c 26 Jan 2009 22:42:34 - @@ -67,6 +67,9 @@ #ifdef HAVE_NETINET_IF_INARP_H #include netinet/if_inarp.h #endif +#ifdef HAVE_NETINET_IN_SYSTM_H +#include netinet/in_systm.h +#endif #ifdef HAVE_NETINET_IP_H #include netinet/ip.h #endif @@ -88,9 +91,6 @@ #ifdef HAVE_NETINET_TCP_VAR_H #include netinet/tcp_var.h #endif -#ifdef HAVE_NETINET_IN_SYSTM_H -#include netinet/in_systm.h -#endif #ifdef HAVE_NETINET_IP_ICMP_H #include netinet/ip_icmp.h #endif I've already sent a patch for this: http://www.winehq.org/pipermail/wine-patches/2009-January/068396.html -- -Austin
Re: [PATCH] ddrawex: use stack ctx instead of uninitialized variable
On Mon, Jan 26, 2009 at 11:06 AM, Marcus Meissner meiss...@suse.de wrote:
---
dlls/ddrawex/ddraw.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dlls/ddrawex/ddraw.c b/dlls/ddrawex/ddraw.c
index b581529..6607c78 100644
--- a/dlls/ddrawex/ddraw.c
+++ b/dlls/ddrawex/ddraw.c
@@ -678,11 +678,11 @@ IDirectDraw4Impl_EnumSurfaces(IDirectDraw4 *iface,
LPDDENUMSURFACESCALLBACK2 Callback)
{
IDirectDrawImpl *This = impl_from_dd4(iface);
-struct enumsurfaces4_ctx *ctx;
+struct enumsurfaces4_ctx ctx;
TRACE((%p)-(0x%08x,%p,%p,%p)\n, This, Flags, DDSD, Context, Callback);
-ctx-orig_cb = Callback;
-ctx-orig_ctx = Context;
+ctx.orig_cb = Callback;
+ctx.orig_ctx = Context;
return IDirectDraw4Impl_EnumSurfaces(This-parent, Flags, DDSD, ctx,
enum_surfaces_wrapper);
}
--
1.6.0.2
This fixes Coverity 867. Pointing out so that AJ can add that to the
patch title, so we can find it in the git log :-).
--
-Austin
Re: gdi32: Implement QueryFontAssocStatus
i don't know what might be wrong, but in case noone answers you: maybe divide this in much smaller patches? this way you can easily pinpoint areas where the problem is, because the patch is quite big. or you could try pinging julliard by mail or on IRC... regards, ricardo -- From: Byeongsik Jeon bsj...@hanmail.net Sent: Monday, January 26, 2009 11:33 PM To: wine-devel@winehq.org Subject: Re: gdi32: Implement QueryFontAssocStatus Again... What's the problem? 2009-01-20 (Tue), 06:39 +0900, Byeongsik Jeon wrote: 2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: QueryFontAssocStatus() is the undocumented function. This is a base patch for bug#16325. http://bugs.winehq.org/show_bug.cgi?id=16325 Hmm... What is the problem of this patch? --- dlls/gdi32/font.c| 12 +++ dlls/gdi32/freetype.c| 66 ++ dlls/gdi32/gdi32.spec|2 +- dlls/gdi32/gdi_private.h |1 + dlls/gdi32/tests/Makefile.in |2 +- dlls/gdi32/tests/font.c | 63 include/wingdi.h |1 + 7 files changed, 145 insertions(+), 2 deletions(-)
Re: [PATCH] wineps.drv: Add a simple implementation of PSDRV_SelectBitmap.
On Mon, Jan 26, 2009 at 6:03 AM, Alexandre Julliard julli...@winehq.org wrote: Lei Zhang thes...@google.com writes: Hi, This fixes bug 17103 for me. I'm not sure if PSDRV_SelectBitmap() need to do more, but this is a start and it's better than a stub. If it doesn't do more, then removing it completely should work just as well. There doesn't seem to be much point in just storing the bitmap, this is easy to retrieve when needed. I looked a bit further, and it turns out PSDRV_SelectBitmap() returning only 0 will cause BITMAP_SelectObject() to not set dc-hBitmap (around line 609) and this is what's causing the print problem. I'm not using the HBITMAP, but simply storing it so PSDRV_SelectBitmap() can return a reasonable value. It looks like I can also fix the problem by not exporting a SelectBitmap() function from wineps.drv.
Re: Wine menu creation questions
Reece Dunn wrote: Along similar lines, building on what Owen said in the talk that if all goes well Jane user will not notice that she is using Wine to run her Windows software: why is there an entry in the Applications section that says 'Wine' (and why does it have the folder icon and not the Wine icon)! It would be better if this said something like Program Files, replacing Wine Programs -- this removes a level of indirection and gives the user something that they are familiar with and is more discoverable than 'Wine'. It has the Wine icon on Ubuntu. Currently, it houses the Programs submenu and 3 other menu items (Uninstall Wine Software, Configure Wine, and Browse C:\ Drive). Ideally, we'd get rid of all 3 of these: Uninstall would be integrated into Add/Remove Programs, Configure Wine would be done through system-preferences and by right click-properties on applications, and Browse C:\ Drive would be in the Places menu. Once those are gone, then we can move things up one step - instead of Applications-Wine-Programs, we'd just have Applications-Wine Programs. One open question: what to do with Windows apps that don't put themselves in Program Files, but rather put themselves at the top of the start menu? Thanks, Scott Ritchie
Is there a way to set Z:\ as the whatever user's home folder?
I want to have a read-only wine prefix that multiple users might access, however I also want to have a Z:\ drive that refers to a dynamic location - a folder inside the current user's home folder. This isn't possible as far as I can tell, as Wine requires a symlink to the folder in the prefix's dosdevices directory, and a symlink can only point to a static file. Assuming this is possible, are there any downsides to using this read-only prefix? Assume for a moment that the application doesn't need write access to the registry or to its own folder. Thanks, Scott Ritchie
Re: Is there a way to set Z:\ as the whatever user's home folder?
2009/1/27 Scott Ritchie sc...@open-vote.org: I want to have a read-only wine prefix that multiple users might access, however I also want to have a Z:\ drive that refers to a dynamic location - a folder inside the current user's home folder. This isn't possible as far as I can tell, as Wine requires a symlink to the folder in the prefix's dosdevices directory, and a symlink can only point to a static file. Symlinks can be relative. Note that C: in winecfg points to ../drive_c by default. However, I don't think Wine supports dynamic paths in drives. Assuming this is possible, are there any downsides to using this read-only prefix? Assume for a moment that the application doesn't need write access to the registry or to its own folder. One way you could do it would be to symlink C: to a shared location instead of the whole prefix. You'd likely want to link/symlink the registry too. This way, you could have H: dynamically set for each user.
