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

Re: x11drv: proper visible region handling for cached dces
by Alexandre Julliard Aug. 11, 2005

Aug. 11, 2005

Frank Richter <frank.richter(a)gmail.com> writes: > Frank Richter <frank.richter(a)gmail.com> > Fix issue where it could happen that, when a cached dce was reused, the > visible region was not updated although the window region had changed > since the last dce use. Now, track is kept of window region changes and > the visible region for a cached dce is updated if the window region > changed in the mean time. You should use invalidate_dce() instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

WINEALSA: remove crackling in DirectSound/ALSA combination
by Alex Villacís Lasso Aug. 11, 2005

Aug. 11, 2005

For a long time, I have been annoyed by a faint crackling that can be heard on the sound output of any DirectSound program when full hardware acceleration is enabled on the ALSA driver. Even after a patch I sent earlier (which corrected a bigger artifact), this crackling remained. Last night, I finally set upon removing this crackling, based on a comment in IDsDriverBufferImpl_GetPosition() in dlls/winmm/winealsa/audio.c, line 3302: //* /*FIXME*/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. *// //* It will NOT return what why want anyway. *// hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm); I thought, maybe it is not returning the correct information for GetPosition, so that is why the crackling exists, since new samples are off-position from what they should be in order to guarantee a smooth sound. So I deduced, maybe the IDsDriverBufferImpl object can keep a simulation of a hardware pointer and use that instead of the (slightly incorrect) hardware pointer. My original intention was to remove entirely the need to reference _snd_pcm_mmap_hw_ptr(), since this is obviously an internal alsa-lib function and should not be used from inside the app (as the comment rightly indicates). However, I found out that the simulated hardware pointer tends to lag behind the real hardware pointer, and horrible mixups happen if the difference approaches or exceeds the length of the mmap buffer. So the simulated pointer is loosely kept close to the hardware pointer in the supplied patch. The good news: the patch sort of works (in my setup, at least, with Fedora Core 4). All the games I have (Japanese RPGs) now have smooth sound, unless the CPU load is too high. The bad news: the patch does nothing to make the dsound tests pass in Wine (but they were already failing before the patch :-) What I would like to know is the following: * Is there any ALSA user for which the DirectSound tests have *actually* passed? In full acceleration mode? * Can somebody check if the DirectSound tests actually pass in Windows? The test code seems very straightforward, but (in my setup at least) they trigger many more errors and FIXMEs than my RPGs, and that is even without taxing the CPU with graphics and bitmap manipulation, as the RPGs do. * Can somebody using the ALSA driver acknowledge whether they have the crackling problem too, and whether this patch actually solves it for them too? * Can somebody please test this patch (even if they don't have the crackling issue) and check whether any previously working game breaks because of it? Also, can some ALSA or DirectSound guru comment on the specifics of *why* the patch actually works? I am not entirely convinced that a mere loose updating of the simulated pointer from the hardware pointer is enough to have a smooth sound, but it works. I also don't understand how did the crackling appear in the first place, even though the direct hardware pointer was used. Any comments or reports are welcome (especially why the patch works). Alex Villacís Lasso Changelog: * Remove crackling in DirectSound/ALSA playback with full hardware acceleration

2 2

Delete Dll(Un)RegisterServer in d3dxof.dll?
by Francois Gouget Aug. 11, 2005

Aug. 11, 2005

Hi, I'm relaying a question from Vincent Béron: we both had a look at the winapi_check output and noticed that the comments of these functions claim they are exported but in fact they are not: they are not mentioned anywhere in the spec file. Now if I look at the APIs exported by d3dxof.dll on various versions of Windows I don't see these APIs either. However it's possible that they are only exported in recent versions of DirectX and I'm not sure the DirectX dlls I have are that recent. So I think the question boils down to this: should the Dll(Un)RegisterServer functions be removed or should they be exported? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

3 2

setup of the MinGW environment
by Saulius Krasuckas Aug. 11, 2005

Aug. 11, 2005

Sadly I miss miss one file from the site [1] and seems to be down. The file is called "mingw-binutils-2.15.94-8hl.i386.rpm". Any chances for the site to get up and running? [1] http://mirzam.it.vu.nl/mingw/

2 1

Awdbedit crashes, wine debugger fails to run aswell.
by Hans Kristian Rosbach Aug. 11, 2005

Aug. 11, 2005

Using wine compiled from CVS yesterday. Awdbedit is available here: http://awdbedit.sourceforge.net/ $ wine awdbedit.exe err:rebar:REBAR_AdjustBands Phase 1 failed, x=32760, maxx=632, start=0, end=0 err:rebar:REBAR_AdjustBands Phase 1 failed, x=32760, maxx=632, start=0, end=0 wine: Unhandled exception (thread 0009), starting debugger... Killed I let the debugger "run" for 5min before killing it, it never showed anything and neither did the awdbedit window update at all. -HK

1 0

co-author needed
by Brian Vincent Aug. 11, 2005

Aug. 11, 2005

