wine-devel April 2006

wine-devel@winehq.org

176 participants
334 discussions

Re: [dsound] set default primary buffer sample rate and bits per sample
by Alexandre Julliard 07 Apr '06

07 Apr '06

Robert Reif <reif(a)earthlink.net> writes: > Programs that are written specifically for 2000 and xp don't > bother to set the primary buffer format because it's a noop. However > wine is patterned after win9x and DirectX 7 or > earlier which has a real primary buffer and expects the > program to change the primary buffer format if necessary. > > This patch provides a way to change the primary buffer format > from 22050x8 to an application specific value or a system wide > value for programs that don't. Shouldn't we make it work the win2k way then, instead of requiring users to configure things manually? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: server: Fix for possible desktop variable being NULL when set_process_default_desktop is called
by Alexandre Julliard 07 Apr '06

07 Apr '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > The desktop variable could be NULL when set_process_default_desktop is > called, so check for this. (Found by Coverity). I don't see how this could happen. Did I miss something? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: buffer check in comdlg
by Robert Shearman 07 Apr '06

07 Apr '06

Aric Stewart wrote: > if(fodInfos->unicode) > { > LPOPENFILENAMEW ofn = fodInfos->ofnInfos; >- strcpyW( ofn->lpstrFile, lpstrPathSpec); >- memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); >+ if (nSizePath+sizeUsed > ofn->nMaxFile) >+ { >+ *((WORD*)ofn->lpstrFile)=nSizePath+sizeUsed; >+ FILEDLG95_Clean(hwnd); >+ EndDialog(hwnd,FALSE); >+ COMDLG32_SetCommDlgExtendedError(FNERR_BUFFERTOOSMALL); >+ return FALSE; >+ } >+ else >+ { >+ strcpyW( ofn->lpstrFile, lpstrPathSpec); >+ memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); >+ } > } > > This formatting doesn't look at all consistent, either with itself or the other code there. -- Rob Shearman

2 1

WineD3D: Add a WINEMAKEFOURCC macro
by Stefan Dösinger 07 Apr '06

07 Apr '06

Hello, Alexandre, if you think > that it should be in the wined3d headers, you can add > #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24)) > in line 169 in wined3d_interface.h, or ask me to send a patch for that. Forget about that, I forgot that wined3d_types is included before that line. Attached is a patch which creates WINEMAKEFOURCC and uses this. Changelog: Stefan Dösinger: Add a WINEMAKEFOURCC macro to wined3d_types.h

1 0

Re: advpack: Rewrite get_parameter to be able to handle an empty parameter
by James Hawkins 07 Apr '06

07 Apr '06

On 4/7/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Changelog: > * Rewrite get_parameter to be able to handle an empty parameter. > blah Ignore this, because I sent too much in one patch. -- James Hawkins

1 0

new to wine, Guild Wars don't display correctly
by BONNEL Christophe 07 Apr '06

07 Apr '06

3 6

Re: msi: Use a debug channel to turn on transform debugging. (Coverity)
by Alexandre Julliard 07 Apr '06

07 Apr '06

Mike McCormack <mike(a)codeweavers.com> writes: > --- a/dlls/msi/table.c > +++ b/dlls/msi/table.c > @@ -1604,13 +1604,12 @@ static MSIRECORD *msi_get_transform_reco > USHORT mask = *rawdata++; > MSICOLUMNINFO *columns = tv->columns; > MSIRECORD *rec; > - const int debug_transform = 0; > > rec = MSI_CreateRecord( tv->num_cols ); > if( !rec ) > return rec; > > - if( debug_transform ) MESSAGE("row -> "); > + if( TRACE_ON(msidb) ) MESSAGE("row -> "); You should use TRACE instead of MESSAGE then, it will be a lot more readable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: x11drv: (bug 4685) properly handle VK_LMENU input (resend)
by Dmitry Timoshkov 07 Apr '06

07 Apr '06

