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

re: Glitch-free iTunes?

by Dan Kegel

Keith wrote: > http://www.pcworld.com/businesscenter/article/229398-2/day_3_dude_wheres_my… > Can you make a goal of supporting iTunes with no glitches? ... > Just this one app could be huge for Linux on the desktop. The main problem is driver support, I think (mainly usb, but probably also cd-r). There is some work on usb support going on; see http://wiki.winehq.org/USB I haven't tried that myself. (Has anyone tried this with iTunes yet?) According to $ winedump -j import ~/".wine/drive_c/Program Files/Common Files/Apple/Mobile Device Support/Drivers/usbaapl.sys" | grep offset offset 00009250 ntoskrnl.exe offset 00009264 HAL.dll offset 00009278 WMILIB.SYS offset 0000928c USBD.SYS support for wmilib.sys might need to be added for this app. And I suspect the pcworld guy was using an outdated version of wine (given the problems he reported with the package manager ui). Otherwise, current iTunes seems to be working reasonably well in current wine. I just downloaded and installed iTunes 10.3.1 with wine-1.3.23. I did have to set win7 mode, and I do have to click through one dialog saying it won't be able to burn cd's, but I can use the iTunes store to search for movies and play their trailers nicely; I can listen to internet radio or a local .mp3 for 5-10 minutes with no hint of trouble. So: yeah, we know it's an important app. But it's hard. Feel free to help out. - Dan

July 2, 2011

Glitch-free iTunes?

by Keith Curtis

Hi; Here is a rant about iTunes: http://www.pcworld.com/businesscenter/article/229398-2/day_3_dude_wheres_my… You guys are doing great, but I think it would be better if you were to work more in priority order. There are 200M devices, last I checked. I don't think iTunes has ever properly worked in WINE. It seems like Apple keep revising it and so the current WINE never works with the current iTunes. Can you make a goal of supporting iTunes with no glitches? I know many of you are volunteers, but it is globally efficient if the installation number plays into the priority of the bugs. Just this one app could be huge for Linux on the desktop. Warm regards, -Keith

July 2, 2011

Random crashes while running (cmd) test runner

by Frédéric Delanoy

