December 2005 - Wine-Devel - list.winehq.org

Re: CVSROOT/. loginfo

by Detlef Riekenberg

Am Samstag, den 03.12.2005, 13:43 +0100 schrieb Martin Fuchs: > What about all three informations: > a.) author > b.) affected directory, like "[dlls/ole32]" > c.) beginning of the changelog IMHO, best of all is starting with the affected directory and use the subject for c. Benefit: Simple sort "by Subject" and the changes for a specific dll/program are all together, no matter, who created the Patch. > An example would be: > "Michael Jung: [dlls/shell32] Implemented scrolling during drag&drop > for the shellview class" "dlls/shell32 [Michael Jung] Implemented scrolling during drag&drop for the shellview class" > Another idea would be to replace b.) and c.) by the original patch mail subject. > This typically already contains the affected code section, for example > "WINED3D: Return the correct parent in IWineD3DPixelShaderImpl_GetParent". ---- So, if the part before the colon has no space, try it as a path when not found, try to prefix with "dll/" or "programs/" When the part is valid, use it as the start of the commit-Subject. When the part is invalid, use the Path of the First affected File as the start of the commit-Subject. ---- Your Example: "WINED3D [Creator] Return the correct parent in IWineD3DPixelShaderImpl_GetParent" -- By By ... ... Detlef

Dec. 3, 2005

Re: Why Steam fails [VirtualAlloc]

by Ivan Gyurdiev

> I tries that with the exact same results... > Attempted mmap_anon of size 200MB...fails...Steam fails, with ENOMEM. > Here's the exact mmap call... it's the only one that fails, and it's the largest without MAP_NORESERVE. mmap2(NULL, 209780736, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) Running the same call from a test program suceeds - I can mmap() things that are an order of magnitude larger without problems (as a regular user).

Dec. 3, 2005

Re: msvcrt incompatibility in Origin 6.0 when saving documents

by Olaf Leidinger

