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

CD-ROM ioctl support on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com June 6, 2011

June 6, 2011

Hi, what's the state of CD-ROM support on the Mac? ntdll/cdrom.c contains quite a few #ifdef apple. I'm asking because the mcicda currently uses these ioctl: 1. READ_RAW 2. READ_TOC 3. READ_Q -> POSITION MCICDA could be changed to avoid the third one entirely -- when using the dsound output. Would that be enough to use mcicda on MacOS to play music? Thanks for your help, Jörg Höhle

2 3

Two enhancement requests for winetricks
by Dan Kegel Feb. 21, 2011

Feb. 21, 2011

OK, filed http://code.google.com/p/winezeug/issues/detail?id=127 "want uninstall" and http://code.google.com/p/winezeug/issues/detail?id=128 "want status" - Dan

6 11

USB Device Support
by James Mckenzie Feb. 18, 2011

Feb. 18, 2011

Alexander: Before I go off and try to update your USB device support for the latest Wine release, are you continuing to maintain this code current to the Wine Development and Wine Stable trunks? Also, the USB Device Support in Wine Wiki page needs an update. The code at snicky.com is no longer available. Thank you for your efforts to support USB devices in Wine. James McKenzie

6 5

re: Wine FAQ edits
by Dan Kegel Feb. 6, 2011

Feb. 6, 2011

Hi Albert, http://wiki.winehq.org/FAQ?action=diff&rev2=384&rev1=383 looks like it was a pretty big edit. Try smaller ones, and try to do just one kind of change per edit.

7 20

RFC: Adding Mac support to secur32/schannel.c
by Ken Thomases Feb. 3, 2011

Feb. 3, 2011

Hi, I'm planning to add an alternative implementation of schannel (SSL/TLS) support for the Mac. The current implementation is based on GnuTLS. That library is not typically found on Mac OS X. Although packagers can build it and ship it and its dependencies with Wine for Mac OS X, I think it's better (especially for security-related functionality) to use the system-provided library. I'm attaching a patch. It is _not_ intended as a proposed commit. It's just a proof-of-concept that shows the direction that I'm going. I plan to introduce a new internal interface (the schan_imp_* stuff in my patch) and incrementally refactor the code to hide uses of GnuTLS behind that interface. Then, I'm thinking of breaking the GnuTLS implementation out into a separate module, schannel_gnutls.c. Then, I'd add a second implementation module, schannel_mac.c, based on the Mac Secure Transport API (as shown in the patch). Each of the two modules would be made "empty" by preprocessor conditionals, as appropriate. I'd appreciate a review of this general plan. Thanks, Ken

8 18

Re: wined3d: Update clip planes when switching to/from offscreen rendering.
by Stefan Dösinger Feb. 2, 2011

Feb. 2, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.01.2011 um 15:13 schrieb Matteo Bruni: > It should fix http://bugs.winehq.org/show_bug.cgi?id=25877 > <0001-wined3d-Update-clip-planes-when-switching-to-from-offs.txt> If we change the shader code to write gl_ClipVertex and result.clip before applying the y inversion then we should be able to avoid this. That should also make it more compatible to fixed function vertex processing - here the clipping is performed before the projection matrix is applied. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJNRssNAAoJEN0/YqbEcdMwZv8P+wbbhcamRsg42fMzJ02jKLcT s4p19OqKPZEdVvzsfQCe4e7KGgGdZUefMWsY2ib9AK21cQXB3R9fnyl5TMDcuxuh EojJvAQCVd/hgnz7tserUJT6rS/W08BPsdHM4dgxdnhRTzi2FAc7l3NgFOONJXpG i8HfcmD2AgaGOam6Wriv3SD8fM0zrfmpZdJDH1moCefqptEEWD9adwWRSMhaMvTl rlj1gDR9cRC9fsxur2U1f5NuXN0AY+a+5VPQHElZV2bP9ulheoa9nYuXU+8F7OhK RyIJ2DO4vpaLpEbXW/amtUWnlBSk0n7k3F9w/fcthOmUvlPHOBY7i2Ukf4j84vQD AhpN7Yf4cFZaSV8q/gww+U9H1udelidiTEL05OKQJUohnM1F9/cRnXbXmmA5Nuia rQlcCnm12cw1ClykdrY7B/hDCqGOPnnmPp580kW1LlEtidYyGbG35seyHxNqcNcQ RWlvVsGwvlzgex7qWf9hT34KOcUzMKZdlehfvtQn0Fjrcf+/3s5EvrtG4Mw6qHNh aBFNaeB8LkV36hu71r/1yxsqHO+taYt1/Ho8poANYbOplV9FCpd0nXeK8n7rqCPx L5TVgSJVd4n354FlguuIUAiFlXxcxFN2CJlN2Hd4dwhZZhGBh+4LH+XhjUtzX4ge 15usBq4VUhhssvv6dVys =urcm -----END PGP SIGNATURE-----

