Re: Coaxing appdb maintainers into testing their apps with rc1?
Dan Kegel dank at kegel.com writes: It doesn't look like many people are paying attention to http://wiki.winehq.org/PlatinumRegressionHunt Think it would be useful to email all the app maintainers and ask them to pretty please test their apps with rc1? Alexander Nicolaysen Sørnes has kindly added support to the AppDB to email all the app maintainers. So let's decide what we want ask our maintainers. How about this: Subject: Wine needs you! Hello Application maintainers! If you weren't already aware, Wine is doing release candidates for the lead up to Wine 1.0 The current release candidate is wine-1.0rc2 We would like to make sure that as many programs as possible are tested with the latest version of Wine and we have selected you as an ideal candidate to test the applications you maintain. Please help us find regressions and embarrassing problems in rc2! We are also running a Platinum Regression Hunt and a Dogfood Challenge * http://wiki.winehq.org/PlatinumRegressionHunt * http://wiki.winehq.org/DogfoodChallenge According to http://wiki.winehq.org/WineReleasePlan, wine-1.0.0-rc3 will be due out Friday, May 30th, 2008 Best regards The Wine AppDB team
Re: Why I think it's worth fixing Valgrind warnings
Dan Kegel wrote: That said, it's important when fixing Valgrind errors to really understand the code you're changing, lest you paper over a bug with another bug, or make things worse. *cough* Debian and OpenSSL *cough* ;) On the other hand, you shouldn't have to be completely intimately familiar with it like the original author was. It's a real problem if our code can't be read by a reasonably skilled hacker and fixed properly when Valgrind starts spewing warnings. Thanks, Scott Ritchie
Re: advpack.c must be compiled with optimization?
Am Montag, den 26.05.2008, 22:16 -0700 schrieb Dan Kegel: Oddly, if I compile the wine tree without -O2, the following test fails: ../../../wine advpack_test.exe.so advpack.c advpack.c:441: Test failed: Expected C:\Program Files, got C:\ advpack.c:443: Test failed: Expected size 17, got 4 make: *** [advpack.ok] Error 2 Compiling advpack/advpack.c with at least -O makes the problem go away. Evil bug of using uninitialized stack space caused by not checking return values. It usually slips through, as the local variable was initialized in a previous run of get_dest_dir. Working patches are available and will be submitted in the next hour. Regards, Michael Karcher
Re: [ws2_32/tests] Fix crash on win98
On Wednesday 28 May 2008 10:08:49 Paul Vriens wrote: Hi, As pi_size was uninitialized the value turned out to be the cause of this crash. I don't know where that limit ( 2*sizeof(WSAPROTOCOL_INFOA) ) comes from but tests show it has to be less then that on win98. Whoops, thanks for the catch. I had that initialized to 0 at one point in my test program, but it seems like I dropped it while reworking the tests. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: wine video codec demo
On Tue, May 27, 2008 at 6:21 PM, Dan Kegel [EMAIL PROTECTED] wrote: I put together a little script demonstrating how to install and use various video codecs and use them in a test application (media player classic). To try it out, do wget http://kegel.com/wine/winetricks wget http://kegel.com/wine/codecdemo sh codecdemo I improved it a bit. 1) The demo now uses bash's select extension, so you have to run it with bash codecdemo. Now it's all menu-driven, so you can try whichever media sample you want, rather than trying them all in a row. 2) by default, it doesn't install any codecs at all, so you can see what the codecs Wine comes with can handle. The codec installers are in the menu at the top. 3) I added all the sample clips from http://www.jhepple.com/support/sample_movies1.htm Dirac / Schroedinger support is still next on the to-do list :-) - Dan
Re: wine site: Translate sendind_patches to Spanish in web.site.git
1. Please preface your patch with [website] so I can pick it out of the large amount of email in wine-patches. 2. The website does not support translations yet. I don't think it is much work to support it. Mainly the HTML class template() function needs to check the browser for the language, then change the template dir, if the template for the language is not found, then the EN version is loaded as a fallback. 3. Some parts, like the news and WWN are not in a system that can be easily translated. Not sure what to do about that. IOW, they are not using the html template() class, they are based on a hacky XML format. Ángel Guzmán Maeso wrote: My patch needs commit. Changelog: Add translation Spanish to sending_patches in Wine site http://www.winehq.org/pipermail/wine-patches/2008-May/055157.html http://www.apogeus.es
Re: 2k is the default version?
On Tue, May 27, 2008 at 5:33 PM, John Klehm [EMAIL PROTECTED] wrote: Hrmm so off by 1 error in your winecfg dropdown box then? Maybe check the actual registry file? grep -C6 \[SoftwareMicrosoftWindows NTCurrentVersion] .wine/system.reg Good luck, John Registry shows the correct entry. Interesting finding: [EMAIL PROTECTED]:~$ rm -rf .wine [EMAIL PROTECTED]:~$ winecfg # shows 2k wine: created the configuration directory '/home/austin/.wine' [EMAIL PROTECTED]:~$ rm -rf .wine [EMAIL PROTECTED]:~$ wineboot wine: configuration in '/home/austin/.wine' has been updated. [EMAIL PROTECTED]:~$ winecfg # shows XP I'm only seeing this in my feisty VM. My feisty p3 server is fine...
Re: 2k is the default version?
Hello Austin, 2008/5/28 Austin English [EMAIL PROTECTED]: On Tue, May 27, 2008 at 5:33 PM, John Klehm [EMAIL PROTECTED] wrote: Hrmm so off by 1 error in your winecfg dropdown box then? Maybe check the actual registry file? grep -C6 \[SoftwareMicrosoftWindows NTCurrentVersion] .wine/system.reg Good luck, John Registry shows the correct entry. Interesting finding: [EMAIL PROTECTED]:~$ rm -rf .wine [EMAIL PROTECTED]:~$ winecfg # shows 2k wine: created the configuration directory '/home/austin/.wine' [EMAIL PROTECTED]:~$ rm -rf .wine [EMAIL PROTECTED]:~$ wineboot wine: configuration in '/home/austin/.wine' has been updated. [EMAIL PROTECTED]:~$ winecfg # shows XP Maybe you installed an old distributors version of wine? Cheers, Maarten
Re: 2k is the default version?
On Wed, May 28, 2008 at 3:01 PM, Maarten Lankhorst [EMAIL PROTECTED] wrote: Maybe you installed an old distributors version of wine? I used to install the budgetdedicated deb each week, and run git from ~/wine-git, but I stopped that a couple months ago. I've been doing a sudo make install...I'll try to fiddle with my system more and see what the problem is, since it's apparently either a misconfiguration on my part, or a strange problem associated with the VM. -Austin
uninformed musings on ddraw + bugs 2082 and 1347 + dib engine
I apologize if what I'm about to say is wrong and useless. I feel the need to say it just in case it is not as wrong and useless as I fear. Background: We have two very difficult (possibly unfixable) ddraw bugs: http://bugs.winehq.org/show_bug.cgi?id=2082 - DirectDraw games only showing black screen http://bugs.winehq.org/show_bug.cgi?id=1347 - Screen is wiped/blanked on usage of DirectDraw Both of these bugs are the result of the fact that Windows (probably even Windows Vista when Aero is disabled, which I believe happens temporarily when an exclusive move ddraw app is active) ddraw can give apps direct access to the screen and X cannot. Instead of drawing to the screen, Wine draws to the application's window, which it determines based on an argument the application passed to SetCooperativeLevel. In the case of 2082, this window is obscured and no drawing happens even though it would on windows. There is a hack for ddraw that uses hwnd 0 instead (so drawing operations do go to the screen), but it can also break things in situations where an application uses both ddraw and gdi. 1347 is the result of non-fullscreen applications passing hwnd 0 to SetCooperativeLevel and (so I'm told) going through this series of steps: 1. Lock the primary surface, thus mapping the image on the screen to memory. 2. Write to your window. 3. Unlock the primary surface. On Windows, as long as Aero isn't running, this works out fine. But on Wine, mapping the image on the screen to memory is impossible. Instead, Wine simply gives the app an empty buffer, which the app writes to (but only its own window). It is impossible to determine afterwards which parts of the that buffer were written. When the primary surface is unlocked, Wine draws the image in the buffer to the application's SCL window, which is often (but not always) what the application happened to be drawing. Stefan mentions the idea of grabbing a screenshot when the surface is locked and writing it back when the surface is unlocked (which he says in one case would cause framerate to drop to less than 1 fps, which I believe). He thinks 1347 is unfixable. I think that if so, 2082 is also unfixable because even in fullscreen mode we can have problems caused by interactions with ddraw and gdi (using hwnd 0 is not always the right thing even for a fullscreen app). Now, here's where we get to the crazy uninformed ideas: What if, instead of picking one hwnd to draw to, ddraw drew to every window owned by an application? I'm making some assumptions here: it has to be possible to find the space occupied by every window owned by an application and draw to it at a reasonable speed. I'm also assuming that no app we want to support will want to draw to windows owned by other programs, especially X programs, even though there's nothing in ddraw that would prevent it. Well, we'd still theoretically have some problems. What if a program locked/unlocked the primary surface multiple times, once for each of various widgets that it wants to draw? The widgets would flicker. And what if a program has its own window that it wants to draw to with gdi? Its gdi parts would be painted black. Alright then, what if we had a single clientside buffer per app, the size and depth (as far as the app is concerned) of the screen, that was not synced with the actual contents of the screen but was preserved between locks/unlocks? Any operation in ddraw or gdi that resulted in a draw to the screen would have to first go through this buffer. The lock/unlock sequence would overdraw all the application's windows with the last thing the application drew there. Ignoring opengl (opengl and ddraw working simultaneously in one process should be extremely rare; maybe some swing apps do it), that should work pretty much perfectly. Sadly I can't even pretend to know enough to say how this affects opengl. It would require clientside buffers, and it would probably be difficult for current gdi to support. It seems like the sort of thing that would be more reasonable if we had a dib engine. (!) Also, giving every process a clientside buffer the size of the screen would be wasteful of memory (and optimizing for a rare case; most programs won't even have a primary surface, let along be locking/unlocking it). It may be more reasonable to have one per visible window or even one per X window, which would be manipulated as needed for lock/unlock (not sure about the X window thing because they'd have to be shared between processes.. but perhaps we need that capability anyway? it would also effectively mean we CAN give apps direct access to the screen for virtual desktops and CAN allow ddraw drawing to other Wine processes' windows). -- Vincent Povirk
Re: uninformed musings on ddraw + bugs 2082 and 1347 + dib engine
There are a few more things to keep in mind: - The DIB engine would not be used to draw to windows or the NULL hwnd. It will be used to draw to device independent bitmaps only. - Some applications may *want* to draw to the screen outside their window. I think the dxdiag.exe app does so. - Some apps may use ddraw without a window at all Can you confirm that the apps that show the black screen problem are broken in vista with aero on? This would be a strong indicator that the apps are doing something wrong(Keep in mind that QuickTime changes its behavior with winver=vista). All in all I think this is a hack that's not going to work well, although I did not think about it in detail yet. First of all, I think we need to do a bit more testing. E.g. test what happens if the app is in fullscreen-exclusive mode and tries to open a regular GDI window. Is it visible? There's also a dx7 sdk sample which illustrates how a GDI window with ddraw works. It works on wine, but I never looked into it in detail.