Hi folks, I'm in the process of writing a couple of cmd tests (on top of master, not of my currently pending patches), and I at times have problems where none of the tests is actually performed, but the test suite still returns without any error indication, e.g. batch.c:306: running TEST_BUILTINS.CMD test... batch: 7 tests executed (0 marked as todo, 0 failures), 0 skipped. which many more tests should be performed After checking with "winedbg --gdb" it gets a SIGSEGV I tried to reproduce with a mimimal output file and expected file, and get weird results. Say you have the following files: test_builtins.cmd @echo off echo should fail <empty line> and test_builtins.cmd.exp dir <empty line> When I run make testclean && make test in programs/cmd/tests, I get the following (first line of .exp file executed somehow...) batch.c:215: Test failed: unexpected char 0x73 position 0 in line 1 (got 'should fail', wanted 'dir') batch.c:227: Test failed: too long output, got additional Volume Serial Number is 0000-0000 Directory of Z:\path\to\wine\programs\cmd\tests 2/07/2011 20:56 <DIR> . 2/07/2011 14:34 <DIR> .. 2/07/2011 2:34 11,074 batch.c <...> batch: 14 tests executed (0 marked as todo, 2 failures), 0 skipped. If I run "/wine winedbg --gdb programs/cmd/tests/cmd.exe_test.exe.so" and run (c)ont, I get a SIGSEGV: Program received signal SIGSEGV, Segmentation fault. 0x7bc481f2 in HEAP_MakeInUseBlockFree (subheap=0x110014, pArena=0x1106a8) at heap.c:640 640 size += (pFree->size & ARENA_SIZE_MASK) + sizeof(ARENA_FREE); Full backtrace: #0 0x7bc481f2 in HEAP_MakeInUseBlockFree (subheap=0x110014, pArena=0x1106a8) at heap.c:640 #1 0x7bc4b7f5 in RtlFreeHeap (heap=0x110000, flags=2, ptr=0x1106b0) at heap.c:1757 #2 0x7bc6ed27 in RtlFreeUnicodeString (str=0x33f8fc) at rtlstr.c:319 #3 0x7b83f06c in CreateFileW (filename=0x7ffd8c00, access=1073741824, sharing=0, sa=0x0, creation=2, attributes=128, template=0x0) at file.c:1421 #4 0x7b83f14a in CreateFileA (filename=0x7effd262 "test.cmd", access=1073741824, sharing=0, sa=0x0, creation=2, attributes=128, template=0x0) at file.c:1443 #5 0x7effaf5a in run_cmd (cmd_data=0x110688 "@echo off\necho should fail\n\n\ndirb", cmd_size=34) at batch.c:68 #6 0x7effb9f4 in run_test (cmd_data=0x7efff52c "@echo off\necho should fail\n\n\ndir\n\n", cmd_size=28, exp_data=0x7efff548 "\ndir\n\n", exp_size=6) at batch.c:239 #7 0x7effbe46 in test_enum_proc (module=0x7eff0000, type=0x7effd4ab "TESTCMD", name=0x110668 "TEST_BUILTINS.CMD", param=0) at batch.c:317 #8 0x7b86d748 in EnumResourceNamesA (hmod=0x7eff0000, type=0x7effd4ab "TESTCMD", lpfun=0x7effbd43 <test_enum_proc>, lparam=0) at resource.c:345 #9 0x7effc008 in func_batch () at batch.c:353 #10 0x7effcc92 in run_test (name=0x7effd745 "batch") at ../../../include/wine/test.h:556 #11 0x7effd057 in main (argc=1, argv=0x1103e0) at ../../../include/wine/test.h:616 #12 0x7effd136 in __wine_spec_exe_entry (peb=0x7ffdf000) at exe_entry.c:36 #13 0x7b860008 in call_process_entry () at process.c:1035 #14 0x7b86014f in start_process (peb=0x7ffdf000) at process.c:1087 #15 0x7bc7f22c in call_thread_func () at signal_i386.c:2473 #16 0x7bc7f26a in call_thread_entry_point (entry=0x7b86000a <start_process>, arg=0x7ffdf000) at signal_i386.c:2499 #17 0x7bc542cf in start_process (kernel_start=0x7b86000a) at loader.c:2612 #18 0xf7609b95 in wine_call_on_stack () at port.c:60 #19 0xf7609b73 in wine_switch_to_stack (func=0x7bc542a9 <start_process>, arg=0x7b86000a, stack=0x340000) at port.c:59 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Does anyone know what's going wrong exactly? Frédéric Note: wine-1.3.23-164-ge18c15d compiled with "-O0 -g" on Natty x86_64

July 2, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Fri, Jul 1, 2011 at 7:22 AM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > On Thu, Jun 30, 2011 at 3:50 PM, Michael Mc Donnell > <michael(a)mcdonnell.dk> wrote: >> I've implemented the look-up scheme that you described. > >> + if (!point_reps) /* Indentity point reps */ >> + { >> + memset(adjacency, -1, 3 * num_faces * sizeof(*adjacency)); >> + return D3D_OK; >> + } > > I think you are missing the most common cases, where vertices are > reused between triangles. For example: > > 0--1 > | /| > |/ | > 2--3 > > If identity point reps are passed to your function it will find the > adjacent edge, but if NULL is passed to the function for point reps, > then it will find no adjacencies even though semantically they should > be the same. Ok, I've added that example to the test and fixed the implementation. > Also, note the spelling error: Indentity -> Identity Check :-) >> +static void free_edge_face_map(struct edge_face_map *edge_face_map) >> +{ >> + if (!edge_face_map) >> + return; >> + >> + HeapFree(GetProcessHeap(), 0, edge_face_map->lists); >> + HeapFree(GetProcessHeap(), 0, edge_face_map->entries); >> +} > ... >> static HRESULT WINAPI ID3DXMeshImpl_ConvertPointRepsToAdjacency(ID3DXMesh *iface, CONST DWORD *point_reps, DWORD *adjacency) >> { >> + struct edge_face_map *edge_face_map = NULL; > ... >> + free_edge_face_map(edge_face_map); >> + iface->lpVtbl->UnlockIndexBuffer(iface); >> + return hr; >> } > > edge_face_map isn't freed. Also, it doesn't need to be allocated on the heap. Ok, I've moved it to the stack. >> + hr = iface->lpVtbl->LockIndexBuffer(iface, 0, &ib_ptr); > > The LockIndexBuffer flags could be D3DLOCK_READONLY rather than 0 > (which seems to have read-write semantics). Fixed. Thank you for the good review.

