July 2004 - Wine-devel - list.winehq.org

Support for IDvdInfo2::GetDiscID
by James Courtier-Dutton 25 Mar '05

25 Mar '05

The Windows api method uses the function call IDvdInfo2::GetDiscID http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… This returns a unique 64bit ID for a DVD. Has anyone found out what exactly it does to create this 64bit ID. It would be nice to get linux DVD players to be able to use the same method. Cheers James

2 2

text edit box not painting text ( on form startup )
by Doug Herbert 09 Mar '05

09 Mar '05

( I have posted a similiar question in wine-users, don't flame me for doing so, just thinking about this some more, perhaps it may be more a developer question ) Ok, I have a windows app, that runs under wine fine - not quite. This app has a form, with many text field edit boxes on. Quite often these edit boxes already have text values, ie. they are not empty - there is a database behind the form. Anyway, the form shows on the screen, but the text within the edit fields is invisible, until you activate each edit box component. When you leave one edit box to the next, the text remains visible. It seems like the repainting is not working, on initial startup of the form. As a way to debug this database app ( I don't have the source code for it ) I wrote a real basic form app in Visual Studio, with two edit boxes, with data in each. Now this basic app shows the text values immediately on startup. So there must be something different that the database app is not doing. I then ran wine using 'wine --debugmsg +edit programname' for both app's. I see both logging 'Creating ANSI edit control, style = xxxxx' but the style reference is different between apps - I am not sure if this the cause or not. The problem app reports style = 54011104 and the basic app shows style = 50010080. Can somebody explain what this style reference means and how do I force an app to use a certain style of edit box ? What other wine class debugmsg types should I use to narrow down the source of this problem ? Is there anyway I can check to see how the database app is repainting text within the text edit components ? Regards Doug Herbert. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 4

Re: Wine on FreeBSD current
by Gerald Pfeifer 30 Oct '04

30 Oct '04

>> I'm just wondering if it is supposed to work as well as FreeBSD stable. Right now, Wine doesn't work at all on FreeBSD -STABLE: wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory and before that I used to see deadlocks upon startup of non-trivial applications (such as Forte Agent, both 16bit and 32bit flavors). I believe there are also signficant threadings issues on -CURRENT, so overall Wine is hardly, if at all, usable on any version of FreeBSD I have access to, even though I'm still working to keep it at least compilable on FreeBSD 4.9 and 5.2/5.3. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

6 13

Don't crash on failing DRIVER_FindFromHDrvr
by Uwe Bonnes 06 Sep '04

06 Sep '04

Hallo, I sent a patch to prevent wine from crashing last friday. It happend, when DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that patch before last year. Eric answered > this doesn't seem right to me: either the loading fails and we shouldn't > get a valid handle, or it succeeds and we should be able to find it > there's must be something wrong elsewhere > could you please send a -debugmsg +driver,+module,+winmm to see what > happens ? and like before, I can't reproduce the error after reverting the patch: > the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. > > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other usage of DRIVER_FindFromHDrvr is like if ((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL) Why should expecting a NULL return be wrong? It happens, as the the crashes show. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 4

Wine bug with delphi Menus
by Robert van Herk 05 Sep '04

05 Sep '04

Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working, when the program is run under Wine. Behind the screens, the setVisible of a menu item calls MenuChanged. This seems to put the menu in such a state that, in wine, all menu components stop doing anything. I've written a small application (455 kb EXE) to show what goes wrong. Would anybody be interested to help me in solving this bug? Would a message trace from Winsight (for example) be of any help? Greetings, Robert

2 1

Remote operations -- need for advice
by Alexander Yaworsky 27 Aug '04

27 Aug '04

I'm thinking how to implement CreateRemoteThread and besides fix memory management functions. The complete (afaik) list includes: RtlCreateUserThread NtAllocateVirtualMemory NtFreeVirtualMemory NtProtectVirtualMemory NtQueryVirtualMemory NtLockVirtualMemory (do nothing?) NtUnlockVirtualMemory (do nothing?) NtFlushVirtualMemory NtMapViewOfSection NtUnmapViewOfSection Suggested implementation. Let's add two groups of handlers to the wineserver, something like remote_operation_xxxx and remote_operation_xxxx_complete. remote_operation should do the following: 1) suspend_for_ptrace(); 2) inject a piece of code into required process and start its execution; 3) resume_after_ptrace(); 4) place calling thread into suspended state (or into some wait state?) remote_operation_complete should prepare reply and resume thread suspended by remote_operation. Injected code should call required function and then remote_operation_complete in context of required process. The question is: how to correctly get address of function? imho possible solutions are: 1) assume ntdll loaded at the same address for all processes -- unreliable; 2) get dll base address from per-process dll list and parse ELF by hand -- too complicated (?); 3) pass relative offsets and add them later to the ntdll's base address -- unreliable a bit: ntdll may be replaced, although, it is unlikely; 4) extend the struct process (server/process.h) and the request init_process with pointers to required functions -- most reliable and simple but looks ugly. What do you think?

