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

Re: Relax test requirements to accomodate fuzz of msacm

by Jeremy White

Robert Reif wrote: > Jeremy White wrote: > >> Robert has persuaded me that msacm on Windows does make 'fuzzy' >> conversions; >> an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of >> the logical (and correct seeming) 48,000 byte buffer. This means that >> when we go to get the position after playing the answer comes up as >> 47992 instead of 48,000, which causes a winmm test failure. > > > The real fix is to fix the wave mapper to do another conversion > when the previous one is incomplete. We will have to do this > anyway if we ever try to support non PCM formats. I don't think that is right; the conversion is not incomplete. In the specific example of 8000 into 48000 (a 6 to 1 ratio), rather than the first source byte going into the first six dest bytes, instead the first source byte goes into the first four destination bytes, and then the second source byte goes into the next six, and so on. That leaves you with an uneven use of the dest buffer, and hence the left over bytes. So the conversion is, in fact, complete, it's just for some odd reason not aligned on the initial buffer. I wrote a patch in the wavemapper to 'fill' such unaligned conversions, but then when I read it I realized it was a wrong change. So the only fix I can imagine would be to not use msacm to perform these conversions and have a parallel set of converters do this in an aligned fashion. But, again, I wonder if Windows doesn't have this exact same behavior but we can never find it because all Windows hardware drivers claim direct support for all of the winmm formats, so Windows never does a software conversion. Hence, in my humble opinion, this patch remains correct; I believe that Wine does exactly what Windows would do if it faced the same limited hardware functionality. Further, I don't see any benefit in leaving these tests broken; the reason to do that would be to spur additional development, and I do not think that any further Wine changes are appropriate. Cheers, Jeremy

Feb. 26, 2005

vartest.c - major pain in the build process

by Krzysztof Foltman

Is there any reason for gcc 3.3.1 to spend several minutes on compiling dlls/oleaut32/tests/vartest.c ? I guess it can be explained by optimization stage going nuts on compiling long functions with many branches (contained in the macros), but there must be a way to speed this up. It's barely tolerable now, and upgrading gcc is not an option for everyone. Krzysztof

Feb. 26, 2005

Re: Relax test requirements to accomodate fuzz of msacm

by Robert Reif

Jeremy White wrote: > Robert has persuaded me that msacm on Windows does make 'fuzzy' > conversions; > an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of > the logical (and correct seeming) 48,000 byte buffer. This means that > when we go to get the position after playing the answer comes up as > 47992 instead of 48,000, which causes a winmm test failure. The real fix is to fix the wave mapper to do another conversion when the previous one is incomplete. We will have to do this anyway if we ever try to support non PCM formats.

Feb. 26, 2005

Re: USER32: GetScrollBarInfo

by Vitaly Lipatov

В сообщении от 26 Февраль 2005 01:42 Alexandre Julliard написал(a): > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > +static BOOL SCROLL_GetScrollBarInfo(HWND hwnd, LONG idObject, > > LPSCROLLBARINFO psbi) +{ > > + RECT rect; > > + INT arrowSize, thumbSize, thumbPos, nBar, vertical; > > + FIXME("check me"); > > This doesn't sound very encouraging... I have not time for write full test this function, but I have the implementation. If anyone will use it, he will can check for correctly. P.S. Or we can remove this line with FIXME :) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Feb. 26, 2005

Re: Build on Fedora core 3 on AMD64

by Marcus Meissner

On Sat, Feb 26, 2005 at 02:47:25PM +1300, Adrian Harvey wrote: > I am having trouble getting wine (latest CVS) to build on my AMD64 box > runngin Fedora core3, and I was hoping some autoconf wizard might be > able to help. To begin at the beginning, the issue that occurs during > build is: > > gcc -m32 -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include > -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack- > boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o > ddraw.dll.dbg.o ddraw.dll.dbg.c > .../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ddraw.spec > convert.o dclipper/main.o ddraw/hal.o ddraw/main.o ddraw/thunks.o > ddraw/user.o dpalette/hal.o dpalette/main.o dsurface/dib.o > dsurface/fakezbuffer.o dsurface/gamma.o dsurface/hal.o dsurface/main.o > dsurface/thunks.o dsurface/user.o dsurface/wndproc.o helper.o main.o > regsvr.o struct_convert.o ddraw.dll.dbg.o version.res -o ddraw.dll.so > -L../../dlls -lole32 -luser32 -lgdi32 -ladvapi32 -lkernel32 - > L../../libs/wine -lwine -ldxguid -luuid -L/usr/X11R6/lib64 -lXext - > lX11 -L../../libs/port -lwine_port > /usr/bin/ld: skipping incompatible /usr/X11R6/lib64/libXext.so when > searching for -lXext > /usr/bin/ld: skipping incompatible /usr/X11R6/lib64/libXext.a when > searching for -lXext > /usr/bin/ld: cannot find -lXext > collect2: ld returned 1 exit status > winegcc: gcc failed. > make[2]: *** [ddraw.dll.so] Error 2 > make[2]: Leaving directory `/home/adrian/wine/dlls/ddraw' > make[1]: *** [ddraw] Error 2 > make[1]: Leaving directory `/home/adrian/wine/dlls' > make: *** [dlls] Error 2 > > So it seems that ld is finding the 64-bit version and failing to link > it. It seems that the reason for this is that configure uses > xmkmf/imake to locate the X11 library directory and that this is always > returning the .../lib64 version. I have split out the Imakefile that > configure generates, and tried various methods to prevent it seeing the > system as 64 bit and handing out the lib64 directory instead of the lib > one, but to no avail. Use the --x-libraries=/usr/X11R6/lib configure option (or wherever fedora keeps the 32bit libs). And make sure that you have the 32bit libraries and devel headers installed. Ciao, Marcus

Feb. 26, 2005

Re: New uninstaller

by Mike McCormack

Jonathan Ernst wrote: > Ok I did it, but the listbox should be updated when the user ask to > uninstall someting OR the user changes the filter string ? How can I do > that using only WM_INITDIALOG ? You can get notifications from the controls that things change. For example, the edit control will send a WM_COMMAND( EN_CHANGE ) when the contents change. WM_INITDIALOG is just for setting things up. So create a function like fill_combo_box(), and call it whenever you need to update the combo box... when handling WM_COMMAND( EN_CHANGE ), WM_INITDIALOG, etc. Mike

Feb. 26, 2005

Re: New uninstaller

by Dmitry Timoshkov

"Ivan Leo Puoti" <ivanleo(a)gmail.com> wrote: > Jonathan Ernst wrote: > > 4) Please tell me if you see things that are bad in the attached code, > > so that I'll fix it before submitting a patch. > > I think you probably want to pass a valid HINSTANCE to DialogBox, to do this you should > start your program with WinMain() instead of main(). main() works just fine. GetModuleHandle(0) returns current HINSTANCE. -- Dmitry.

