September 2010 - Wine-devel

USB Device Support
by James Mckenzie 18 Feb '11

18 Feb '11

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: Improve handling of invalid input in dlls/comctl32/datetime.c
by Nikolay Sivov 19 Jan '11

19 Jan '11

On 12/25/2009 14:18, Gerald Pfeifer wrote: > Otherwise max_count will be undefined in the following loop may do > interesting things it seems. (Does Coverity diagnose similar items?) > > Gerald > > ChangeLog: > Improve handling of invalid input in DATETIME_ReturnFieldWidth. > > diff --git a/dlls/comctl32/datetime.c b/dlls/comctl32/datetime.c > index c240d4f..08c7082 100644 > --- a/dlls/comctl32/datetime.c > +++ b/dlls/comctl32/datetime.c > @@ -38,6 +38,7 @@ > * -- FORMATCALLBACK > */ > > +#include<assert.h> > #include<math.h> > #include<string.h> > #include<stdarg.h> > @@ -619,6 +620,9 @@ DATETIME_ReturnFieldWidth (const DATETIME_INFO *infoPtr, HDC hdc, int count, SHO > lctype = LOCALE_SMONTHNAME1; > max_count = 12; > break; > + default: > + assert(0); > + max_count=0; > } > > cx = 0; > Hi, Gerald. This can't even happen. spec if filtered later with: --- case THREECHARMONTH: case FULLMONTH: case THREECHARDAY: case FULLDAY: --- So no default case here.

3 6

Re: ws2_32: Add default case for family in debugstr_wsaioctl.
by Juan Lang 08 Jan '11

08 Jan '11

Hi Gerald, > This mimicks what we already do a few lines above for buf_type. It's also unneeded: switch(ioctl & 0x18000000) There are only 4 possible combinations of ioctl & 0x18000000. Three are covered in this switch statement, and the fourth is eliminated due to the outer switch statement. You'd be adding dead code. --Juan

2 1

Re: Wine: Use GCC's -Wlogical-op if supported.
by Alexandre Julliard 11 Dec '10

11 Dec '10

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > In the past this has found a dozen or two real issues and lead to some > simplifications. Now the tree is clean in that regard, so we can make > this a default. I still see a ton of warnings here (gcc 4.4.5), mostly because of the glibc string macros. -- Alexandre Julliard julliard(a)winehq.org

2 3

Wine runs IE7!
by Hans Leidekker 26 Nov '10

26 Nov '10

Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet that I had to implement, stub and override my way past before it would render a page, but finally, here's the obligatory screenshot. -Hans

3 2

current state of full screen on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com 20 Oct '10

20 Oct '10

Hi, I'd like to know whether a MacOSX user can expect full screen modes to work, as I've heard only rumors and too little facts. My experience is this: + winecfg's window opens fine even with desktop set uo full screen, no window. E.g. as in the initial setting after rm -rf ~/.wine; wine winecfg. + Likewise, other programs opening windows work fine (regedit, notepad etc.). - Programs that offer a "select screen resolution" requester present a list whose largest vertical/Y resolution is 22 pixel less than what the monitor offers. I believe OSX reserves some place for its menu bar. Lower resolution entries, e.g. 1024x768 and 800x600, are listed normally. They work in desktop window mode. - Programs that want to make use of full screen fail or hang somehow. The issue may be two-fold: a) full screen does not work at all, or b) switching to full screen resolutions less than my LCD's native resolution does not work, and applications do not cope with that. E.g. many want to display a low-resolution intro video. - Approx. two monthes ago, a hybrid desktop mode was implemented in Wine: eliminate the desktop window when it matches the full screen size; recreate it when switching back to lower resolutions. I've not observed that effect either, but the idea is brilliant. I've heard that OSX would not switch to lower resolutions like Linux machines do with e.g. xrandr -s 1 or -s 2 etc. My LCD monitor can stretch low resolution VGA signals, e.g. when plugged to a Linux netbook. However the "early 2009" nVidia Macs do not produce analog video signals anymore, and I'm using the DVI-D output. What's the current state of Wine (and Darwine) w.r.t. full screen mode? Is it just my digital DVI + LCD setting or is there an issue with Wine? I've built Wine-1.1.24 with OSX 10.5.7 and XQuartz 2.3.3.2. Thank you, Jörg Höhle.

3 2

Ongoing Debian package maintenance.
by Ben Klein 13 Oct '10

13 Oct '10

Hello everyone, My health has not improved at all since my last call for help with the Debian package management. I really need someone to take over from me, or at least some help to devise a new set of (semi-)automated build scripts. Any volunteers? Kind regards, Ben

5 11

Re: [PATCH] winealsa.drv: Count micelem in mixer chans, don't add spare capture input for half-duplex mics.
by Alexandre Julliard 11 Oct '10

11 Oct '10

Jeff Cook <jeff(a)deserettechnology.com> writes: > @@ -520,7 +520,12 @@ static void ALSA_MixerInit(void) > } > > /* Add master channel, uncounted channels and an extra for capture */ > - mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + 1; > + /* Do not add the extra channel needed for capture on half-duplex capture cards > + like snd_usb_audio mics */ > + if (micelem && !mastelem && !captelem) > + mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + !!micelem; > + else > + mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + !!micelem + 1; This statement wasn't exactly clear before, but now it's really impossible to follow. Please rewrite this in a way that makes sense to a casual reader. -- Alexandre Julliard julliard(a)winehq.org

4 3

Debugging 64-bit Wine Apps with winedbg
by Tom Grubbe 09 Oct '10

09 Oct '10

Hello, we're the developers of a large 64-bit Windows application that uses Wine 1.3.0 64-bit on Linux. When testing began we discovered several crashes inside our windows code on startup and needed to debug them. But the problem seems to be getting any kind of stack trace information from the 64-bit winedbg. This used to work with the 32-bit version of winedbg. Even if I write a 64-bit "hello world" app that intentionally crashes I still can't get a clean stack trace from winedbg. We get a register dump and a stack dump but no back trace. So in our app, we have to resort to calculating the address of the crash in our DLLs using a MAP file and adding a bunch of printfs to try and locate the source of the SEGV. This is awkward, slow and just a bad way to debug. So here's my question - Has anyone had any luck getting a debugger stack trace using the 64-bit winedbg? Some relevant info: * We build wine 64-bit 1.3.0 ourselves * We're running on RHEL 5.5 (Tikanga) 2.6.18-194.el5 64-bit * We get the same non-results from both release and debug windows binaries * Using winedbg --gdb crashes gdb * We tried using msvsmon.exe to attach to and debug the wine process using Visual Studio but it hasn't been helpful * Setting WINEDEBUG to several debug channels has helped some but is difficult to sift through all the noise So any info on strategies to debug 64-bit Wine applications is welcome, or if you need more info I'll be glad to supply it. Thanks for your help! --Tom Grubbe ESRI

4 6

Wineconf 2010: You're running out of procrastination time...act now! Supplies are limited!
by Jeremy White 30 Sep '10

30 Sep '10

Alright, we're now down to about six weeks out. Soon, flights and the rooms will go up in price. So book your travel now! One new favor - if you are coming, please RSVP here: http://www.winehq.org/wineconf/rsvp/ so we can have counts for meals and such. Again, if money is an issue, please write to me; the Wine Party Fund may be able to help. And, as always, the Wiki page has the latest scoop: http://wiki.winehq.org/WineConf2010 and most chatter is happening on the wineconf(a)winehq.org mailing list (except for pushy loud mouthed types like myself :-/). Cheers, Jeremy

1 0