6 11

USB?
by Alex Zeiger 25 Aug '04

25 Aug '04

I'm interested in possibly working on USB support for Wine. I'm not particularly familiar with USB programming, but I'm fluent in C and C++. Where do I start?

6 7

Re: wave tests patch
by Francois Gouget 16 Aug '04

16 Aug '04

Robert Reif wrote: > Notify when position format not supported. > Test that position is 0 at start. Good patch. I was worried that tracing all waveGetPosition() failures would clober the output but after that's what one wants when tracing is enabled. Plus it uncovers interesting results: wave.c:584:found 1 WaveOut devices wave.c:472: 0: "SigmaTel Audio" (\\?\pci#ven_8086&dev_24c5&subsys_01641028&rev_01#3&61aaa01&0&fd#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wave) 5.10 (1:100): channels=65535 formats=bffff support=002c(WAVECAPS_VOLUME WAVECAPS_LRVOLUME WAVECAPS_SAMPLEACCURATE) wave.c:482:Playing a 5 seconds reference tone. wave.c:483:All subsequent tones should be identical to this one. wave.c:484:Listen for stutter, changes in pitch, volume, etc. wave.c:369:Playing 5 second 440Hz tone at 22050x 8x1 wave.c:268:TIME_MS not supported, returned TIME_SAMPLES wave.c:290:TIME_SMPTE not supported, returned TIME_SAMPLES wave.c:268:TIME_MS not supported, returned TIME_SAMPLES wave.c:290:TIME_SMPTE not supported, returned TIME_SAMPLES ... I get the same results on Windows 95, 98 and NT4. How is it that this works on your machine? Anyway, assuming that we need to round up I propose to modify the implementation as in the attached patch. The advantage is that it does not rely on ceil(). In fact it doesn't even use floating point arithmetic so we cannot get any rounding error. If this patch is ok by you, then I can apply it to all the drivers. I also noticed that we have similar code for the input devices. Does this one also round up? Or does it round down? (I could very well see MS make that one round down) -- Francois Gouget fgouget(a)codeweavers.com Index: dlls/winmm/wineoss/audio.c =================================================================== RCS file: /var/cvs/wine/dlls/winmm/wineoss/audio.c,v retrieving revision 1.135 diff -u -r1.135 audio.c --- dlls/winmm/wineoss/audio.c 19 Jul 2004 20:08:06 -0000 1.135 +++ dlls/winmm/wineoss/audio.c 20 Jul 2004 08:58:43 -0000 @@ -2077,7 +2077,6 @@ */ static DWORD wodGetPosition(WORD wDevID, LPMMTIME lpTime, DWORD uSize) { - double time; DWORD val; WINE_WAVEOUT* wwo; @@ -2116,15 +2115,21 @@ TRACE("TIME_SAMPLES=%lu\n", lpTime->u.sample); break; case TIME_SMPTE: - time = (double)val / (double)wwo->format.wf.nAvgBytesPerSec; - lpTime->u.smpte.hour = time / (60 * 60); - time -= lpTime->u.smpte.hour * (60 * 60); - lpTime->u.smpte.min = time / 60; - time -= lpTime->u.smpte.min * 60; - lpTime->u.smpte.sec = time; - time -= lpTime->u.smpte.sec; - lpTime->u.smpte.frame = round(time * 30); - lpTime->u.smpte.fps = 30; + val = val / (wwo->format.wBitsPerSample / 8) / wwo->format.wf.nChannels; + lpTime->u.smpte.sec = val / wwo->format.wf.nSamplesPerSec; + val -= lpTime->u.smpte.sec * wwo->format.wf.nSamplesPerSec; + lpTime->u.smpte.min = lpTime->u.smpte.sec / 60; + lpTime->u.smpte.sec -= 60 * lpTime->u.smpte.min; + lpTime->u.smpte.hour = lpTime->u.smpte.min / 60; + lpTime->u.smpte.min -= 60 * lpTime->u.smpte.hour; + lpTime->u.smpte.fps = 30; + lpTime->u.smpte.frame = val * lpTime->u.smpte.fps / wwo->format.wf.nSamplesPerSec; + val -= lpTime->u.smpte.frame * wwo->format.wf.nSamplesPerSec / lpTime->u.smpte.fps; + if (val != 0) + { + /* Round up */ + lpTime->u.smpte.frame++; + } TRACE("TIME_SMPTE=%02u:%02u:%02u:%02u\n", lpTime->u.smpte.hour, lpTime->u.smpte.min, lpTime->u.smpte.sec, lpTime->u.smpte.frame);

3 4

console message encoding
by Vitaly Lipatov 15 Aug '04

15 Aug '04

Is it known that console message printed to output in wine internal encoding (OEM?), not in locale encoding. Is it bug or just needed coding right behavior? For example, I have koi8-r as locale encoding, cp866 as OEM CP and cp1251 as ANSI CP. -- Lav Vitaly Lipatov Saint-Petersburg GNU! ALT Linux Team! LaTeX! LyX!

2 1

Debugger crash
by Mike Hearn 15 Aug '04

15 Aug '04

Hi, If I start a simple OLE hello world app (shouldn't really matter what app it is though) and run "b CoRegisterClassObject" winedbg crashes: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1075380896 (LWP 4932)] 0x408a2562 in symt_find_nearest (module=0x403e4248, addr=1081494000) at symbol.c:623 623 symt_get_info(&module->addr_sorttab[0]->symt, TI_GET_ADDRESS, &ref_addr); (gdb) bt #0 0x408a2562 in symt_find_nearest (module=0x403e4248, addr=1081494000) at symbol.c:623 #1 0x4089693b in elf_new_wine_thunks (module=0x403e4248, ht_symtab=0x4087dc70, num_areas=8, thunks=0x4087dc80) at elf_module.c:368 #2 0x40897071 in elf_load_debug_info (module=0x403e4248) at elf_module.c:598 #3 0x4089894d in module_get_debug (pcs=0x40330d80, module=0x403f44d0) at module.c:215 #4 0x408a2b3d in SymEnumSymbols (hProcess=0x30, BaseOfDll=0, Mask=0x4087de24 "*!CoRegisterClassObject", EnumSymbolsCallback=0x4076585c <sgv_cb>, UserContext=0x4087e164) at symbol.c:807 #5 0x40765cfc in symbol_get_lvalue (name=0x415b0038 "CoRegisterClassObject", lineno=-1, rtn=0x4087eb4c, bp_disp=1) at symbol.c:231 #6 0x4075a58a in break_add_break_from_id (name=0x415b0038 "CoRegisterClassObject", lineno=-1) at break.c:244 #7 0x4076b25f in yyparse () at ./dbg.y:216 #8 0x4076c98b in parser (filename=0x0) at ./dbg.y:562 #9 0x40769f73 in dbg_main_loop () at winedbg.c:991 #10 0x4076a2c1 in main (argc=2, argv=0xbffff608) at winedbg.c:1229 #11 0x407592f1 in __wine_exe_main () from /opt/wine/lib/wine/winedbg.exe.so #12 0x4049f953 in start_process (arg=0x0) at process.c:995 #13 0x400307a9 in wine_switch_to_stack () from /opt/wine/lib/libwine.so.1 (gdb) print module $1 = (struct module *) 0x403e4248 (gdb) print module->addr_sorttab[0] $2 = (struct symt_ht *) 0x0 Eric, any ideas? I don't understand what this code is doing. thanks -mike

2 1