wine-devel

wine-devel@winehq.org

2 participants
84471 discussions

msvcrt: handle inheritance problem
by qingdoa daoo 08 Apr '06

08 Apr '06

HI all, Recently I have been trying to improve support for some MinGW based IDEs without native msvcrt. Now I am dealing with a problem with standard io handle redirection which prevents output from gcc tools from being piped to IDE message windows. I have been able to find that the problem is related to this patch on dlls/msvcrt/file.c http://cvs.winehq.org/cvsweb/wine/dlls/msvcrt/file.c.diff?r1=1.59&r2=1.60&f… It has a one line changlog saying: Duplicate stdin/stdout handles to avoid closing them when library is unloaded. If I revert file.c to pre-patch state, redirection works fine. But am not sure if there will be unexpected consequences. So I searched the wine-patch and wine-devel archives but didn't find the patch or any discussion about it. Could someone explain what exactly that changelog line means? A simple test program ------------------------------------------------------------------------ #include "stdio.h" #include "process.h" int main(int argc, char* argv[]) { if( argc == 1 ) { char *argv2[] = { argv[0], "foo", NULL }; _spawnv(_P_NOWAIT, argv[0], argv2); } else { puts("This won't print with builtin msvcrt"); } return 0; } --------------------------------- Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice.

1 0

FFXI Winsock Question
by Andres Mejia 08 Apr '06

08 Apr '06

I'm having a problem with staying connected while logged in to the PlayOnline service of FFXI. The only debug message I keep finding is a warning that goes "warn:winsock: WSAErrno errno 4 (Interrupted system call)." I already submitted a bug for this but I'm wondering if there was anymore I could do. What I'm asking is, have I done enough or is there something more that I can do to help with fixing this bug?

1 0

NtProtectVirtualMemory
by Segin 07 Apr '06

07 Apr '06

Could someone clue me in to just what this means and why it is: err:virtual:NtProtectVirtualMemory Unsupported on other process A quick Google comes up that function is undocumented, so I don't have much info on it. From the wine source: if (!is_current_process( process )) { ERR("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; } And that's self explanitory, but why is it "Unsupported on other process"?

5 8

Re: WineD3D: Allow the inclusion of the wined3d headers when the ddraw headers are included
by Alexandre Julliard 07 Apr '06

07 Apr '06

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: >> 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. Windows has a MAKEFOURCC in ddraw.h too, probably you should use that instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

server: Fix for possible desktop variable being NULL when set_process_default_desktop is called
by Dan Kegel 07 Apr '06

07 Apr '06

Mike Hearn wrote: >I'm not really convinced a static >analysis can catch things that we "know" cannot happen (eg it'd be a >violation of the X protocol or something) and so rely on them without >explicit checks. To be secure, I think we have to handle X protocol violations, too. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

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 at 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 from the way 0.9.10 was configured. 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$ The eerors at this stage are only seen for two programs namely wine-kthread and wine-server at this moment. The entire log for the last remaining errors 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

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

Building in Unicode mode
by Sergio 06 Apr '06

06 Apr '06

Hi, I am trying to compile something that needs to be compiled defining UNICODE and _UNICODE but I am getting this error: In file included from plugins/yapp/../../include/m_database.h:67, from plugins/yapp/stdafx.h:39, from plugins/yapp/options.cpp:1: /usr/include/wine/windows/tchar.h:27:2: error: #error You must use msvcrt when building in Unicode/MBCS mode I tried defining __WINE_USE_MSVCRT but it did not help. Does anyone have any idea of how to solve this problem? Thank you in advance. Sergio.

1 0

Re: [coverity] Don't close uninitialized handle on VXD error path
by Andrey Turkin 06 Apr '06

06 Apr '06

