April 2011 - Wine-Devel - list.winehq.org

Re: Must multimedia players check the message queue and invoke DispatchMessage?

by Ove Kaaven

Den 08. april 2011 13:15, skrev Joerg-Cyril.Hoehle(a)t-systems.com: > DispatchMessage is not always needed. Unfortunately, I don't grok > yet when DispatchMessage is required. > > http://blogs.msdn.com/b/oldnewthing/archive/2004/06/08/150929.aspx > "Everybody who has messed with window messaging knows that GetMessage > and PeekMessage retrieve queued messages, which are dispatched to > windows via DispatchMessage." > > None the clearer. If I just retrieved them (they were obviously > "dispatched" to my queue), why must I dispatch again? No, they were *not* dispatched to your queue, they were queued (posted). DispatchMessage calls the appropriate window procedure, it is not used to queue messages. Sending and queuing is *not* the same. The rule is basically: - If the message was queued with Post*Message, then GetMessage/PeekMessage returns it and you should pass it to DispatchMessage. - If the message was sent with Send*Message, then GetMessage/PeekMessage handles (dispatches) it, does not return it, and thus DispatchMessage would never even see it. Consider sent messages synchronous, and posted/queued messages as asynchronous. Windows may reorder queued (asynchronous) messages by message priority class, so that e.g. GetMessage may return a WM_PAINT only after all other (higher-priority) messages have been returned and dispatched. > I.e. what's the kind of work that the function calling GetMessage > Should/can do vs. the work to be done by whatever function DispatchMessage > eventually calls? The function calling GetMessage isn't supposed to do anything beyond calling DispatchMessage.

April 9, 2011

Re: Project: x86 to ARM binary translator

by Stefan Dösinger

Am 08.04.2011 um 11:16 schrieb Yale Zhang: > The 2nd approach, which is almost identical to FX!32 (runs x86 Windows programs on Alpha Windows), will be to do what Stefan proposed 2nd: create a stand alone process VM to run x86 Windows apps on ARM Windows, using wrappers to translate x86 Windows functions to ARM Windows functions. I think those wrappers/jackets can be generated automatically by scanning header files. I don't think you can autogenerate the wrappers. They require very deep understanding of the data passed around, e.g. if a parameter is a pointer to a structure you have to convert the members, which also may be pointers, ... You could even have things like double-linked lists where you have to know when to abort. Very often you don't even know the size of memory blobs pointed to by pointers without an in-depth look at other parameters, e.g. glTexImage2D. Sometimes you might take some shortcuts in the conversion, especially with endianess or alignment. E.g. the D3D API already gives you 16 byte alignment for resources. Instead of swapping the byte order of the image data passed to glTexImage2D(or d3dsurface::lock) you could just change the pixelformat(fmt and type parameter or the d3d pixel format). As I said, writing such an API wrapper is probably comparable to the effort needed to implement Wine. > I still don't like this approach due to doing the API translation and instruction set translation in 2 separate programs. Ideally, I would take the Darwine approach of doing both API translation and binary translation both in Wine. Separation of concerns? You do of course need a bit of integration. An API wrapper needs a functionality in the CPU emulator to enter and leave the emulated environment, somewhat similar to switching between ring3 and ring0 on x86 CPUs. > To me, the API translation is less interesting than doing x86 to ARM translation efficiently. I said earlier, QEMU's approach of translating target instructions => micro ops => host instructions is inefficient due to generating redundant operations. I'm afraid you're looking at the wrong project then, you'd probably be better off looking at something less complex than the Windows API and focus on something that stresses the CPU side more. My impression is that running x86 code on <insert other platform here> is a more or less solved problem. It's probably not solved at maximum efficiency, but there are working solutions(bochs, qemu, probably some JIT compilers)

April 9, 2011

Re: Try to implement my first stub function - AbortPrinter() - (try 3)

by Loïc Maury