July 2, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Thu, Jun 30, 2011 at 10:59 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Thursday 30 June 2011 21:50:45 Michael Mc Donnell wrote: >> I have another question about my test. I've basically copied all the >> test data from my ConvertAdjacencyToPointReps test, and then just >> inverted the conditions. Should I merge the two tests, put the test >> data in a separate function, or just ignore the duplication? > IMO keeping the tests separated and as simple as possible is more important > than avoiding code duplication here, but I don't think we have a policy about > this. Ok, I'll keep what I have for now.

July 2, 2011

Re: user32: check for the file signature before load a cursor/icon from it (try2)

by Nikolay Sivov

On Sat, Jul 2, 2011 at 4:29 PM, Vitaly Perov <vitperov(a)etersoft.ru> wrote: > It fix crash in the russian accounting application "CheckXML+" > > -- > Best regards, > Vitaly Perov > This patch needs a test I think.

July 2, 2011

Re: wine bug 27600

by Vincas Miliūnas

On 07/02/2011 04:21 AM, Austin Lund wrote: > On 1 July 2011 06:10, <wylda(a)volny.cz> wrote: >> >> gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ >> -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >> -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes >> -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o adsiid.o >> adsiid.c >> >> In file included from bug_test.c:8: >> >> ../include/winternl.h:2361: error: expected declaration specifiers >> or ‘...’ before ‘va_list’ >> > Try adding "#include <stdarg.h>" before the windows headers. > That is the correct answer, it's just the 64bit version of gcc (due to a feature or configuration path) works without it.

July 2, 2011

copy/paste bug in imm32: Test and fix ImmIsUIMessageA/W?

by wylda＠volny.cz

Hi, i guess you know my programming skill, so be nice to me if total nonsence: if ( ... || ... + (msg == WM_IME_SELECT) || + (msg == WM_IME_SELECT) || ... seem to redundant. It happens it two places. Regards, W.

July 2, 2011

Re: wine bug 27600

by Austin Lund

On 1 July 2011 06:10, <wylda(a)volny.cz> wrote: > > > gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wempty-body -Wstrict-prototypes > -Wtype-limits -Wwrite-strings -Wpointer-arith -g -O2 -o adsiid.o > adsiid.c > > In file included from bug_test.c:8: > > ../include/winternl.h:2361: error: expected declaration specifiers > or ‘...’ before ‘va_list’ > Try adding "#include <stdarg.h>" before the windows headers.

July 2, 2011

Re: [2/6] wined3d: Move FBO application into a state handler

by Stefan Dösinger

On Friday 01 July 2011 20:26:58 Henri Verbeet wrote: > On 1 July 2011 18:49, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > I put the code that used to be in context_apply_draw_state into state.c > > because the FBO stuff is now a state handler. The alternative would be to > > keep it in context.c and just export one function - that means we don't > > need the rt mask functions in wined3d_private.h > > That's probably nicer. I'll try to change the patch in this way and see what happens. This would remove part of the rationale for patch 1, but I think patch 1 is still worth it for consistency.

July 1, 2011