<tkho(a)ucla.edu> wrote: A couple of suggestions about coding style: > +struct transition_s { > + BYTE wVk; It would be more logical to use WORD for VK codes as everywhere else. > + BYTE before_state; > + BYTE _todo_wine; > +}; Same for _todo_wine, it should be BOOL. > + > +struct sendinput_test_s { > + WORD wVk; > + DWORD dwFlags; > + struct transition_s expected_transitions[MAXKEYEVENTS+1]; > + UINT expected_messages[MAXKEYMESSAGES+1]; > +} sendinput_test[] = { > + /* test ALT+F */ > + {VK_LMENU, 0, {{0x12, 0x00, 0}, {0xa4, 0x00, 0}, {0}}, {0x104, 0}}, > + {'F', 0, {{0x46, 0x00, 0}, {0}}, {0x104, 0x106, 0x112, 0}}, > + {'F', KEYEVENTF_KEYUP, {{0x46, 0x80, 0}, {0}}, {0x105, 0}}, > + {VK_LMENU, KEYEVENTF_KEYUP, {{0x12, 0x80, 0}, {0xa4, 0x80, 0}, {0}}, > + {0x101, 0}}, Please use VK names and symbolic message names in the above arrays to make them more readable. > /*********************************************************************** > * X11DRV_send_keyboard_input > @@ -1128,14 +1141,16 @@ > { > message = WM_KEYUP; > if ((key_state_table[VK_MENU] & 0x80) && > - ((wVk == VK_MENU) || (wVk == VK_CONTROL) || !(key_state_table[VK_CONTROL] & 0x80))) > + ((VkStripLR(wVk) == VK_MENU) || (VkStripLR(wVk) == VK_CONTROL) > + || !(key_state_table[VK_CONTROL] & 0x80))) > { > if( TrackSysKey == VK_MENU || /* <ALT>-down/<ALT>-up sequence */ > - (wVk != VK_MENU)) /* <ALT>-down...<something else>-up */ > + (VkStripLR(wVk) != VK_MENU)) /* <ALT>-down...<something else>-up */ > message = WM_SYSKEYUP; > TrackSysKey = 0; > } > key_state_table[wVk] &= ~0x80; > + key_state_table[VkStripLR(wVk)] &= ~0x80; > keylp.lp1.previous = 1; > keylp.lp1.transition = 1; > } > @@ -1145,12 +1160,13 @@ > keylp.lp1.transition = 0; > if (!(key_state_table[wVk] & 0x80)) key_state_table[wVk] ^= 0x01; > key_state_table[wVk] |= 0xc0; > + key_state_table[VkStripLR(wVk)] |= 0xc0; > > message = WM_KEYDOWN; > if ((key_state_table[VK_MENU] & 0x80) && !(key_state_table[VK_CONTROL] & 0x80)) > { > message = WM_SYSKEYDOWN; > - TrackSysKey = wVk; > + TrackSysKey = VkStripLR(wVk); It would be much simpler to call VkStripLR() only once and use the result for further processing. -- Dmitry.

1 0

Compiling wine 0.9.11 under solaris 10
by Chiaki 07 Apr '06

07 Apr '06

I am trying to build wine-0.9.11 on a solaris express system (nevada b29). But the end of compilation, I got link errors in a couple places. (messages are given below.) I followed the guidance at http://www.blastwave.org/wine/winemaking.html I had not known the tips mentioned at http://wiki.jswindle.com/index.php/Installing_Wine#Solaris before I tried compilation, Because I didn't know, instead of disabling some macros as suggested in the above URL, I hacked the source files so that the previously ignored files were compiled under Solaris 10 (or Solaris 11 beta). (I listed some of these into a mail list mentioned at blastware web page [solaris package repository] http://lists.blastwave.org/pipermail/users/2006-April/thread.html when I was tinkering with 0.9.10. The changes are basically the same for the case of 0.9.11 with a few additions now that I have configured 0.9.11 in a slightly different manner as was done for 0.9.10 mentioned in the above link. And the link errors I saw have not changed between 0.9.10 and 0.9.11) Anyway, at the end of compilation, I got link errors in a couple places. ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status These seem to be due to versioning(?) of read/write system call symbols or something. (SUNW seems to be symbol used by SUN to mark symbols coming from their libraries, etc.. It is market symbol for Sun Microsystems. Most of Sun-supplied `packages' for solaris is named like SUNWxyz to denote that they are coming from Sun instead of 3rd parties.) Have anybody seen these link problems before? Are there any workarounds? Or am I using incorrect ld/gas, etc? Tool chain information. $ uname -a SunOS solaris-nv-28-home 5.11 snv_28 i86pc i386 i86pc $ which gcc /usr/sfw/bin/gcc bash-3.00$ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (I have replaced /usr/ccs/bin/ld invoked with the above to be gnu ld instead of the original sun ld.) bash-3.00$ /usr/ccs/bin/ld --version GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. bash-3.00$ There are only seen for two programs namely wine-kthread and wine-server at this moment. The entire log for the last remaining erros follows here. (Line folding is done by the mailer here, sorry about this.) cd /home/ishikawa/local-src/wine-sources/wine-0.9.11/ bash-3.00$ make -k gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wine-kthread -Wl,--export -dynamic -Wl,--section-start,.interp=0x7bf00400 -Wl,--rpath,\$ORIGIN/`../tools /relpath /usr/local/bin /usr/local/lib` kthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/lo ader *** Error code 1 The following command caused the error: cd loader && make `libdinput.def.a' is up to date. ../../tools/winegcc/winegcc -B../../tools/winebuild -mwindows curses.o dialog .o registry.o user.o wineconsole.o wineconsole_res.res -o wineconsole.exe. so -Wl,--rpath,\$ORIGIN/`../../tools/relpath /usr/local/lib/wine /usr/local/li b` -L../../dlls -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L.. /../libs -lwine -L../../libs/port -lwine_port -lrt -lthread -lsocket -lnsl - lcurses -Wb,-dcomctl32 -Wb,-duser32 -Wb,-dgdi32 gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wineserver -Wl,--rpath,\$ ORIGIN/`../tools/relpath /usr/local/bin /usr/local/lib` atom.o change.o clas s.o clipboard.o console.o context_alpha.o context_i386.o context_powerpc. o context_sparc.o context_x86_64.o debugger.o directory.o event.o fd.o file.o handle.o hook.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o ptrace.o queue.o region.o registry.o request.o sem aphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o sunptrace.o -L. ./libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port -lrt -lthread -lsocket -lnsl ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/se rver *** Error code 1 The following command caused the error: cd server && make make: Warning: Target `all' not remade because of errors bash-3.00$ TIA -- int main(void){int j=2006;/*(c)2006 cishikawa. */ char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\""; char *i ="d>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz"; while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1), (putchar(t[j])));return 0;}/* under GPL */

1 0

Coverity Open Source Defect Scan of Wine
by Ben Chelf 07 Apr '06

07 Apr '06

Hello Wine Developers, As some of you may have heard, last month Coverity set up http://scan.coverity.com as a site dedicated to scanning open source projects for defects. In just 1 month, over 4500 defects have been examined by various open source developers, and from what we can tell, it seems that there have been over 2500 patches to the scanned code bases! Due to popular request, I’m happy to announce that we’ve added Wine to the list of projects scanned on the site. For those of you not familiar with "scan" yet and by way of introduction ... I'm the CTO of Coverity, Inc., a company that has technology that performs static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framework internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. To see the results of the project, check out: http://scan.coverity.com My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results. Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of Wine, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, I'd ask that if you are interested in really digging into the results a bit further for your project, please have a couple of core maintainers and/or developers reach out to us to request access. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort. So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to register on our site or email me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message. Many thanks for reading this far... -ben Ben Chelf Chief Technology Officer Coverity, Inc.

2 1

← Newer
1
...
25
26
27
28
29
30
31
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel April 2006