Hello Andrew, > Hi Loïc, > > On 04/08/2011 07:54 AM, Loïc Maury wrote: >> I try always to implement my first stub function - AbortPrinter. > > It's looking good. Before you submit this, you should add some tests. > Take a look in <dlls/winspool.drv/tests/>. Demonstrate that > AbortPrinter() on Windows behaves the same way as your function does. > Make sure to test the value of GetLastError() on failure. You can run > your tests through the testbot <https://testbot.winehq.org/> before > submitting. Look at other tests for some guidance. Ok I will see that. > > Below are a couple of tiny suggestions. > > + ERR("The handle for the printer is invalid.\n"); > + TRACE("Document inside for job id : %d\n", > printer->doc->job_id); > + ERR("No document.\n"); > + TRACE("(hf : %p, job id : %d)\n", printer->doc->hf, > printer->doc->job_id); > + TRACE("portname : %s\n", debugstr_w(portname)); > + TRACE("Remove job from the list.\n"); > + TRACE("Remove document for the printer : %s.\n", > debugstr_w(printer->printername)); > > You're outputting a lot of debug information. The ERRs aren't really > errors, but just invalid values from the application which are handled > appropriately. No problem here, so no need to ERR. > > The other TRACE statements might be useful for debugging this > particular function, but can clutter the output and make future > maintenance more difficult. I'd remove them. Ok I will remove this TRACE and ERR. > > + /* For each jobs, see if we have a job document in the double > linked list */ > + /* Get portname. */ > + /* Cups Port */ > + /* The document for the printer is not useful > anymore. */ > > These comments are entirely redundant. The code is perfectly clear, > and the comments will just rot if this code is updated later. Don't > bother with comments like these unless you're doing something very > unclear. Ok > > + retFromGetPrinter = GetPrinterW(hPrinter, 2, > (LPBYTE)pi2, needed, &needed); > + if(!retFromGetPrinter) > + goto end; > > You can just do "if(!GetPrinterW(...))" and remove the local variable. Yes the local variable is not necessary Thank you for your help. Loïc > > Thanks for contributing, > Andrew >

April 8, 2011

Re: Must multimedia players check the message queue and invoke DispatchMessage?

by Juan Lang

Hi Joerg, > DispatchMessage is not always needed. Unfortunately, I don't grok > yet when DispatchMessage is required. > > http://blogs.msdn.com/b/oldnewthing/archive/2004/06/08/150929.aspx > "Everybody who has messed with window messaging knows that GetMessage > and PeekMessage retrieve queued messages, which are dispatched to > windows via DispatchMessage." > > None the clearer. If I just retrieved them (they were obviously > "dispatched" to my queue), why must I dispatch again? > I.e. what's the kind of work that the function calling GetMessage > Should/can do vs. the work to be done by whatever function DispatchMessage > eventually calls? GetMessage removes a message from the input queue, PeekMessage allows you to examine the contents of the message queue, but neither actually delivers the message to the appropriate WndProc. That's what DispatchMessage does. They're separate either because of history or because of design, but in either case, they are separate ;) PeekMessage is useful for message pumps: it allows you to retrieve specific messages from the queue that you wish to handle yourself, without retrieving messages the main application expects to receive. There are many references out there on Win32, but if you were to consult a book, Charles Petzold's book Programming Windows is the classic guide: http://www.charlespetzold.com/pw5/index.html --Juan

April 8, 2011

Re: wined3d: Track when the FBO is dirty. (try 3)

by Henri Verbeet

On 7 April 2011 18:51, Adam Martinson <amartinson(a)codeweavers.com> wrote: > - context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, depth_stencil, SFLAG_INTEXTURE); > + > + if (rt_count == device->adapter->gl_info.limits.buffers && > + rts == device->render_targets && > + depth_stencil == device->depth_stencil) > + { > + if (context->device_fbo != NULL) > + { > + context_apply_device_fbo(context); > + } > + else > + { > + context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, depth_stencil, SFLAG_INTEXTURE); > + context->device_fbo = context->current_fbo; > + } > + } > + else > + { > + context_apply_fbo_state(context, GL_FRAMEBUFFER, context->blit_targets, depth_stencil, SFLAG_INTEXTURE); > + } That's not very pretty. > @@ -6709,6 +6721,7 @@ void device_resource_released(struct IWineD3DDeviceImpl *device, struct wined3d_ > { > ERR("Surface %p is still in use as render target %u.\n", surface, i); > device->render_targets[i] = NULL; > + fbo_dirty = TRUE; > } > } > > @@ -6716,7 +6729,10 @@ void device_resource_released(struct IWineD3DDeviceImpl *device, struct wined3d_ > { > ERR("Surface %p is still in use as depth/stencil buffer.\n", surface); > device->depth_stencil = NULL; > + fbo_dirty = TRUE; That code should never execute, hence the ERR.