Feb. 26, 2005

Re: New uninstaller

by Dmitry Timoshkov

"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote: > 1) Strange problem with UpdateWindow > uninstaller.c, line 264 > I implemented a search/filter field and I want to repaint the window > after each input in the EDITTEXT control. However, when I call > UpdateWindow on this line, the value returned is 1 so that a WM_PAINT > message should be sent right ? No. UpdateWindow only sends WM_PAINT if there are invalidated areas to repaint. You need to use InvalidateRect first. Are you sure you want to repaint the whole window on each EN_CHANGE and not some small area of a dialog? > But strangly no message is sent and I > have to make something else (like moving the dialog) to force the window > to repaint and filter the entries. > The funny thing is that UpdateWindow on line 279 works just fine. > I guess it's a bug in my code and not in Wine so I'd be glad if you > could help me. > 2) Improve filter code > Currently I filter the entries that match exactly the filter string. I > would like to at least make a case insensitive strstr on the string. > What's the best way to do it (See uninstaller.c, line 235) Just send LB_FINDSTRING or LB_FINDSTRINGEXACT to listbox, it will do the job for you. > 3) Stringtables > a)Is there a way to load localized strings without having to guess > beforehand the size of the string in each language ? > b)Is there a way to not call LoadString for each string ? > c)Where is the best place to load every string of a stringtable ? in > main(), just before calling DialogBox() ? It's better to void using string tables, since now you have converted code to use dialog box instead. > 4) Please tell me if you see things that are bad in the attached code, > so that I'll fix it before submitting a patch. > +BOOL CALLBACK DlgProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam) BOOL -> INT_PTR WM_PAINT is not needed for dialog boxes, user32 does the job. > +int main(int argc, char *argv[]) > +{ > + MSG msg; > + WNDCLASS wc; > + HWND hWnd; > + LPSTR token = NULL; > + int i = 1; > + HINSTANCE hInst = NULL; HINSTANCE hInst = GetModuleHandle(0); -- Dmitry.

Feb. 26, 2005

Space Empires: Starfury

by Adam Babcock

I have posted to the list before about this game. Anyway, a group of us over at the publisher's forum really want to see this game running, so we will be getting in #starfury on freenode this saturday to try and get it to run. We would really appreciate the help if anyone from the list with a more technical background on the inner workings of wine would join in and help. We've set a starting time of around 15h00 UTC, so if any of you wanted to join in, would be greatly appreciated.

Feb. 26, 2005

Re: New uninstaller

by Jonathan Ernst

Le samedi 26 février 2005 à 09:49 +0900, Mike McCormack a écrit : [...] > Cool. Some comments: > > The dialog box procedure should not handle WM_PAINT or WM_CLOSE, so just > delete those cases from the switch statement. > Ok I did it, but the listbox should be updated when the user ask to uninstall someting OR the user changes the filter string ? How can I do that using only WM_INITDIALOG ? > Don't send WM_SETFONT messages to the controls in the dialog. Let the > dialog template define what the dialog looks like. I removed it. > > Your WM_INITDIALOG handler should fill the listbox, not WM_PAINT. > See my first question. > You can remove the "No items selected" message if uninstall is clicked > without a listbox element select. That's just going to annoy people, > and it's not internationalized. I removed it. Internationalizaton will come after everything is alright. Thanks. P.S. Ivan Leo Puti I don't know if it'll be better to use WinMain. Using WinMain will make me to parse the command line manually isn't it ?

Feb. 26, 2005