It's been a while since I mentioned anything about the Wine book I'm working on. First, I've lost a co-author. Ira had been working on 5 chapters about Winelib. He actually had a lot written and re-written. However, he's backed out of it. So this is a plea for anyone interested in writing those chapters to contact me. I can fill you in on all the specifics. Even if you don't have a strong Winelib background, I think there's a great opportunity for someone interested in technical writing to put something together. Honestly, I haven't closely reviewed the few chapters that have been rewritten, but I think there's a lot of material to work from. (We're still working out the specifics of that.) The rest of the book is rolling along. I have seven chapters completed totaling over 200 pages. I think I have most of the hard stuff done and the two chapters left shouldn't be too difficult. Right now the review process has been held up by the Winelib sections. Ira's rewrite blew that schedule out of the water and we're seriously overdue on starting reviews. Right now my goal is to shoot for finishing those two chapters by mid September partly to coincide with a beta release of Wine. From there we're still at least 6 months from having a book on the shelves. The licensing on the book will remain OPL. At some point the text will be available to the Wine community. I think that happens about 90 days from the original publication date. I really don't want that to stop anyone from working on the Wine User Guide or Winelib User Guide. Both of those docs are horribly out of date and need some love. Ideally someone would have the User Guide in shape for a beta release. O'Reilly.. after not hearing anything from O'Reilly for a few months I got an email from them the other day. In the "Running Linux 5th ed." book coming out later this year I wrote a section on Wine. Previously they had about one paragraph. It's been expanded to about 8 pages including a section on CrossOver Office 5. Anyway, back to my original question, anyone wanna write a book? -Brian

1 0

IE6 installer claims unimplemented function in advpack.dll (IsNTAdmin)
by Hans Kristian Rosbach Aug. 10, 2005

Aug. 10, 2005

Wine CVS of about 1 hour old. ie6setup.exe from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=1e1550cb-5e5d-48f5… $ wine ie6setup.exe fixme:advapi:CheckTokenMembership ((nil) 0x6ed886d0 0x7fddfd9c) stub! fixme:advapi:DecryptFileA "C:\\install\\IXP000.TMP\\" 00000000 fixme:advpack:TranslateInfString ("C:\\install\\IXP000.TMP\\IESetup.inf" "Options.NTx86" "Options.NTx86" "InstallDir" 0x10253f8 260 0x7fdcf83c (nil)): stubfixme:advpack:NeedReboot (0x00000000): stub wine: Call from 0x1013ac7 to unimplemented function advpack.dll.IsNTAdmin, aborting wine: Unhandled exception (thread 000b), starting debugger... -HK

3 2

Re: LZDone is exported by kernel32
by Francois Gouget Aug. 10, 2005

Aug. 10, 2005

On Wed, 9 Aug 2005, Vincent Béron wrote: > Changelog: > LZDone is also exported by kernel32 now. Should the same treatment be applied to the other functions too? Examples: LZStart, LZInit, GetExpandedNameA, etc. It's strange that winapi_check does not complain about them. Does it really work to declare LZDone as exported by multiple dlls in a single comment? Should winapi_check scan the forwards and ask that we mention them all in the relevant dll documentation? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

3 2

Re: Try 3: Use /proc filesystem to create HKLM\HARDWARE\DEVICEMAP\Scsi entries
by Vitaliy Margolen Aug. 10, 2005

Aug. 10, 2005

Any reason this patch http://www.winehq.com/hypermail/wine-patches/2005/08/0087.html and this patch http://www.winehq.com/hypermail/wine-patches/2005/08/0088.html haven't been applied? Vitaliy Margolen Wednesday, August 3, 2005, 19:07:05, Vitaliy Margolen wrote: > Change few names. > This time use correct types with scanf. > Use /proc filesystem to create HKLM\HARDWARE\DEVICEMAP\Scsi entries. > Now it works for IDE and SCSI. Most of the /proc/scsi/scsi parsing is moved > from winaspi. > Vitaliy Margolen > changelog: > dlls/kernel/oldconfig.c > Use /proc filesystem to create HKLM\HARDWARE\DEVICEMAP\Scsi entries.

1 1

crosscompiler
by Dimitrije Jankovic Aug. 10, 2005

Aug. 10, 2005

Recently, a target option was added to winebuild, and winebuild code was changed to use this option instead of preprocessor defines. I was wondering if a similar option will be added to winegcc, based on which it would pass the corresponding option to winebuild. When using winegcc to crossbuild wine dlls between different platforms (for instance x86-linux and sparc-solaris) that have different endianess more problems arise, especially related to resources. The resource compiler has --endianess option that caould be used to crosscompile resources, but winebuild always reads resource files as if they were compiled natively, maining --endianess cannot be used to crossbuild. Correct me if I'm wrong. If I want to be able to crossbuild from x86-linux to sparc-solaris, I need to compile resources with big-endianess and have winebuild use the target option to recognize that resource file was compiled with big-endianess and read it as such, and not natively. This is not the case currently. Like I said, winebuild reads the res file using native byteorder and fails to check res header. Regards, Dimitrije

2 1