February 2007 - Wine-Devel - list.winehq.org

Re: 0.9.31 not suitable for gaming

by Pavel Troller

> > > trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was > > 90000000,00000008, setting to 90080000,00000008 > > trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8) > This here seems strange. If you compare that to the good log you'll see that > IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a > possible reason for the abortion I think that somewhere an exception is > thrown, caught by the game which terminates afterwards. Doesn't seem so. See below. > > You can do the following: > -> Run the game in winedbg and see if it catches the execption and gives a > backtrace and crash position There is no such exception, at least winedbg doesn't catch any. Is a special action (command etc.) > -> Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the > last line that is exectuted successfully. Hmm... I added some traces to device.c. We know that last known trace from Init3D in the bad case is "Creating implicit swapchain." I added a new trace here: /* Setup the implicit swapchain */ TRACE("Creating implicit swapchain\n"); if (D3D_OK != D3DCB_CreateAdditionalSwapChain((IUnknown *) This->parent, pPresentationParameters, (IWineD3DSwapChain **)&swapchain) || swapchain == NULL) { WARN("Failed to create implicit swapchain\n"); return WINED3DERR_INVALIDCALL; } TRACE("1674\n"); (it's on line 1674) and this one was NOT reached. I'm a bit confusd because I failed to find the code for D3DCB_CreateAdditionalSwapChain(), I found only its call in device.c and its definition in wined3d_interface.h. So, what to do next ? With regards, Pavel Troller

Feb. 21, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Alexandre Julliard wrote: >> Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: >> >>> Alexandre Julliard wrote: >>>> Yes, but duplicate_handle has no reason to call get_handle on the dst >>> Sure there is. How else do I set the requested access mask? >> >> By creating the handle with the correct mask right away, instead of >> setting a wrong mask and patching it up afterwards. > > That can only be done if permissions are not checked. I thought it was > clear from the tests that even when expressly prohibited, you can create > a handle with full access rights to the process if you can duplicate handle. > I tried to keep all the changes in the one place (duplicate_handle) and > not spread them around into create_handle. No, all the mess is because you added checks in alloc_handle (which is fine) then try to hack around them in duplicate_handle. What you should do is do the appropriate checks in duplicate_handle and then call alloc_entry directly. -- Alexandre Julliard julliard(a)winehq.org

Feb. 21, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> Alexandre Julliard wrote: >>> Yes, but duplicate_handle has no reason to call get_handle on the dst >> Sure there is. How else do I set the requested access mask? > > By creating the handle with the correct mask right away, instead of > setting a wrong mask and patching it up afterwards. That can only be done if permissions are not checked. I thought it was clear from the tests that even when expressly prohibited, you can create a handle with full access rights to the process if you can duplicate handle. I tried to keep all the changes in the one place (duplicate_handle) and not spread them around into create_handle. Vitaliy.

Feb. 21, 2007

Re: resend : gdi32:WidenPath partial implementation

by Alexandre Julliard

Laurent Vromman <laurent(a)vromman.org> writes: > + > + dc = DC_GetDCPtr( hdc ); You shouldn't need that, the caller has done it already. Simply pass a DC* to this function. > + if(pPath->state != PATH_Closed) { > + ERR("Path Closed\n"); > + return FALSE; > + } > + > + hPen = SelectObject(hdc, GetStockObject(DC_PEN)); You shouldn't select a new pen into the DC, just use the current one. > + case PT_BEZIERTO: > + // should never happen because of the FlattenPath call Please avoid C++ comments. > + default: > + ERR("Got path flag %d\n", (INT)pPath->pFlags[i]); Please avoid casts like this, use the correct printf format instead. -- Alexandre Julliard julliard(a)winehq.org

Feb. 21, 2007

Re: 0.9.31 not suitable for gaming

by Stefan Dösinger

> OK, did it. Sending two traces: A bad one, and a good one made by wine just > before the above commit. > With regards, Pavel Troller > trace:d3d:IWineD3DDeviceImpl_SetupFullscreenWindow Old style was > 90000000,00000008, setting to 90080000,00000008 > trace:ddraw:IDirectDrawImpl_FlipToGDISurface (0x19daf8) This here seems strange. If you compare that to the good log you'll see that IWineD3DDeviceImpl_Init3D was left way to early. As there is no ERR about a possible reason for the abortion I think that somewhere an exception is thrown, caught by the game which terminates afterwards. You can do the following: -> Run the game in winedbg and see if it catches the execption and gives a backtrace and crash position -> Add some extra traces(or ERRs) to Init3D and its subfunctions to catch the last line that is exectuted successfully.

Feb. 21, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Alexandre Julliard wrote: >> Yes, but duplicate_handle has no reason to call get_handle on the dst > Sure there is. How else do I set the requested access mask? By creating the handle with the correct mask right away, instead of setting a wrong mask and patching it up afterwards. -- Alexandre Julliard julliard(a)winehq.org

Feb. 21, 2007

Re: [Bug 7503] Eve Online pasword box on login screen doesn't work

by Frank Richter

On 21.02.2007 03:31, Dmitry Timoshkov wrote: > "Lei Zhang" <thestig(a)google.com> wrote: > >> Can we change wineprefixcreate to copy the truetype fonts (if any) from >> /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert >> distro specific X11/fonts/TTF directory] to >> $WINEPREFIX/drive_c/windows/fonts/ ? > > No. It's the distribution's duty to put ttf fonts in the path available > through the fontconfig APIs. Unless the game tries to read the .TTF file directly from the Windows\Fonts directory. (For e.g. "custom" rendering without GDI. I don't know if that's the case, but it's a possibility.) -f.r.

Feb. 20, 2007

Re: 0.9.31 not suitable for gaming

by Pavel Troller

> > > I don't know about this regression. Can you do a bisect? > > > > Yes, done. It's the following commit: > > > > commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc > > Author: Stefan DĂśsinger <stefan(a)codeweavers.com> > > Date: Wed Feb 14 17:59:08 2007 +0100 > > > > wined3d: More fullscreen window fixes. > > > > The game is run in a virtual desktop (i.e. it appears in the Linux window, > > not in full screen). > That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace? OK, did it. Sending two traces: A bad one, and a good one made by wine just before the above commit. With regards, Pavel Troller >

Feb. 20, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> http://source.winehq.org/source/server/handle.c#L523 calls >> duplicate_handle with NULL process. > > Yes, but duplicate_handle has no reason to call get_handle on the dst Sure there is. How else do I set the requested access mask? > process. I see that your 3/3 patch does this, but that's broken. Right that's the way it's designed by the original! I tried to explain the reason by I guess all that and tests are not enough. If you have a better solution, please implement it by all means. I have other things to worry about ATM. Vitaliy.

Feb. 20, 2007

Re: [Bug 7503] Eve Online pasword box on login screen doesn't work

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: > Can we change wineprefixcreate to copy the truetype fonts (if any) from > /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert > distro specific X11/fonts/TTF directory] to > $WINEPREFIX/drive_c/windows/fonts/ ? No. It's the distribution's duty to put ttf fonts in the path available through the fontconfig APIs. -- Dmitry.

Feb. 20, 2007

Re: [10/13] D3D9: Fix the circular converted vertex declaration reference

by Ivan Gyurdiev

H. Verbeet wrote: > On 20/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> If anyone knows a nicer way to release the converted declaration from >> SetVertexDeclaration feel free to comment. >> >> Not applying this patch won't affect patches 11-13 >> > Wouldn't it be better to directly compare This against convertedDecl > from the device in IDirect3DVertexDeclaration9Impl_Release, rather > than adding a convertedDecl flag to IDirect3DVertexDeclaration9Impl > and setting / unsetting it? I think it makes things harder than it has > to be. Also, afaik Ivan has some tests for the exact behaviour. "Some tests" attached. I cannot guarantee whether the tests make any sense or are correct (don't remember what I was trying to do , but maybe they'll be helpful :) The converted declaration is evil... I lost patience when trying to figure out the exact behavior, so decided to leave it broken, rather than fix it incorrectly. I think I wasn't sure whether the conversion happens on the setFVF call, or on the GetDeclaration call following it.

Feb. 20, 2007

Re: 0.9.31 not suitable for gaming

by Stefan Dösinger

Am Dienstag 20 Februar 2007 21:55 schrieb Pavel Troller: > Hi! > > > Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: > > > - Steam based games, mainly HL2: During game load, the screen goes > > > black. Moving the cursor causes sound effects as it hovers across the > > > menus and buttons, so the program runs, but nothing can be seen. > > > > This regression is known, and it should be fixed already. It was caused > > by my patch which made wined3d return an error if an unsupported query is > > created, like windows does. Wine does not support event queries, but many > > apps expect them to be supported. I have sent another patch(committed > > already) that re-enables the fake event queries. > > OK. This bug seems to be really fixed, but the game crashes later (during > the startup of the "real" game, after all the selections). It crashes in > its own code (called "Engine") but ntdll and kernel32 are visible in the > backtrace. I can send it exactly if it helps. I don't know how to bisect > this crash because the one initially mentioned is "masking" it. Yeah, I've introduced a new regression right after fixing the last one :-) Today's patches should fix it(and maybe bring a new breakage) > > > - Fallout Tactics (BOS.exe): Shows a dialog stating > > > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > > > Could not create display buffers" > > > and then another one about abnormal termination of the program and > > > quits. > > > > I don't know about this regression. Can you do a bisect? > > Yes, done. It's the following commit: > > commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc > Author: Stefan DĂśsinger <stefan(a)codeweavers.com> > Date: Wed Feb 14 17:59:08 2007 +0100 > > wined3d: More fullscreen window fixes. > > The game is run in a virtual desktop (i.e. it appears in the Linux window, > not in full screen). That is strange. Can you send be a +ddraw,+d3d8,+d3d9,+d3d trace?

Feb. 20, 2007

Re: [Bug 7503] Eve Online pasword box on login screen doesn't work

by Lei Zhang

Can we change wineprefixcreate to copy the truetype fonts (if any) from /usr/X11R6/lib/X11/fonts/TTF or /usr/share/X11/fonts/TTF or [insert distro specific X11/fonts/TTF directory] to $WINEPREFIX/drive_c/windows/fonts/ ? On 2/20/07, Wine Bugs <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=7503 > > > > > > ------- Additional Comments From kelfe(a)gmx.de 2007-20-02 16:57 ------- > to fix the issue you need to copy the font file arial.ttf into > .wine/drive_c/windows/fonts folder (.wine is a hidden folder) > > the arial.ttf can be found in the mscorefonts packages or search engine/windows box > > I don't know if font files should be placed in the fonts folder by wine or by > the user. So close this bug or keep it open until basic fonts are installed by > wine when creating the .wine folder. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > >

Feb. 20, 2007

Re: [10/13] D3D9: Fix the circular converted vertex declaration reference

by H. Verbeet

On 20/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > If anyone knows a nicer way to release the converted declaration from > SetVertexDeclaration feel free to comment. > > Not applying this patch won't affect patches 11-13 > Wouldn't it be better to directly compare This against convertedDecl from the device in IDirect3DVertexDeclaration9Impl_Release, rather than adding a convertedDecl flag to IDirect3DVertexDeclaration9Impl and setting / unsetting it? I think it makes things harder than it has to be. Also, afaik Ivan has some tests for the exact behaviour.

Feb. 20, 2007

Re: [6/13]D3D: Index buffer fixes

by Mirek

Some games are still broken with latest 13 patches from your tree. Oblivion still hangs while loading game and Flatout 2 crashed after 2 seconds with this output: athlon64:/usr/games/flatout2# ./flatout2 fixme:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x17fe20) : stub, simulating 256MB for now, returning 256MB left fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub fixme:d3d:IWineD3DDeviceImpl_ValidateDevice (0x17fe20) : stub err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded fixme:wave:DBSB_MMAPLoop Can't access sound driver's buffer directly. err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE wine: Unhandled page fault on read access to 0x7c3a4270 at address 0x7c3a4270 (thread 0011), starting debugger... Unhandled exception: page fault on read access to 0x7c3a4270 in 32-bit code (0x7c3a4270). fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x17fe20) : stub Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7c3a4270 ESP:7b8cea60 EBP:7b8ceab8 EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:7c3be764 ECX:00000000 EDX:7b8cea90 ESI:7b8cea90 EDI:00010028 Stack dump: 0x7b8cea60: 00000000 00000000 00000000 00000000 0x7b8cea70: fffffffd 00000000 00000000 00000000 0x7b8cea80: 00000001 7ffd2000 00000018 7ef935ef 0x7b8cea90: 00000000 00000012 00000000 00000000 0x7b8ceaa0: 00002357 00000000 00000000 7efe5368 0x7b8ceab0: 0173fc34 7c3a41b0 7b8ceb58 7efc81bb Backtrace: =>1 0x7c3a4270 (0x7b8ceab8) 2 0x7efc81bb call_thread_func+0x3b(rtl_func=<register EDI not in topmost frame>, arg=<register ESI not in topmost frame>) [/root/.WineCVS/sources/cvswine/wine/dlls/ntdll/thread.c:371] in ntdll (0x7b8ceb58) 3 0x7efc8461 in ntdll (+0x48461) (0x7b8cf458) err:dbghelp:elf_load_debug_info_from_map Bad CRC for module (got aa34a405 while expecting ef5281d2) 4 0xb7df10bd start_thread+0x6d() in libpthread.so.0 (0x7b8cf4c8) err:dbghelp:elf_load_debug_info_from_map Bad CRC for module (got 61a1649a while expecting f01d3064) 5 0xb7d859ee __clone+0x5e() in libc.so.6 (0x00000000) 0x7c3a4270: -- no code accessible -- Modules: Module Address Debug info Name (83 modules) PE 400000-152e000 Deferred flatout2 PE 1740000-19a0000 Deferred d3dx9_30 ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7c663000-7c6ac000 Deferred dsound<elf> \-PE 7c670000-7c6ac000 \ dsound ELF 7c781000-7c7b3000 Deferred uxtheme<elf> \-PE 7c790000-7c7b3000 \ uxtheme ELF 7c7b3000-7c874000 Deferred libasound.so.2 ELF 7c87e000-7c893000 Deferred midimap<elf> \-PE 7c880000-7c893000 \ midimap ELF 7c893000-7c8be000 Deferred winealsa<elf> \-PE 7c8a0000-7c8be000 \ winealsa ELF 7cb5a000-7cb5f000 Deferred libxfixes.so.3 ELF 7cb5f000-7cb68000 Deferred libxcursor.so.1 PE 7cb70000-7cb85000 --none-- msacm32 ELF 7cb87000-7cb8a000 Deferred libxrandr.so.2 ELF 7cb8a000-7cb92000 Deferred libxrender.so.1 ELF 7cb92000-7cb95000 Deferred libxinerama.so.1 ELF 7cb98000-7cbb4000 Deferred imm32<elf> \-PE 7cba0000-7cbb4000 \ imm32 ELF 7d55e000-7d5ec000 Deferred winex11<elf> \-PE 7d570000-7d5ec000 \ winex11 ELF 7d650000-7d670000 Deferred libexpat.so.1 ELF 7d670000-7d69b000 Deferred libfontconfig.so.1 ELF 7d6ba000-7d724000 Deferred libfreetype.so.6 ELF 7d743000-7d769000 Deferred msacm32<elf> ELF 7d769000-7d7cd000 Deferred msvcrt<elf> \-PE 7d780000-7d7cd000 \ msvcrt ELF 7d835000-7d840000 Deferred libgcc_s.so.1 ELF 7d925000-7d927000 Deferred libnvidia-tls.so.1 ELF 7d927000-7e298000 Deferred libglcore.so.1 ELF 7e298000-7e29d000 Deferred libxdmcp.so.6 ELF 7e29d000-7e32d000 Deferred libglu.so.1 ELF 7e32d000-7e3c1000 Deferred libgl.so.1 ELF 7e3c1000-7e4ad000 Deferred libx11.so.6 ELF 7e4ad000-7e4bb000 Deferred libxext.so.6 ELF 7e4bb000-7e4d3000 Deferred libice.so.6 ELF 7e4d3000-7e4dc000 Deferred libsm.so.6 ELF 7e4dc000-7e596000 Deferred wined3d<elf> \-PE 7e4f0000-7e596000 \ wined3d ELF 7e596000-7e5c1000 Deferred d3d9<elf> \-PE 7e5a0000-7e5c1000 \ d3d9 ELF 7e5c1000-7e5ed000 Deferred ws2_32<elf> \-PE 7e5d0000-7e5ed000 \ ws2_32 ELF 7e5ed000-7e6aa000 Deferred comctl32<elf> \-PE 7e600000-7e6aa000 \ comctl32 ELF 7e6aa000-7e6bd000 Deferred libresolv.so.2 ELF 7e6c6000-7e6da000 Deferred libz.so.1 ELF 7e6dc000-7e6fa000 Deferred iphlpapi<elf> \-PE 7e6e0000-7e6fa000 \ iphlpapi ELF 7e6fa000-7e74f000 Deferred rpcrt4<elf> \-PE 7e710000-7e74f000 \ rpcrt4 ELF 7e74f000-7e7e8000 Deferred ole32<elf> \-PE 7e760000-7e7e8000 \ ole32 ELF 7e7e8000-7e840000 Deferred shlwapi<elf> \-PE 7e800000-7e840000 \ shlwapi ELF 7e840000-7e935000 Deferred shell32<elf> \-PE 7e850000-7e935000 \ shell32 ELF 7e935000-7e97b000 Deferred advapi32<elf> \-PE 7e940000-7e97b000 \ advapi32 ELF 7e97b000-7ea0e000 Deferred gdi32<elf> \-PE 7e990000-7ea0e000 \ gdi32 ELF 7ea0e000-7eb48000 Deferred user32<elf> \-PE 7ea30000-7eb48000 \ user32 ELF 7eb48000-7ebd6000 Deferred winmm<elf> \-PE 7eb50000-7ebd6000 \ winmm ELF 7edd6000-7eefc000 Deferred kernel32<elf> \-PE 7edf0000-7eefc000 \ kernel32 ELF 7eefc000-7ef07000 Deferred libnss_files.so.2 ELF 7ef07000-7ef11000 Deferred libnss_nis.so.2 ELF 7ef11000-7ef27000 Deferred libnsl.so.1 ELF 7ef27000-7ef4c000 Deferred libm.so.6 ELF 7ef4c000-7ef4f000 Deferred libxau.so.6 ELF 7ef6b000-7f000000 Dwarf ntdll<elf> \-PE 7ef80000-7f000000 \ ntdll ELF b7cb0000-b7cb5000 Deferred libxxf86vm.so.1 ELF b7cb6000-b7cba000 Deferred libdl.so.2 ELF b7cba000-b7dec000 Export libc.so.6 ELF b7dec000-b7dfe000 Export libpthread.so.0 ELF b7e11000-b7e15000 Deferred iso8859-2.so ELF b7e15000-b7e1e000 Deferred libnss_compat.so.2 ELF b7e1e000-b7f2f000 Deferred libwine.so.1 ELF b7f31000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) G:\usr\games\flatout2\FlatOut2.exe 00000012 15 00000011 0 <== 00000010 0 0000000f 2 0000000e 15 0000000d 15 00000009 0 Stefan Dösinger napsal(a): > The ddraw index buffer handling needs a proper fix somewhen, either by an VB + > up Indices drawing method(but there are already too many of them) or my a > SetMem method in index buffers > > This patch should(hopefully) fix the regressions introduced with my former > index buffer patch > > > ------------------------------------------------------------------------ > > From fadece932e1ff556a4434545d7bf6753aaabdaf1 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Tue, 20 Feb 2007 16:15:04 +0100 > Subject: [PATCH] D3D: Index buffer fixes > > Some things that missed in my former patch. Do not unset the index buffer in _Release, that > is not needed. Dirtify the index buffer state in unlock because the bound buffer is changed. > GL vbos are GLuints. The index buffer used by ddraw should have dynamic usage, and preferably > be locked only on the size that has to be locked > --- > dlls/ddraw/device.c | 2 +- > dlls/ddraw/direct3d.c | 2 +- > dlls/wined3d/device.c | 2 +- > dlls/wined3d/indexbuffer.c | 9 +++++++-- > 4 files changed, 10 insertions(+), 5 deletions(-) > > diff --git a/dlls/ddraw/device.c b/dlls/ddraw/device.c > index c201df7..0814921 100644 > --- a/dlls/ddraw/device.c > +++ b/dlls/ddraw/device.c > @@ -3691,7 +3691,7 @@ IDirect3DDeviceImpl_7_DrawIndexedPrimitiveVB(IDirect3DDevice7 *iface, > */ > hr = IWineD3DIndexBuffer_Lock(This->indexbuffer, > 0 /* OffSetToLock */, > - 0 /* SizeToLock - doesn't matter */, > + IndexCount * sizeof(WORD), > (BYTE **) &LockedIndices, > 0 /* Flags */); > assert(IndexCount < 0x100000); > diff --git a/dlls/ddraw/direct3d.c b/dlls/ddraw/direct3d.c > index 4896ba7..b716a60 100644 > --- a/dlls/ddraw/direct3d.c > +++ b/dlls/ddraw/direct3d.c > @@ -804,7 +804,7 @@ IDirect3DImpl_7_CreateDevice(IDirect3D7 *iface, > */ > hr = IWineD3DDevice_CreateIndexBuffer(This->wineD3DDevice, > 0x40000, /* Length. Don't know how long it should be */ > - 0, /* Usage */ > + WINED3DUSAGE_DYNAMIC, /* Usage */ > WINED3DFMT_INDEX16, /* Format. D3D7 uses WORDS */ > WINED3DPOOL_DEFAULT, > &object->indexbuffer, > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index c039798..2ac8797 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -4294,7 +4294,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitive(IWineD3DDevice * > UINT idxStride = 2; > IWineD3DIndexBuffer *pIB; > WINED3DINDEXBUFFER_DESC IdxBufDsc; > - GLint vbo; > + GLuint vbo; > > pIB = This->stateBlock->pIndexData; > This->stateBlock->streamIsUP = FALSE; > diff --git a/dlls/wined3d/indexbuffer.c b/dlls/wined3d/indexbuffer.c > index b16ddd0..ae2294a 100644 > --- a/dlls/wined3d/indexbuffer.c > +++ b/dlls/wined3d/indexbuffer.c > @@ -60,8 +60,11 @@ static ULONG WINAPI IWineD3DIndexBufferImpl_Release(IWineD3DIndexBuffer *iface) > if (ref == 0) { > if(This->vbo) { > ENTER_GL(); > - GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > - checkGLcall("glBindBufferARB"); > + /* No need to manually unset the buffer. glDeleteBuffers unsets it for the current context, > + * but not for other contexts. However, because the d3d buffer is destroyed the app has to > + * unset it before doing the next draw, thus dirtifying the index buffer state and forcing > + * binding a new buffer > + */ > GL_EXTCALL(glDeleteBuffersARB(1, &This->vbo)); > checkGLcall("glDeleteBuffersARB"); > LEAVE_GL(); > @@ -159,6 +162,8 @@ static HRESULT WINAPI IWineD3DIndexBufferImpl_Unlock(IWineD3DIndexBuffer *iface) > LEAVE_GL(); > This->dirtystart = 0; > This->dirtyend = 0; > + /* TODO: Move loading into preload when the buffer is used, that avoids dirtifying the state */ > + IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); > } > return WINED3D_OK; > } > > > ------------------------------------------------------------------------ > >

Feb. 20, 2007

Re: Working on JScript/VBScript support for MSI

by Misha Koshelev