April 8, 2011

Re: Try to implement my first stub function - AbortPrinter() - (try 3)

by Andrew Eikum

Hi Loïc, On 04/08/2011 07:54 AM, Loïc Maury wrote: > I try always to implement my first stub function - AbortPrinter. It's looking good. Before you submit this, you should add some tests. Take a look in <dlls/winspool.drv/tests/>. Demonstrate that AbortPrinter() on Windows behaves the same way as your function does. Make sure to test the value of GetLastError() on failure. You can run your tests through the testbot <https://testbot.winehq.org/> before submitting. Look at other tests for some guidance. Below are a couple of tiny suggestions. + ERR("The handle for the printer is invalid.\n"); + TRACE("Document inside for job id : %d\n", printer->doc->job_id); + ERR("No document.\n"); + TRACE("(hf : %p, job id : %d)\n", printer->doc->hf, printer->doc->job_id); + TRACE("portname : %s\n", debugstr_w(portname)); + TRACE("Remove job from the list.\n"); + TRACE("Remove document for the printer : %s.\n", debugstr_w(printer->printername)); You're outputting a lot of debug information. The ERRs aren't really errors, but just invalid values from the application which are handled appropriately. No problem here, so no need to ERR. The other TRACE statements might be useful for debugging this particular function, but can clutter the output and make future maintenance more difficult. I'd remove them. + /* For each jobs, see if we have a job document in the double linked list */ + /* Get portname. */ + /* Cups Port */ + /* The document for the printer is not useful anymore. */ These comments are entirely redundant. The code is perfectly clear, and the comments will just rot if this code is updated later. Don't bother with comments like these unless you're doing something very unclear. + retFromGetPrinter = GetPrinterW(hPrinter, 2, (LPBYTE)pi2, needed, &needed); + if(!retFromGetPrinter) + goto end; You can just do "if(!GetPrinterW(...))" and remove the local variable. Thanks for contributing, Andrew

April 8, 2011

Try to implement my first stub function - AbortPrinter() - (try 3)

by Loïc Maury

Hello, I try always to implement my first stub function - AbortPrinter. The last time, I send into Wine patch mailling list, but the patch was not correct. Now I think the format for the patch is correct (no whitespace, etc…). More over, I have modified the value if(!job->portname) by if(!portname), because after the test "if(!job->portname)", I print trace of portname, but before he was initialized into the "if condition" and can to not enter into this condition. What do you think ? Thank you Loïc

April 8, 2011

Re: [PATCH 4/5] wined3d: Merge the IWineD3DSwapChain::Destroy() implementations.

by Henri Verbeet