I thought INVALID_HANDLE_VALUE==-1 and not 0. Moreover, I can't see any code path leading to ERR where handle is allocated (or assigned to) at all so I think there is no need to close it. Mike Hearn wrote: > Mike Hearn <mike(a)plan99.net> > Don't close uninitialized handle on VXD error path > > diff --git a/dlls/kernel/vxd.c b/dlls/kernel/vxd.c > index 5d16684..2a004a0 100644 > --- a/dlls/kernel/vxd.c > +++ b/dlls/kernel/vxd.c > @@ -179,7 +179,7 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR > { > static const WCHAR dotVxDW[] = {'.','v','x','d',0}; > int i; > - HANDLE handle; > + HANDLE handle = INVALID_HANDLE_VALUE; > HMODULE module; > WCHAR *p, name[16]; > > @@ -254,10 +254,14 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR > } > > ERR("too many open VxD modules, please report\n" ); > - CloseHandle( handle ); > + > + if (handle) > + { > + CloseHandle( handle ); > + handle = 0; > + } > FreeLibrary( module ); > - handle = 0; > - > + > done: > RtlLeaveCriticalSection( &vxd_section ); > if (!DuplicateHandle( GetCurrentProcess(), handle, GetCurrentProcess(), &handle, 0, > > >

1 0

strange win in 2006 SourceForge.net Community Choice Awards
by Marcus Meissner 06 Apr '06

06 Apr '06

Hi, The 2006 SourceForge.net Community Choice Awards have been announced ... and it seems the Desktop Winner is: "WINE ..... for Darwin and Mac OS X" Strangely enough, our project directly does not appear to be listed at all in the "Desktop" category. Still considering whether to be sad or happy. I have now added us to the "Desktop environment" category. Ciao, Marcus

1 0

Re: fonts: Add the Won sign in place of the backslash for Korean fonts
by Huw D M Davies 06 Apr '06

06 Apr '06

On Thu, Apr 06, 2006 at 12:45:01PM +0100, Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > fonts: Add the Won Sign in place of the backslash for Korean fonts Actually could you ignore this for the moment? Dmitry's got a patch that's about to arrive that'll clash with this, and this one is much easier to regenerate. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Invisible fonts regression
by Ivan Gyurdiev 06 Apr '06

06 Apr '06

I am no longer able to see fonts in: - the GTA installer - for example on the intial screen ("What language to use?") - Steam (*with* Tahoma previously installed and working). When selecting menus fonts will flash quickly making the menu visible, and then disappear. In addition, when re-creating a new clean wine root, I also lose the ability to see fonts in winecfg. This is Wine 0.9.11 on Fedora Rawhide x86_64. There is no error output. The Steam problem was in the last release as well. What should I do to track down the problem?

5 8

SimCity 4 and hardware rendering -- Not working.
by Segin 06 Apr '06

06 Apr '06

As usual, I went out and found something else to test. SimCity 4 Deluxe works, impeckably well, but it only does software rendering (which can literally bring your system to it's knees). I use a patched .exe cause the default one didn't work for me (and this one has a no-cd deal, plus is smaller). Anyways, when starting in Direct3D mode, it goes to a back window, but quickly flashes back to your desktop, with this debug: err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (0000000a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (0000000b) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (0000000c) value : 0000000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (0000000d) value : ffffffff ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (00000010) value : 00000001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0000001e) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (00000028) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (00000030) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (0000008a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (00000097) value : 00000000 ! It then resumes loading in software rendering.

3 2

WINE & Microsoft WGA
by Marcus Meissner 06 Apr '06

06 Apr '06

Hi, Just found by random websearch... http://www.microsoft.com/genuine/downloads/FAQ.aspx?displaylang=en ... Q: Will systems running WINE pass WGA validation? A: Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix. When WGA validation detects WINE running on the system, it will notify users that they are running non-genuine Windows, and it will not allow genuine Windows downloads for that system. Users of WINE should consult the WINE community for WINE updates. It is important to note that WINE users, and other users of non-genuine Windows, can continue to download updates for most Microsoft applications from Microsoft application-specific sites, such as Office Update. Ciao, Marcus

3 2

EU CVS server is not up to date
by Berend Reitsma 05 Apr '06

05 Apr '06

Hello, The EU CVS server is not up to date. The head of the Changelog is 1.110 while on cvs.winehq it is 1.111. $ cvs -n -d:pserver:cvs@rhlx01.fht-esslingen.de:/home/wine -q log ChangeLog | head RCS file: /home/wine/wine/ChangeLog,v Working file: ChangeLog head: 1.110 branch: locks: strict access list: symbolic names: Wine-0_9_10: 1.110 Wine-0_9_9: 1.109 Regards, Berend.

1 0

[opengl] Another possible fix for the BadMatch error
by Leon Freitag 05 Apr '06

05 Apr '06

> The BadMatch in X_GLXCreateGLXPixmap is another problem.. here you > should get a BadMatch in X_GLXMakeCurrent. That's true, this patch should only fix the BadMatches in glXMakeCurrent. > BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a > patch but it was rejected. Well, try to resubmit it :) Or post it here, so that others could test it. Perhaps you could merge this one-liner into it and then resubmit it. Leon

2 5

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