On Tue, 2007-02-20 at 21:44 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > Hi, since MSDN states that any installer that requires JScript/VBScript > > must make sure to install it, and since some applications require these > > for install (bug #7353 and another one is there for VBScript for a > > different installer), I figure there is no reason why builtin MSI cannot > > use Microsoft Script if it is there (and plus when we have our own > > JScript/VBScript we will be able to use it off the bat with MSI). > > > > I have posted my initial work on this on the bugzilla for bug #7353. The > > first file (a patch, will attach also) is my patch which updates > > custom.c to have the appropriate handlers for the custom action types, > > extracts the script from the appropriate place, writes it to a file, and > > uses a framework very similar to the current thread framework for DLLs > > to call my helper call_script function. This first patch, in theory, > > should not have to change much (if at all), although I have not > > thoroughly tested it yet so it probably will. > > > > The second file (and attached here too) is dlls/msi/script.c, which is > > where the meat and potatoes of the actual call_script function is/will > > be. Right now it is pretty barebones, but it does load the script from > > the file and calls it appropriately. > > > > Now I am working on implementing the Session object, although it looks > > like a wrapper around MSI functions we already have so I think it should > > be doable. > > > > Anyways, any comments on my work so far will be appreciated. > > > > Nice work! Does MSI expose any builtin objects to the scripts (a quick > Google search indicates there should be a Session object exposed)? > Btw, I did a little more work on my script.c yesterday, added a Session object. Right now it just does a FIXME for any properties/methods that are looked up, but what I need to do now is implement the Session class (fair amount of work) and then just add an ITypeLib interface to Session and then on to testing. Misha

Feb. 20, 2007

Re: Working on JScript/VBScript support for MSI

by Misha Koshelev

On Tue, 2007-02-20 at 21:44 +0000, Robert Shearman wrote: > Misha Koshelev wrote: > > Hi, since MSDN states that any installer that requires JScript/VBScript > > must make sure to install it, and since some applications require these > > for install (bug #7353 and another one is there for VBScript for a > > different installer), I figure there is no reason why builtin MSI cannot > > use Microsoft Script if it is there (and plus when we have our own > > JScript/VBScript we will be able to use it off the bat with MSI). > > > > I have posted my initial work on this on the bugzilla for bug #7353. The > > first file (a patch, will attach also) is my patch which updates > > custom.c to have the appropriate handlers for the custom action types, > > extracts the script from the appropriate place, writes it to a file, and > > uses a framework very similar to the current thread framework for DLLs > > to call my helper call_script function. This first patch, in theory, > > should not have to change much (if at all), although I have not > > thoroughly tested it yet so it probably will. > > > > The second file (and attached here too) is dlls/msi/script.c, which is > > where the meat and potatoes of the actual call_script function is/will > > be. Right now it is pretty barebones, but it does load the script from > > the file and calls it appropriately. > > > > Now I am working on implementing the Session object, although it looks > > like a wrapper around MSI functions we already have so I think it should > > be doable. > > > > Anyways, any comments on my work so far will be appreciated. > > > > Nice work! Does MSI expose any builtin objects to the scripts (a quick > Google search indicates there should be a Session object exposed)? > Thanks. It exposes a Session object, which is the next thing I have to work on. Actually the object seems to be a wrapper around all the functions MSI exposes as a Dll, and should not be _too_ much work to implement. I can get an .idl from oleview on the native MSI that has the appropriate objects with a slight bugfix in oleview (tonight I am going to delve a little more into that to figure out if it proper and if so will submit a patch), and then I just have to implement each function as a call to the appropriate Msi... function, which shouldn't be too bad. I do have a dayjob though, so my estimated ETA for this is probably going to be in a bit though (I am thinking couple of weeks). Misha

Feb. 20, 2007

Re: Working on JScript/VBScript support for MSI

by Robert Shearman

Misha Koshelev wrote: > Hi, since MSDN states that any installer that requires JScript/VBScript > must make sure to install it, and since some applications require these > for install (bug #7353 and another one is there for VBScript for a > different installer), I figure there is no reason why builtin MSI cannot > use Microsoft Script if it is there (and plus when we have our own > JScript/VBScript we will be able to use it off the bat with MSI). > > I have posted my initial work on this on the bugzilla for bug #7353. The > first file (a patch, will attach also) is my patch which updates > custom.c to have the appropriate handlers for the custom action types, > extracts the script from the appropriate place, writes it to a file, and > uses a framework very similar to the current thread framework for DLLs > to call my helper call_script function. This first patch, in theory, > should not have to change much (if at all), although I have not > thoroughly tested it yet so it probably will. > > The second file (and attached here too) is dlls/msi/script.c, which is > where the meat and potatoes of the actual call_script function is/will > be. Right now it is pretty barebones, but it does load the script from > the file and calls it appropriately. > > Now I am working on implementing the Session object, although it looks > like a wrapper around MSI functions we already have so I think it should > be doable. > > Anyways, any comments on my work so far will be appreciated. > Nice work! Does MSI expose any builtin objects to the scripts (a quick Google search indicates there should be a Session object exposed)? -- Rob Shearman

Feb. 20, 2007

Re: Progress in implementation of Direct3D

by João Eiras

Na , Mirek <thunder.m(a)czela.net> escreveu: > Hi, i would like to say "Thanks for your work!" to all wine developers. > In past months there was realy big progress in implementation of > Direct3D in wine (that part is most important for me) and other parts > such Dinput, so I would like to introduce you some more sreenshots from > latest Direct3D applications. I will try to post them on official wine > website. > > To run third benchmark in 3DMark 2005 I used wined3d_3dmark05.diff.txt > patch (from H. Verbeet) > To run Call of Dutty 2 I used cod2.diff patch (my latest modification of > patch against current CVS) > > All screenshots are from today CVS 20.02.2007 without patch "[9/10] > WineD3D: Use VBOs for index buffers" which caused some regressions. > > http://headline.czela.net/Mirek/wine/ > > or via IP: http://62.240.181.87/Mirek/wine/ Indeed excellent ! Damn ! I really want to play COD 2 on my pc :p

Feb. 20, 2007

Re: 0.9.31 not suitable for gaming

by Pavel Troller

Hi! > Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: > > - Steam based games, mainly HL2: During game load, the screen goes black. > > Moving the cursor causes sound effects as it hovers across the menus and > > buttons, so the program runs, but nothing can be seen. > This regression is known, and it should be fixed already. It was caused by my > patch which made wined3d return an error if an unsupported query is created, > like windows does. Wine does not support event queries, but many apps expect > them to be supported. I have sent another patch(committed already) that > re-enables the fake event queries. OK. This bug seems to be really fixed, but the game crashes later (during the startup of the "real" game, after all the selections). It crashes in its own code (called "Engine") but ntdll and kernel32 are visible in the backtrace. I can send it exactly if it helps. I don't know how to bisect this crash because the one initially mentioned is "masking" it. > > > - Fallout Tactics (BOS.exe): Shows a dialog stating > > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > > Could not create display buffers" > > and then another one about abnormal termination of the program and quits. > I don't know about this regression. Can you do a bisect? Yes, done. It's the following commit: commit 388499ff28616ef03bf8949a78e658e1bdb4e4fc Author: Stefan DĂśsinger <stefan(a)codeweavers.com> Date: Wed Feb 14 17:59:08 2007 +0100 wined3d: More fullscreen window fixes. The game is run in a virtual desktop (i.e. it appears in the Linux window, not in full screen). With regards, Pavel Troller

Feb. 20, 2007

Progress in implementation of Direct3D

by Mirek

Hi, i would like to say "Thanks for your work!" to all wine developers. In past months there was realy big progress in implementation of Direct3D in wine (that part is most important for me) and other parts such Dinput, so I would like to introduce you some more sreenshots from latest Direct3D applications. I will try to post them on official wine website. To run third benchmark in 3DMark 2005 I used wined3d_3dmark05.diff.txt patch (from H. Verbeet) To run Call of Dutty 2 I used cod2.diff patch (my latest modification of patch against current CVS) All screenshots are from today CVS 20.02.2007 without patch "[9/10] WineD3D: Use VBOs for index buffers" which caused some regressions. http://headline.czela.net/Mirek/wine/ or via IP: http://62.240.181.87/Mirek/wine/ --- dlls/wined3d/directx.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 841e16f..ca3eaaf 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -585,7 +585,7 @@ BOOL IWineD3DImpl_FillGLCaps(IWineD3D *iface, Display* display) { glGetIntegerv(GL_MAX_TEXTURE_UNITS_ARB, &gl_max); TRACE_(d3d_caps)(" FOUND: ARB Multitexture support - GL_MAX_TEXTURE_UNITS_ARB=%u\n", gl_max); gl_info->supported[ARB_MULTITEXTURE] = TRUE; - gl_info->max_textures = min(MAX_TEXTURES, gl_max); + gl_info->max_textures = 8; gl_info->max_texture_stages = min(MAX_TEXTURES, gl_max); gl_info->max_samplers = max(gl_info->max_samplers, gl_max); } else if (strcmp(ThisExtn, "GL_ARB_texture_cube_map") == 0) { @@ -2196,7 +2196,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, *pCaps->MaxVertexBlendMatrixIndex = 1; *pCaps->MaxAnisotropy = GL_LIMITS(anisotropy); - *pCaps->MaxPointSize = GL_LIMITS(pointsize); + *pCaps->MaxPointSize = 64.0f; *pCaps->VertexProcessingCaps = WINED3DVTXPCAPS_DIRECTIONALLIGHTS | @@ -2294,7 +2294,8 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, *pCaps->NumSimultaneousRTs = GL_LIMITS(buffers); - *pCaps->StretchRectFilterCaps = 0; + *pCaps->StretchRectFilterCaps = WINED3DPTFILTERCAPS_MINFLINEAR | + WINED3DPTFILTERCAPS_MAGFLINEAR; *pCaps->VertexTextureFilterCaps = 0; if(*pCaps->VertexShaderVersion == WINED3DVS_VERSION(3,0)) {

Feb. 20, 2007

Re: [9/10] WineD3D: Use VBOs for index buffers

by Stefan Dösinger

Am Dienstag 20 Februar 2007 16:54 schrieb Mirek: > I tried it three times in different places, it helped in some games: > > Flatout II - graphic in menu was without any problems, but game crashed > (still regression). > HalfLife 2 EO - works, I was in game only about 2 minuts and it look fixed > Alpine Sky Racing 2007 - works > TES IV: Oblivion - still crashing while loading (it just hang while > loading, picture is frozen, and I have to manualy kill it) > > So it fixed something, but not all regressions. Yes, there is another case of that in IWineD3DVertexBufferImpl_Release. Remove the glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER, 0) there too. I will send a patch soon.

Feb. 20, 2007

Re: Rediffed patch from Rein Klazes:winex11.drv:Add pointer check in X11DRV_SetDIBits

by Felix Nawothnig

Louis. Lenders wrote: > + if( IsBadReadPtr( bits, nrsrcbytes)) return 0; AFAIK you should never use that function since it introduces a race con. Try using an exception handler around the memory access itself. Felix

Feb. 20, 2007

Re: wine-0.9.31 version is absent from bugzilla

by Ben Hodgetts (Enverex)

It's done manually by an admin. Lei Zhang wrote: > Does someone manually add new versions to bugzilla or is it done > automatically? > > On 2/19/07, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> Please whoever has powers to add new versions to bugzilla, can they >> please do that? >> >> Thanks. >> >> Vitaliy. >> >> >> > >

Feb. 20, 2007

Re: a big fan of your work

by Joris Huizer

--- Jeffrey Sabarese <core5fedora(a)gmail.com> wrote: > I have installed, and use the "ies4linux" > ( here for more info if you're unfamiliar with it: > http://novicenotes.com/install-internet-explorer-on-linux-under-wine-run-ie… > ), but though it works VERY well launching from the > Fedora Terminal I don't think you need ies4linux. At least in the current wine version you could just download ie6 (sp1) from the microsoft site (and I guess have a good look at the terms of use -- though I think you already agreed to them with running ies4linux) and run the installer - it gets the thing installed properly regards, Joris ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html

Feb. 20, 2007

Re: AppDB performance issue

by Bryan Haskins

I'm actually noticing it a little now... about a minute hang sometimes then poof it's up. So it's not a crawl... just a hang. It's weird really. Feels like too many people trying to connect for the server to handle so it throws them to the queue, or similar. On 2/20/07, Nick Law <nlaw(a)nildram.co.uk> wrote: > > I still find appdb really slow 60 seconds to view some pages, post on > the forums etc.... It's driving me nuts to the point I've gone back to > real life for a while as it's less frustrating. BTW this problems exists > on systems separated by over 100 miles (but same login account) so it > not hardware at my end. > > I'll check back now and again to see if it's fixed. > > Apart from that, keep up the good work devs, wine's functionality is > improving all the time but appdb needs fixing. > > Cheers > Nick > > John Smith wrote: > > Humm very strange it works well for me, > > > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 > > <http://2.0.0.1> on windows 2000, on gentoo x86 with firefox 2.0.0.1 > > <http://2.0.0.1> , and on gentoo amd64 firefox 2.0.0.1 <http://2.0.0.1>. > > > > I added, then removed, then edited a test result. Speed seemed normal. > > > > Hope this helps the investigation. > > > > Regards, > > John Klehm > > > > On 2/14/07, *Louis Lenders* <xerox_xerox2000(a)yahoo.co.uk > > <mailto:xerox_xerox2000(a)yahoo.co.uk>> wrote: > > > > Bryan Haskins <kingofallhearts999 <at> gmail.com > > <http://gmail.com>> writes: > > > > > > > > > > > I was just replying, and reading now, no slow down at all. It > > loads a little > > slow running through all that text, but no where near the minutes > > everyone says > > it takes them, even on dialup. > > > > > > > > > For your info, Appdb, is complete unusable for me ... Loading a > > page, or > > adding a test result to an application takes several minutes. > > Please fix, as > > this is really annoying :( > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > -- Cheers, Bryan

Feb. 20, 2007

Re: [9/10] WineD3D: Use VBOs for index buffers

by Mirek

Stefan Dösinger napsal(a): > Am Dienstag 20 Februar 2007 15:03 schrieb Mirek: >> Hi, this patch caused regression in many Direct3D games. TES IV: >> Oblivion can't start game (menu works), Flatout II is completly broken, >> Alpine Sky Racing 2007 can't run, HalfLife 2 EO can't run. I tried >> rewrite GLint vbo; to GLuint vbo; but it doesn't help. > Argh, sounds kinda bad :-( . > > Do the games crash, or display incorrect graphics? HL 2 EO can't even start to menu, it just hangs TES IV: Oblivion can start, but it hangs while loading game Flatout II can start, but graphic in menu is completly broken and it crash after start of game > > Can you try to add the following line in > IWineD3DIndexBufferImpl_Unlock(dlls/wined3d/indexbuffer.c),somewhere in the > locks == 0 && This->vbo if statement: > > IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, > STATE_INDEXBUFFER); > > The bound index buffer is changed there, and it needs to be restored for the > next draw. I forgot to add that because originally I planned to make the vbo > and state table things 2 patches, but that didn't work out right. I tried it three times in different places, it helped in some games: Flatout II - graphic in menu was without any problems, but game crashed (still regression). HalfLife 2 EO - works, I was in game only about 2 minuts and it look fixed Alpine Sky Racing 2007 - works TES IV: Oblivion - still crashing while loading (it just hang while loading, picture is frozen, and I have to manualy kill it) So it fixed something, but not all regressions. 1. /* For now load in unlock */ if(locks == 0 && This->vbo) { ENTER_GL(); IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); checkGLcall("glBindBufferARB"); GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); checkGLcall("glBufferSubDataARB"); LEAVE_GL(); This->dirtystart = 0; This->dirtyend = 0; } return WINED3D_OK; 2. /* For now load in unlock */ if(locks == 0 && This->vbo) { IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); ENTER_GL(); GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); checkGLcall("glBindBufferARB"); GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); checkGLcall("glBufferSubDataARB"); LEAVE_GL(); This->dirtystart = 0; This->dirtyend = 0; IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); } return WINED3D_OK; 3. /* For now load in unlock */ if(locks == 0 && This->vbo) { ENTER_GL(); GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); checkGLcall("glBindBufferARB"); GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); checkGLcall("glBufferSubDataARB"); LEAVE_GL(); This->dirtystart = 0; This->dirtyend = 0; } return WINED3D_OK; Mirek

Feb. 20, 2007

Re: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers

by H. Verbeet

On 20/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > > On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > > > This also checked the sampler state, not just the sampler. > I added a test to see if the sampler state is checked too, and neither ddraw, > d3d8 nor d3d9 did checks on the sampler state / texture stage state. I am not > sure if we should commit the test to wine because it could cause invisible > memory corruption in the native d3d object which randomly breaks other tests. > > DirectX is incorrect here, because I have a test for lights where the light > type IS checked. > Would it make sense to catch out of bounds samplers/sampler states, print a ERR/WARN, and just return WINED3D_OK? Memory corruption is pretty nasty, and we'd at least have some log info that an application is doing something it shouldn't be doing.

Feb. 20, 2007

Re: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers

by H. Verbeet

On 20/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > > On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > > > This also checked the sampler state, not just the sampler. > I added a test to see if the sampler state is checked too, and neither ddraw, > d3d8 nor d3d9 did checks on the sampler state / texture stage state. I am not > sure if we should commit the test to wine because it could cause invisible > memory corruption in the native d3d object which randomly breaks other tests. > > DirectX is incorrect here, because I have a test for lights where the light > type IS checked. > Would it make sense to catch out of bounds samplers/sampler states, print a ERR/WARN, and just return WINED3D_OK? Memory corruption is pretty nasty, and we'd at least have some log info that an application is doing something it shouldn't be doing.

Feb. 20, 2007

Re: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers

by Stefan Dösinger

Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > This also checked the sampler state, not just the sampler. I added a test to see if the sampler state is checked too, and neither ddraw, d3d8 nor d3d9 did checks on the sampler state / texture stage state. I am not sure if we should commit the test to wine because it could cause invisible memory corruption in the native d3d object which randomly breaks other tests. DirectX is incorrect here, because I have a test for lights where the light type IS checked.

Feb. 20, 2007

Re: [9/10] WineD3D: Use VBOs for index buffers

by Stefan Dösinger