On 8 April 2011 14:08, Alexandre Julliard <julliard(a)winehq.org> wrote: > =>0 0x687550fa context_destroy+0x2a(This=0x134d58, context=(nil)) [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d (0x0032f948) > 1 0x6880052b IWineD3DBaseSwapChainImpl_Destroy+0x18a(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:65] in wined3d (0x0032f9a8) Applying the attached patch anywhere before 4 should help. Would you like a new series?

April 8, 2011

Re: [PATCH 4/5] wined3d: Merge the IWineD3DSwapChain::Destroy() implementations.

by Alexandre Julliard

Henri Verbeet <hverbeet(a)codeweavers.com> writes: > They're mostly the same, except for the GL version also destroying its > contexts, and being a bit more careful about the order in which backbuffers > are destroyed. > --- > dlls/wined3d/swapchain.c | 175 ++++++++++++++++----------------------------- > 1 files changed, 62 insertions(+), 113 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so ddrawmodes.c && touch ddrawmodes.ok wine: Unhandled page fault on read access to 0x00000f2c at address 0x687550fa (thread 0021), starting debugger... Unhandled exception: page fault on read access to 0x00000f2c in 32-bit code (0x687550fa). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:687550fa ESP:0032f910 EBP:0032f948 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000021 EBX:6884b244 ECX:00110064 EDX:00000000 ESI:00000000 EDI:00000001 Stack dump: 0x0032f910: 00001302 00131ef0 00000000 00000000 0x0032f920: 00000000 00000000 00000000 00110014 0x0032f930: 0000ff00 000000ff 687550db 6884b244 0x0032f940: 00131848 00000001 0032f9a8 6880052b 0x0032f950: 00134d58 00000000 00131ef0 7bc73cfc 0x0032f960: 00000002 00129f28 00000000 000004b0 Backtrace: =>0 0x687550fa context_destroy+0x2a(This=0x134d58, context=(nil)) [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d (0x0032f948) 1 0x6880052b IWineD3DBaseSwapChainImpl_Destroy+0x18a(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:65] in wined3d (0x0032f9a8) 2 0x688006a1 IWineD3DBaseSwapChainImpl_Release+0x40(iface=0x131848) [/home/julliard/wine/wine/dlls/wined3d/swapchain.c:125] in wined3d (0x0032f9e8) 3 0x686d25b9 D3D7CB_DestroySwapChain+0x58(swapchain=0x131848) [/home/julliard/wine/wine/dlls/ddraw/ddraw.c:2621] in ddraw (0x0032fa18) 4 0x6875d317 IWineD3DDeviceImpl_UninitGDI+0x66(iface=0x134d58, D3DCB_DestroySwapChain=0x686d2560) [/home/julliard/wine/wine/dlls/wined3d/device.c:2300] in wined3d (0x0032fa78) 5 0x686f8f6e ddraw_surface7_Release+0x1cd(iface=0x129f28) [/home/julliard/wine/wine/dlls/ddraw/surface.c:396] in ddraw (0x0032fad8) 6 0x68689c21 func_ddrawmodes+0x2720() [/home/julliard/wine/wine/dlls/ddraw/tests/ddrawmodes.c:583] in ddraw_test (0x0032fd38) 7 0x686adc9e run_test+0x14d(name="ddrawmodes.c") [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:556] in ddraw_test (0x0032fd88) 8 0x686ae767 main+0x156(argc=0xffffffff, argv=(nil)) [/home/julliard/wine/wine/dlls/ddraw/tests/../../../include/wine/test.h:624] in ddraw_test (0x0032fe48) 9 0x686ae93c __wine_spec_exe_entry+0x7b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ddraw_test (0x0032fe90) 10 0x7b859a6c call_process_entry+0xb() in kernel32 (0x0032fea8) 11 0x7b85a69f start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1086] in kernel32 (0x0032fee8) 12 0x7bc74c78 call_thread_func+0xb() in ntdll (0x0032fef8) 13 0x7bc776b0 call_thread_entry_point+0x6f(entry=0x7b85a640, arg=0x7ffdf000) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2499] in ntdll (0x0032ffc8) 14 0x7bc4d27a start_process+0x29(kernel_start=0x7b85a640) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2606] in ntdll (0x0032ffe8) 15 0x6802996d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x687550fa context_destroy+0x2a [/home/julliard/wine/wine/dlls/wined3d/context.c:1615] in wined3d: cmpl %eax,0xf2c(%esi) 1615 if (context->tid == GetCurrentThreadId() || !context->current) -- Alexandre Julliard julliard(a)winehq.org

April 8, 2011

Re: ntdll: Remove more path trailing chars.

by Vincent Pelletier

Le vendredi 08 avril 2011 13:05:18, Joerg-Cyril.Hoehle(a)t-systems.com a écrit : > It means tests never fail on native, which renders the test useless. That's exactly my point. I started writing a mail to describe just what you said, with the extra data that on wine, test will verify something decided upon test writing. It just won't be compared to any windows version. I'm (somehow) glad to hear it's not the only test which has problems with just NT. > Any other means to detect NT *that is relevant for your test* is fine, i.e. > don't query the DLL version or use some function outside of your test > domain. > Typical detectors are different GetLastError() values. I'll check what error this triggers on NT, and fallback on the code you wrote above. As I don't have access to an NT machine, I sent an account request for the test bot. Regards, -- Vincent Pelletier

April 8, 2011