Hello again! Sorry for not sending an answer but there where some exercises waiting for me ;-( Origin doesn't work with CrossOver 5 on my machine, so the problem isn't solved for me. Still using the native dll saving works fine. And here is the next part of my investigation: Now the _cipow function call again with the patch: native: 0009:call msvcrt._cipow() ret=7f82aaf9 0009:ret msvcrt._cipow() retval=40f00020 ret=7f82aaf9 0009:call msvcrt._ftol() ret=7f82a67a 0009:ret msvcrt._ftol() retval=00000001 ret=7f82a67a builtin: 0009:call msvcrt._cipow() ret=7f82aaf9 trace:msvcrt:_cipow x 10.000000 y 5.000000 trace:msvcrt:_cipow z 100000.000000 0009:ret msvcrt._cipow() retval=00000001 ret=7f82aaf9 0009:call ntdll._ftol() ret=7f82a67a 0009:ret ntdll._ftol() retval=0000000000000001 ret=7f82a67a I also found a different behaviour of the putc function. In most cases the putc's look like this one: native: 0009:call msvcrt.putc(00000000,78037ca8) ret=7f822012 0009:call ntdll.rtlentercriticalsection(7d937a18) ret=78001075 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=78001075 0009:call ntdll.rtlleavecriticalsection(7d937a18) ret=780012b1 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=780012b1 0009:ret msvcrt.putc() retval=00000000 ret=7f822012 builtin: 0009:call msvcrt.putc(00000000,7d724018) ret=7f822012 0009:ret msvcrt.putc() retval=00000000 ret=7f822012 But sometimes the builtin one does a writefile: native: 0009:call msvcrt.putc(0000000a,78037ca8) ret=7f82b869 0009:call ntdll.rtlentercriticalsection(7d937a18) ret=78001075 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=78001075 0009:call ntdll.rtlleavecriticalsection(7d937a18) ret=780012b1 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=780012b1 0009:ret msvcrt.putc() retval=0000000a ret=7f82b869 0009:call ok60.?onbeforeprojectsave(a)cokaccess@@uaehg(a)z(<unknown, check return>) ret=7f7f35f2 builtin: 0009:call msvcrt.putc(0000000a,7d724018) ret=7f82b869 0009:call kernel32.writefile(00000018,7fe636f0,0000000e,7fadeec0,00000000) ret=7e876a07 0009:call ntdll.ntwritefile(00000018,00000000,00000000,00000000,7fadedc8,7fe636f0,0000000e,00000000,00000000) ret=7fcc4389 0009:ret ntdll.ntwritefile() retval=00000000 ret=7fcc4389 0009:ret kernel32.writefile() retval=00000001 ret=7e876a07 0009:ret msvcrt.putc() retval=0000000a ret=7f82b869 0009:call ok60.?onbeforeprojectsave(a)cokaccess@@uaehg(a)z(<unknown, check return>) ret=7f7f35f2 The ftell-function also calls rtlentercriticalsection: native: 0009:call msvcrt.ftell(78037ca8) ret=7f81f030 0009:call ntdll.rtlentercriticalsection(7d937a18) ret=78001075 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=78001075 0009:call ntdll.rtlentercriticalsection(7d920188) ret=780124b6 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=780124b6 0009:call kernel32.setfilepointer(00000018,00000000,00000000,00000001) ret=78012115 0009:call ntdll.wine_server_handle_to_fd(00000018,00000000,7fadee1c,00000000) ret=7fcc36f1 builtin: 0009:call msvcrt.ftell(7d724018) ret=7f81f030 trace:msvcrt:_lseeki64 :fd (3) handle (0x18) trace:msvcrt:_lseeki64 :fd (3) to 300000018 pos seek_cur 0009:call kernel32.setfilepointerex(00000018,00000000,00000000,7fadee80,00000001) ret=7e8766dc 0009:call ntdll.wine_server_handle_to_fd(00000018,00000000,7fadeda4,00000000) ret=7fcc36f1 Then there is a bit stange part. It happens during a lot of putc calls... native: (line 32599) 0009:call msvcrt.putc(00000000,78037ca8) ret=7f822012 0009:call ntdll.rtlentercriticalsection(7d937a18) ret=78001075 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=78001075 0009:call ntdll.rtlleavecriticalsection(7d937a18) ret=780012b1 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=780012b1 0009:ret msvcrt.putc() retval=00000000 ret=7f822012 0009:call msvcrt.putc(fffffffb0009:call ntdll.rtlentercriticalsection(7e699888) ret=7e6553d2 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=7e6553d2 0009:call ntdll.rtlleavecriticalsection(7e699888) ret=7e655412 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=7e655412 ,78037ca8) ret=7f822012 0009:call ntdll.rtlentercriticalsection(7d937a18) ret=78001075 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=78001075 0009:call ntdll.rtlleavecriticalsection(7d937a18) ret=780012b1 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=780012b1 0009:ret msvcrt.putc() retval=000000fb ret=7f822012 0009:call msvcrt.putc(ffffffff0009:call ntdll.rtlentercriticalsection(7e699888) ret=7e6553d2 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=7e6553d2 0009:call ntdll.rtlleavecriticalsection(7e699888) ret=7e655412 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=7e655412 ,78037ca8) ret=7f822012 0009:call ntdll.rtlentercriticalsection(7d937a18) ret=78001075 0009:ret ntdll.rtlentercriticalsection() retval=00000000 ret=78001075 0009:call ntdll.rtlleavecriticalsection(7d937a18) ret=780012b1 0009:ret ntdll.rtlleavecriticalsection() retval=00000000 ret=780012b1 0009:ret msvcrt.putc() retval=000000ff ret=7f822012 0009:call msvcrt.putc(00000019,78037ca8) ret=7f822012 ... builtin: (line 32376) 0009:call msvcrt.putc(00000000,7d724018) ret=7f822012 0009:ret msvcrt.putc() retval=00000000 ret=7f822012 0009:call msvcrt.putc(fffffffb,7d724018) ret=7f822012 0009:ret msvcrt.putc() retval=fffffffb ret=7f822012 0009:call msvcrt.putc(ffffffff,7d724018) ret=7f822012 0009:ret msvcrt.putc() retval=ffffffff ret=7f822012 I also get the three putc's of the builtin version but after that there are about 7000 lines of putc-calls like above and NO MORE putc calls at all in the builtin version. Also the output of the native debug output is a bit "diverted" (two calls in one line!). Till the lines above I can't see any differences (except the ones I already reported). Might the missing RtlEnterCriticalSection calls lead to a problem? Isn't the wine msvcrt thread-safe? If anyone is interested in the logs, I've put them onto my webspace : http://gordon.cip.physik.uni-saarland.de/~oleid/origin6_builtin.log.bz2 http://gordon.cip.physik.uni-saarland.de/~oleid/origin6_native.log.bz2 Thanks a lot! Ciao, Olaf Leidinger

Dec. 3, 2005

Re: Why Steam fails

by Ivan Gyurdiev

Stefan Dösinger wrote: > Hello, > >> It doesn't seem to check the retval of the first alloc, which fails >> about half of the time in >> wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, >> Steam proceeds to run. >> If it fails, Steam dies with the message above. >> > I just started Steam 5 times without a single failure. I can't reproduce the > problem. > I think I'm the only one with that problem... and I can't figure out what's wrong :( >> Isn't this supposed to be a Virtual allocation...Why does it work one >> time, and not the other... >> The manpage for mmap() says ENOMEM can occur if the process exceeds its >> allowed number of mappings. >> Is this relevant? >> > Maybe you should check your /etc/limits file. Your distro might have limited > the amount of memory a user may allocate. > The limits are the default ones - all lines in that file are commented out. > If you don't mind security risks, you could try to run Steam as root, and see > if the problem continues. But back up your MBR first ; > I tries that with the exact same results... Attempted mmap_anon of size 200MB...fails...Steam fails, with ENOMEM.

Dec. 3, 2005

wine alsa impelmentation

by Tomas Carnecky

I have a Envy24PT sound chip, without hardware mixing, so I had to setup dmix (in ~/.asoundrc). That works fine when I try to play two sound files with any combination of mplayer, alsaplayer and mpg123). But when I start any of those a then wine, I get this: ALSA lib pcm_dmix.c:788:(snd_pcm_dmix_open) unable to create IPC shm instance and I get no sound. If I start wine first and then mplayer I get this: pcm_params.c:187: snd_pcm_hw_param_get_min: Assertion `!snd_interval_empty(i)' failed. In which way does the wine alsa implementation differ from the one of mplayer, alsaplayer or mpg123? Or what could cause this problem.. Also I get lots of fixme:dsound:DSOUND_MixOne problem with underrun detection (mixlen=16384 < primary_done=21168) err:dsound:DSOUND_MixOne underrun on sound buffer 0x55952bf8 err:wave:wodPlayer_ProcessMessages pcm_pause failed: Input/output error and rarely fixme:wave:ALSA_AddRingMessage two fast messages in the queue!!!! toget = 11(WINE_WM_RESTARTING), tosave=12(UNKNOWN(0x00000000)) messages. How can I improve my sound quality? My asoundrc is in the attachment. thanks tom pcm.!dmix { type dmix ipc_key 5678293 slave { pcm "hw:0,0" period_size 1024 buffer_size 16384 format S32_LE } } pcm.!dsnoop { type dsnoop ipc_key 5778293 slave { pcm "hw:0,0" format S32_LE } } pcm.duplex { type asym playback.pcm "dmix" capture.pcm "dsnoop" } pcm.!default { type plug slave.pcm "duplex" } pcm.default { type plug slave.pcm "duplex" } pcm.!dsp { type plug slave.pcm "duplex" } ctl.!mixer { type hw card 0 }

Dec. 3, 2005

Re: advpack: Handle dwFlags for DelNode with tests

by James Hawkins

On 12/1/05, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > I changed the invalid CharPrev != "\\" comparison to string[len] != '\\'. > > Changelog > * Use DelNode itself for the directory recursion. > * Handle the dwFlags parameter. > * Factor out file creation and deletion. > * Add test cases for DelNode and make them pass. > Anything wrong with this? -- James Hawkins

Dec. 3, 2005

Re: [MSI] DllCanUnloadNow

by James Hawkins

On 12/3/05, Christian Gmeiner <christian.gmeiner(a)students.fh-vorarlberg.ac.at> wrote: > It also fixes some spacing stuff. Whitespace changes need to go in a separate patch, if at all. -- James Hawkins

Dec. 3, 2005

Re: trouble with uxtheme dll

by Marcus Meissner

On Sat, Dec 03, 2005 at 06:16:48PM +0100, Stefan Leichter wrote: > Hi, > > i am a little confuse about the uxtheme dll. I have a program that raises an > execption after each call (not the return!) to the ordinal 1 of the dll. The > strange thing is the relay log shows up to eight arguments for the function > call, but according to the spec file of the uxtheme dll the function does not > have any argument. Also the implemantation is only a stub which should not > crash. > > Here an example for the call: > > 000b:Call uxtheme.1(00000090,42865450,0001aa9b,406acef4,00000000) ret=41ebcca5 > trace:seh:__regs_RtlRaiseException code=c0000005 flags=0 addr=(nil) > > Does anyone have a wild guess what happend here? Its actually calling number 2 from the .spec file perhaps, OpenThemeFile. And the :seh: might be from the relay string printing code? I don't know. Ciao, Marcus

Dec. 3, 2005

trouble with uxtheme dll

by Stefan Leichter

Hi, i am a little confuse about the uxtheme dll. I have a program that raises an execption after each call (not the return!) to the ordinal 1 of the dll. The strange thing is the relay log shows up to eight arguments for the function call, but according to the spec file of the uxtheme dll the function does not have any argument. Also the implemantation is only a stub which should not crash. Here an example for the call: 000b:Call uxtheme.1(00000090,42865450,0001aa9b,406acef4,00000000) ret=41ebcca5 trace:seh:__regs_RtlRaiseException code=c0000005 flags=0 addr=(nil) Does anyone have a wild guess what happend here? Bye Stefan

Dec. 3, 2005

Re: Why Steam fails

by Stefan Dösinger

Hello, > It doesn't seem to check the retval of the first alloc, which fails > about half of the time in > wine_anon_mmap (mmap() call) with ENOMEM. If the allocation succeeds, > Steam proceeds to run. > If it fails, Steam dies with the message above. I just started Steam 5 times without a single failure. I can't reproduce the problem. > This is a machine with 1G memory. How much memory does one need to run > Steam? I have 512 MB, but I think 128 should be enought for Steam alone. > Isn't this supposed to be a Virtual allocation...Why does it work one > time, and not the other... > The manpage for mmap() says ENOMEM can occur if the process exceeds its > allowed number of mappings. > Is this relevant? Maybe you should check your /etc/limits file. Your distro might have limited the amount of memory a user may allocate. If you don't mind security risks, you could try to run Steam as root, and see if the problem continues. But back up your MBR first ;) Stefan

Dec. 3, 2005