3 5

Wine FAQ edits
by Albert Lee Feb. 2, 2011

Feb. 2, 2011

Hi Vitaliy, I notice you have reverted my edits to the FAQ on the wiki ( http://wiki.winehq.org/FAQ?action=info ). As I was trying to clarify the shell metacharacter information and operating system/platform support, and add new file association instructions, I would like to know why this happened and what changes should be done. -Albert

2 3

Re: user32: Test for behavior of WM_SETTEXT handler regarding WM_CTLCOLOR*
by Marvin Jan. 31, 2011

Jan. 31, 2011

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=8777 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout

1 0

Wine Gecko 1.2.0 beta1
by Jacek Caban Jan. 31, 2011

Jan. 31, 2011

Hi all, We're nearing the time for the next Gecko update. Beta builds are done and available on Sourceforge [1]. To use them, you need to download the .cab file, put it as you usually do into the right directory (most likely wine_gecko-1.2.0-beta1-x86.cab, see [2] for details) and apply the attached patch to recent Wine git version. The plan for release is other than we usually did and we have still some work to do. I hope to do the release short after Firefox 4 release, which is scheduled for the end of February. Firefox is nearing final beta and we will branch together with RC branch for Firefox 4. This should give us more stability in the code base than we usually had. We've never succeeded in avoiding regressions with the new Gecko releases and I hope to improve this situation. This early beta build is one part of the plan. It would be great if you could use it for some time or try some apps with it. I'm most interested in reports about regression, but also general stability and improvements. * Changes - We use Firefox 4 beta11pre codebase - Some regression caused by integration with new parser are fixed (affected among others CS4 installer, STO, EQ2) - IO fixes for custom protocol handlers, mostly affecting .chm files and Outlook If you hit a blank-page bug, some page elements don't work or just a crash, there is a big chance that this build will fix it. Of course it's always nice to test everything regardless if it's currently working or not. * TODO - win64 fix It currently crashes, that's a regression. I've decided to do the beta release anyways, but it's an obvious blocker for further releases. I've put win64 builds on Sourceforge in case anyone is interested in looking at them, but the problem seems to be in the build, not in Wine. - MSI packages This beta still uses .cab files done on Windows. We're planning to do some work on it with Hans and Alexandre so that the final release will use MSI files. - dbghelp fixes winedbg has problems with debug info from Gecko debug build, making debugging possibilities quite limited and backtraces lacking most of the calls. This is not related to Gecko release itself, but still it would be great to have it fixed. - Getting rid of ugly hacks that Firefox uses Esp. API hooks. I don't think it's acceptable for us. - Tests and fixes The more tests, the better. I really hope to get community help here. * For packagers If you're considering building the next Gecko release yourself, it's probably a good idea to try the compilation now. It requires very recent mingw-w64, so a package update (or creating a new package if it's not yet available for the distro) will most likely be needed. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.2.0-beta1/ [2] http://wiki.winehq.org/Gecko

2 2

RE: Correction to crash inside RtlCaptureStackBackTrace() + test case
by Janne Hakonen Jan. 31, 2011

Jan. 31, 2011

Hi Alexandre Julliard, I see you had another idea of how to correct the RtlCaptureStackBackTrace() function. I tested your implementation with Anarchy Online's item store (ingame web browser based on Awesomium) and with AwesomiumGL (sample app from Awesomium's SDK). With AwesomiumGL I did, after a while (scrolling in an image heavy site), got it to crash: wine: Unhandled page fault on read access to 0xfffffffc at address 0x7bc7586b (thread 002e) To file dlls/ntdll/signal_i386.c, line 2438: frame = (ULONG *)*frame; (inside the skipping loop). And, so, if 'frame' is 0xfffffffc, then the added check, unfortunately, will not cut it. With Anarchy Online, I browsed quite a lot within the item store, changing pages, and finally just left the window open for ~20 minutes. No crash so far, so the correction might have worked for the game or then I just didn't wait long enough ;) Should I still add the try-except blocks to RtlCaptureStackBackTrace() and tests for 0xfffffffc value also? Please advice. Best Regards, Janne

2 1