Am Dienstag 20 Februar 2007 15:03 schrieb Mirek: > Hi, this patch caused regression in many Direct3D games. TES IV: > Oblivion can't start game (menu works), Flatout II is completly broken, > Alpine Sky Racing 2007 can't run, HalfLife 2 EO can't run. I tried > rewrite GLint vbo; to GLuint vbo; but it doesn't help. Argh, sounds kinda bad :-( . Do the games crash, or display incorrect graphics? Can you try to add the following line in IWineD3DIndexBufferImpl_Unlock(dlls/wined3d/indexbuffer.c),somewhere in the locks == 0 && This->vbo if statement: IWineD3DDeviceImpl_MarkStateDirty(This->resource.wineD3DDevice, STATE_INDEXBUFFER); The bound index buffer is changed there, and it needs to be restored for the next draw. I forgot to add that because originally I planned to make the vbo and state table things 2 patches, but that didn't work out right.

Feb. 20, 2007

Re: [9/10] WineD3D: Use VBOs for index buffers

by Mirek

Hi, this patch caused regression in many Direct3D games. TES IV: Oblivion can't start game (menu works), Flatout II is completly broken, Alpine Sky Racing 2007 can't run, HalfLife 2 EO can't run. I tried rewrite GLint vbo; to GLuint vbo; but it doesn't help. Mirek Stefan Dösinger napsal(a): > > ------------------------------------------------------------------------ > > From 4d52be700666b6b1e853bad296c502b5b0d76189 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Mon, 19 Feb 2007 15:12:39 +0100 > Subject: [PATCH] WineD3D: Use VBOs for index buffers > > This patch uses (if available) gl vertex buffer objects for static d3d index buffers > to store indices in video memory. Therefore a new index buffer state is added which > binds the vbo to GL_ELEMENT_ARRAY_BUFFER. DrawStrided* use the index buffer stride to > tell if indices are used for drawing because a NULL index data pointer is valid now. > DrawStridedSlow has to read the indices from the index buffer if it is used, because > it can't use the data from the vbo(or only very inefficiently). > --- > dlls/wined3d/device.c | 68 ++++++++++++++++++++++++++++++++++++--- > dlls/wined3d/drawprim.c | 14 ++++++-- > dlls/wined3d/indexbuffer.c | 49 +++++++++++++++++++++++++++- > dlls/wined3d/state.c | 12 +++++++ > dlls/wined3d/wined3d_private.h | 8 ++++- > 5 files changed, 139 insertions(+), 12 deletions(-) > > diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c > index 18f3e75..af0e96a 100644 > --- a/dlls/wined3d/device.c > +++ b/dlls/wined3d/device.c > @@ -443,21 +443,67 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateVertexBuffer(IWineD3DDevice *ifac > return WINED3D_OK; > } > > +static void CreateIndexBufferVBO(IWineD3DDeviceImpl *This, IWineD3DIndexBufferImpl *object) { > + GLenum error, glUsage; > + TRACE("Creating VBO for Index Buffer %p\n", object); > + > + ENTER_GL(); > + while(glGetError()); > + > + GL_EXTCALL(glGenBuffersARB(1, &object->vbo)); > + error = glGetError(); > + if(error != GL_NO_ERROR || object->vbo == 0) { > + ERR("Creating a vbo failed, continueing without vbo for this buffer\n"); > + object->vbo = 0; > + return; > + } > + > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, object->vbo)); > + error = glGetError(); > + if(error != GL_NO_ERROR) { > + ERR("Failed to bind index buffer, continueing without vbo for this buffer\n"); > + goto out; > + } > + > + /* Use static write only usage for now. Dynamic index buffers stay in sysmem, and due to the sysmem > + * copy no readback will be needed > + */ > + glUsage = GL_STATIC_DRAW; > + GL_EXTCALL(glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, object->resource.size, NULL, glUsage)); > + error = glGetError(); > + if(error != GL_NO_ERROR) { > + ERR("Failed to initialize the index buffer\n"); > + goto out; > + } > + LEAVE_GL(); > + TRACE("Successfully created vbo %d for index buffer %p\n", object->vbo, object); > + return; > + > +out: > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > + GL_EXTCALL(glDeleteBuffersARB(1, &object->vbo)); > + LEAVE_GL(); > + object->vbo = 0; > +} > + > static HRESULT WINAPI IWineD3DDeviceImpl_CreateIndexBuffer(IWineD3DDevice *iface, UINT Length, DWORD Usage, > WINED3DFORMAT Format, WINED3DPOOL Pool, IWineD3DIndexBuffer** ppIndexBuffer, > HANDLE *sharedHandle, IUnknown *parent) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > IWineD3DIndexBufferImpl *object; > TRACE("(%p) Creating index buffer\n", This); > - > + > /* Allocate the storage for the device */ > D3DCREATERESOURCEOBJECTINSTANCE(object,IndexBuffer,WINED3DRTYPE_INDEXBUFFER, Length) > - > - /*TODO: use VBO's */ > - if (Pool == WINED3DPOOL_DEFAULT ) { /* Allocate some system memory for now */ > + > + if (Pool == WINED3DPOOL_DEFAULT ) { /* We need a local copy for drawStridedSlow */ > object->resource.allocatedMemory = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,object->resource.size); > } > > + if(Pool != WINED3DPOOL_SYSTEMMEM && !(Usage & WINED3DUSAGE_DYNAMIC) && GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT)) { > + CreateIndexBufferVBO(This, object); > + } > + > TRACE("(%p) : Len=%d, Use=%x, Format=(%u,%s), Pool=%d - Memory@%p, Iface@%p\n", This, Length, Usage, Format, > debug_d3dformat(Format), Pool, object, object->resource.allocatedMemory); > *ppIndexBuffer = (IWineD3DIndexBuffer *) object; > @@ -2557,10 +2603,15 @@ static HRESULT WINAPI IWineD3DDeviceImpl_SetIndices(IWineD3DDevice *iface, IWine > return WINED3D_OK; > } > > - /* So far only the base vertex index is tracked */ > + /* The base vertex index affects the stream sources, while > + * The index buffer is a seperate index buffer state > + */ > if(BaseVertexIndex != oldBaseIndex) { > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_STREAMSRC); > } > + if(oldIdxs != pIndexData) { > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > + } > return WINED3D_OK; > } > > @@ -4224,9 +4275,11 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitive(IWineD3DDevice * > UINT idxStride = 2; > IWineD3DIndexBuffer *pIB; > WINED3DINDEXBUFFER_DESC IdxBufDsc; > + GLint vbo; > > pIB = This->stateBlock->pIndexData; > This->stateBlock->streamIsUP = FALSE; > + vbo = ((IWineD3DIndexBufferImpl *) pIB)->vbo; > > TRACE("(%p) : Type=(%d,%s), min=%d, CountV=%d, startIdx=%d, countP=%d\n", This, > PrimitiveType, debug_d3dprimitivetype(PrimitiveType), > @@ -4245,7 +4298,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitive(IWineD3DDevice * > } > > drawPrimitive(iface, PrimitiveType, primCount, 0, NumVertices, startIndex, > - idxStride, ((IWineD3DIndexBufferImpl *) pIB)->resource.allocatedMemory, minIndex); > + idxStride, vbo ? NULL : ((IWineD3DIndexBufferImpl *) pIB)->resource.allocatedMemory, minIndex); > > return WINED3D_OK; > } > @@ -4310,6 +4363,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawIndexedPrimitiveUP(IWineD3DDevice * > This->stateBlock->loadBaseVertexIndex = 0; > /* Mark the state dirty until we have nicer tracking of the stream source pointers */ > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_VDECL); > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > > drawPrimitive(iface, PrimitiveType, PrimitiveCount, 0 /* vertexStart */, NumVertices, 0 /* indxStart */, idxStride, pIndexData, MinVertexIndex); > > @@ -4332,8 +4386,10 @@ static HRESULT WINAPI IWineD3DDeviceImpl_DrawPrimitiveStrided (IWineD3DDevice *i > * that value. > */ > IWineD3DDeviceImpl_MarkStateDirty(This, STATE_VDECL); > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_INDEXBUFFER); > This->stateBlock->baseVertexIndex = 0; > This->up_strided = DrawPrimStrideData; > + This->stateBlock->streamIsUP = TRUE; > drawPrimitive(iface, PrimitiveType, PrimitiveCount, 0, 0, 0, 0, NULL, 0); > This->up_strided = NULL; > return WINED3D_OK; > diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c > index 2cc3a15..7cf6877 100644 > --- a/dlls/wined3d/drawprim.c > +++ b/dlls/wined3d/drawprim.c > @@ -571,7 +571,7 @@ static void drawStridedFast(IWineD3DDevice *iface,UINT numberOfVertices, GLenum > const void *idxData, short idxSize, ULONG minIndex, ULONG startIdx, ULONG startVertex) { > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > > - if (idxData != NULL /* This crashes sometimes!*/) { > + if (idxSize != 0 /* This crashes sometimes!*/) { > TRACE("(%p) : glElements(%x, %d, %d, ...)\n", This, glPrimitiveType, numberOfVertices, minIndex); > idxData = idxData == (void *)-1 ? NULL : idxData; > #if 1 > @@ -629,7 +629,15 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > TRACE("Using slow vertex array code\n"); > > /* Variable Initialization */ > - if (idxData != NULL) { > + if (idxSize != 0) { > + /* Immediate mode drawing can't make use of indices in a vbo - get the data from the index buffer. > + * If the index buffer has no vbo(not supported or other reason), or with user pointer drawing > + * idxData will be != NULL > + */ > + if(idxData == NULL) { > + idxData = ((IWineD3DIndexBufferImpl *) This->stateBlock->pIndexData)->resource.allocatedMemory; > + } > + > if (idxSize == 2) pIdxBufS = (const short *) idxData; > else pIdxBufL = (const long *) idxData; > } > @@ -1165,7 +1173,7 @@ inline void drawStridedInstanced(IWineD3DDevice *iface, WineDirect3DVertexStride > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; > IWineD3DStateBlockImpl *stateblock = This->stateBlock; > > - if (idxData == NULL) { > + if (idxSize == 0) { > /* This is a nasty thing. MSDN says no hardware supports that and apps have to use software vertex processing. > * We don't support this for now > * > diff --git a/dlls/wined3d/indexbuffer.c b/dlls/wined3d/indexbuffer.c > index 39a270d..0f768ac 100644 > --- a/dlls/wined3d/indexbuffer.c > +++ b/dlls/wined3d/indexbuffer.c > @@ -58,6 +58,15 @@ static ULONG WINAPI IWineD3DIndexBufferImpl_Release(IWineD3DIndexBuffer *iface) > ULONG ref = InterlockedDecrement(&This->resource.ref); > TRACE("(%p) : Releasing from %d\n", This, ref + 1); > if (ref == 0) { > + if(This->vbo) { > + ENTER_GL(); > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > + checkGLcall("glBindBufferARB"); > + GL_EXTCALL(glDeleteBuffersARB(1, &This->vbo)); > + checkGLcall("glDeleteBuffersARB"); > + LEAVE_GL(); > + } > + > IWineD3DResourceImpl_CleanUp((IWineD3DResource *)iface); > HeapFree(GetProcessHeap(), 0, This); > } > @@ -108,13 +117,49 @@ static HRESULT WINAPI IWineD3DIndexBufferImpl_GetParent(IWineD3DIndexBuffer *ifa > ****************************************************** */ > static HRESULT WINAPI IWineD3DIndexBufferImpl_Lock(IWineD3DIndexBuffer *iface, UINT OffsetToLock, UINT SizeToLock, BYTE** ppbData, DWORD Flags) { > IWineD3DIndexBufferImpl *This = (IWineD3DIndexBufferImpl *)iface; > - TRACE("(%p) : no real locking yet, offset %d, size %d, Flags=%x\n", This, OffsetToLock, SizeToLock, Flags); > + TRACE("(%p) : offset %d, size %d, Flags=%x\n", This, OffsetToLock, SizeToLock, Flags); > + > + InterlockedIncrement(&This->lockcount); > *ppbData = (BYTE *)This->resource.allocatedMemory + OffsetToLock; > + > + if(Flags & (WINED3DLOCK_READONLY | WINED3DLOCK_NO_DIRTY_UPDATE) || This->vbo == 0) { > + return WINED3D_OK; > + } > + > + if(This->dirtystart != This->dirtyend) { > + if(This->dirtystart > OffsetToLock) This->dirtystart = OffsetToLock; > + if(SizeToLock) { > + if(This->dirtyend < OffsetToLock + SizeToLock) This->dirtyend = OffsetToLock + SizeToLock; > + } else { > + This->dirtyend = This->resource.size; > + } > + } else { > + This->dirtystart = OffsetToLock; > + if(SizeToLock) > + This->dirtyend = OffsetToLock + SizeToLock; > + else > + This->dirtyend = This->resource.size; > + } > + > return WINED3D_OK; > } > static HRESULT WINAPI IWineD3DIndexBufferImpl_Unlock(IWineD3DIndexBuffer *iface) { > IWineD3DIndexBufferImpl *This = (IWineD3DIndexBufferImpl *)iface; > - TRACE("(%p) : stub\n", This); > + unsigned long locks = InterlockedDecrement(&This->lockcount);; > + TRACE("(%p)\n", This); > + > + /* For now load in unlock */ > + if(locks == 0 && This->vbo) { > + ENTER_GL(); > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, This->vbo)); > + checkGLcall("glBindBufferARB"); > + GL_EXTCALL(glBufferSubDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, > + This->dirtystart, This->dirtyend - This->dirtystart, This->resource.allocatedMemory + This->dirtystart)); > + checkGLcall("glBufferSubDataARB"); > + LEAVE_GL(); > + This->dirtystart = 0; > + This->dirtyend = 0; > + } > return WINED3D_OK; > } > static HRESULT WINAPI IWineD3DIndexBufferImpl_GetDesc(IWineD3DIndexBuffer *iface, WINED3DINDEXBUFFER_DESC *pDesc) { > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index 0b96e54..f78720a 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -3062,6 +3062,17 @@ static void scissorrect(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3D > checkGLcall("glScissor"); > } > > +static void indexbuffer(DWORD state, IWineD3DStateBlockImpl *stateblock, WineD3DContext *context) { > + if(GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT)) { > + if(stateblock->streamIsUP || stateblock->pIndexData == NULL ) { > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 0)); > + } else { > + IWineD3DIndexBufferImpl *ib = (IWineD3DIndexBufferImpl *) stateblock->pIndexData; > + GL_EXTCALL(glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, ib->vbo)); > + } > + } > +} > + > const struct StateEntry StateTable[] = > { > /* State name representative, apply function */ > @@ -4077,6 +4088,7 @@ const struct StateEntry StateTable[] = > { /*511, WINED3DTS_WORLDMATRIX(255) */ STATE_TRANSFORM(WINED3DTS_WORLDMATRIX(255)), transform_worldex }, > /* Various Vertex states follow */ > { /* , STATE_STREAMSRC */ STATE_VDECL, vertexdeclaration }, > + { /* , STATE_INDEXBUFFER */ STATE_INDEXBUFFER, indexbuffer }, > { /* , STATE_VDECL */ STATE_VDECL, vertexdeclaration }, > { /* , STATE_VSHADER */ STATE_VDECL, vertexdeclaration }, > { /* , STATE_VIEWPORT */ STATE_VIEWPORT, viewport }, > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index 3bf0c8e..be8cd6e 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -426,8 +426,10 @@ typedef void (*APPLYSTATEFUNC)(DWORD state, IWineD3DStateBlockImpl *stateblock, > > #define STATE_STREAMSRC (STATE_TRANSFORM(WINED3DTS_WORLDMATRIX(255)) + 1) > #define STATE_IS_STREAMSRC(a) ((a) == STATE_STREAMSRC) > +#define STATE_INDEXBUFFER (STATE_STREAMSRC + 1) > +#define STATE_IS_INDEXBUFFER(a) ((a) == STATE_INDEXBUFFER) > > -#define STATE_VDECL (STATE_STREAMSRC + 1) > +#define STATE_VDECL (STATE_INDEXBUFFER + 1) > #define STATE_IS_VDECL(a) ((a) == STATE_VDECL) > > #define STATE_VSHADER (STATE_VDECL + 1) > @@ -793,6 +795,10 @@ typedef struct IWineD3DIndexBufferImpl > const IWineD3DIndexBufferVtbl *lpVtbl; > IWineD3DResourceClass resource; > > + GLuint vbo; > + UINT dirtystart, dirtyend; > + LONG lockcount; > + > /* WineD3DVertexBuffer specifics */ > } IWineD3DIndexBufferImpl; > > > > ------------------------------------------------------------------------ > >

Feb. 20, 2007

Re: AppDB performance issue

by Nick Law

I still find appdb really slow 60 seconds to view some pages, post on the forums etc.... It's driving me nuts to the point I've gone back to real life for a while as it's less frustrating. BTW this problems exists on systems separated by over 100 miles (but same login account) so it not hardware at my end. I'll check back now and again to see if it's fixed. Apart from that, keep up the good work devs, wine's functionality is improving all the time but appdb needs fixing. Cheers Nick John Smith wrote: > Humm very strange it works well for me, > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 > <http://2.0.0.1> on windows 2000, on gentoo x86 with firefox 2.0.0.1 > <http://2.0.0.1> , and on gentoo amd64 firefox 2.0.0.1 <http://2.0.0.1>. > > I added, then removed, then edited a test result. Speed seemed normal. > > Hope this helps the investigation. > > Regards, > John Klehm > > On 2/14/07, *Louis Lenders* <xerox_xerox2000(a)yahoo.co.uk > <mailto:xerox_xerox2000(a)yahoo.co.uk>> wrote: > > Bryan Haskins <kingofallhearts999 <at> gmail.com > <http://gmail.com>> writes: > > > > > > > I was just replying, and reading now, no slow down at all. It > loads a little > slow running through all that text, but no where near the minutes > everyone says > it takes them, even on dialup. > > > > > For your info, Appdb, is complete unusable for me ... Loading a > page, or > adding a test result to an application takes several minutes. > Please fix, as > this is really annoying :( > > > > > ------------------------------------------------------------------------ > > >

Feb. 20, 2007

Re: [PATCH 3/3] server: Check object's security when creating handles.

by Vitaliy Margolen

Robert Shearman wrote: > Vitaliy Margolen wrote: >> After >> checking object's SD against token we fail some tests. >> What it seems to me is that some one tried to "optimize" this part in >> windows and instead created a security problem. > > If you already have a valid handle to the object, then it isn't really a > security problem to have another one with the same access rights. Actually that's a pseudo-handle from GetCurrentProcess(). Which can be duplicated into say global handle with maximum access. So when an app creates a process and sets any access restrictions on it, it's all useless for the process itself - as it can always gain 100% access to itself, and give that 100% access to anyone who wants. Vitaliy.

Feb. 20, 2007

Re: [PATCH 3/3] server: Check object's security when creating handles.

by Robert Shearman

Vitaliy Margolen wrote: > After > checking object's SD against token we fail some tests. > What it seems to me is that some one tried to "optimize" this part in > windows and instead created a security problem. If you already have a valid handle to the object, then it isn't really a security problem to have another one with the same access rights. > @@ -450,25 +453,34 @@ obj_handle_t duplicate_handle( struct pr > unsigned int access, unsigned int attr, unsigned int options ) > { > obj_handle_t res; > + struct handle_entry *entry; > + unsigned int src_access, dst_access; > struct object *obj = get_handle_obj( src, src_handle, 0, NULL ); > > if (!obj) return 0; > - if (options & DUP_HANDLE_SAME_ACCESS) > + if ((entry = get_handle( src, src_handle ))) > + src_access = entry->access; > + else /* pseudo-handle, give it full access */ > { > - struct handle_entry *entry = get_handle( src, src_handle ); > - if (entry) > - access = entry->access; > - else /* pseudo-handle, give it full access */ > - { > - access = obj->ops->map_access( obj, GENERIC_ALL ); > - clear_error(); > - } > + src_access = obj->ops->map_access( obj, GENERIC_ALL ); > + clear_error(); > } > - access &= ~RESERVED_ALL; > + src_access &= ~RESERVED_ALL; > + > + if (options & DUP_HANDLE_SAME_ACCESS) > + dst_access = src_access; > + else > + dst_access = obj->ops->map_access( obj, access ) & ~RESERVED_ALL; > + > + /* asking for more or the same/less access rights */ > + access = ~src_access & dst_access ? dst_access : 0; > + > if (options & DUP_HANDLE_MAKE_GLOBAL) > res = alloc_global_handle( obj, access ); > else > res = alloc_handle( dst, obj, access, attr ); > + if (res) get_handle( dst, res )->access = dst_access; > + > It would seem better to add an extra parameter to alloc_handle and alloc_global_handle to tell them to not check access rather than adding this hack. It should use less processor time and it should make patch 2 not necessary. -- Rob Shearman

Feb. 20, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > http://source.winehq.org/source/server/handle.c#L523 calls > duplicate_handle with NULL process. Yes, but duplicate_handle has no reason to call get_handle on the dst process. I see that your 3/3 patch does this, but that's broken. -- Alexandre Julliard julliard(a)winehq.org

Feb. 20, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > >> Resend as-is. I need this function to work on global handles when >> process is NULL. > > If you need this you are doing something wrong. Callers are not > supposed to know that a handle is global. > http://source.winehq.org/source/server/handle.c#L523 calls duplicate_handle with NULL process. Vitaliy.

Feb. 20, 2007

Re: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers

by Stefan Dösinger

Am Montag 19 Februar 2007 16:19 schrieb H. Verbeet: > On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > This also checked the sampler state, not just the sampler. True. I'll extend the test for that and send an updated patch

Feb. 20, 2007

Re: [00/16] CMD.exe patches

by Stefan Dösinger

Am Dienstag 20 Februar 2007 01:32 schrieb Ann & Jason Edmeades: > After being away from active development in wine for a while I wanted to > start somewhere easy, and picked some bugs from the bug database in the > wcmd (cmd.exe) shell. > > I think I got carried away, but the following patches fix some reported > bugs and lots of other issues I found while doing some playing within the > shell. > > All feedback welcome, although I think I need to lean to use git a bit > better! Did patches 1-5 get lost?

Feb. 20, 2007

Re: [10/10] WineD3D: With FVFs only one stream is used

by H. Verbeet

On 20/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > But I think we should keep the FVF->decl conversion at a central place instead > of having 3 copies of it(d3d9, d3d8, ddraw). I think we could make a single > exported function to convert a fvf->wined3d decl which does not depend on any > other code in wined3d > Sure. I think it should be easy enough to just add another constructor for the wined3d vertex declaration that takes an FVF instead of an array of WINED3DVERTEXELEMENT's.

Feb. 20, 2007

Re: [10/10] WineD3D: With FVFs only one stream is used

by Stefan Dösinger

Am Montag 19 Februar 2007 16:42 schrieb H. Verbeet: > Eventually, the FVF path should be removed from wined3d completely. We > should convert the FVF in d3d8 to a vertex declaration, just like in > d3d9. Agreed. But I think we should keep the FVF->decl conversion at a central place instead of having 3 copies of it(d3d9, d3d8, ddraw). I think we could make a single exported function to convert a fvf->wined3d decl which does not depend on any other code in wined3d

Feb. 20, 2007

Re: [PATCH 2/3] server: Fix get_handle for global handles. It doesn't need process for them.

by Alexandre Julliard

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > Resend as-is. I need this function to work on global handles when > process is NULL. If you need this you are doing something wrong. Callers are not supposed to know that a handle is global. -- Alexandre Julliard julliard(a)winehq.org

Feb. 20, 2007

Re: 0.9.31 not suitable for gaming

by Stefan Dösinger

Am Dienstag 20 Februar 2007 06:37 schrieb Pavel Troller: > - Steam based games, mainly HL2: During game load, the screen goes black. > Moving the cursor causes sound effects as it hovers across the menus and > buttons, so the program runs, but nothing can be seen. This regression is known, and it should be fixed already. It was caused by my patch which made wined3d return an error if an unsupported query is created, like windows does. Wine does not support event queries, but many apps expect them to be supported. I have sent another patch(committed already) that re-enables the fake event queries. > - Fallout Tactics (BOS.exe): Shows a dialog stating > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > Could not create display buffers" > and then another one about abnormal termination of the program and quits. I don't know about this regression. Can you do a bisect?

Feb. 20, 2007

Re: 0.9.31 not suitable for gaming

by H. Verbeet

On 20/02/07, Pavel Troller <patrol(a)sinus.cz> wrote: > Hi! > I've tried 0.9.31 and it seems that there is a regression in at least two > games: > - Fallout Tactics (BOS.exe): Shows a dialog stating > "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: > Could not create display buffers" > and then another one about abnormal termination of the program and quits. > - Steam based games, mainly HL2: During game load, the screen goes black. > Moving the cursor causes sound effects as it hovers across the menus and > buttons, so the program runs, but nothing can be seen. > Both those games are known to work with wine at about a half between .29 > and .30. > I tried it with basic .31 as well as with today's git update. > Are those regressions known and is it a work in progress, or should I make > a bisecting session to find the problem ? > With regards, Pavel Troller > It's a bit unfortunate that right before the release a couple of regressions appear to have crept in. I think that at least the one in HL2/CSS is supposed to be fixed in current git, so if it isn't it probably makes sense to do a regression test.

Feb. 20, 2007

Re: Comctl32 Status Bar Test

by Lei Zhang

On 2/10/07, Felix Nawothnig <flexo(a)holycrap.org> wrote: > Alex Arazi wrote: > > - ok(rc.top == 2, "Expected 2, got %d\n", rc.top); > > - ok(rc.bottom == 21, "Expected 21, got %d\n", rc.bottom); > > - ok(rc.left == 0, "Expected 0, got %d\n", rc.left); > > - ok(rc.right == 50, "Expected 50, got %d\n", rc.right); > > I didn't really look at your new tests but the second of those tests you > removed failed ("got 1" IIRC) on Windows (XP) because we don't create a > parent window (and because the 21 is wrong. Should be 22 IIRC) - native > comctl32 sometimes does some strange stuff when a control doesn't have > one - so the test should create it. > > Felix > Hi Felix, Alex removed the incorrect test, it should have been 22. To make native comctl32 behave correctly, Alex tried to create a parent window but that didn't help. What actually needs to happen is to set the WS_VISIBLE style for the status bar. (Dan and I discovered this a few weeks back but it slipped our minds.) Alex and I did some more testing and we noticed the value for rc.bottom isn't consistent on Windows either. On Windows XP, depending on the window style and font size, the size can vary between 22, 23, and 26. So WS_VISIBLE needs to be set, #include <stdio.h> is unneeded and should be removed, and (at least for me) a couple tests failed and should be wrapped in todo_wine{ }. - Lei

Feb. 20, 2007

Re: [PATCH 3/3] ntdll: fix up instruction pointer in contextinsideraise_exception

by Dmitry Timoshkov

"Peter Oberndorfer" <kumbayo84(a)arcor.de> wrote: > The strange thing is my testcase [patch 2/3] shows/(should show) that the debugger > gets a unmodified eip for a first chance exception > + if (de.u.Exception.dwFirstChance) > + { > + /* debugger gets first chance exception with unmodified ctx.Eip */ > + ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xb, "Eip at %x instead of 0x%x\n", > + ctx.Eip, (DWORD)code_mem_address + 0xb); > > and the modified one when the application did not handle the exception Could that be due to an error in your test? > Unfortunetely i don't own that book :-( > Could you please verify in the pseudocode that the modified context gets sent to the debugger, > and not some unmodified copy? The pseudocode of KiDispatchException as the very first thing calls KeContextFromKframes and then unconditionally decrements context.Eip in the case of STATUS_BREAKPOINT. > Or maybe they unfix the context again in the send_to_debugger function ;-) > Or the pseudo code is not fully correct. That's a possibility, yes. -- Dmitry.

Feb. 20, 2007

AppDB e-mail notifications.

by Vitaliy Margolen

Can some one fix e-mail notifications sent err. NOT sent from appdb? I have not received a single notification from the apps I am a super maintainer for! Except my own messages! On a side not, thanks to whomever that was who edited steam's howto and erased all the formatting! And they haven't even added themselves to the "laste changed by" entry. Vitaliy

Feb. 20, 2007

0.9.31 not suitable for gaming

by Pavel Troller

Hi! I've tried 0.9.31 and it seems that there is a regression in at least two games: - Fallout Tactics (BOS.exe): Shows a dialog stating "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: Could not create display buffers" and then another one about abnormal termination of the program and quits. - Steam based games, mainly HL2: During game load, the screen goes black. Moving the cursor causes sound effects as it hovers across the menus and buttons, so the program runs, but nothing can be seen. Both those games are known to work with wine at about a half between .29 and .30. I tried it with basic .31 as well as with today's git update. Are those regressions known and is it a work in progress, or should I make a bisecting session to find the problem ? With regards, Pavel Troller

Feb. 19, 2007

Re: [8/10] WineD3D: Move the scissor rectangle to the state table,Stefan Dösinger

by Vitaliy Margolen

Stefan Dösinger wrote: > + if(memcmp(&This->updateStateBlock->scissorRect, pRect, sizeof(*pRect)) == 0) { > + TRACE("App is setting the old scissor rectangle over, nothing to do\n"); > + return WINED3D_OK; > + } > memcpy(&This->updateStateBlock->scissorRect, pRect, sizeof(*pRect)); You should use EqualRect() and CopyRect() instead of memcmp and memcpy for RECTs. Vitaliy

Feb. 19, 2007

Re: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers

by Vitaliy Margolen

H. Verbeet wrote: > On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> - if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { > > This also checked the sampler state, not just the sampler. > > I would also keep some warning messages in there like WARN so we can easily see if game does something wrong. Vitaliy

Feb. 19, 2007

Re: [start][start] Output with console encoding

by Vitaliy Margolen

Anatoly Lyutin wrote: > Vitaliy Margolen wrote: >>> Changelog: >>> Fix output console to output with console encoding. >>> static void output(const char *message) >> >> This is not correct. This function and everything else, using it should >> be rewritten as unicode, not ansi. Also you should use >> HeapAlloc/HeapFree. >> > This program works with 8-bits strings and rewritten all "start" to > unicode is precocious because wineconsole now not yet support unicode in > curses mode (I`m working on it) :) > All you need to do is to convert output() function and all callers into WCHAR. Then you can do whatever magic you need inside of output(). Then you can properly load resources and deal with them properly until the step you need to display them. Vitaliy

Feb. 19, 2007

re: XCOPY support

by Dan Kegel

Jason, >Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of >XCOPY support. I've been wishing for this for other reasons lately. Glad you're looking at it! >Does anyone have anything like this in their tree, or should >I try to knock something up? I'm not aware of anything like it in the wine tree. (It's tempting to borrow code from freedos, but they're GPL... still, you could peek at e.g. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/xcopy/rxcopy/ and maybe ask the author to relicense if you like it.) >I also assume it needs to be a separate program, not part of cmd.exe, to >mimic how windows does it? Yes. BTW, it would be nice if you could include a conformace test of some sort. Maybe a batch file that reports problems by using echo FAIL ...reason... ? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Feb. 19, 2007

Re: wine-0.9.31 version is absent from bugzilla

by Lei Zhang

Does someone manually add new versions to bugzilla or is it done automatically? On 2/19/07, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Please whoever has powers to add new versions to bugzilla, can they > please do that? > > Thanks. > > Vitaliy. > > >

Feb. 19, 2007

wine-0.9.31 version is absent from bugzilla

by Vitaliy Margolen

Please whoever has powers to add new versions to bugzilla, can they please do that? Thanks. Vitaliy.

Feb. 19, 2007

Re: generic.ppd does not appear in the build dir - cannot print

by Michael [Plouj] Ploujnikov

I have just finished confirming that this problem was indeed caused by some mess up in Gentoo's 32bit filesystem layout (as we discussed on IRC). A solution has been posted: http://wiki.winehq.org/WineOn64bit I am now able to print in Wine using CUPS, not Wine's generic.ppd, again. Thanks for the input. -- Libre Software: http://www.gnu.org/philosophy/free-sw.html

Feb. 19, 2007

XCOPY support

by Ann & Jason Edmeades

Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of XCOPY support. Does anyone have anything like this in their tree, or should I try to knock something up? I also assume it needs to be a separate program, not part of cmd.exe, to mimic how windows does it? Jason

Feb. 19, 2007

Re: [2/2] quartz: Return proper error codes from GraphBuilder_RenderFile

by Mirek

Hi, this patch caused regression in TES IV: Oblivion, now it can't run, here is output: fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb41-f175-11d1-a392-00e0291f3959} not found fixme:devenum:DEVENUM_ICreateDevEnum_CreateClassEnumerator Category {cc7bfb46-f175-11d1-a392-00e0291f3959} not found wine: Unhandled page fault on read access to 0xffffffea at address 0x7bfd278f (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0xffffffea in 32-bit code (0x7bfd278f). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7bfd278f ESP:0034f098 EBP:0034f1d0 EFLAGS:00010282( - 00 - RIS1) EAX:00000001 EBX:7bffec00 ECX:0034f198 EDX:ffffffea ESI:80004005 EDI:00000001 Stack dump: 0x0034f098: 115cc680 00000001 0034f198 0034f19c 0x0034f0a8: 00000000 00000001 00000001 0034f150 0x0034f0b8: 00000000 00000000 00000000 00000000 0x0034f0c8: 00000000 00000000 00000000 00000000 0x0034f0d8: 0034f108 7efa09be 7bff527c 0034f19c 0x0034f0e8: 0034f198 0034f1ac 0034f1a8 00000010 Backtrace: =>1 0x7bfd278f GraphBuilder_RenderFile+0x66f(iface=0x115cb968, lpcwstrFile=0x34f3f0, lpcwstrPlayList=0x0) [/usr/src/wine/dlls/q uartz/filtergraph.c:1094] in quartz (0x0034f1d0) 2 0x0069302b in oblivion (+0x29302b) (0x00000008) 3 0x00000000 (0x00000000) 0x7bfd278f GraphBuilder_RenderFile+0x66f [/usr/src/wine/dlls/quartz/filtergraph.c:1094] in quartz: movl 0x0(%edx),%eax 1094 IBaseFilter_Release(psplitter); Modules: Module Address Debug info Name (109 modules) PE 400000-b59000 Export oblivion PE b60000-daf000 Deferred d3dx9_27 PE 18000000-18068000 Deferred binkw32 PE 70000000-700b2000 Deferred dinput8 ELF 7b2de000-7b2f2000 Deferred avicap32<elf> \-PE 7b2e0000-7b2f2000 \ avicap32 ELF 7b2f2000-7b38b000 Deferred oleaut32<elf> \-PE 7b300000-7b38b000 \ oleaut32 ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7bf81000-7bfa8000 Deferred msvfw32<elf> \-PE 7bf90000-7bfa8000 \ msvfw32 ELF 7bfa8000-7c000000 Dwarf quartz<elf> \-PE 7bfb0000-7c000000 \ quartz ELF 7c4b4000-7c4bf000 Deferred libgcc_s.so.1 ELF 7c5a4000-7c634000 Deferred libglu.so.1 ELF 7c634000-7c653000 Deferred devenum<elf> \-PE 7c640000-7c653000 \ devenum ELF 7c653000-7c70d000 Deferred wined3d<elf> \-PE 7c660000-7c70d000 \ wined3d ELF 7c70d000-7c737000 Deferred d3d9<elf> \-PE 7c710000-7c737000 \ d3d9 ELF 7c857000-7c86b000 Deferred winejoystick<elf> \-PE 7c860000-7c86b000 \ winejoystick ELF 7c86b000-7c882000 Deferred cfgmgr32<elf> \-PE 7c870000-7c882000 \ cfgmgr32 ELF 7c882000-7c8de000 Deferred setupapi<elf> \-PE 7c890000-7c8de000 \ setupapi ELF 7c8de000-7c8f2000 Deferred hid<elf> \-PE 7c8e0000-7c8f2000 \ hid ELF 7c9ed000-7caae000 Deferred libasound.so.2 ELF 7caae000-7cad9000 Deferred winealsa<elf> \-PE 7cac0000-7cad9000 \ winealsa ELF 7cad9000-7cb0b000 Deferred uxtheme<elf> \-PE 7cae0000-7cb0b000 \ uxtheme ELF 7cd9e000-7cdb3000 Deferred midimap<elf> \-PE 7cda0000-7cdb3000 \ midimap ELF 7cdb3000-7cdb8000 Deferred libxfixes.so.3 ELF 7cdbd000-7cdd5000 Deferred msacm32<elf> \-PE 7cdc0000-7cdd5000 \ msacm32 ELF 7cdd7000-7cdda000 Deferred libxinerama.so.1 ELF 7cddd000-7cdf9000 Deferred imm32<elf> \-PE 7cde0000-7cdf9000 \ imm32 ELF 7d7a3000-7d7a5000 Deferred libnvidia-tls.so.1 ELF 7d7a5000-7e116000 Deferred libglcore.so.1 ELF 7e116000-7e1aa000 Deferred libgl.so.1 ELF 7e1aa000-7e1af000 Deferred libxdmcp.so.6 ELF 7e1af000-7e1b2000 Deferred libxau.so.6 ELF 7e1b2000-7e29e000 Deferred libx11.so.6 ELF 7e29e000-7e2ac000 Deferred libxext.so.6 ELF 7e2ac000-7e2b1000 Deferred libxxf86vm.so.1 ELF 7e2b1000-7e2c9000 Deferred libice.so.6 ELF 7e2c9000-7e2d2000 Deferred libsm.so.6 ELF 7e2d3000-7e2dc000 Deferred libxcursor.so.1 ELF 7e2dc000-7e2df000 Deferred libxrandr.so.2 ELF 7e2df000-7e2e7000 Deferred libxrender.so.1 ELF 7e2f1000-7e37f000 Deferred winex11<elf> \-PE 7e300000-7e37f000 \ winex11 ELF 7e3fb000-7e41b000 Deferred libexpat.so.1 ELF 7e41b000-7e446000 Deferred libfontconfig.so.1 ELF 7e446000-7e45a000 Deferred libz.so.1 ELF 7e45a000-7e4c4000 Deferred libfreetype.so.6 ELF 7e4e3000-7e50f000 Deferred ws2_32<elf> \-PE 7e4f0000-7e50f000 \ ws2_32 ELF 7e50f000-7e529000 Deferred wsock32<elf> \-PE 7e520000-7e529000 \ wsock32 ELF 7e529000-7e58d000 Deferred msvcrt<elf> \-PE 7e540000-7e58d000 \ msvcrt ELF 7e58d000-7e5a1000 Deferred lz32<elf> \-PE 7e590000-7e5a1000 \ lz32 ELF 7e5a1000-7e5f9000 Deferred shlwapi<elf> \-PE 7e5b0000-7e5f9000 \ shlwapi ELF 7e5f9000-7e6ee000 Deferred shell32<elf> \-PE 7e610000-7e6ee000 \ shell32 ELF 7e6ee000-7e701000 Deferred libresolv.so.2 ELF 7e707000-7e720000 Deferred version<elf> \-PE 7e710000-7e720000 \ version ELF 7e720000-7e73e000 Deferred iphlpapi<elf> \-PE 7e730000-7e73e000 \ iphlpapi ELF 7e73e000-7e793000 Deferred rpcrt4<elf> \-PE 7e750000-7e793000 \ rpcrt4 ELF 7e793000-7e82c000 Deferred ole32<elf> \-PE 7e7a0000-7e82c000 \ ole32 ELF 7e82c000-7e875000 Deferred dsound<elf> \-PE 7e830000-7e875000 \ dsound ELF 7e875000-7e903000 Deferred winmm<elf> \-PE 7e880000-7e903000 \ winmm ELF 7e903000-7e949000 Deferred advapi32<elf> \-PE 7e910000-7e949000 \ advapi32 ELF 7e949000-7e9dc000 Deferred gdi32<elf> \-PE 7e960000-7e9dc000 \ gdi32 ELF 7e9dc000-7eb16000 Deferred user32<elf> \-PE 7ea00000-7eb16000 \ user32 ELF 7eb16000-7ebd6000 Deferred comctl32<elf> \-PE 7eb20000-7ebd6000 \ comctl32 ELF 7edd6000-7eefc000 Deferred kernel32<elf> \-PE 7edf0000-7eefc000 \ kernel32 ELF 7eefc000-7ef07000 Deferred libnss_files.so.2 ELF 7ef07000-7ef11000 Deferred libnss_nis.so.2 ELF 7ef11000-7ef27000 Deferred libnsl.so.1 ELF 7ef27000-7ef4c000 Deferred libm.so.6 ELF 7ef6b000-7f000000 Deferred ntdll<elf> \-PE 7ef80000-7f000000 \ ntdll ELF b7cb6000-b7cba000 Deferred libdl.so.2 ELF b7cba000-b7dec000 Deferred libc.so.6 ELF b7dec000-b7dfe000 Deferred libpthread.so.0 ELF b7e11000-b7e15000 Deferred iso8859-2.so ELF b7e15000-b7e1e000 Deferred libnss_compat.so.2 ELF b7e1e000-b7f2f000 Deferred libwine.so.1 ELF b7f31000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000c 0 0000000b 0 00000008 (D) G:\usr\games\oblivion\Oblivion.exe 00000010 2 0000000f -1 0000000e -1 0000000d 15 00000009 0 <== Mirek Chris Robinson napsal(a): > > ------------------------------------------------------------------------ > > From 427782e216badd48afc917c85682bc5a1954b24b Mon Sep 17 00:00:00 2001 > From: Chris Robinson <chris.kcat(a)gmail.com> > Date: Wed, 14 Feb 2007 11:27:26 -0800 > Subject: [PATCH] quartz: Return proper error codes from GraphBuilder_RenderFile > > --- > dlls/quartz/filtergraph.c | 82 +++++++++++++++++++++++---------------------- > 1 files changed, 42 insertions(+), 40 deletions(-) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index 8b38a3b..a3db8dd 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -961,9 +961,9 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > IEnumPins* penumpins; > ULONG pin; > HRESULT hr; > - IEnumMoniker* pEnumMoniker; > + IEnumMoniker* pEnumMoniker = NULL; > GUID tab[2]; > - IPin** ppins; > + IPin** ppins = NULL; > ULONG nb; > IMoniker* pMoniker; > IFileSourceFilter* pfile = NULL; > @@ -972,6 +972,9 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > > TRACE("(%p/%p)->(%s, %s)\n", This, iface, debugstr_w(lpcwstrFile), debugstr_w(lpcwstrPlayList)); > > + if (lpcwstrPlayList != NULL) > + return E_INVALIDARG; > + > hr = IGraphBuilder_AddSourceFilter(iface, lpcwstrFile, string, &preader); > > /* Retrieve file media type */ > @@ -982,6 +985,13 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > IFileSourceFilter_Release(pfile); > } > > + if (SUCCEEDED(hr)) > + hr = IBaseFilter_EnumPins(preader, &penumpins); > + if (SUCCEEDED(hr)) { > + hr = IEnumPins_Next(penumpins, 1, &ppinreader, &pin); > + IEnumPins_Release(penumpins); > + } > + > if (SUCCEEDED(hr)) { > tab[0] = mt.majortype; > tab[1] = mt.subtype; > @@ -990,6 +1000,8 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > > if (FAILED(hr)) > { > + if (pEnumMoniker) > + IEnumMoniker_Release(pEnumMoniker); > if (preader) { > IGraphBuilder_RemoveFilter(iface, preader); > IBaseFilter_Release(preader); > @@ -1019,65 +1031,49 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > hr = IGraphBuilder_AddFilter(iface, psplitter, NULL); > if (FAILED(hr)) { > ERR("Unable add filter (%x)\n", hr); > - return hr; > + IBaseFilter_Release(psplitter); > + continue; > } > > /* Connect file source and splitter filters together */ > /* Make the splitter analyze incoming data */ > - hr = IBaseFilter_EnumPins(preader, &penumpins); > - if (FAILED(hr)) { > - ERR("Enumpins (%x)\n", hr); > - return hr; > - } > - hr = IEnumPins_Next(penumpins, 1, &ppinreader, &pin); > - if (FAILED(hr)) { > - ERR("Next (%x)\n", hr); > - return hr; > - } > - if (pin == 0) { > - ERR("No Pin\n"); > - return E_FAIL; > - } > - IEnumPins_Release(penumpins); > > hr = IBaseFilter_EnumPins(psplitter, &penumpins); > - if (FAILED(hr)) { > - ERR("Splitter Enumpins (%x)\n", hr); > - return hr; > - } > - hr = IEnumPins_Next(penumpins, 1, &ppinsplitter, &pin); > - if (FAILED(hr)) { > - ERR("Next (%x)\n", hr); > - return hr; > - } > - if (pin == 0) { > - ERR("No Pin\n"); > - return E_FAIL; > + if (SUCCEEDED(hr)) { > + hr = IEnumPins_Next(penumpins, 1, &ppinsplitter, &pin); > + IEnumPins_Release(penumpins); > } > - IEnumPins_Release(penumpins); > > - hr = IPin_Connect(ppinreader, ppinsplitter, NULL); > + if (SUCCEEDED(hr)) > + hr = IPin_Connect(ppinreader, ppinsplitter, NULL); > if (SUCCEEDED(hr)) { > /* Make sure there's some output pins in the filter */ > hr = GetInternalConnections(psplitter, ppinsplitter, &ppins, &nb); > - if(SUCCEEDED(hr)) { > + if (SUCCEEDED(hr)) { > if(nb > 0) { > TRACE("Successfully connected to filter\n"); > break; > } > CoTaskMemFree(ppins); > ppins = NULL; > - TRACE("No output pins found in filter\n"); > } > - IBaseFilter_Release(ppinsplitter); > - ppinsplitter = NULL; > + > + TRACE("No output pins found in filter\n"); > + hr = VFW_E_CANNOT_RENDER; > } > + > + IPin_Release(ppinsplitter); > + ppinsplitter = NULL; > + IGraphBuilder_RemoveFilter(iface, psplitter); > + IBaseFilter_Release(psplitter); > + ppinsplitter = NULL; > + > TRACE("Cannot connect to filter (%x), trying next one\n", hr); > - hr = E_FAIL; > } > > /* Render all output pin of the splitter by calling IGraphBuilder_Render on each of them */ > if (SUCCEEDED(hr)) { > + int partial = 0; > int i; > TRACE("pins to consider: %d\n", nb); > for(i = 0; i < nb; i++) { > @@ -1085,13 +1081,19 @@ static HRESULT WINAPI GraphBuilder_RenderFile(IGraphBuilder *iface, > hr = IGraphBuilder_Render(iface, ppins[i]); > if (FAILED(hr)) { > ERR("Cannot render pin %p (%x)\n", ppins[i], hr); > - /* FIXME: We should clean created things properly */ > - break; > + partial = 1; > } > + IPin_Release(ppins[i]); > } > CoTaskMemFree(ppins); > + > + hr = (partial ? VFW_S_PARTIAL_RENDER : S_OK); > } > - > + > + if (psplitter) > + IBaseFilter_Release(psplitter); > + IBaseFilter_Release(preader); > + > return hr; > } > > > > ------------------------------------------------------------------------ > >

Feb. 19, 2007

Working on JScript/VBScript support for MSI

by Misha Koshelev

Hi, since MSDN states that any installer that requires JScript/VBScript must make sure to install it, and since some applications require these for install (bug #7353 and another one is there for VBScript for a different installer), I figure there is no reason why builtin MSI cannot use Microsoft Script if it is there (and plus when we have our own JScript/VBScript we will be able to use it off the bat with MSI). I have posted my initial work on this on the bugzilla for bug #7353. The first file (a patch, will attach also) is my patch which updates custom.c to have the appropriate handlers for the custom action types, extracts the script from the appropriate place, writes it to a file, and uses a framework very similar to the current thread framework for DLLs to call my helper call_script function. This first patch, in theory, should not have to change much (if at all), although I have not thoroughly tested it yet so it probably will. The second file (and attached here too) is dlls/msi/script.c, which is where the meat and potatoes of the actual call_script function is/will be. Right now it is pretty barebones, but it does load the script from the file and calls it appropriately. Now I am working on implementing the Session object, although it looks like a wrapper around MSI functions we already have so I think it should be doable. Anyways, any comments on my work so far will be appreciated. Misha

Feb. 19, 2007

Re: [start][start][try2] Output with console encoding

by Robert Shearman

Anatoly Lyutin wrote: > + len = MultiByteToWideChar( CP_ACP, 0, message, -1, NULL, 0 ); > + bufW = HeapAlloc( GetProcessHeap(), 0, len ); > + len is in WCHARs, not bytes so this will cause heap corruption. It really would be a lot easier to make "output" take a Unicode string instead. -- Rob Shearman

Feb. 19, 2007

Re: a big fan of your work

by Robert Shearman

Jeffrey Sabarese wrote: > I guess you could say then that my question for you is: > "How might i go about trying to get IE6 to be "recognized" by such > WinE-apps as TopStyle?" > > I have installed, and use the "ies4linux" I believe ies4linux installs IE in a different WINEPREFIX to the default. Therefore, you either need to install IE without using ies4linux (preferable) or use "WINEPREFIX=~/.ies4linux wine ..." when installing your programs. Given that the author of ies4linux is riding the wave of Wine's success, without giving any contributions back either financial or in code, many people here will be unlikely to help you if you have any difficulties in the former configuration. -- Rob Shearman

Feb. 19, 2007

Re: [PATCH] return when not finding the name

by Eric Pouech

Marcus Meissner a écrit : > On Sun, Feb 18, 2007 at 01:40:12PM +0100, Eric Pouech wrote: > >> Marcus Meissner a écrit : >> >>> --- >>> dlls/dbghelp/dwarf.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c >>> index 4f74b6a..f51a948 100644 >>> --- a/dlls/dbghelp/dwarf.c >>> +++ b/dlls/dbghelp/dwarf.c >>> @@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar >>> >>> TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di)); >>> >>> - if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string >>> = NULL; >>> + if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; >>> if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) >>> value.u.svalue = 0; >>> symt_add_enum_element(ctx->module, parent, name.u.string, >>> value.u.svalue); >>> >>> >>> >> Hi Marcus, >> >> can you send me the ELF file(s) which is/are causing this? >> > > There is no ELF file. > > Coverity spotted this as error, since name.u.string can be NULL > in the flow and symt_add_enum_element() would crash in pool_strdup. > > It is CID 461. 462 and 463 are related issues. > > Ciao, Marcus > the point is that the code paths you're trying to fix would only be taken in case of corrupt ELF file (those attributes are mandatory in the dwarf specs) the proposed fix is not correct as we'll still have NULL references (to the objects for enumerators and variables you don't create) and this will crash later on so, I'd rather fix the symbol.c file by allowing to have NULL names for those objects, this will less likely lead to a crash A+

Feb. 19, 2007

Re: Resend 1/4 NtCreateMailslotFile tests

by Eric Pouech

richardvoigt(a)gmail.com a écrit : > On 2/17/07, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: >> Jeff L a écrit : >> > Eric Pouech wrote: >> >> Jeff Latimer a écrit : >> >>> Establish the framework for testing NtCreateMailslotFile. Have >> >>> fixed issues with NTSTATUS return codes etc. >> >> those tests belong to dlls/ntdll, not dlls/kernel32 >> >> also, if the test is for ntdll functions, it shouldn't use kernel32 >> >> ones... hence, NtClose should be used instead of CloseHandle >> > I put the proposition a while ago about putting the tests in kernel32 >> > as, although they are ntdll functions, they related to mailslot >> > functions and relating the tests would be easier on the tester. I >> > take it that that is not the case? >> my call would be to put the tests for functions sitting in DLL X in the >> directory X/tests, even if we need to rewrite some code (or bother some >> code from some other tests) >> but as the API are different, we need in the end the both sets of test >> > > perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ? > > dlls/ntdll/tests/mailslot.c A+

Feb. 19, 2007

Re: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it.

by Eric Pouech

Robert Shearman a écrit : > Eric Pouech wrote: >> Robert Shearman a écrit : >>> >>> Keep the debuglink elf_file_map mapped until after >>> elf_new_public_symbols is called, otherwise we could use unmapped >>> memory. >> >> this is still not the full valid solution... what should be done is: >> when we search for a given section, we should look first in the >> original .so, then, if not found, in the .gnu_debuglink one... >> your patch only covers the case where all relevant information is to >> be found in the .gnu_debuglink file, which is not guaranteed > > And that should be easier for an interested person to do after this > patch is applied, right? I was just interested in getting rid of bogus > crc errors when using winedbg. > first, it's not exactly what your patch is entirely about... your patch ensures that the newly .gnu_debuglink mapped file is present for symbols resolution... and the bogus CRC errors come from the fact that we have an ERR for that, were it should be a WARN... a user could have different versions of the debug info files secondly, the correct fix will require a rewrite of the mapping algorithm itself, which is rather orthogonal to what you did my reco would simply to downgrade the ERR to a WARN if you don't want to go into the full fix A+

Feb. 19, 2007

a big fan of your work

by Jeffrey Sabarese

hi there! I have to wonder if i don't use WinE more than the "average" Fedora Core 5 user. I am forever trying to figure out how to run my old Windows apps here in the linux environment, using your incredible software. If ever you seek a "test subject", or feedback of any kind, please don't hesitate to include me as a candidate for some "volunteer work". If i may be so bold, i wish to address an issue related to WinE and some Web Development software: I have been able to successfully install, and use the Web Dev IDE, HomeSite+ (as in "the homesite which comes w/ dreamweaver nowadays"). previous to this, i was unable to get Bradbury's TopStyle Lite to operate under WinE due to the inability to "find Internet Exlorer", yet it seems as though HomeSite opens TopStyle w/out it's dependecy on IE keeping it from opening (bypassing the "warning" you might say). [can i just say it's sooo cool to finally have TopStyle here in Linux!!! thank you!). I guess you could say then that my question for you is: "How might i go about trying to get IE6 to be "recognized" by such WinE-apps as TopStyle?" I have installed, and use the "ies4linux" ( here for more info if you're unfamiliar with it: http://novicenotes.com/install-internet-explorer-on-linux-under-wine-run-ie… ), but though it works VERY well launching from the Fedora Terminal, i can't seem to get it to be recognized by "Windows" (WinE) as an available Browser. The apps i've tried which seem unable to integrate it are i. EditPlus 2.x (current) ii. TSW WebCoder 5 (as TSW Webcoder 2005 ( Delphi ) will NOT run on WinE, though i wish i did as i have a purchased licence) iii. TopStyle Lite iv. HomeSite Dreamweaver 8 will both run on WinE, and execute "normally", the ies4linux IE6-- yet, obviously there is a primary difference in that IE is NOT integrated into DreamWeaver as "part of the app", as it is in WebCoder and TopStyle. My best guess is that those apps have some security measure preventing a "non-standard" IE to become part of its processes. who knows. anyway-- i thought there was something else, but i suppose that's more than enough b.s. from me from one sitting. good luck in your work! if you have any ideas for my situation, i'd appriciate your input. again, please don't hesitate to inquire if you'd like for me to "test" anything for you and report my findings. i realize you probably have a whole lot of people already out there, but feel free to add me to the list. thanks, --Jeff Sabarese

Feb. 19, 2007

Re: [PATCH 3/3] ntdll: fix up instruction pointer in context insideraise_exception

by Peter Oberndorfer

On Monday 19 February 2007 09:37, Dmitry Timoshkov wrote: > "Peter Oberndorfer" <kumbayo84(a)arcor.de> wrote: > > > I'm not fully sure if the fixup also happens for other architectures > > (i guess not) > > so this patch is more a RFC > > > @@ -336,6 +336,10 @@ static NTSTATUS raise_exception( EXCEPTION_RECORD *rec, CONTEXT *context, BOOL f > > if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) > > return STATUS_SUCCESS; > > > > + /* fix up instruction pointer in context for EXCEPTION_BREAKPOINT */ > > + if (rec->ExceptionCode == EXCEPTION_BREAKPOINT) > > + GET_IP(context) = (DWORD_PTR)GET_IP(context) - 1; > > Gary Nebbett's book "Windows Nt/2000 Native API Reference" in the section C > "Exceptions and Debugging" provides a pseudocode for KiDispatchException > (page 439, Example C.1), and it does exactly the same thing as the patch > above. *But* it does it as a very first thing after getting the context and > before sending the debugger event. > The strange thing is my testcase [patch 2/3] shows/(should show) that the debugger gets a unmodified eip for a first chance exception + if (de.u.Exception.dwFirstChance) + { + /* debugger gets first chance exception with unmodified ctx.Eip */ + ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xb, "Eip at %x instead of 0x%x\n", + ctx.Eip, (DWORD)code_mem_address + 0xb); and the modified one when the application did not handle the exception + else + { + /* debugger gets context after exception handler has played with it */ + /* ctx.Eip is the same value the exception handler got */ + if (de.u.Exception.ExceptionRecord.ExceptionCode == EXCEPTION_BREAKPOINT) + { + todo_wine{ + ok((DWORD)ctx.Eip == (DWORD)code_mem_address + 0xa, "Eip at %x instead of 0x%x\n", + ctx.Eip, (DWORD)code_mem_address + 0xa); + } i tested this testcase on XP and 2K Unfortunetely i don't own that book :-( Could you please verify in the pseudocode that the modified context gets sent to the debugger, and not some unmodified copy? Or maybe they unfix the context again in the send_to_debugger function ;-) Or the pseudo code is not fully correct. Thanks, Greetings Peter

Feb. 19, 2007

Re: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it.

by Robert Shearman

Eric Pouech wrote: > Robert Shearman a écrit : >> >> Keep the debuglink elf_file_map mapped until after >> elf_new_public_symbols is called, otherwise we could use unmapped >> memory. > > this is still not the full valid solution... what should be done is: > when we search for a given section, we should look first in the > original .so, then, if not found, in the .gnu_debuglink one... > your patch only covers the case where all relevant information is to > be found in the .gnu_debuglink file, which is not guaranteed And that should be easier for an interested person to do after this patch is applied, right? I was just interested in getting rid of bogus crc errors when using winedbg. -- Rob Shearman

Feb. 19, 2007

Re: dbghelp: Match the crc for debug link files in elf_locate_debug_link so that we get the correct debug file before trying to parse it.

by Eric Pouech

Robert Shearman a écrit : > > Keep the debuglink elf_file_map mapped until after > elf_new_public_symbols is called, otherwise we could use unmapped memory. this is still not the full valid solution... what should be done is: when we search for a given section, we should look first in the original .so, then, if not found, in the .gnu_debuglink one... your patch only covers the case where all relevant information is to be found in the .gnu_debuglink file, which is not guaranteed A+

Feb. 19, 2007

Re: [10/10] WineD3D: With FVFs only one stream is used

by H. Verbeet

Eventually, the FVF path should be removed from wined3d completely. We should convert the FVF in d3d8 to a vertex declaration, just like in d3d9.

Feb. 19, 2007

Re: [9/10] WineD3D: Use VBOs for index buffers

by H. Verbeet

On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >+ GLint vbo; vbo should be a GLuint.

Feb. 19, 2007

Re: winecfg: Add check for device access to Drives tab.

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > I disagree. It have to be scary! It have to tell user that they do not > have direct access to the device. And that enything that will try doing > that will fail! CD checks is a specific case, there are many other perfectly valid uses for loop mounts where direct SCSI access is not required. -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2007

Re: [7/10] WineD3D: No bounds checking is done on sampler / texture numbers

by H. Verbeet

On 19/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >- if(Sampler > GL_LIMITS(sampler_stages) || Sampler < 0 || Type > WINED3D_HIGHEST_SAMPLER_STATE || Type < 0) { This also checked the sampler state, not just the sampler.

Feb. 19, 2007

Re: comctl32: rebar[1/4]: rewrite the layouting code

by Alexandre Julliard

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > From 2b42e9b97b443ced2531a445b531fddc5db2dcad Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Miko=C5=82aj_Zalewski?= <mikolaj(a)zalewski.pl> > Date: Sat, 17 Feb 2007 19:24:25 +0100 > Subject: [PATCH] comctl32: rebar: rewrite the layouting code This crashes in make test: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so rebar.c && touch rebar.ok wine: Unhandled page fault on read access to 0xffff001a at address 0x601bb75b (thread 0024), starting debugger... WineDbg starting on pid 0023 Unhandled exception: page fault on read access to 0xffff001a in 32-bit code (0x601bb75b). err:dbghelp:elf_load_debug_info_from_map Bad CRC for module (got 1ef14dcf while expecting 31f52e76) Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:601bb75b ESP:0033e50c EBP:0033e548 EFLAGS:00010202( - 00 - -RI1) EAX:ffff001a EBX:7b8aa9a0 ECX:00000002 EDX:00000000 ESI:00000000 EDI:ffffffff Stack dump: 0x0033e50c: 7b85b545 ffff001a 00000000 606a0081 0x0033e51c: 605b4fbc 0015df30 00000006 0033e548 0x0033e52c: 6055ddc0 00000040 0000000c 00000006 0x0033e53c: 605e9244 0015e0fc 0033f560 0033e578 0x0033e54c: 6055de30 00000000 00000000 ffff001a 0x0033e55c: ffffffff 00000000 00000000 0033e578 Backtrace: =>1 0x601bb75b strlen+0xb() in libc.so.6 (0x0033e548) 2 0x6055de30 Str_SetPtrAtoW+0x60(lppDest=0x15e10c, lpSrc=0xffff001a) [/home/julliard/wine/wine/dlls/comctl32/comctl32undoc.c:949] in comctl32 (0x0033e578) 3 0x605c06ef TOOLBAR_AddButtonsT+0x14f(hwnd=0x4002c, wParam=0x6, lParam=0x33f53c, fUnicode=0x0) [/home/julliard/wine/wine/dlls/comctl32/toolbar.c:2880] in comctl32 (0x0033e5c8) 4 0x605c2842 ToolbarWindowProc+0x1b52(hwnd=0x4002c, uMsg=<register EDI not in topmost frame>, wParam=0x6, lParam=0x33f53c) [/home/julliard/wine/wine/dlls/comctl32/toolbar.c:6622] in comctl32 (0x0033ee58) 5 0x606bb40a WINPROC_wrapper+0x1a() in user32 (0x0033ee88) 6 0x606bbb6b call_window_proc+0x6b(hwnd=<register EDI not in topmost frame>, msg=0x414, wp=0x6, lp=0x33f53c, result=0x33f3b8, arg=0x605c0cf0) [/home/julliard/wine/wine/dlls/user32/winproc.c:452] in user32 (0x0033eec8) 7 0x606beae7 WINPROC_CallProcAtoW+0x2c7(callback=0x606bbb00, hwnd=0x4002c, msg=0x414, wParam=0x6, lParam=0x33f53c, result=0x33f3b8, arg=0x605c0cf0) [/home/julliard/wine/wine/dlls/user32/winproc.c:903] in user32 (0x0033f388) 8 0x606bf923 CallWindowProcA+0xc3(func=0xffff0014, hwnd=0x4002c, msg=<register EDI not in topmost frame>, wParam=<register ESI not in topmost frame>, lParam=0x33f53c) [/home/julliard/wine/wine/dlls/user32/winproc.c:2229] in user32 (0x0033f3c8) 9 0x60688023 call_window_proc+0xe3(hwnd=<register ESI not in topmost frame>, msg=0x414, wparam=0x6, lparam=0x33f53c, unicode=0x0, same_thread=0x1) [/home/julliard/wine/wine/dlls/user32/message.c:1547] in user32 (0x0033f438) 10 0x6068bba1 SendMessageTimeoutA+0x201(hwnd=<register ESI not in topmost frame>, msg=0x414, wparam=0x6, lparam=0x33f53c, flags=0x0, timeout=0x0, res_ptr=0x33f4e0) [/home/julliard/wine/wine/dlls/user32/message.c:2457] in user32 (0x0033f4a8) 11 0x6068bc5c SendMessageA+0x4c(hwnd=0x4002c, msg=0x414, wparam=0x6, lparam=0x33f53c) [/home/julliard/wine/wine/dlls/user32/message.c:2496] in user32 (0x0033f4e8) 12 0x60507938 build_toolbar+0x2c8(nr=0x1, hParent=<is not available>) [/home/julliard/wine/wine/dlls/comctl32/tests/rebar.c:79] in comctl32_test (0x0033f5e8) 13 0x60508011 add_band_w+0x71(hRebar=<register EDI not in topmost frame>, lpszText=<is not available>, cxMinChild=<register ESI not in topmost frame>, cx=0x28, cxIdeal=0x64) [/home/julliard/wine/wine/dlls/comctl32/tests/rebar.c:288] in comctl32_test (0x0033f778) 14 0x6050c205 func_rebar+0x4175() [/home/julliard/wine/wine/dlls/comctl32/tests/rebar.c:358] in comctl32_test (0x0033fe58) 15 0x60525f20 run_test+0x120(name=0x1103a1) [/home/julliard/wine/wine/dlls/comctl32/tests/../../../include/wine/test.h:389] in comctl32_test (0x0033fea8) 16 0x605265a1 main+0x141(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/comctl32/tests/../../../include/wine/test.h:437] in comctl32_test (0x0033fed8) 17 0x6052666b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in comctl32_test (0x0033ff08) 18 0x7b86fbeb start_process+0xeb() in kernel32 (0x0033ffe8) 19 0x6001f7a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x601bb75b strlen+0xb in libc.so.6: cmpb %ch,0x0(%eax) Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

Feb. 19, 2007

Re: 1/4 NtCreateMailslotFile tests

by Jeff L

richardvoigt(a)gmail.com wrote: >> > Microsoft >> > appears to be pushing people away from NtClose. >> >> I'd suggest you to find a reason why. > That particular documentation happens to be part of the API released > under court order. They didn't want to give it out to begin with, and > they don't want people using it now. Ok I am happy with this as an explanation and will move the tests. Another case of MSDN telling fibs to the gullible. Jeff

Feb. 19, 2007

Re: Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1

by Marcus Meissner

On Sun, Feb 18, 2007 at 02:08:12PM -0700, Vitaliy Margolen wrote: > Sorry but I'm not longer interested in working on something that will > never be included in Wine. Why? I have no clue! If anyone can explain > that it would be helpfull to know for whomever next will try this. I > have removed all the related patches from my tree so that for sure won't > be me. > > Vitaliy. > > Mario Demontis wrote: > > Hello Vitaliy > > May you please send out the patches for ntoskrnl? > > > > Is there any reason why ntoskrnl doesn't get integrated into official > > wine? It needs major design work, as seen above. WINE will get there at some point in time, but its not foreseeable. Ciao, Marcus

Feb. 19, 2007

Re: Let's get rid of the FAQ and move it into the wiki

by Lei Zhang

On 2/18/07, Scott Ritchie <scott(a)open-vote.org> wrote: > Updating the FAQ is a bit of a pain, as is maintaining it. There is, > after all, still a lot of ancient stuff in it. > > Why not just move it into the wiki and point the link on the web page > there? I promise I'll watch it a bit closer. > > Thanks, > Scott Ritchie > Sounds like a good idea to me.

Feb. 19, 2007

Re: [PATCH 3/3] ntdll: fix up instruction pointer in context insideraise_exception

by Dmitry Timoshkov

"Peter Oberndorfer" <kumbayo84(a)arcor.de> wrote: > I'm not fully sure if the fixup also happens for other architectures > (i guess not) > so this patch is more a RFC > @@ -336,6 +336,10 @@ static NTSTATUS raise_exception( EXCEPTION_RECORD *rec, CONTEXT *context, BOOL f > if (status == DBG_CONTINUE || status == DBG_EXCEPTION_HANDLED) > return STATUS_SUCCESS; > > + /* fix up instruction pointer in context for EXCEPTION_BREAKPOINT */ > + if (rec->ExceptionCode == EXCEPTION_BREAKPOINT) > + GET_IP(context) = (DWORD_PTR)GET_IP(context) - 1; Gary Nebbett's book "Windows Nt/2000 Native API Reference" in the section C "Exceptions and Debugging" provides a pseudocode for KiDispatchException (page 439, Example C.1), and it does exactly the same thing as the patch above. *But* it does it as a very first thing after getting the context and before sending the debugger event. -- Dmitry.

Feb. 19, 2007

Re: What does it mean if doing WINEDEBUG=+relay fixes a bug?

by Marcus Meissner

On Mon, Feb 19, 2007 at 12:00:26AM -0600, Misha Koshelev wrote: > Hi, I am trying to debug bug #7484 but am having some problems as simply > doing a WINEDEBUG=+relay causes this bug to be fixed, thus making it > difficult for me to track it down (WINEDEBUG=+listview or WINEDEBUG= > +snoop do not have this effect of fixing it). If there is something that > the fact that this bug is fixed by +relay suggests, I would love to > know. This usually points to uninitialized variables or uninitialized memory on the stack, or timing issues or similar.. Ciao, Marcus

Feb. 19, 2007

What does it mean if doing WINEDEBUG=+relay fixes a bug?

by Misha Koshelev

Hi, I am trying to debug bug #7484 but am having some problems as simply doing a WINEDEBUG=+relay causes this bug to be fixed, thus making it difficult for me to track it down (WINEDEBUG=+listview or WINEDEBUG= +snoop do not have this effect of fixing it). If there is something that the fact that this bug is fixed by +relay suggests, I would love to know. Thanks a lot Misha

Feb. 19, 2007

Re: [wineconsole][dialog] Fix inversion in work Up-down control (Option Dialog)

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > struct dialog_info* di; > unsigned idc; > + unsigned nMaxHistUD = 500; > > switch (msg) > { > @@ -66,6 +67,8 @@ static INT_PTR WINAPI WCUSER_OptionDlgPr > di = (struct dialog_info*)((PROPSHEETPAGEA*)lParam)->lParam; > di->hDlg = hDlg; > SetWindowLongPtr(hDlg, DWLP_USER, (LONG_PTR)di); > + > + SendMessage(GetDlgItem(hDlg,IDC_OPT_HIST_SIZE_UD), UDM_SETRANGE, (WPARAM) 0, MAKELONG (nMaxHistUD, 0)); There is no need for (WPARAM) cast. Better use MAKELPARAM to construct an lParam instead of MAKELONG. Simple MAKELPARAM(500, 0) works just fine without introducing a new variable. -- Dmitry.

Feb. 18, 2007

Re: [start][start] Output with console encoding

by Dmitry Timoshkov

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > @@ -33,7 +33,20 @@ > static void output(const char *message) > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + WCHAR *bufW; > + char *bufC; > + int len = strlen(message); > + bufW = calloc(len+1,sizeof(WCHAR)); > + bufC = calloc(len+1,sizeof(CHAR)); Please do not use calloc/malloc calls in the Wine code, use win32 API HeapAlloc instead. > + MultiByteToWideChar( CP_ACP, 0, message, len, bufW, len ); > + WideCharToMultiByte( GetConsoleOutputCP(), 0, bufW, len, bufC, len, NULL, NULL ); > + bufC[len] = '\0'; Please refer to other parts of Wine code how to properly allocate space for this kind of a conversion. -- Dmitry.

Feb. 18, 2007

Re: Make wineprefixcreate put wordpad.exe where XP does; fixes bug 5627

by Dan Kegel

[reposting to right list. Maybe I should break down and subscribe to wine-devel so I can just hit 'reply'...] Detlef wrote: >The Idea sounds good, but your Patch is wrong for every >system in the World, that does not use English as locale: Oh, right. Well, at least I'm enthusiastic, if not wise :-) I guess the way to fix this right would be to create IDS_PROGRAM_FILES_ACCESSORIES analogous to IDS_PROGRAM_FILES; that would let us localize the path in shell32.dll, and setupapi.dll could handle it just like it does IDS_PROGRAM_FILES already (it translates the %16422% into the localized Program Files directory name). Then maybe get rid of the need to create the directores in wineprefixcreate by modifying create_fake_dll in setupapi/fakedll.c to create the directories if they don't exist. Lotta trouble to go through just to support broken-ish apps that need to know where wordpad is, but maybe I'll see about doing it if nobody else fixes this.

Feb. 18, 2007

Let's get rid of the FAQ and move it into the wiki

by Scott Ritchie

Updating the FAQ is a bit of a pain, as is maintaining it. There is, after all, still a lot of ancient stuff in it. Why not just move it into the wiki and point the link on the web page there? I promise I'll watch it a bit closer. Thanks, Scott Ritchie

Feb. 18, 2007

Re: Resend 1/4 NtCreateMailslotFile tests

by richardvoigt＠gmail.com

On 2/17/07, Eric Pouech <eric.pouech(a)wanadoo.fr> wrote: > Jeff L a écrit : > > Eric Pouech wrote: > >> Jeff Latimer a écrit : > >>> Establish the framework for testing NtCreateMailslotFile. Have > >>> fixed issues with NTSTATUS return codes etc. > >> those tests belong to dlls/ntdll, not dlls/kernel32 > >> also, if the test is for ntdll functions, it shouldn't use kernel32 > >> ones... hence, NtClose should be used instead of CloseHandle > > I put the proposition a while ago about putting the tests in kernel32 > > as, although they are ntdll functions, they related to mailslot > > functions and relating the tests would be easier on the tester. I > > take it that that is not the case? > my call would be to put the tests for functions sitting in DLL X in the > directory X/tests, even if we need to rewrite some code (or bother some > code from some other tests) > but as the API are different, we need in the end the both sets of test > perhaps split out ntdll tests, as in ntdll/tests/kernel32.c ?

Feb. 18, 2007

Re: 1/4 NtCreateMailslotFile tests

by richardvoigt＠gmail.com

> > Microsoft > > appears to be pushing people away from NtClose. > > I'd suggest you to find a reason why. That particular documentation happens to be part of the API released under court order. They didn't want to give it out to begin with, and they don't want people using it now. Perhaps someone should determine if there are any applications statically linking to any of those functions, which would disprove the claim "There is no import library, you must use GetProcAddress" and leave MS in violation of said order.

Feb. 18, 2007

Re: -ansi, -pedantic warnings and errors on

by richardvoigt＠gmail.com

On 2/18/07, Robert Shearman <rob(a)codeweavers.com> wrote: > Joris Huizer wrote: > > Though the keyword "inline" implies the code should get inlined, and > > if it shouldn't, the implementation copy should be removed from the > > unicode.h file > > No, it's a hint to the compiler. "static inline" says to the compiler > try to inline this function if it is worth it, or otherwise include a > copy of this function in the object file. "extern inline" says to the > compiler try to inline this function if it is worth it, or otherwise > link to shared copy of this function (in our case, implemented in the > libwine shared object). I believe just "inline" by itself has that effect. One doesn't ordinarily put "extern" on the function definition (unless it's 'extern "C"'). > > -- > Rob Shearman > > > >

Feb. 18, 2007

Re: ANN: Wiki upgrade

by Vitaliy Margolen

Dimi Paun wrote: > Folks, > > We finished upgrading the wiki to MoinMoin 1.5.7. > Please let me know if you encounter any problems. > Something hapaned to all tables. Ex: http://wiki.winehq.org/KnownIssues All cells have extra space in them. I don't see anything wrong with the text and it worked fine before. Vitaliy.

Feb. 18, 2007

Re: Mouse not warping properly in full screen mode

by Vitaliy Margolen

Raf Geens wrote: > When this has happened and you return to the main menu, it can occur > that for example the cursor can't reach the top part of the screen > anymore. It's as if an invisible rectangle that keeps the cursor > inside the screen has moved. In such a case, moving the cursor all the > way to the bottom and back up again restores normal behaviour. > > I've isolated the problem to the following line in dlls/dinput/mouse.c : That's the consequence and not the real place where the problem is. > > This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; Wine'd dinput warps mouse in some cases (much lesser number then it was before) while it shouldn't do that at all! The real issue is in x11drv which should warp mouse and report "relative" mouse moves while it doesn't. I've sent two patches that haven't been applied yet. See bug 6971 for more info. Vitaliy.

Feb. 18, 2007

Re: Mouse not warping properly in full screen mode

by Mirek

Hi similar bug with mouse in TES IV: Oblivion was introduced in wine 0.9.31 Mirek Raf Geens napsal(a): > Hi, > > I'm new to Wine and DirectX development, but I've dug around a bit in > the Wine source code to get Determinance, a sword-fighting game to > work. I've submitted an entry for it to the application database. > > The main problem I had was with strange mouse behaviour in full screen > mode. The player can rotate his character by holding down the right > mouse button and moving the mouse. In Windows, this allows you to turn > as much as you want. In Wine, the rotation stops at a certain point. > You can't see the cursor, but I'm fairly certain the point at which > movement stops is when the cursor hits the edge of the screen. > > When this has happened and you return to the main menu, it can occur > that for example the cursor can't reach the top part of the screen > anymore. It's as if an invisible rectangle that keeps the cursor > inside the screen has moved. In such a case, moving the cursor all the > way to the bottom and back up again restores normal behaviour. > > I've isolated the problem to the following line in dlls/dinput/mouse.c : > > This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; > > Changing it to This->need_warp = TRUE; as a quick test makes the mouse > behave correctly. > > I've read about the mouse warping hack over here: > http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a > TRACE statement displaying the variables in that line of code revealed > that: > > - it is only executed in full screen mode, and not in windowed mode > - dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false. > > So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading > about the meanings of the dwCoop values at msdn ( > http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers > might not have entirely been following the rules. However, it works > properly on Windows. Would it be acceptable to drop the > DISCL_EXCLUSIVE constraint? > > Raf Geens > > >

Feb. 18, 2007

Mouse not warping properly in full screen mode

by Raf Geens

Hi, I'm new to Wine and DirectX development, but I've dug around a bit in the Wine source code to get Determinance, a sword-fighting game to work. I've submitted an entry for it to the application database. The main problem I had was with strange mouse behaviour in full screen mode. The player can rotate his character by holding down the right mouse button and moving the mouse. In Windows, this allows you to turn as much as you want. In Wine, the rotation stops at a certain point. You can't see the cursor, but I'm fairly certain the point at which movement stops is when the cursor hits the edge of the screen. When this has happened and you return to the main menu, it can occur that for example the cursor can't reach the top part of the screen anymore. It's as if an invisible rectangle that keeps the cursor inside the screen has moved. In such a case, moving the cursor all the way to the bottom and back up again restores normal behaviour. I've isolated the problem to the following line in dlls/dinput/mouse.c : This->need_warp = (pt.x || pt.y) && dwCoop & DISCL_EXCLUSIVE; Changing it to This->need_warp = TRUE; as a quick test makes the mouse behave correctly. I've read about the mouse warping hack over here: http://www.kernel-traffic.com/wine/wn20040618_227.html#2 . Inserting a TRACE statement displaying the variables in that line of code revealed that: - it is only executed in full screen mode, and not in windowed mode - dwCoop is DISCL_NOWINKEY , causing the expression to evaluate to false. So it seems the DISCL_EXCLUSIVE constraint is too restrictive. Reading about the meanings of the dwCoop values at msdn ( http://tinyurl.com/2lmgbw ), I'm guessing the Determinance developers might not have entirely been following the rules. However, it works properly on Windows. Would it be acceptable to drop the DISCL_EXCLUSIVE constraint? Raf Geens

Feb. 18, 2007

Re: Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1

by Vitaliy Margolen

Sorry but I'm not longer interested in working on something that will never be included in Wine. Why? I have no clue! If anyone can explain that it would be helpfull to know for whomever next will try this. I have removed all the related patches from my tree so that for sure won't be me. Vitaliy. Mario Demontis wrote: > Hello Vitaliy > May you please send out the patches for ntoskrnl? > > Is there any reason why ntoskrnl doesn't get integrated into official > wine? > > Regards > Mario > > Il giorno gio, 27/07/2006 alle 23.08 -0600, Vitaliy Margolen ha scritto: >> Same as before. Just recompiled with new version. >> http://www.kievinfo.com/wine-0.9.18-1.2.i586.rpm >> http://www.kievinfo.com/wine-0.9.18-1.2.src.rpm >>

Feb. 18, 2007

Re: Lost KOI8-U.

by Oleh R. Nykyforchyn

On Sun, 18 Feb 2007 16:06:04 +0300 Anatoly Lyutin <vostok(a)etersoft.ru> wrote: > For generate collation table The cpmap.pl (/libs/wine) takes data from > www.unicode.org and I find some bugs in it. > Cpmap.pl uses for generate KOI8-U but in www.unicode.org this file absences! > I can not understand it... =( Some time ago I proposed a patch to support KOI8-U, and it was committed. I submitted an extra function to cpmap.pl to build KOI8-U file from KOI8-R.TXT from unicode.org, but afterwards I found out that cpmap.pl is left almost intact, except for a reference to KOI8-U.TXT that is absent at unicode.org. I guess that there is KOI8-U.TXT added to the local copy of ftp.unicode.org at winehq.org. It is quite reasonable because KOI8-U is an approved RFC**** and there cannot be a confusion because of distinct versions of this file. I hope that Wine team will not abandon KOI8-U support, at least I depend on it. Oleh R. Nykyforchyn

Feb. 18, 2007

Re: resend : gdi32:WidenPath partial implementation

by James Hawkins

On 2/18/07, Laurent Vromman <laurent(a)vromman.org> wrote: > Changelog : > - Add a partial implementation for the function gd32:WidenPath > > It is the second time I send this patch. It seems it was forgotten the > previous time. I am sorry for that. > > > If this patch needs to be improved, please let me know, I'll try to do it. > > Laurent Vromman > > > > > diff --git a/dlls/gdi32/path.c b/dlls/gdi32/path.c > index 306ed37..d9ccbb3 100644 > --- a/dlls/gdi32/path.c > +++ b/dlls/gdi32/path.c > @@ -1823,6 +1823,14 @@ BOOL WINAPI StrokePath(HDC hdc) > /******************************************************************* > * WidenPath [GDI32.@] > * > + * Redefines the current path as the area that would be painted if the path were stroked using the pen currently selected into the given device context. > + * > + * PARAMS > + * hdc [I] Handle to a device context that contains a closed path. > + * > + * RETURNS > + * Success: TRUE. The path is updated with the new computed path. > + * Failure: FALSE. > * You copied this documentation word-for-word from msdn, which is not allowed. -- James Hawkins

Feb. 18, 2007

Re: winecfg: Add check for device access to Drives tab.

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> Any reasons why this patch is not applied? >> http://www.winehq.org/pipermail/wine-patches/2007-January/035264.html >> >> This is one of the major headaches for users trying to get programs >> requiring direct CD-ROM drive access to work. And it's nearly impossible >> to get required information from users to find if the direct access >> actually works or not. > > I think you should distinguish the case of no device at all from the > case of a SCSI ioctl failing, for instance loop mounts wouldn't > support the ioctl but would still work fine for many things. Also the That is exactly the point! Some "smart" users use iso images and complain that cd-checks fail. This is a more generic ioctl that will fail on a loop device. And that's a reason I used it. > no device case needs to be less scary, there's nothing wrong with it I disagree. It have to be scary! It have to tell user that they do not have direct access to the device. And that enything that will try doing that will fail! In most cases users will get some obscure error messages that will tell them nothing about the actual cause. I want to have at least one place where we can point users to go look if they have or properly configured system or not. > for most devices. And the strings need to be in resources. Will do that. Vitaliy.

Feb. 18, 2007

Re: Updated version of Wine-0.9.18 RPMs with ntoskrnl for SuSE 10.1

by Mario Demontis

Hello Vitaliy May you please send out the patches for ntoskrnl? Is there any reason why ntoskrnl doesn't get integrated into official wine? Regards Mario Il giorno gio, 27/07/2006 alle 23.08 -0600, Vitaliy Margolen ha scritto: > Same as before. Just recompiled with new version. > http://www.kievinfo.com/wine-0.9.18-1.2.i586.rpm > http://www.kievinfo.com/wine-0.9.18-1.2.src.rpm >

Feb. 18, 2007

Re: generic.ppd does not appear in the build dir - cannot print

by Detlef Riekenberg

On Sa, 2007-02-17 at 18:08 -0500, Michael [Plouj] Ploujnikov wrote: > However, here are the messages that I started getting: > > $ wine notepad > Couldn't find PPD file This can only happen, when wine is unable to receive a ppd-File from CUPS and no ppd-file is configured in the registry. See my previous message : http://www.winehq.org/pipermail/wine-devel/2007-January/053617.html ("trace:winspool:CUPS_LoadPrinters loaded libcups.so.2") What do you get from: $ grep -i cups include/config.h Where is the library located, that is used in "#define SONAME_LIBCUPS" from above $ find /usr/l* -name libcups.* What do you get from: $ file <your_path_and_name_from_above> $ file /usr/lib/libcups.* $ file /usr/lib64/libcups.* > After some playing around I realized that generic.pdd resides in my > Wine source checkout directory: > but not inside the build directory: That is an issue, that must be fixed in wine. > After finding a quick solution I'm wondering what, a person like me, > who builds (and runs) wine in a directory parallel to the source, I do the same here, but my wine is using CUPS -- By by ... Detlef

Feb. 18, 2007

RE: [start][start] Output with console encoding

by Vitaliy Margolen

> Changelog: > Fix output console to output with console encoding. > static void output(const char *message) > Index: programs/start/start.c > =================================================================== > RCS file: /home/wine/wine/programs/start/start.c,v > retrieving revision 1.5 > diff -u -p -u -r1.5 start.c > --- programs/start/start.c 23 May 2006 12:49:22 -0000 1.5 > +++ programs/start/start.c 30 Jan 2007 09:47:52 -0000 > @@ -33,7 +33,20 @@ > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + WCHAR *bufW; > + char *bufC; > + int len = strlen(message); > + bufW = calloc(len+1,sizeof(WCHAR)); > + bufC = calloc(len+1,sizeof(CHAR)); > + > + MultiByteToWideChar( CP_ACP, 0, message, len, bufW, len ); > + WideCharToMultiByte( GetConsoleOutputCP(), 0, bufW, len, bufC, len, NULL, NULL ); > + bufC[len] = '\0'; > + > + WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), bufC, len, &count, NULL); > + > + free(bufW); > + free(bufC); > } This is not correct. This function and everything else, using it should be rewritten as unicode, not ansi. Also you should use HeapAlloc/HeapFree. Vitaliy.

Feb. 18, 2007

kernel32 (profile.c): allow profile section and key names of zero length patch

by Claudio Fontana

Hello all, I was wondering if there's anything wrong with my patch to kernel32/profile.c and its tests: http://www.winehq.org/pipermail/wine-patches/2007-February/035468.html It fixes a problem that causes applications built with Multimedia Fusion to fail under wine, since the "INI object" of MF relies on zero length section and key names to store and retrieve values. The changes in tests/profile.c contain new testcases, and a generally useful fix to the tests, where some values are currently passed directly to the functions instead of using the values in the testcases table. If there's anything unclear or wrong about this patch, please tell me so that I will be able to fix it. Thanks, Claudio

Feb. 18, 2007

Re: lostwages/ news/2006081001.xml news/2007021602 ...

by Jeremy Newman

Yes, that is on my todo list. First, I need each of the wineowner users to contact me so I can get them setup. On Sat, 2007-02-17 at 20:23 +0100, Francois Gouget wrote: > On Fri, 16 Feb 2007, WineHQ wrote: > > > ChangeSet ID: 30931 > > CVSROOT: /opt/cvs-commit > > Module name: lostwages > > Changes by: wineowner(a)winehq.org 2007/02/16 18:13:29 > > Could we get rid of wineowner account? It makes it impossible to know > who's doing the changes. Each user having access to the WineHQ box > should have his own login. > > Welcome back Brian (if I read the wwn right). >

Feb. 18, 2007

Re: Make wineprefixcreate put wordpad.exe where XP does; fixes bug 5627

by Detlef Riekenberg

On Sa, 2007-02-17 at 13:32 -0800, Dan Kegel wrote: > +++ b/tools/wine.inf > @@ -2149,6 +2149,7 @@ HKLM,%CurrentVersion%\Telephony\Country > > [FakeDllsSection] > +10,..\Program Files\Windows NT\Accessories,wordpad.exe > +++ b/tools/wineprefixcreate.in > + "$CROOT/Program Files" \ > + "$CROOT/Program Files/Windows NT" \ > + "$CROOT/Program Files/Windows NT/Accessories" The Idea sounds good, but your Patch is wrong for every system in the World, that does not use English as locale: My XP has wordpad.exe here: "C:\Programme\Windows NT\Zubehör\wordpad.exe" -- By by ... Detlef

Feb. 18, 2007

Re: Error in ntdll/module.c?

by Eric Pouech

Rolf Kalbermatter a écrit : > Christian Iversen [mailto:chrivers(a)iversen-net.dk] wrote: > > >> According to: >> >> http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/ >> Executable%20Images/LdrGetProcedureAddress.html >> >> The parameter order for LdrGetProcedureAddress is (Handle, Function, >> Ordinal, Address) >> >> The file dlls/ntdll/module.c has the order as (Handle, Ordinal, >> Function, Address) >> > > Ok. I took a look at the call sequence of this function in a native > kernel32.dll and the second parameter is initialized with RtlInitString. > So I guess the parameter order as on that web site would be correct. > > Having looked at the particular assembly code obviously excludes me > from doing any work on this part anymore. > > As to the current implemenation I'm not sure that makes any difference > since most undocumented APIs are unlikely to be used by applications. > And since ntdll and kernel32 are both also Wine specific and therefore > can't be replaced by Windows ones this won't matter either it would seem. > > You can try to post a proper patch to both kernel32 and ntdll to > wine-patches and then let Alexandre decide if he wants to apply it. > googling LdrGetProcedureAddress gives the same conclusion It's always a good idea to have APIs behaving like on windows A+

Feb. 18, 2007

Re: [PATCH] return when not finding the name

by Marcus Meissner

On Sun, Feb 18, 2007 at 01:40:12PM +0100, Eric Pouech wrote: > Marcus Meissner a écrit : > >--- > > dlls/dbghelp/dwarf.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > >diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > >index 4f74b6a..f51a948 100644 > >--- a/dlls/dbghelp/dwarf.c > >+++ b/dlls/dbghelp/dwarf.c > >@@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar > > > > TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di)); > > > >- if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string > >= NULL; > >+ if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; > > if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) > > value.u.svalue = 0; > > symt_add_enum_element(ctx->module, parent, name.u.string, > > value.u.svalue); > > > > > Hi Marcus, > > can you send me the ELF file(s) which is/are causing this? There is no ELF file. Coverity spotted this as error, since name.u.string can be NULL in the flow and symt_add_enum_element() would crash in pool_strdup. It is CID 461. 462 and 463 are related issues. Ciao, Marcus

Feb. 18, 2007

Re: Error in ntdll/module.c?

by Rolf Kalbermatter

Christian Iversen [mailto:chrivers(a)iversen-net.dk] wrote: >According to: > >http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/ >Executable%20Images/LdrGetProcedureAddress.html > >The parameter order for LdrGetProcedureAddress is (Handle, Function, >Ordinal, Address) > >The file dlls/ntdll/module.c has the order as (Handle, Ordinal, >Function, Address) Ok. I took a look at the call sequence of this function in a native kernel32.dll and the second parameter is initialized with RtlInitString. So I guess the parameter order as on that web site would be correct. Having looked at the particular assembly code obviously excludes me from doing any work on this part anymore. As to the current implemenation I'm not sure that makes any difference since most undocumented APIs are unlikely to be used by applications. And since ntdll and kernel32 are both also Wine specific and therefore can't be replaced by Windows ones this won't matter either it would seem. You can try to post a proper patch to both kernel32 and ntdll to wine-patches and then let Alexandre decide if he wants to apply it. Rolf Kalbermatter

Feb. 18, 2007

Lost KOI8-U.

by Anatoly Lyutin

Feb. 18, 2007

Re: -ansi, -pedantic warnings and errors on

by Robert Shearman

Joris Huizer wrote: > Though the keyword "inline" implies the code should get inlined, and > if it shouldn't, the implementation copy should be removed from the > unicode.h file No, it's a hint to the compiler. "static inline" says to the compiler try to inline this function if it is worth it, or otherwise include a copy of this function in the object file. "extern inline" says to the compiler try to inline this function if it is worth it, or otherwise link to shared copy of this function (in our case, implemented in the libwine shared object). -- Rob Shearman

Feb. 18, 2007

Re: [PATCH] return when not finding the name

by Eric Pouech

Marcus Meissner a écrit : > --- > dlls/dbghelp/dwarf.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c > index 4f74b6a..f51a948 100644 > --- a/dlls/dbghelp/dwarf.c > +++ b/dlls/dbghelp/dwarf.c > @@ -1203,7 +1203,7 @@ static void dwarf2_parse_enumerator(dwar > > TRACE("%s, for %s\n", dwarf2_debug_ctx(ctx), dwarf2_debug_di(di)); > > - if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) name.u.string = NULL; > + if (!dwarf2_find_attribute(ctx, di, DW_AT_name, &name)) return; > if (!dwarf2_find_attribute(ctx, di, DW_AT_const_value, &value)) value.u.svalue = 0; > symt_add_enum_element(ctx->module, parent, name.u.string, value.u.svalue); > > Hi Marcus, can you send me the ELF file(s) which is/are causing this? A+

Feb. 18, 2007

Re: Error in ntdll/module.c?

by Uwe Bonnes

>>>>> "Christian" == Christian Iversen <chrivers(a)iversen-net.dk> writes: Christian> (Please CC me, I'm not on the list) Christian> According to: Christian> http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Execu… Christian> The parameter order for LdrGetProcedureAddress is (Handle, Christian> Function, Ordinal, Address) Christian> The file dlls/ntdll/module.c has the order as (Handle, Christian> Ordinal, Function, Address) Christian> This of course works well because kernel32.dll is the only Christian> caller (and it indeed uses, if not the correct, then at least Christian> the same order). Christian> I haven't attached a patch, because I'm not actually sure Christian> which version is right. Anyone? Write a test for our test suite and run the test on wine and a windows machine. Send at least the test. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Feb. 18, 2007

Re: patches and more

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: >> this one should be added to windows.h (maybe it's not the best >> place for it, but it works): >> >> #define stricmp strcasecmp > > This define is not present in the Platform SDK. It is a by-product of > using glibc instead of msvcrt as your C library. If you used the headers > in include/msvcrt and added -lmsvcrt to the linker command line then it > should have worked out of the box. If you want to link against glibc, > then think of changing stricmp to strcasecmp as part of porting the program. Rob is right, but I'd like to point out to a caveat caused by using strcasecmp instead of a Win32 API: since Unix and Wine internal (Win32) *are* different, that could lead to subtle bugs in many locales. -- Dmitry.

Feb. 17, 2007

Re: Font issue - workaround found

by Dmitry Timoshkov

"Timm" <timmr(a)atlanticbb.net> wrote: > My one win app that makes me a devotee of WINE is TablEdit > (demo at www.tabledit.com/download/tabled32.exe) > has a custom font , tef260.ttf, that has failed to display since > somewhere after ver 9.6. The program installs the font into > c:\windows\font, but can not display it within the program, instead > displaying for the most part, empty squares. After reading WWN with this problem raised again, I think that it sounds like the same bug as reported in http://bugs.winehq.org/show_bug.cgi?id=7379 Could you please re-test with Wine 0.9.31 and report if the problem still persists? -- Dmitry.

Feb. 17, 2007

re: generic.ppd does not appear in the build dir - cannot print

by Dan Kegel

> [I keep my source and object in different directories, and generic.ppd isn't found during build] That method of building is great, and is supported, but not too many people build that way, so bugs do creep in. You can either keep living with the workaround you found, or submit a patch to fix the build. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Feb. 17, 2007

generic.ppd does not appear in the build dir - cannot print

by Michael [Plouj] Ploujnikov

With a recent update to Wine 0.9.31, my printing issue [1] has changed in some way that actually generated some meaningful error messages being printed. I don't know if this is indeed the same issue or not. However, here are the messages that I started getting: $ wine notepad Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! Couldn't find PPD file '/home/plouj/apps/build_dir/dlls/wineps.drv/generic.ppd', expect a crash now! err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"our old printer" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! Note: my Wine source is checked out from git into ~/apps/wine-git . However, I execute ./configure && make inside ~/apps/build_dir to separate the source from the build files. I also run Wine by executing ~/apps/build_dir/wine . After some playing around I realized that generic.pdd resides in my Wine source checkout directory: $ file ~/apps/wine-git/dlls/wineps.drv/generic.ppd /home/plouj/apps/wine-git/dlls/wineps.drv/generic.ppd: PPD file, ve but not inside the build directory: ls ~/apps/build_dir/dlls/wineps.drv/*.ppd ls: cannot access /home/plouj/apps/build_dir/dlls/wineps.drv/*.ppd: No such file or directory After simply copying generic.pdd to my build directory I was able to print without (absolutely any) errors or warning messages. After finding a quick solution I'm wondering what, a person like me, who builds (and runs) wine in a directory parallel to the source, should do in this case? Should I just live with this hack-ish copying of the .ppd file? Is my usage case not 'popular' enough to warrant a fix? Is this how Autotools is supposed to be used to install generic.ppd? Why didn't the older versions of Wine [2] have this issue? The Makefile doesn't look promising to me: install install-lib:: $(DESTDIR)$(datadir)/wine $(INSTALL_DATA) $(SRCDIR)/generic.ppd $(DESTDIR)$(datadir)/wine/generic.ppd The way I understand this is that generic.ppd is meant to reside in the source directory and the install directory only. This probably means that Autotools won't put it in the build directory. References [1] - http://www.winehq.org/pipermail/wine-devel/2007-January/053606.html [2] - As you can see I've been successfully printing with a non-free application running under Wine since around 0.9.9: http://appdb.winehq.org/appview.php?iVersionId=4498 -- Libre Software: http://www.gnu.org/philosophy/free-sw.html

Feb. 17, 2007

Re: 32 bpp cursors?

by H. Verbeet

On 17/02/07, Duane Clark <dclark(a)akamail.com> wrote: > Well, no server changes are needed just to implement 32 bits per pixel. > There are rather simple changes needed in the file > dlls/winex11.drv/mouse.c in create_cursor(), and the places that need to > be changed are cleverly marked by "switch (ptr->bBitsPerPixel)" ;) > > I tried installing Google Sketchup, but could not get that to install. > That said, it looks like 32 bit pixels use 8 bits each of RGB, plus an > extra 8 bits of "alpha" (which apparently controls transparency). So > probably you could duplicate the 24 bit case, read out the extra 8 bits > and just throw them away for now. Standard X cursors don't support > alpha, AFAIK. > The only thing that really needs cursors to be in the server is passing cursor/icon handles around between processes.

Feb. 17, 2007

Re: 32 bpp cursors?

by H. Verbeet

On 17/02/07, Dan Kegel <dank(a)kegel.com> wrote: > Could you break off some of the features and > do them first, e.g. 32 bpp cursors? > - Dan > My plan was to redo the set for local cursors only, but there's also wined3d that needs attention :-)

Feb. 17, 2007

Re: 32 bpp cursors?

by Duane Clark

Dan Kegel wrote: > http://bugs.winehq.org/show_bug.cgi?id=4273 points to a > patch set that implements 32 bit per pixel cursors > and a bunch of other cursor stuff. > > Looks like the patch got dropped by the author, though, > and since it makes server changes, it's going to be hard > to get past Alexandre. > > Is anyone interested in picking this up? Well, no server changes are needed just to implement 32 bits per pixel. There are rather simple changes needed in the file dlls/winex11.drv/mouse.c in create_cursor(), and the places that need to be changed are cleverly marked by "switch (ptr->bBitsPerPixel)" ;) I tried installing Google Sketchup, but could not get that to install. That said, it looks like 32 bit pixels use 8 bits each of RGB, plus an extra 8 bits of "alpha" (which apparently controls transparency). So probably you could duplicate the 24 bit case, read out the extra 8 bits and just throw them away for now. Standard X cursors don't support alpha, AFAIK.

Feb. 17, 2007

Re: 32 bpp cursors?

by Dan Kegel

On 2/16/07, H. Verbeet wrote: >> http://bugs.winehq.org/show_bug.cgi?id=4273 points to a >> patch set that implements 32 bit per pixel cursors >> and a bunch of other cursor stuff. [What's up with it?] > >I believe the problem is not that Henri has dropped the patches. >The problem was that Alexandre didn't have time for reviewing the patches. >The patches are very, very, very big and change big parts of Wine. >For this reason Alexandre is reluctant in applying it. Is it neccessary to move cursors into the server first? Could you break off some of the features and do them first, e.g. 32 bpp cursors? - Dan

Feb. 17, 2007

Re: -ansi, -pedantic warnings and errors on

by Joris Huizer

Robert Shearman <rob(a)codeweavers.com> wrote: Joris Huizer wrote: > Hello, > > I was looking at the result of configuring with -ansi, > -pedantic flags. It gives loads of warnings (not all > relevant - also complaining about 'long long' not > being ansi) and indicates unnamed unions, among other > things. > Could someone confirm my idea that unnamed unions must > all be dealt with? Am hoping to fix those if I get it > to compile thus far; > > At this point, it complains about > include/wine/unicode.h which has the combination > 'extern' and 'inline', which it doesn't like. > Getting rid of that, with -Dinline=__inline__, helps > it get a bit further > > Next it complains about is libs/wine/string.c, which > implements several functions that are also implemented > in include/wine/unicode.h. These are again the 'extern > inline' functions. > > As most headers have 'static inline' instead of > 'extern inline', with the advantage of not having to > duplicate the functions. I'm hoping this is an allowed > fix, it gets compiling further anyway > On modern CPUs it is much better to have one copy of the function instead of inlining it. Making the functions static instead of extern will probably cause wine to be a bit slower at the expense of silencing some not very useful warnings. If you want to fix it for this case, I suggest you add a define that changes to "static inline" if pedantic/ansi mode is being used and "extern inline" otherwise and use it when declaring the functions. -- Rob Shearman Well if it isn't applied (btw how could I see what is/isn't applied?) will try to look at that. Though the keyword "inline" implies the code should get inlined, and if it shouldn't, the implementation copy should be removed from the unicode.h file Joris --------------------------------- Have a burning question? Go to Yahoo! Answers and get answers from real people who know.

Feb. 17, 2007

Re: -ansi, -pedantic warnings and errors on

by Robert Shearman

Joris Huizer wrote: > Hello, > > I was looking at the result of configuring with -ansi, > -pedantic flags. It gives loads of warnings (not all > relevant - also complaining about 'long long' not > being ansi) and indicates unnamed unions, among other > things. > Could someone confirm my idea that unnamed unions must > all be dealt with? Am hoping to fix those if I get it > to compile thus far; > > At this point, it complains about > include/wine/unicode.h which has the combination > 'extern' and 'inline', which it doesn't like. > Getting rid of that, with -Dinline=__inline__, helps > it get a bit further > > Next it complains about is libs/wine/string.c, which > implements several functions that are also implemented > in include/wine/unicode.h. These are again the 'extern > inline' functions. > > As most headers have 'static inline' instead of > 'extern inline', with the advantage of not having to > duplicate the functions. I'm hoping this is an allowed > fix, it gets compiling further anyway > On modern CPUs it is much better to have one copy of the function instead of inlining it. Making the functions static instead of extern will probably cause wine to be a bit slower at the expense of silencing some not very useful warnings. If you want to fix it for this case, I suggest you add a define that changes to "static inline" if pedantic/ansi mode is being used and "extern inline" otherwise and use it when declaring the functions. -- Rob Shearman

Feb. 17, 2007

Re: patches and more

by Robert Shearman

David Saez Padros wrote: > This line should be added to commctrl.h: > > #define ListView_GetOrigin(hwndLV, ppt) \ > (BOOL)SNDMSG((hwndLV), LVM_GETORIGIN, (WPARAM)0, (LPARAM)ppt) I've submitted a patch for this. > this one should be added to windows.h (maybe it's not the best > place for it, but it works): > > #define stricmp strcasecmp This define is not present in the Platform SDK. It is a by-product of using glibc instead of msvcrt as your C library. If you used the headers in include/msvcrt and added -lmsvcrt to the linker command line then it should have worked out of the box. If you want to link against glibc, then think of changing stricmp to strcasecmp as part of porting the program. -- Rob Shearman

Feb. 17, 2007

Re: lostwages/ news/2006081001.xml news/2007021602 ...

by Francois Gouget

On Fri, 16 Feb 2007, WineHQ wrote: > ChangeSet ID: 30931 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: wineowner(a)winehq.org 2007/02/16 18:13:29 Could we get rid of wineowner account? It makes it impossible to know who's doing the changes. Each user having access to the WineHQ box should have his own login. Welcome back Brian (if I read the wwn right). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Feb. 17, 2007

Re: Resend 1/4 NtCreateMailslotFile tests

by Eric Pouech

Jeff L a écrit : > Eric Pouech wrote: >> Jeff Latimer a écrit : >>> Establish the framework for testing NtCreateMailslotFile. Have >>> fixed issues with NTSTATUS return codes etc. >> those tests belong to dlls/ntdll, not dlls/kernel32 >> also, if the test is for ntdll functions, it shouldn't use kernel32 >> ones... hence, NtClose should be used instead of CloseHandle > I put the proposition a while ago about putting the tests in kernel32 > as, although they are ntdll functions, they related to mailslot > functions and relating the tests would be easier on the tester. I > take it that that is not the case? my call would be to put the tests for functions sitting in DLL X in the directory X/tests, even if we need to rewrite some code (or bother some code from some other tests) but as the API are different, we need in the end the both sets of test rationale behind this: - that's what is the most logical - when someone changes DLL X, he/she doesn't want (at first) to rerun the tests from every DLL note: there's currently only one case of this (in kernel32/tests) for virtual memory, and it should be moved to ntdll A+

Feb. 17, 2007

Error in ntdll/module.c?

by Christian Iversen

(Please CC me, I'm not on the list) According to: http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Execu… The parameter order for LdrGetProcedureAddress is (Handle, Function, Ordinal, Address) The file dlls/ntdll/module.c has the order as (Handle, Ordinal, Function, Address) This of course works well because kernel32.dll is the only caller (and it indeed uses, if not the correct, then at least the same order). I haven't attached a patch, because I'm not actually sure which version is right. Anyone? -- Mvh Christian Iversen

Feb. 17, 2007

Re: 1/4 NtCreateMailslotFile tests

by Dmitry Timoshkov

"Jeff L" <lats(a)yless4u.com.au> wrote: >>> Have reread MSDN >>> http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems >>> that NtClose has been superseded by CloseHandle. So I suppose that >>> CloseHandle is the one to use. >> >> The information in MSDN is misleading in this case, CloseHandle is a >> kernel32 >> API, not an NT (native) one. >> > So the correct move is to use the depreciated function? It's not deprecated, even Microsof tries to create an impression it is. > Microsoft > appears to be pushing people away from NtClose. I'd suggest you to find a reason why. > Is the it that they are > reserving NtClose etc for their ntdll use? Also I'd suggest to learn about a difference between Native and Win32 API before writing the tests that mix them. -- Dmitry.

Feb. 17, 2007

-ansi, -pedantic warnings and errors on

by Joris Huizer

Hello, I was looking at the result of configuring with -ansi, -pedantic flags. It gives loads of warnings (not all relevant - also complaining about 'long long' not being ansi) and indicates unnamed unions, among other things. Could someone confirm my idea that unnamed unions must all be dealt with? Am hoping to fix those if I get it to compile thus far; At this point, it complains about include/wine/unicode.h which has the combination 'extern' and 'inline', which it doesn't like. Getting rid of that, with -Dinline=__inline__, helps it get a bit further Next it complains about is libs/wine/string.c, which implements several functions that are also implemented in include/wine/unicode.h. These are again the 'extern inline' functions. As most headers have 'static inline' instead of 'extern inline', with the advantage of not having to duplicate the functions. I'm hoping this is an allowed fix, it gets compiling further anyway ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097

Feb. 17, 2007

Re: Resend 1/4 NtCreateMailslotFile tests

by Jeff L

Eric Pouech wrote: > Jeff Latimer a écrit : >> Establish the framework for testing NtCreateMailslotFile. Have fixed >> issues with NTSTATUS return codes etc. > those tests belong to dlls/ntdll, not dlls/kernel32 > also, if the test is for ntdll functions, it shouldn't use kernel32 > ones... hence, NtClose should be used instead of CloseHandle I put the proposition a while ago about putting the tests in kernel32 as, although they are ntdll functions, they related to mailslot functions and relating the tests would be easier on the tester. I take it that that is not the case? Jeff

Feb. 17, 2007

Re: Resend 1/4 NtCreateMailslotFile tests

by Eric Pouech

Jeff Latimer a écrit : > Establish the framework for testing NtCreateMailslotFile. Have fixed > issues with NTSTATUS return codes etc. those tests belong to dlls/ntdll, not dlls/kernel32 also, if the test is for ntdll functions, it shouldn't use kernel32 ones... hence, NtClose should be used instead of CloseHandle A+

Feb. 17, 2007

Re: 1/4 NtCreateMailslotFile tests

by Jeff L

Dmitry Timoshkov wrote: > "Jeff L" <lats(a)yless4u.com.au> wrote: > >>> To close the handle returned by an NT API you have you use an NT API >>> as well. > > What is not apparent in the explanation above? I have no problem with what you have said though I did have a bit of difficulty marrying to the sentence below. > >> Have reread MSDN >> http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems >> that NtClose has been superseded by CloseHandle. So I suppose that >> CloseHandle is the one to use. > > The information in MSDN is misleading in this case, CloseHandle is a > kernel32 > API, not an NT (native) one. > So the correct move is to use the depreciated function? Microsoft appears to be pushing people away from NtClose. Is the it that they are reserving NtClose etc for their ntdll use? Jeff

Feb. 17, 2007

Re: 32 bpp cursors?

by Roderick Colenbrander

> http://bugs.winehq.org/show_bug.cgi?id=4273 points to a > patch set that implements 32 bit per pixel cursors > and a bunch of other cursor stuff. > > Looks like the patch got dropped by the author, though, > and since it makes server changes, it's going to be hard > to get past Alexandre. > > Is anyone interested in picking this up? > - Dan > I believe the problem is not that Henri has dropped the patches. The problem was that Alexandre didn't have time for reviewing the patches. The patches are very, very, very big and chance big parts of Wine. For this reason Alexandre is reluctant in applying it. Roderick -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

Feb. 17, 2007

Re: 1/4 NtCreateMailslotFile tests

by Dmitry Timoshkov

"Jeff L" <lats(a)yless4u.com.au> wrote: >> To close the handle returned by an NT API you have you use an NT API >> as well. What is not apparent in the explanation above? > Have reread MSDN http://msdn2.microsoft.com/en-us/library/ms648410.aspx > and it seems that NtClose has been superseded by CloseHandle. So I > suppose that CloseHandle is the one to use. The information in MSDN is misleading in this case, CloseHandle is a kernel32 API, not an NT (native) one. -- Dmitry.

Feb. 17, 2007

Re: 1/4 NtCreateMailslotFile tests

by Jeff L

Dmitry Timoshkov wrote: > "Jeff Latimer" <lats(a)yless4u.com.au> wrote: >> + ok( CloseHandle(hslot), "CloseHandle failed\n"); > To close the handle returned by an NT API you have you use an NT API > as well. Have reread MSDN http://msdn2.microsoft.com/en-us/library/ms648410.aspx and it seems that NtClose has been superseded by CloseHandle. So I suppose that CloseHandle is the one to use. Have fixed the other points. Jeff

Feb. 17, 2007

Re: comctl32: rebar: New conformance test for CCS_NORESIZE style.[PATCH 1/2]

by Dmitry Timoshkov

"Misha Koshelev" <mk144210(a)bcm.tmc.edu> wrote: > +/* MSDN 672579: "CCS_NORESIZE: Prevents the control from using the default width and height when setting its > + * initial size or a new size. Instead, the control uses the width and height specified in the request for > + * creation or sizing." This test checks both creation and sizing dimensions. */ You can't quote MSDN in the Wine code, but you can explain the problem using your own wording. -- Dmitry.

Feb. 17, 2007

32 bpp cursors?

by Dan Kegel

http://bugs.winehq.org/show_bug.cgi?id=4273 points to a patch set that implements 32 bit per pixel cursors and a bunch of other cursor stuff. Looks like the patch got dropped by the author, though, and since it makes server changes, it's going to be hard to get past Alexandre. Is anyone interested in picking this up? - Dan

Feb. 16, 2007

Re: VB, Access based program on Linux

by Dan Kegel

[-wine-users, +wine-devel] On 2/6/07, Dan Kegel <dank(a)kegel.com> wrote: > Neelesh wrote: > >I work in one public charitable trust. Here we are using one > >Accounting+Inventory+Report management Program. Two developers have > >developed in VB, Access and Crystal Reports. > > > >Now I am trying to use it through wine on linux.... > ... > If you want to help us get Wine ready for > VB/Access applications, you could send a Wine > developer a copy of your application so he could > look at the problems locally. Thanks for sending the app to me. Of the many problems it seems to present, I'm starting with the first one: an error dialog during install. When it tries to run a couple subinstallers, it fails, and puts up a dialog box saying the directory is invalid. After a bit of looking, I am starting to suspect that ShellExecuteEx is being called by the installer with a quoted directory name, and Wine isn't handling that right. Here's a bit of log: dank(a)krunch:/C:/foo/bar_Installation$ grep -i Shell.*Execute log7.c 000e:Call shell32.ShellExecuteExA(0035f40c) ret=0041e5a4 000e:trace:exec:SHELL_execute mask=0x00000640 hwnd=0x1002c verb=L"open" file=L"C:\\foo\\bar_Installation\\InstMsiA.EXE" parm=L"" dir=L"\"C:\\foo\\bar_Installation" show=0x00000001 class=not used 000e:fixme:exec:SHELL_execute flags ignored: 0x00000400 000e:trace:exec:ShellExecute_FromContextMenu L"C:\\foo\\bar_Installation\\InstMsiA.EXE" 000e:trace:exec:ShellExecute_GetClassKey ext = L".EXE" 000e:trace:exec:ShellExecute_GetClassKey class = L"exefile" 000e:trace:exec:SHELL_execute execute:L"C:\\foo\\bar_Installation\\InstMsiA.EXE",L"",L"\"C:\\foo\\bar_Installation" 000e:trace:exec:SHELL_ExecuteW Execute L"C:\\foo\\bar_Installation\\InstMsiA.EXE" from directory L"\"C:\\foo\\bar_Installation" 000e:err:exec:SHELL_ExecuteW cannot set directory L"\"C:\\foo\\bar_Installation" 000e:trace:exec:SHELL_ExecuteW CreateProcess returned error 267 000e:trace:exec:SHELL_ExecuteW returning 11 The directory only has a quote mark at the beginning; this may be a bug in your installer, but if Windows' ShellExecute can handle that, Wine should be able to, too. My computer time is limited, or I'd add a testcase in shell32/tests/shlexec.c to check this. Maybe someone else can have a look. - Dan

Feb. 16, 2007

Re: comctl32: move up-down msg seq tests into new 'msg' test

by Lei Zhang

On 2/13/07, James Hawkins <truiken(a)gmail.com> wrote: > On 2/13/07, Felix Nawothnig <flexo(a)holycrap.org> wrote: > > James Hawkins wrote: > > > This is not what needs to happen. The generic message sequence > > > testing code needs to be factored into msg.c, but the specific tests > > > need to stay in each control's test file. > > > > Guessed so... How about putting it into include/wine/test.h to share the > > code with user32/msg? Wouldn't help object size but I don't think a > > shared lib would be worth it... > > > > No, comctl32's message sequence testing code is different than > user32's, and will be even more different when I add in WM_NOTIFY > testing support. > > -- > James Hawkins > I sent a couple of new patches for this: http://www.winehq.org/pipermail/wine-patches/2007-February/035992.html http://www.winehq.org/pipermail/wine-patches/2007-February/035993.html - Lei

Feb. 16, 2007

calling _splitpath from cmd.exe, and 64 bit decimal formatting

by Ann & Jason Edmeades

Hello, Its been a while since I did any wine work so thought I'd fix some bugs in the cmd shell. I have come across a call which fails at compile time which I was interested in knowing the 'right' way to solve _splitpath appears to exist in ntdll, but none of the #includes I have tried pick it up. Stblib, for example, is just using the standard compiler one. Additionally looking at winefile it has just copied the implementation in, so why did it do that? Also, I wanted to sprintf using %I64d but again I believe we are ending up using the standard sprintf gcc library function which does not support it. Is there any easy way around this (its trivial functionality which can be left as a fixme if not). Jason

Feb. 16, 2007

Re: Google Summer of Code 2007

by Kai Blin

On Friday 16 February 2007 16:21, Tom Wickline wrote: > I see Google is going to do there summer of code again this year :-) Yup, let's see what it will bring this year. > They plan to start accepting applications in March, so now would be > the time for us to propose new projects and review the ones we have > already listed on the Wiki for interested applicants? I'm not at all convinced anymore that DirectPlay is a SoC scope. I _might_ consider giving that a dash myself, but only if I manage to get some more groundwork covered on the wire protocol side of things. I've updated the Wiki page and removed the proposals that were successful last year. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Feb. 16, 2007

Re: [5/10] DDraw: Fix a leak in a test

by Stefan Dösinger

Am Freitag 16 Februar 2007 21:28 schrieb H. Verbeet: > Does this really matter? Not really, but it avoids a few FIXMEs about unreleased surfaces and textures. We could downgrade the FIXMEs to warnings, but not releasing the objects in the test is wrong :-)

Feb. 16, 2007

Re: [1/10] - [10/10] WineD3D

by Neil Skrypuch

On Friday 16 February 2007, H. Verbeet wrote: > On 16/02/07, Neil Skrypuch <ns03ja(a)brocku.ca> wrote: > > http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch > > That won't apply/compile anymore, use the attached patch instead. Ah, thanks, I didn't notice that. It applied just a few days ago. I updated my link as well. - Neil

Feb. 16, 2007

Re: [1/10] - [10/10] WineD3D

by H. Verbeet

On 16/02/07, Neil Skrypuch <ns03ja(a)brocku.ca> wrote: > http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch > That won't apply/compile anymore, use the attached patch instead.

Feb. 16, 2007

Re: [1/10] - [10/10] WineD3D

by Neil Skrypuch

On Wednesday 14 February 2007, Mirek wrote: > Luke Bratch napsal(a): > >> Wow, great work!!!!! 3DMark 2006 with fbo looks > > > > realy coool!! And some > > > >> Nvidia SDK demos are completly fixed! > > > > How did you test 3DMark2006? When I try and run it, > > it tells me I need Pixel Shader 2.0 support. > > > > I have UseGLSL set to enabled and OffscreenRenderMode > > set to fbo, and the Pixel Shader 2 test in 3DMark03 > > works fine. > > Yes, but after accept this error message i can select some test and run > benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 > and GT2 tests are almost perfect, but very slow (fbo is slower than > backbuffer, so I am not using it in other applications), you should also > disable post procesing (very very slow) in 3DMark. Here are some > screenshots with latest wine and latest Stefan patches: > http://62.240.181.87/Mirek/3DMark2006/ > > PS: I have GF 6800GS, Core 2 Duo X6800(a)3700MHz and about 2 FPS, but it > works! :) > > Mirek 3DMark 05 and 06 are quite picky about caps, there's a few that are slightly off and it refuses to run, you can apply this hack to make it work: http://otc.dyndns.org/stuff/wineshots/3dmark_capshack.patch This may also be of interest: http://bugs.winehq.org/show_bug.cgi?id=7434 - Neil

Feb. 16, 2007

We need a new version numbering scheme

by Scot Hetzel

I read about users confusion with wine version numbering scheme. Personally, I would redirect these confused users to the wiki page at wikipedia where it discusses what the numbers mean in a software version numbering scheme. http://en.wikipedia.org/wiki/Software_version The MAME project had the same user confusion when it went from 0.99 to 0.100. Several of the users of MAME had expected the next version to be 1.00. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised.

Feb. 16, 2007

Re: AppDB performance issue

by Jeremy Newman

A few problems. First off, the web server and smtp server for winehq.org are all on the same box. WineHQ just gets hammered with spam some days. All that spam load takes I/O away from mysql. I've updated the mail daemon to go into a queue only mode when the load average gets to high. Secondly, for those who admin the appdb. Some pages send out email. The default settings for PHP when sending mail are very slow. I changed a setting in PHP to speed that up. On Fri, 2007-02-16 at 15:28 -0500, Bryan Haskins wrote: > Out of complete curiosity, what kind of problem caused only some > people to slow down, while me, on dial-up sped right along? Lol. > > On 2/16/07, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > I made some tweaks to the server on Wednesday. Hopefully > everything is > running fine now.

Feb. 16, 2007

Re: [5/10] DDraw: Fix a leak in a test

by H. Verbeet

Does this really matter?

Feb. 16, 2007

Re: AppDB performance issue

by Bryan Haskins

Out of complete curiosity, what kind of problem caused only some people to slow down, while me, on dial-up sped right along? Lol. On 2/16/07, Jeremy Newman <jnewman(a)codeweavers.com> wrote: > > I made some tweaks to the server on Wednesday. Hopefully everything is > running fine now. > > Let me know if it is still running slow. > > On Wed, 2007-02-14 at 16:35 -0600, John Smith wrote: > > Humm very strange it works well for me, > > > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 on > > windows 2000, on gentoo x86 with firefox 2.0.0.1 , and on gentoo amd64 > > firefox 2.0.0.1. > > > > I added, then removed, then edited a test result. Speed seemed > > normal. > > > > Hope this helps the investigation. > > > > Regards, > > John Klehm > > > > On 2/14/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > Bryan Haskins <kingofallhearts999 <at> gmail.com> writes: > > > > > > > > > > > I was just replying, and reading now, no slow down at all. > > It loads a little > > slow running through all that text, but no where near the > > minutes everyone says > > it takes them, even on dialup. > > > > > > > > > For your info, Appdb, is complete unusable for me ... Loading > > a page, or > > adding a test result to an application takes several minutes. > > Please fix, as > > this is really annoying :( > > > > > > > > > > > > -- Cheers, Bryan

Feb. 16, 2007

Re: Wine and menu integration

by Bryan Haskins

It does work in Ubuntu fine, which should conversely mean it works with any other gnome menu standard desktop. *should should should*. And in Feisty when you say always open this type of program (exe in this case) to use wine, it sticks and now I can just double-click and I'm in. Any Distro using the latest dev release of Gnome should be able to do this (don't know about pre this.) On 2/15/07, Scott Ritchie <scott(a)open-vote.org> wrote: > > > On 2/15/07, David Saez Padros <david(a)ols.es> wrote: > > > I also have what should be add to installation so .exe files > > > are executed with wine when double-clicked (tested in ubuntu) > > When did this break? I thought this worked in Ubuntu just fine. > > Thanks, > Scott Ritchie > > > > -- Cheers, Bryan

Feb. 16, 2007

Re: We need a new version numbering scheme

by Bryan Haskins

90 percent of statistics don't contain a 0 either! Whoops... Jokes aside, I was answering some wine related question on Ubuntuforums.org and came across this, many light users tend to do it. I even thought of it that way when I first learned about the common linux versioning system. I don't think there is anything we can do about it but educate users. And correct them when they do this, maybe on the main download info page for repos and such say outright it's important. Thinks like that. Maybe on some kind of getting support page or the future wine help talk about how it's important. even after 1.0 we'll be hitting this again too unless you do major revisions and reworking it will always be 1.XX.XX so... they need to get with it somehow. Just a users POV. On 2/16/07, Scott Ritchie <scott(a)open-vote.org> wrote: > > On Fri, 2007-02-16 at 20:13 +0100, Marcus Meissner wrote: > > On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: > > > On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > > > > Maybe this would be unworkable in git or whatnot but perhaps always > > > > making the minor version field double digit would do the trick? > > > > > > How about we make the next version Wine 0.9.99.01? > > > > > > Or how about we make the next version 1.0 ;) > > > > I think 0.9.31 will have removed this confusion again. > > > > Ciao, Marcus > > Except maybe that 0.9.4 might be thought of as higher than 0.9.31 > > Thanks, > Scott Ritchie > > > > -- Cheers, Bryan

Feb. 16, 2007

Re: git question

by Stefan Dösinger

Am Freitag 16 Februar 2007 17:32 schrieb Joris Huizer: > Hello, > > As a new wine is released I'm trying to get updated. > Before I had used git for generating patches, I could > do: > > git fetch; git rebase origin > > however, now this doesn't seem to pickup anything. > How should I tell git to actually update to the files > on the server? That should still work. Does it give any error message? Most likely some of the patches in your tree conflict with some newly commited patches on the server.

Feb. 16, 2007

Re: We need a new version numbering scheme

by Scott Ritchie

On Fri, 2007-02-16 at 20:13 +0100, Marcus Meissner wrote: > On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: > > On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > > > Maybe this would be unworkable in git or whatnot but perhaps always > > > making the minor version field double digit would do the trick? > > > > How about we make the next version Wine 0.9.99.01? > > > > Or how about we make the next version 1.0 ;) > > I think 0.9.31 will have removed this confusion again. > > Ciao, Marcus Except maybe that 0.9.4 might be thought of as higher than 0.9.31 Thanks, Scott Ritchie

Feb. 16, 2007

Re: wininet: Improve FtpOpenFile()'s parameter checking and remove the corresponding todo_wines.

by Paul Vriens

Francois Gouget wrote: > Also make test_getfile_no_open() succeed on Windows 98. > --- > > I have had some strange results with these tests. One of them was > actually succeeding in a todo_wine for a good while. > > dlls/wininet/ftp.c | 12 +++++++++++- > dlls/wininet/tests/ftp.c | 12 +++--------- > 2 files changed, 14 insertions(+), 10 deletions(-) > This was the last one for now on my list, you beat me to it. We do have some conflicting patches now in wine-patches. > diff --git a/dlls/wininet/ftp.c b/dlls/wininet/ftp.c > index 5b073cf..2bd29fd 100644 > --- a/dlls/wininet/ftp.c > +++ b/dlls/wininet/ftp.c > @@ -1011,11 +1011,21 @@ HINTERNET WINAPI FtpOpenFileW(HINTERNET hFtpSession, > debugstr_w(lpszFileName), fdwAccess, dwFlags, dwContext); > > lpwfs = (LPWININETFTPSESSIONW) WININET_GetObject( hFtpSession ); > - if (NULL == lpwfs || WH_HFTPSESSION != lpwfs->hdr.htype) > + if (NULL == lpwfs) > + { > + INTERNET_SetLastError(ERROR_INTERNET_NOT_INITIALIZED); > + goto lend; Why do a 'goto lend' you could just 'return FALSE' like I did in the other ftp functions. No need do another check for lpwfs being NULL. If you do a 'return FALSE' you could also get rid of the check for lpwfs being NULL right after lend:. > + } > + if (WH_HFTPSESSION != lpwfs->hdr.htype) > { > INTERNET_SetLastError(ERROR_INTERNET_INCORRECT_HANDLE_TYPE); > goto lend; > } > + if (dwFlags & ~(INTERNET_FLAGS_MASK|FTP_TRANSFER_TYPE_MASK)) > + { > + INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > + goto lend; > + } I think this covers the 5 in the test but not all possible combinations. I did some (loop) testing with dwFlags (also used in FtpGetFile and FtpPutFile) and it appears all boils down to the last 3 bits (see FtpGetFile). Cheers, Paul.

Feb. 16, 2007

Re: We need a new version numbering scheme

by Marcus Meissner

On Fri, Feb 16, 2007 at 10:53:51AM -0800, Scott Ritchie wrote: > On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > > Maybe this would be unworkable in git or whatnot but perhaps always > > making the minor version field double digit would do the trick? > > How about we make the next version Wine 0.9.99.01? > > Or how about we make the next version 1.0 ;) I think 0.9.31 will have removed this confusion again. Ciao, Marcus

Feb. 16, 2007

Re: git question

by Jeff L

Joris Huizer wrote: > git fetch; git rebase origin Have you committed all updates before you git rebase origin? git commit -a -m "all"; git rebase origin; git reset HEAD^ Jeff Latimer

Feb. 16, 2007

Re: We need a new version numbering scheme

by Scott Ritchie

On Fri, 2007-02-16 at 09:40 -0600, John Smith wrote: > Maybe this would be unworkable in git or whatnot but perhaps always > making the minor version field double digit would do the trick? How about we make the next version Wine 0.9.99.01? Or how about we make the next version 1.0 ;) Thanks, Scott Ritchie

Feb. 16, 2007

Re: AppDB performance issue

by Jeremy Newman

I made some tweaks to the server on Wednesday. Hopefully everything is running fine now. Let me know if it is still running slow. On Wed, 2007-02-14 at 16:35 -0600, John Smith wrote: > Humm very strange it works well for me, > > I just tested it myself, seems reasonably fast in firefox 2.0.0.1 on > windows 2000, on gentoo x86 with firefox 2.0.0.1 , and on gentoo amd64 > firefox 2.0.0.1. > > I added, then removed, then edited a test result. Speed seemed > normal. > > Hope this helps the investigation. > > Regards, > John Klehm > > On 2/14/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Bryan Haskins <kingofallhearts999 <at> gmail.com> writes: > > > > > > > I was just replying, and reading now, no slow down at all. > It loads a little > slow running through all that text, but no where near the > minutes everyone says > it takes them, even on dialup. > > > > > For your info, Appdb, is complete unusable for me ... Loading > a page, or > adding a test result to an application takes several minutes. > Please fix, as > this is really annoying :( > > > >

Feb. 16, 2007

Re: [7/10] WineD3D: Test for supported queries

by Stefan Dösinger

Am Donnerstag 15 Februar 2007 19:13 schrieb Juan Lang: > The label cleanup isn't used anywhere except in the failure to create the > device. In this case, wouldn't: > if (FAILED(hr)) return; > be clearer, and omit the unneeded label? There's no reason to release > pDevice in creating it failed. You're right. Its just copypasted from the other tests :-/

Feb. 16, 2007

Re: DIB Engine, some summarization

by Stefan Dösinger

> This sounds like a really simple way to support client-side and > server-side drawing without the mixing that causes repeated network > transfers: gdi32.dll GetDC, GetClientDC, and CreateCompatibleDC would > all be done client-size, while IDirectWhatever::GetDC would return a > device context that is strictly server-side. Not necessarily a good idea. DirectDraw (software emulation) would profit a lot from client side DCs. On the other hand, for GetDC on a Direct3D rendertarget(aka opengl frame buffer), a server side context may help together with the GLX_texture_from_pixmap extension(maybe, the extension does not match exactly what we need). My other(crazy) idea is to implement GDI calls in opengl, or at least a part of them, and fall back to downloading the framebuffer, drawing in software and uploading again otherwise. Would we call that client side or server side rendering?

Feb. 16, 2007

git question

by Joris Huizer

Hello, As a new wine is released I'm trying to get updated. Before I had used git for generating patches, I could do: git fetch; git rebase origin however, now this doesn't seem to pickup anything. How should I tell git to actually update to the files on the server? Thanks, Joris ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

Feb. 16, 2007

Re: We need a new version numbering scheme

by John Smith

Ack in my previous message I was speaking of 99 minor versions not revisions, sorry for the typo! John On 2/16/07, John Smith <xixsimplicityxix(a)gmail.com> wrote: > > Maybe this would be unworkable in git or whatnot but perhaps always making > the minor version field double digit would do the trick? > > 0.9.03 > 0.9.09 > 0.9.10 > ... > 0.9.30 > etc > > this would fix the sorting problems that arise from going from single to > double digit names in most programs too. As long as the major and minor > fields always have the same number of digits it will sort correctly even > with alphanumeric names. Of course they would have to update the older > versions to double digits but that isn't impossible. > > Of course if you break 99 minor revisions you'd run into the problem again > but I think 99 minor revisions is a lot harder to over run than 9. Plus, > maybe if we have 99 minor versions it would be time for an increase in the > major version number =) > > I'd be willing to implement this for a summer of code project. > > Just kidding. =) Hopefully I'll come up with something more exciting that > you guys will like. > > Just a thought, > John Klehm > > On 2/16/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > > > > Scott Ritchie wrote: > > > > > On several occasions I have received emails referring to Wine version > > > 0.9.3. One person even told me about a regression from 0.9.28 to > > 0.9.3. > > > > > > Presumably, this version is being confused with Wine 0.9.30 in these > > > letters, however I have been unable to tell whether people were > > ACTUALLY > > > using 0.9.3 or were instead simply referring to 0.9.30 in the > > intuitive > > > way of chopping off the last 0. > > > > > > Either way, version numbers should be completely clear, and they're > > not > > > currently. I'm not quite sure what to do at this point. > > > > > > Thanks, > > > Scott Ritchie > > > > The problem arises when version control programs sort the release "tags" > > > > alphanumerically, presenting them in the following order, since the > > digits > > are just treated as members of an extended alphabet, not as real > > numbers. > > > > Wine-0_9 > > Wine-0_9_1 > > Wine-0_9_10 > > ... > > Wine-0_9_19 > > Wine-0_9_2 > > Wine-0_9_20 > > ... > > Wine-0_9_29 > > Wine-0_9_3 > > Wine-0_9_30 > > > > I think it's probably only a trap for people who download from a source > > repository - and it is not a problem peculiar to Wine. Packaged versions > > > > are unlikely to be presented in this bizarre order. > > > > -- Andy. > > > > > > > > > > >

Feb. 16, 2007

Re: We need a new version numbering scheme

by John Smith

Maybe this would be unworkable in git or whatnot but perhaps always making the minor version field double digit would do the trick? 0.9.03 0.9.09 0.9.10 ... 0.9.30 etc this would fix the sorting problems that arise from going from single to double digit names in most programs too. As long as the major and minor fields always have the same number of digits it will sort correctly even with alphanumeric names. Of course they would have to update the older versions to double digits but that isn't impossible. Of course if you break 99 minor revisions you'd run into the problem again but I think 99 minor revisions is a lot harder to over run than 9. Plus, maybe if we have 99 minor versions it would be time for an increase in the major version number =) I'd be willing to implement this for a summer of code project. Just kidding. =) Hopefully I'll come up with something more exciting that you guys will like. Just a thought, John Klehm On 2/16/07, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > > Scott Ritchie wrote: > > > On several occasions I have received emails referring to Wine version > > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > > > Presumably, this version is being confused with Wine 0.9.30 in these > > letters, however I have been unable to tell whether people were ACTUALLY > > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > > way of chopping off the last 0. > > > > Either way, version numbers should be completely clear, and they're not > > currently. I'm not quite sure what to do at this point. > > > > Thanks, > > Scott Ritchie > > The problem arises when version control programs sort the release "tags" > alphanumerically, presenting them in the following order, since the digits > are just treated as members of an extended alphabet, not as real numbers. > > Wine-0_9 > Wine-0_9_1 > Wine-0_9_10 > ... > Wine-0_9_19 > Wine-0_9_2 > Wine-0_9_20 > ... > Wine-0_9_29 > Wine-0_9_3 > Wine-0_9_30 > > I think it's probably only a trap for people who download from a source > repository - and it is not a problem peculiar to Wine. Packaged versions > are unlikely to be presented in this bizarre order. > > -- Andy. > > > > >

Feb. 16, 2007

Google Summer of Code 2007

by Tom Wickline

Hello, I see Google is going to do there summer of code again this year :-) They plan to start accepting applications in March, so now would be the time for us to propose new projects and review the ones we have already listed on the Wiki for interested applicants? As well as line up mentors for the accepted applicants? http://wiki.winehq.org/SummerOfCode http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Tom

Feb. 16, 2007

Re: We need a new version numbering scheme

by Andrew Talbot

Scott Ritchie wrote: > On several occasions I have received emails referring to Wine version > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > Presumably, this version is being confused with Wine 0.9.30 in these > letters, however I have been unable to tell whether people were ACTUALLY > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > way of chopping off the last 0. > > Either way, version numbers should be completely clear, and they're not > currently. I'm not quite sure what to do at this point. > > Thanks, > Scott Ritchie The problem arises when version control programs sort the release "tags" alphanumerically, presenting them in the following order, since the digits are just treated as members of an extended alphabet, not as real numbers. Wine-0_9 Wine-0_9_1 Wine-0_9_10 ... Wine-0_9_19 Wine-0_9_2 Wine-0_9_20 ... Wine-0_9_29 Wine-0_9_3 Wine-0_9_30 I think it's probably only a trap for people who download from a source repository - and it is not a problem peculiar to Wine. Packaged versions are unlikely to be presented in this bizarre order. -- Andy.

Feb. 16, 2007

Re: We need a new version numbering scheme

by Dmitry Timoshkov

"Scott Ritchie" <scott(a)open-vote.org> wrote: > On Fri, 2007-02-16 at 09:48 +0200, SorinN wrote: >> If I presume correct, instead of changing numbering system - maybe is >> better to explain this system to users - somewhere on first page - >> first paragraph - on Wine HQ - and on Synaptic ( or other package >> managers where Details appear ). >> > > If we have to teach them, something is not obvious. And that's the > source of the confusion - better to avoid it entirely. I'd say that if you have to explain something then something is wrong. How many open source projects versioning schemes do you know? Wine is using what is commonly accepted, we don't invent something new. -- Dmitry.

Feb. 16, 2007

Re: We need a new version numbering scheme

by Scott Ritchie

On Fri, 2007-02-16 at 09:48 +0200, SorinN wrote: > If I presume correct, instead of changing numbering system - maybe is > better to explain this system to users - somewhere on first page - > first paragraph - on Wine HQ - and on Synaptic ( or other package > managers where Details appear ). > If we have to teach them, something is not obvious. And that's the source of the confusion - better to avoid it entirely. Thanks, Scott Ritchie

Feb. 16, 2007

regression in 613998d4f6ff953a22a4455a28f77d2126642c7d

by Marcus Meissner

Hi Shanren, your commit 613998d4f6ff953a22a4455a28f77d2126642c7d Author: Shanren Zhou <shanren(a)ucla.edu> Date: Mon Feb 12 19:53:51 2007 -0800 comctl32: Add header tests. generates a Coverity Warning in this code: ... HIMAGELIST hImageList; HIMAGELIST hImageListRetVal; hImageListRetVal = (HIMAGELIST) SendMessage(hWndHeader, HDM_SETIMAGELIST, 0, (LPARAM) &hImageList); HDM_SETIMAGELISTs parameter is used and stored, so hImageList should be: - initialized to something (likely 0 is ok, didnt check) - and not a pointer (did you add the & just to kill the warning?) Ciao, Marcus

Feb. 16, 2007

Re: We need a new version numbering scheme

by SorinN

mr. Scott, I am a wine user for long time - I understand from start that actual system is not a decimal system - but a numbering one - so for me the difference between 0.9.3. and 0.9.30 is the difference between 3 and 30. If I presume correct, instead of changing numbering system - maybe is better to explain this system to users - somewhere on first page - first paragraph - on Wine HQ - and on Synaptic ( or other package managers where Details appear ). At least, it's true - the position of the last point on right can make this confusion - this point make the difference - so here is to be explained ( 0.9.3. < 0.9.30. ; 03.9.3.1 < 0.9.30.1 ...etc ). SorinN 2007/2/16, Scott Ritchie <scott(a)open-vote.org>: > On several occasions I have received emails referring to Wine version > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > Presumably, this version is being confused with Wine 0.9.30 in these > letters, however I have been unable to tell whether people were ACTUALLY > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > way of chopping off the last 0. > > Either way, version numbers should be completely clear, and they're not > currently. I'm not quite sure what to do at this point. > > Thanks, > Scott Ritchie > > > > -- Nemes Ioan Sorin

Feb. 16, 2007

Re: We need a new version numbering scheme

by L. Rahyen

Friday February 16 2007 05:53、Scott Ritchie さんは書きました: > On several occasions I have received emails referring to Wine version > 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. > > Presumably, this version is being confused with Wine 0.9.30 in these > letters, however I have been unable to tell whether people were ACTUALLY > using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive > way of chopping off the last 0. > > Either way, version numbers should be completely clear, and they're not > currently. I'm not quite sure what to do at this point. > > Thanks, > Scott Ritchie I think there is no problem. Most people do understand that 0.9.30 and 0.9.3 different things. Chopping off the last 0 isn't intuitive at all. This is the same as replacing amount of something with value of 10 times smaller: 3 apples instead of 30 for example! So my opinion that there is no problem at all. This is mostly problem of some people that don't understand simple things. I think it is very clear that if we have "0" in version number then it is important. And also - it actually have very intuitive meaning! BTW, 90% of versions doesn't contain zeros in the version number.

Feb. 16, 2007

We need a new version numbering scheme

by Scott Ritchie

On several occasions I have received emails referring to Wine version 0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3. Presumably, this version is being confused with Wine 0.9.30 in these letters, however I have been unable to tell whether people were ACTUALLY using 0.9.3 or were instead simply referring to 0.9.30 in the intuitive way of chopping off the last 0. Either way, version numbers should be completely clear, and they're not currently. I'm not quite sure what to do at this point. Thanks, Scott Ritchie

Feb. 15, 2007

Re: Wine and menu integration

by Scott Ritchie

> On 2/15/07, David Saez Padros <david(a)ols.es> wrote: > > I also have what should be add to installation so .exe files > > are executed with wine when double-clicked (tested in ubuntu) When did this break? I thought this worked in Ubuntu just fine. Thanks, Scott Ritchie

Feb. 15, 2007

Re: DIB Engine, some summarization

by richardvoigt＠gmail.com

On 2/12/07, Daniel Remenak <dtremenak(a)gmail.com> wrote: > On 2/12/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am Montag 12 Februar 2007 19:54 schrieb Daniel Remenak: > > > On 2/11/07, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > > > > What about the case where you draw with GDI, then render with OpenGL > > > > on top of that, then draw on top of that with GDI, then swap buffers? > > > > If you draw only client-side, you have to copy to the server, then > > > > copy back, then copy to the server *again*. You have to upload or > > > > download the image *every time* you go between OpenGL and GDI drawing, > > > > whereas when you draw with X11, there is no uploads/downloads unless > > > > you use DIB sections and draw directly. > > > > > > Not that it's relevant to this conversation (since wine needs to > > > support legacy apps), but just so you know, even Microsoft no longer > > > supports this sample scenario. Drawing with GDI over OpenGL (or DX), > > > and reading from the GDI buffer on a hardware-accelerated window, are > > > both undefined (officially "not supported") operations on Windows > > > Vista. Caused a ton of problems for my company's product > > > > So IDirect3DSurface9::GetDC does not work any longer? (Or > > IDirectDrawSurface7::GetDC) > > > > /me parties! > > > > > > Unfortunately, no; it looks like you can still render GDI onto a DX > surface, just not directly onto a window which is also being rendered > to by DX. > > >From the linked blog article: > "Note that there is an alternative that can often work for an > application -- DirectX is capable of handing back a DC to a DirectX > surface, and applications can perform GDI rendering to that DC. From > the DWM's perspective, that DirectX surface remains purely rendered by > DirectX, and all is well." > > --Daniel Remenak This sounds like a really simple way to support client-side and server-side drawing without the mixing that causes repeated network transfers: gdi32.dll GetDC, GetClientDC, and CreateCompatibleDC would all be done client-size, while IDirectWhatever::GetDC would return a device context that is strictly server-side. Does that seem reasonable?

Feb. 15, 2007

ANN: Wiki upgrade

by Dimi Paun

Folks, We finished upgrading the wiki to MoinMoin 1.5.7. Please let me know if you encounter any problems. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Feb. 15, 2007

Re: [1/4] wined3d: Fix WINED3DPRESENT_PARAMETERS and use it instead of D3DPRESENT_PARAMETERS

by Duane Clark

H. Verbeet wrote: > It looks like the patch might be a bit large for the list, here's a > compressed version instead. > Anything over 80K just gets caught in the mail queue. It should get through eventually.

Feb. 15, 2007

Re: Office 2007 help wine

by Robert Shearman

Keith H. Pratt wrote: > Hi, > I went to a Microsoft Launch for their enterprise and business products > this past tuesday, and they gave me a full version of Office 2007 > Professional. Nice of them huh. Well, I am a linux user, and an avid > evangelist for open source, and for anything that lets thw linux and > windows world work together. I also have spent a considerable amount of > time testing and bug reporting beta software. > With all that said, here's my point. > What can I do with this software to help you in the testing and > development of wine? I run a dual-boot system with winxp and ubuntu > linux. linux is where i work, and windows is there to make it easier to > support my clients in their windows machines. > If theres nothing now that applies to wine and office 2007, maybe keep > this message for when the need does arise. Hi Keith, It would help if you could try to install it with Wine and report any problems that arise in bugzilla. If I can help you get past any issues, I will. -- Rob Shearman

Feb. 15, 2007

Re: [7/10] WineD3D: Test for supported queries

by Juan Lang

Hi Stefan, + hr = IDirect3D9_CreateDevice( pD3d, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hwnd, + D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &pDevice ); + ok(SUCCEEDED(hr), "Failed to create IDirect3D9Device (%s)\n", DXGetErrorString9(hr)); + if (FAILED(hr)) goto cleanup; (snip) + cleanup: + if(pDevice) IDirect3DDevice9_Release(pDevice); The label cleanup isn't used anywhere except in the failure to create the device. In this case, wouldn't: if (FAILED(hr)) return; be clearer, and omit the unneeded label? There's no reason to release pDevice in creating it failed. --Juan ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

Feb. 15, 2007

Re: [PATCH 6/6] kernel32: Fix the GetComputerName* functions to not write to the buffer at all if there is not enough space.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Remove the exception handlers, since testing on XP SP2 shows that > access violations are not caught. Yes, but they are caught on Win9x, and the handler was added because an app needed it. I'd suggest to keep it at least in the A function. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2007

Office 2007 help wine

by Keith H. Pratt

Hi, I went to a Microsoft Launch for their enterprise and business products this past tuesday, and they gave me a full version of Office 2007 Professional. Nice of them huh. Well, I am a linux user, and an avid evangelist for open source, and for anything that lets thw linux and windows world work together. I also have spent a considerable amount of time testing and bug reporting beta software. With all that said, here's my point. What can I do with this software to help you in the testing and development of wine? I run a dual-boot system with winxp and ubuntu linux. linux is where i work, and windows is there to make it easier to support my clients in their windows machines. If theres nothing now that applies to wine and office 2007, maybe keep this message for when the need does arise. Thanks Keith

Feb. 15, 2007

Re: Wine and menu integration

by Mike Hearn

Hi David, Sounds great! To submit those files, you need to make a patch ... git can do this but I don't remember the exact command to use (depends on your setup also). Or you can do it the old fashioned way using diff directly. Feel free to ask if you'd like more guidance with this. Once you have a patch, email it to wine-patches(a)winehq.org so Alexandre and the others can review it, suggest improvements etc. Good luck! On 2/15/07, David Saez Padros <david(a)ols.es> wrote: > Hi !! > > I saw your post at http://wiki.winehq.org/GnomeMenusIntegration > and i made some freedesktop compliant files which: > > - add a global Wine menu item in the Aplications menu (seen > by all users) with WineFile and WineMine, which also merge > all user specific wine installed programs. > > - add a global menu item for winecfg in System -> Preferences > (seen by all users) > > I also have what should be add to installation so .exe files > are executed with wine when double-clicked (tested in ubuntu) > > How could i submit those files ?? I cannot din anything > related to this in the bugzilla :( > > -- > Best regards ... > > I am Homer of Borg. Prepare to be assim... mmmm, donuts. > > ---------------------------------------------------------------- > David Saez Padros http://www.ols.es > On-Line Services 2000 S.L. e-mail david(a)ols.es > Pintor Vayreda 1 telf +34 902 50 29 75 > 08184 Palau-Solita i Plegamans movil +34 670 35 27 53 > ---------------------------------------------------------------- > > >

Feb. 15, 2007

Re: gdi32: Symbol encoding should be always selectable

by Dmitry Timoshkov

"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote: > this patch fixes a failure in the font charset test in the case when > only Arial is installed. As the test shows the symbol encoding should be > always selectable. Please do not commit this patch, it's wrong. According to GetTextFace XP selects Wingdings if SYMBOL_CHARSET was requested. I'm not sure how to make the test pass: probably SYMBOL_CHARSET should be skipped if Symbol or Wingdings are not installed. -- Dmitry.

Feb. 15, 2007

Re: WINSPOOL: search for a printer driver

by Detlef Riekenberg

On Mi, 2007-02-14 at 17:51 +0300, Vitaly Lipatov wrote: > When wine is loading, CUPS_LoadPrinters function get printer list from CUPS > and add printer and their printer drivers to registry. > Note, we place printer driver in "Windows 4.0" registry entry if Wine version > is win9x and use "Windows NT x86" registry entry if Wine version is win2000 > and above. > > If we will change wine version after printer loaded, Wine printing is got > failed. Wine search in empty registry entry. Thanks for mention this. Just a short first note: There is a move/update for that Area in progress, but that needs a working "IniFileMapping" first. (Away for some days.) -- By by ... Detlef

Feb. 15, 2007

Re: Direct Draw "palette_convert"

by H. Verbeet

On 15/02/07, Nathan Williams <nathan.andrew.williams(a)gmail.com> wrote: > Google to the rescue! (I googled Roderick's name, i was lead right to > the patches!) > http://www.kernel-traffic.org/wine/wn20051211_301.html#2 > > I believe this is the patch he was talking about, I'll give it a try > in the morning & see how it goes. > I think there was a more recent version of those patches, I'm not sure if the ones linked there still apply.

Feb. 15, 2007

avifil32: sign-compare fixes

by Joris Huizer

Hello As the previous time I was inserting too many casts, I want to ask whether this approach is better (introducing an ULONG version if it fixes compare warnings, and casting away remaining problems) If this is not alright, could you tell what's the best way to fix? regards, Joris ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/

Feb. 15, 2007

Re: Direct Draw "palette_convert"

by Nathan Williams

Google to the rescue! (I googled Roderick's name, i was lead right to the patches!) http://www.kernel-traffic.org/wine/wn20051211_301.html#2 I believe this is the patch he was talking about, I'll give it a try in the morning & see how it goes. On 2/15/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Donnerstag 15 Februar 2007 08:52 schrieb Roderick Colenbrander: > > Use this patch which I made a while ago. I still need to fix some things in > > it but it handles the conversion using fragment shaders. You need to set > > the DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I > > hope to clean it up soon. > Forgot the patch? > > -- Nathan

Feb. 15, 2007

Re: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them

by Alexandre Julliard

"H. Verbeet" <hverbeet(a)gmail.com> writes: > On 15/02/07, Alexandre Julliard <julliard(a)winehq.org> wrote: >> I think this could just as well go into an existing file like >> wined3d_types.h. > It could, but the idea was to keep things similar to d3d8 and d3d9 > where the corresponding defines are in d3d8caps.h and d3d9caps.h OK, that makes sense. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2007

Re: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them

by H. Verbeet

On 15/02/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > I think this could just as well go into an existing file like > wined3d_types.h. It could, but the idea was to keep things similar to d3d8 and d3d9 where the corresponding defines are in d3d8caps.h and d3d9caps.h

Feb. 15, 2007

Re: [05/10] wined3d: Add WINED3DTEXOPCAPS flags and use them

by Alexandre Julliard

"H. Verbeet" <hverbeet(a)gmail.com> writes: > diff --git a/include/wine/wined3d_caps.h b/include/wine/wined3d_caps.h > new file mode 100644 > index 0000000..4bf474b > --- /dev/null > +++ b/include/wine/wined3d_caps.h > @@ -0,0 +1,49 @@ > +/* > + * Copyright 2007 Henri Verbeet > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#ifndef __WINE_WINED3D_CAPS_H > +#define __WINE_WINED3D_CAPS_H > + > +#define WINED3DTEXOPCAPS_DISABLE 0x00000001 > +#define WINED3DTEXOPCAPS_SELECTARG1 0x00000002 > +#define WINED3DTEXOPCAPS_SELECTARG2 0x00000004 > +#define WINED3DTEXOPCAPS_MODULATE 0x00000008 > +#define WINED3DTEXOPCAPS_MODULATE2X 0x00000010 > +#define WINED3DTEXOPCAPS_MODULATE4X 0x00000020 > +#define WINED3DTEXOPCAPS_ADD 0x00000040 > +#define WINED3DTEXOPCAPS_ADDSIGNED 0x00000080 > +#define WINED3DTEXOPCAPS_ADDSIGNED2X 0x00000100 > +#define WINED3DTEXOPCAPS_SUBTRACT 0x00000200 > +#define WINED3DTEXOPCAPS_ADDSMOOTH 0x00000400 > +#define WINED3DTEXOPCAPS_BLENDDIFFUSEALPHA 0x00000800 > +#define WINED3DTEXOPCAPS_BLENDTEXTUREALPHA 0x00001000 > +#define WINED3DTEXOPCAPS_BLENDFACTORALPHA 0x00002000 > +#define WINED3DTEXOPCAPS_BLENDTEXTUREALPHAPM 0x00004000 > +#define WINED3DTEXOPCAPS_BLENDCURRENTALPHA 0x00008000 > +#define WINED3DTEXOPCAPS_PREMODULATE 0x00010000 > +#define WINED3DTEXOPCAPS_MODULATEALPHA_ADDCOLOR 0x00020000 > +#define WINED3DTEXOPCAPS_MODULATECOLOR_ADDALPHA 0x00040000 > +#define WINED3DTEXOPCAPS_MODULATEINVALPHA_ADDCOLOR 0x00080000 > +#define WINED3DTEXOPCAPS_MODULATEINVCOLOR_ADDALPHA 0x00100000 > +#define WINED3DTEXOPCAPS_BUMPENVMAP 0x00200000 > +#define WINED3DTEXOPCAPS_BUMPENVMAPLUMINANCE 0x00400000 > +#define WINED3DTEXOPCAPS_DOTPRODUCT3 0x00800000 > +#define WINED3DTEXOPCAPS_MULTIPLYADD 0x01000000 > +#define WINED3DTEXOPCAPS_LERP 0x02000000 > + > +#endif /* __WINE_WINED3D_CAPS_H */ I think this could just as well go into an existing file like wined3d_types.h. We should try to keep the number of Wine-specific global includes to a minimum. -- Alexandre Julliard julliard(a)winehq.org

Feb. 15, 2007

Re: [4/10] WineD3D: Convert and load U8V8 surfaces as rgb

by Stefan Dösinger

Am Donnerstag 15 Februar 2007 09:50 schrieb H. Verbeet: > On 15/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > GL_INDEX is definitly not the way to load U8V8 surfaces > > I think you should be using something like GL_DU8DV8_ATI or GL_DSDT_NV > instead. Thats my plan, but I think we should handle it in some way if none of the extensions is available. We can later use the extension-specific formats if they are available.

Feb. 15, 2007

Re: [10/10] DDraw: Forward D3DRS_TEXTUREADDRESS* and D3DTSS_ADDRESS* to sampler states

by Stefan Dösinger

Am Donnerstag 15 Februar 2007 09:51 schrieb H. Verbeet: > On 15/02/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >+ case D3DTSS_ADDRESS: > >+ return IWineD3DDevice_GetSamplerState(This->wineD3DDevice, > >+ Stage, > >+ WINED3DSAMP_ADDRESSW, > >+ State); > > Is that correct? Hm. No, it isn't. I thought I fixed that sort of things. Maybe an old version of the patch got sent NULL

Feb. 15, 2007

Re: Direct Draw "palette_convert"

by Stefan Dösinger

Am Donnerstag 15 Februar 2007 08:52 schrieb Roderick Colenbrander: > Use this patch which I made a while ago. I still need to fix some things in > it but it handles the conversion using fragment shaders. You need to set > the DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I > hope to clean it up soon. Forgot the patch?

Feb. 15, 2007

Re: Regression in comctl32

by Dmitry Timoshkov

"Pavel Troller" <patrol(a)sinus.cz> wrote: > I just found a regression in comctl32 and bisected it successfully. > The following commit > > 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit > commit 369749dcb2ba12ce8481503543afd18ad99805d1 > Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> > Date: Mon Feb 12 16:47:56 2007 +0800 > > comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. > > :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls > > causes that IDA Pro shows black squares instead of its toolbar icons. The regrssion was reported already and the the bug #7405 tracks its status. I'm working on it. -- Dmitry.

Feb. 15, 2007

Re: Direct Draw "palette_convert"

by Roderick Colenbrander

Use this patch which I made a while ago. I still need to fix some things in it but it handles the conversion using fragment shaders. You need to set the DirectDrawRenderer to opengl and RenderTargetLockMode to readtex. I hope to clean it up soon. Roderick > I'm working on some direct draw code to get Carmageddon working. > > I think I have found my issue in IWineD3DPaletteImpl_SetEntries > > Carmageddon runs in 8 bit mode, my x windows is set at 24bit. > > If I drop xorg to 8bit, wine refuses to load. > If i set it to 16bit, the Carmageddon menus are still bad, but > noticeably better then running in 24bit. > > In SetEntries there is a bit of code idef'd out: > > #if 0 > /* Now, if we are in 'depth conversion mode', update the screen > palette */ > /* FIXME: we need to update the image or we won't get palette fading. > */ > if (This->ddraw->d->palette_convert != NULL) > > This->ddraw->d->palette_convert(palent,This->screen_palents,start,count); > #endif > > Uncommenting the above only leads to compile errors. > Dredging through the wine archives, I see that the palette convert > functions haven't been there since 2000. > > Can anyone give me an idea on why they were removed & what might be > the best way to reimplement some form of palette conversion? > (Even just in a hacky way right now, so i can test my assumptions) > > -- > Nathan > -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out

Feb. 15, 2007

Re: [07/10] wined3d: Add WINED3DPBLENDCAPS flags and use them

by Mirek

Hi, this patch has bad attachment, it has same attachment as "[08/10] wined3d: Add WINED3DPMISCCAPS flags and use them". Mirek Slugen H. Verbeet napsal(a): > Changelog: > - Add WINED3DPBLENDCAPS flags and use them > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/directx.c | 34 +++++++++++++++++----------------- > include/wine/wined3d_caps.h | 19 +++++++++++++++++++ > 2 files changed, 36 insertions(+), 17 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 1753ef9..cc1e0f6 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -1872,29 +1872,29 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > WINED3DDEVCAPS_DRAWPRIMITIVES2 | > WINED3DDEVCAPS_DRAWPRIMITIVES2EX; > > - *pCaps->PrimitiveMiscCaps = D3DPMISCCAPS_CULLNONE | > - D3DPMISCCAPS_CULLCCW | > - D3DPMISCCAPS_CULLCW | > - D3DPMISCCAPS_COLORWRITEENABLE | > - D3DPMISCCAPS_CLIPTLVERTS | > - D3DPMISCCAPS_CLIPPLANESCALEDPOINTS | > - D3DPMISCCAPS_MASKZ | > - D3DPMISCCAPS_BLENDOP; > + *pCaps->PrimitiveMiscCaps = WINED3DPMISCCAPS_CULLNONE | > + WINED3DPMISCCAPS_CULLCCW | > + WINED3DPMISCCAPS_CULLCW | > + WINED3DPMISCCAPS_COLORWRITEENABLE | > + WINED3DPMISCCAPS_CLIPTLVERTS | > + WINED3DPMISCCAPS_CLIPPLANESCALEDPOINTS | > + WINED3DPMISCCAPS_MASKZ | > + WINED3DPMISCCAPS_BLENDOP; > /* TODO: > - D3DPMISCCAPS_NULLREFERENCE > - D3DPMISCCAPS_INDEPENDENTWRITEMASKS > - D3DPMISCCAPS_FOGANDSPECULARALPHA > - D3DPMISCCAPS_SEPARATEALPHABLEND > - D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS > - D3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING > - D3DPMISCCAPS_FOGVERTEXCLAMPED */ > + WINED3DPMISCCAPS_NULLREFERENCE > + WINED3DPMISCCAPS_INDEPENDENTWRITEMASKS > + WINED3DPMISCCAPS_FOGANDSPECULARALPHA > + WINED3DPMISCCAPS_SEPARATEALPHABLEND > + WINED3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS > + WINED3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING > + WINED3DPMISCCAPS_FOGVERTEXCLAMPED */ > > /* The caps below can be supported but aren't handled yet in utils.c 'd3dta_to_combiner_input', disable them until support is fixed */ > #if 0 > if (GL_SUPPORT(NV_REGISTER_COMBINERS)) > - *pCaps->PrimitiveMiscCaps |= D3DPMISCCAPS_TSSARGTEMP; > + *pCaps->PrimitiveMiscCaps |= WINED3DPMISCCAPS_TSSARGTEMP; > if (GL_SUPPORT(NV_REGISTER_COMBINERS2)) > - *pCaps->PrimitiveMiscCaps |= D3DPMISCCAPS_PERSTAGECONSTANT; > + *pCaps->PrimitiveMiscCaps |= WINED3DPMISCCAPS_PERSTAGECONSTANT; > #endif > > *pCaps->RasterCaps = WINED3DPRASTERCAPS_DITHER | > diff --git a/include/wine/wined3d_caps.h b/include/wine/wined3d_caps.h > index 1cedae7..98a655d 100644 > --- a/include/wine/wined3d_caps.h > +++ b/include/wine/wined3d_caps.h > @@ -34,6 +34,25 @@ > #define WINED3DPBLENDCAPS_BOTHINVSRCALPHA 0x00001000 > #define WINED3DPBLENDCAPS_BLENDFACTOR 0x00002000 > > +#define WINED3DPMISCCAPS_MASKZ 0x00000002 > +#define WINED3DPMISCCAPS_LINEPATTERNREP 0x00000004 > +#define WINED3DPMISCCAPS_CULLNONE 0x00000010 > +#define WINED3DPMISCCAPS_CULLCW 0x00000020 > +#define WINED3DPMISCCAPS_CULLCCW 0x00000040 > +#define WINED3DPMISCCAPS_COLORWRITEENABLE 0x00000080 > +#define WINED3DPMISCCAPS_CLIPPLANESCALEDPOINTS 0x00000100 > +#define WINED3DPMISCCAPS_CLIPTLVERTS 0x00000200 > +#define WINED3DPMISCCAPS_TSSARGTEMP 0x00000400 > +#define WINED3DPMISCCAPS_BLENDOP 0x00000800 > +#define WINED3DPMISCCAPS_NULLREFERENCE 0x00001000 > +#define WINED3DPMISCCAPS_INDEPENDENTWRITEMASKS 0x00004000 > +#define WINED3DPMISCCAPS_PERSTAGECONSTANT 0x00008000 > +#define WINED3DPMISCCAPS_FOGANDSPECULARALPHA 0x00010000 > +#define WINED3DPMISCCAPS_SEPARATEALPHABLEND 0x00020000 > +#define WINED3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS 0x00040000 > +#define WINED3DPMISCCAPS_MRTPOSTPIXELSHADERBLENDING 0x00080000 > +#define WINED3DPMISCCAPS_FOGVERTEXCLAMPED 0x00100000 > + > #define WINED3DSTENCILCAPS_KEEP 0x00000001 > #define WINED3DSTENCILCAPS_ZERO 0x00000002 > #define WINED3DSTENCILCAPS_REPLACE 0x00000004 > > > ------------------------------------------------------------------------ > >

Feb. 15, 2007

Re: Regression in comctl32

by Paul Romanyszyn

Pavel Troller wrote: > Hi! > I just found a regression in comctl32 and bisected it successfully. > The following commit > > 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit > commit 369749dcb2ba12ce8481503543afd18ad99805d1 > Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> > Date: Mon Feb 12 16:47:56 2007 +0800 > > comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. > > :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls > > causes that IDA Pro shows black squares instead of its toolbar icons. > > With regards, Pavel Troller > > > See bug 7405 for 2 additional programs. > http://bugs.winehq.org/show_bug.cgi?id=7405 Paul R.

Feb. 15, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by Felix Nawothnig

richardvoigt(a)gmail.com wrote: > And I have never advocated for putting this in the registry, my > suggestion has always been to store these settings in a file outside > the .wine/drive_c jail area that is accessbile via wine's Win32 API. Wine is *not* a sandbox. Any .exe run can make use of native (Linux) syscalls as it wants. Felix

Feb. 15, 2007

Regression in comctl32

by Pavel Troller

Hi! I just found a regression in comctl32 and bisected it successfully. The following commit 369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit commit 369749dcb2ba12ce8481503543afd18ad99805d1 Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Mon Feb 12 16:47:56 2007 +0800 comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls causes that IDA Pro shows black squares instead of its toolbar icons. With regards, Pavel Troller

Feb. 15, 2007

Re: [cmd][try3] Update Russian translate (edited) [Really sorry!!]

by Dmitry Timoshkov

----- Original Message ----- From: "Detlef Riekenberg" <wine.dev(a)web.de> To: <wine-devel(a)winehq.org> Sent: Thursday, February 15, 2007 7:12 AM Subject: Re: [cmd][try3] Update Russian translate (edited) [Really sorry!!] > On Mi, 2007-02-14 at 15:16 +0300, Anatoly Lyutin wrote: >> - HELP <> .\n" >> + HELP <> .\n\ >> + DOS http://www.citforum.ru/operating_systems/msdos/\n" >> } > > > That link is wrong in wine. Please remove from your Patch Moreover it doesn't match an original english wording in En.rc: "Enter HELP <command> for further information on any of the above commands\n" -- Dmitry.

Feb. 14, 2007

Re: wineboot: Start items in StartUp folder on boot, includes security measures.

by richardvoigt＠gmail.com

On 2/12/07, James Hawkins <truiken(a)gmail.com> wrote: > On 2/12/07, richardvoigt(a)gmail.com <richardvoigt(a)gmail.com> wrote: > > > > You advocated that wine aim for working exactly like Windows, no less > > and no more, rather than deviating in user-configurable ways to > > enhance the user's control over his own system. > > > > Right. That's the purpose of Wine. You'd know that if you were a > developer on this project. You'll get there a lot faster by contributing to colinux (www.colinux.org) instead. > > > Maybe while we're at > > it, wine should have the bug which allows certain software to prevent > > screen grabs. > > > > I don't know of any apps that depend on this behavior, so that's not > likely to happen. Any DRM-enabled media player... which you would have understood if you looked at my next comment! > > > No, I think defeating DRM to enable fair use is > > perfectly reasonable, and there are some bugs which should be fixed. > > Should wine try to patch remote exploits at the exact same rate as > > windowsupdate.com? > > > > Since we have completely different code bases, I don't see how we can > fix their code in our tree. You misunderstood me completely, I'm beginning to wonder if you're doing so intentionally. To maintain "bug for bug compatibility", then when an exploit is discovered, wine won't be able to release a patch until after Microsoft has done so, because to do so earlier would be to implement functionality that doesn't match WIndows, breaking compatibility. > > > That would be also be required for true > > bug-for-bug compatibility. After all, someone properly authorized > > might be using that backdoor to reboot their webfarm remotely -- not! > > > > There are things that are wrong in a theoretical sense (i.e. the > > Pentium floating-point bug), or misclassification of Unicode > > characters, which some programs might reasonably depend on. And then > > there are things that are wrong from a practical engineering > > perspective, like software taking away the user's choice to not run > > it, which the mere fact that a program depends on it makes it malware. > > > > Are you a software engineer? From a practical engineering > perspective, adding this option adds unnecessary complication to the > code base and increases the chances for bugs. This is exactly what I consider this sort of thing quite necessary, I would implement that function on Windows if it was possible without totally replacing all the security code (processing of Start menu/Programs/Startup and HKLM/Software/.../Run can be turned off, but group policy start items can't be disabled in any way that I'm aware of). > UAC does, and no competent engineer thinks UAC is a good thing, or > that it adds any amount of security. This "malware" that you're so UAC does add security, but the interface is horrid. It's really the same idea as Linux's don't-login-as-root, except that with linux you don't necessarily have to use sudo and type a password for every process you want to run elevated, there's suid, sudo remembers your credentials for a short while, you can open an elevated shell, etc. I think UAC has some of the same capability between signed manifests in place of suid and you can probably run an elevated shell there as well. > afraid of can just write over that registry entry. > I don't run Vista, but my understanding is that you can't permanently approve a particular program to run elevated, the question reappears every single time. Giving the user a per-program "Remember my answer" option improves the user experience so much it's not even comparable. And I have never advocated for putting this in the registry, my suggestion has always been to store these settings in a file outside the .wine/drive_c jail area that is accessbile via wine's Win32 API. > If this entry defaults to "Always" or "Never", then the users won't > even know that the option exists, and that's one more piece of > information that we'll have to broadcast and answer questions about. So the best thing would be to set "Ask" as the installation default, and in addition to the "Yes/No/Always/Never" buttons on the prompt, provide a link to the winecfg page where the default is configured. > > > Reduced privileges do little or nothing to prevent network abuse (open > > spam relay and the like). > > > > If you're running executables that are going to add themselves to > AutoStart, the fact that they might run again is the least of your > concerns. While I agree 100%, stopping the malware from running itself after a reboot is still a very good thing. How useful would chroot be if the chrooted programs could set up autostart items or cron jobs without the admin's approval? Not nearly as much as it is now.

Feb. 14, 2007

Re: [Janitorial] snmpapi: Remove the last-but-one %ll printf format

by Detlef Riekenberg

On Mi, 2007-02-14 at 15:27 -0200, Pedro Araujo Chaves Jr. wrote: > - TRACE("Counter64 %llu\n", any->asnValue.counter64.QuadPart); > + TRACE("Counter64 %su\n", > wine_dbgstr_longlong(any->asnValue.counter64.QuadPart)); > return; Did you mean "%s" ? (used "%su") -- By by ... Detlef

Feb. 14, 2007

Re: [cmd][try3] Update Russian translate (edited) [Really sorry!!]

by Detlef Riekenberg

On Mi, 2007-02-14 at 15:16 +0300, Anatoly Lyutin wrote: > - HELP <> .\n" > + HELP <> .\n\ > + DOS http://www.citforum.ru/operating_systems/msdos/\n" > } That link is wrong in wine. Please remove from your Patch -- By by ... Detlef

Feb. 14, 2007

Direct Draw "palette_convert"

by Nathan Williams

I'm working on some direct draw code to get Carmageddon working. I think I have found my issue in IWineD3DPaletteImpl_SetEntries Carmageddon runs in 8 bit mode, my x windows is set at 24bit. If I drop xorg to 8bit, wine refuses to load. If i set it to 16bit, the Carmageddon menus are still bad, but noticeably better then running in 24bit. In SetEntries there is a bit of code idef'd out: #if 0 /* Now, if we are in 'depth conversion mode', update the screen palette */ /* FIXME: we need to update the image or we won't get palette fading. */ if (This->ddraw->d->palette_convert != NULL) This->ddraw->d->palette_convert(palent,This->screen_palents,start,count); #endif Uncommenting the above only leads to compile errors. Dredging through the wine archives, I see that the palette convert functions haven't been there since 2000. Can anyone give me an idea on why they were removed & what might be the best way to reimplement some form of palette conversion? (Even just in a hacky way right now, so i can test my assumptions) -- Nathan

Feb. 14, 2007

Re: AppDB performance issue

by John Smith

Humm very strange it works well for me, I just tested it myself, seems reasonably fast in firefox 2.0.0.1 on windows 2000, on gentoo x86 with firefox 2.0.0.1, and on gentoo amd64 firefox 2.0.0.1. I added, then removed, then edited a test result. Speed seemed normal. Hope this helps the investigation. Regards, John Klehm On 2/14/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > Bryan Haskins <kingofallhearts999 <at> gmail.com> writes: > > > > > > > I was just replying, and reading now, no slow down at all. It loads a > little > slow running through all that text, but no where near the minutes everyone > says > it takes them, even on dialup. > > > > > For your info, Appdb, is complete unusable for me ... Loading a page, or > adding a test result to an application takes several minutes. Please fix, > as > this is really annoying :( > > > >

Feb. 14, 2007

Re: [1/10] - [10/10] WineD3D

by Mirek

Luke Bratch napsal(a): >> Wow, great work!!!!! 3DMark 2006 with fbo looks > realy coool!! And some >> Nvidia SDK demos are completly fixed! > > How did you test 3DMark2006? When I try and run it, > it tells me I need Pixel Shader 2.0 support. > > I have UseGLSL set to enabled and OffscreenRenderMode > set to fbo, and the Pixel Shader 2 test in 3DMark03 > works fine. Yes, but after accept this error message i can select some test and run benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 and GT2 tests are almost perfect, but very slow (fbo is slower than backbuffer, so I am not using it in other applications), you should also disable post procesing (very very slow) in 3DMark. Here are some screenshots with latest wine and latest Stefan patches: http://62.240.181.87/Mirek/3DMark2006/ PS: I have GF 6800GS, Core 2 Duo X6800(a)3700MHz and about 2 FPS, but it works! :) Mirek

Feb. 14, 2007

[1/10] - [10/10] WineD3D

by Luke Bratch

> Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some > Nvidia SDK demos are completly fixed! How did you test 3DMark2006? When I try and run it, it tells me I need Pixel Shader 2.0 support. I have UseGLSL set to enabled and OffscreenRenderMode set to fbo, and the Pixel Shader 2 test in 3DMark03 works fine. ___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk

Feb. 14, 2007

Re: AppDB performance issue

by Louis Lenders

Bryan Haskins <kingofallhearts999 <at> gmail.com> writes: > > > I was just replying, and reading now, no slow down at all. It loads a little slow running through all that text, but no where near the minutes everyone says it takes them, even on dialup. > For your info, Appdb, is complete unusable for me ... Loading a page, or adding a test result to an application takes several minutes. Please fix, as this is really annoying :(

Feb. 14, 2007

Re: [1/10] - [10/10] WineD3D

by Stefan Dösinger

Am Mittwoch 14 Februar 2007 20:11 schrieb Mirek: > Wow, great work!!!!! 3DMark 2006 with fbo looks realy coool!! And some > Nvidia SDK demos are completly fixed! Though I doubt that patch fixed it. You can do a regression test to find the patch that fixed it if you want, but last I tried to look for a fix I had to revert the sense of good and bad > Mirek > > Stefan Dösinger napsal(a): > > ------------------------------------------------------------------------ > > > > From c59f7c4eea148cfb9a1321bbbbc587ef52194bc9 Mon Sep 17 00:00:00 2001 > > From: Stefan Doesinger <stefan(a)codeweavers.com> > > Date: Fri, 2 Feb 2007 15:30:34 +0100 > > Subject: [PATCH] WineD3D: Properly release the converted vertex > > declaration > > > > --- > > dlls/d3d9/d3d9_private.h | 5 +++++ > > dlls/d3d9/device.c | 3 +++ > > dlls/d3d9/vertexdeclaration.c | 5 +++++ > > 3 files changed, 13 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h > > index 435a37e..972945d 100644 > > --- a/dlls/d3d9/d3d9_private.h > > +++ b/dlls/d3d9/d3d9_private.h > > @@ -179,6 +179,11 @@ typedef struct IDirect3DDevice9Impl > > /* Avoids recursion with nested ReleaseRef to 0 */ > > BOOL inDestruction; > > > > + /* A vertex declaration was converted from setFVF. > > + * Keep track of it, so it can be properly freed > > + */ > > + IDirect3DVertexDeclaration9 *convertedDecl; > > + > > } IDirect3DDevice9Impl; > > > > > > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > > index 4eff550..e6ecd96 100644 > > --- a/dlls/d3d9/device.c > > +++ b/dlls/d3d9/device.c > > @@ -62,6 +62,8 @@ static ULONG WINAPI > > IDirect3DDevice9Impl_Release(LPDIRECT3DDEVICE9 iface) { > > > > if (ref == 0) { > > This->inDestruction = TRUE; > > + if (This->convertedDecl != NULL) > > + IUnknown_Release(This->convertedDecl); > > IWineD3DDevice_Uninit3D(This->WineD3DDevice, > > D3D9CB_DestroyDepthStencilSurface, D3D9CB_DestroySwapChain); > > IWineD3DDevice_Release(This->WineD3DDevice); > > HeapFree(GetProcessHeap(), 0, This); > > @@ -766,6 +768,7 @@ HRESULT WINAPI > > IDirect3DDevice9Impl_SetFVF(LPDIRECT3DDEVICE9 iface, DWORD FVF) > > > > hr = IDirect3DDevice9Impl_SetVertexDeclaration(iface, pDecl); > > if (hr != S_OK) goto exit; > > + This->convertedDecl = pDecl; > > pDecl = NULL; > > > > exit: > > diff --git a/dlls/d3d9/vertexdeclaration.c > > b/dlls/d3d9/vertexdeclaration.c index a7f5486..c3f462e 100644 > > --- a/dlls/d3d9/vertexdeclaration.c > > +++ b/dlls/d3d9/vertexdeclaration.c > > @@ -360,6 +360,11 @@ HRESULT WINAPI > > IDirect3DDevice9Impl_SetVertexDeclaration(LPDIRECT3DDEVICE9 ifa > > > > TRACE("(%p) : Relay\n", iface); > > > > + if (This->convertedDecl && This->convertedDecl != pDecl) { > > + IUnknown_Release(This->convertedDecl); > > + This->convertedDecl = NULL; > > + } > > + > > hr = IWineD3DDevice_SetVertexDeclaration(This->WineD3DDevice, > > pDeclImpl == NULL ? NULL : pDeclImpl->wineD3DVertexDeclaration); > > > > return hr; > > > > > > ------------------------------------------------------------------------

Feb. 14, 2007