wine-devel

wine-devel@winehq.org

10 participants
84460 discussions

Re: RPCRT4_NdrClientCall2 stub (fixme)?
by Filip Navara 30 Jul '04

30 Jul '04

Alexandre Julliard wrote: > Mike Hearn <mike(a)navi.cx> writes: > >>> Yes, I have an implementation of NdrClientCall2 in my local tree, but >>> I'm a bit busy with other COM things at the moment. I'll send an >>> updated >>> patch to the list either tonight or sometime over the weekend. >>> >> >> Alexandre, why was this not merged when it was originally sent? >> > > No idea, please resubmit. > IIRC Robert said that the patch isn't cleaned up yet and so it shouldn't be commited. He also said that he hasn't tested it much except for simple tests and the complex types weren't tested at all. - Filip

3 4

possible bug in wcmd
by Henning Gerhardt 30 Jul '04

30 Jul '04

Hi, I discovered a possible bug in wcmd. If you run "help for" inside wcmd, wcmd crashed and the winedebugger is called. I used to confirm this bug on my machine the latest tarball and a CVS-snapshot from today. If anybody can confirm this bug I will be happy :) The following lines are only correct if this bug is true: The problem is that a single % letter inside the resource strings. Look for the for-help text in En.rc file and you find the sentence "The requirement to double the % sign when using FOR in a batch file does") get parsed and this single % caused the crash. I found the following solutions and I don't know what is the right solution: 1. replace the single % with a double %% in all resource files 2. replace in the function WCMD_give_help (builtins.c:330) WCMD_output with WCMD_output_asis (WCMD_output (wcmdmain.c:733) called WCMD_output_asis but make some stuff for possible dynamic parameters) 3. patch the function WCMD_output (wcmdmain.c:733) with the attached patch (Replace a single % with a double % and all later called system function are be happy) I prefer personal the second or third solution. Regards, Henning

1 0

Linking with dlls and Linux libs using winelib?
by James Supancic 30 Jul '04

30 Jul '04

I need to compile a Windows application under Linux. I need to use dlls and Linux librarys. No matter what I try I can't get winegcc to include the Linux librarys in the linking stage. What must I do to get winegcc to link with both the dlls and Linux libs? Thank you for your time, James Steven Supancic III _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Re: Re: WineHQ:service.cgi: fix winrash option
by chmorgan＠charter.net 30 Jul '04

30 Jul '04

> <chmorgan(a)charter.net> writes: > > > Which errors are you referring to? The most frequent ones > > lately are the ones where the winetest package isn't > > available on the sourceforge osdn mirror. > > For example this: > > > Winrash version: winrash-0008-chris-msvc.exe > > [...] > > winetest = winetest-200407091000-kevin-mingw.zip > > winetest_history = > > Script: > > 8 total commands, current command is 6 > > 0: error_url http://test.winehq.org/error > > 1: error_sleep 3600 > > 2: download winetest-200407091000-kevin-mingw.zip http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin… > > 3: cookie winetest winetest-200407091000-kevin-mingw.zip > > 4: cookie winetest_history > > 5: unzip winetest-200407091000-kevin-mingw.zip > > --> 6: run winetest-200407091000-kevin-mingw.exe -c -t Cogman -u http://osdn.dl.sourceforge.net/sourceforge/wine/winetest-200407091000-kevin… > > 7: sleep 300 > > Command in error: > > 6 > > Last error text: The system cannot find the file specified. > > Does the above mean that the download was unsuccessful? > Equally for "Last error text: %1 is not a valid Win32 > application."? Then we don't need these messages (which > could be improved at least). > Yep. I just tried that url and it worked. Many of the ones I've tried in the past haven't and the cause seems to be that the mirror chosen doesn't have the file. I'm not sure what a good solution is. Perhaps we should implement a way of providing a list of potential download sites for a file. I'm not sure how to detect that the download fails. Sourceforge provides a page that says that the file can't be found. This is what winrash probably downloaded in this case. Any ideas how to make the system more robust without making it much more complex? > Hmm, some still try to download winrash-0008 from the osdn > mirror, which has been obsoleted for a long time. Why? > I have no idea what the issue is here. The script should be telling the 0007 client to download 0009. I'm not sure if this is a bug or not. > And service.cgi shouldn't pass the -u option to winetest > anymore, I patched it out. At least I think so. > > > We are still asking people to download the tests from this > > location for particular test releases. I'd imagine the > > fix is simply to point the downloads at valid mirror for > > the file. > > By editing service.cgi's database? You could ask Jer, his > is very helpful if you can catch him on IRC. I wish there > was some logging feature in service.cgi... I'll go deeper > in a couple of days. > -- > Feri. Your help is much appreciated. This is a tricky issue it seems as SF isn't always reliable for downloads... Chris

7 9

formal standard for wine devel style
by James Hawkins 30 Jul '04

30 Jul '04

Is there a written formal standard specifying the style in which wine code is written? I remember a message a while back about how a patch couldn't be committed because it didn't meet the standards of wine coding style and that someone who knew the style could fix it. -- James Hawkins

3 2

Re: DCOM: Disconnect Proxies at COM Shutdown
by Robert Shearman 30 Jul '04

30 Jul '04

Robert Shearman wrote: > Changelog: > > Mike Hearn <mh(a)codeweavers.com> > Disconnect proxies at COM shutdown to release the corresponding stubs. Sorry, this one was an old patch. Rob

1 0

Bug in menu.c
by Dan Timis 30 Jul '04

30 Jul '04

Hi, The MS documentation on the structure MENUITEMINFO says that the field fMask indicates what fields to retrieve or set. Here is what it says about the value MIIM_TYPE: > Retrieves or sets the fType and dwTypeData members. Windows 98/Me, > Windows 2000/XP: MIIM_TYPE is replaced by MIIM_BITMAP, MIIM_FTYPE, > and MIIM_STRING. So if one wants to specify a text menu item in XP, one would use MIIM_STRING, not MIIM_TYPE. fType would also need to be MFT_STRING. In menu.c in GetMenuItemInfo_common(): /* copy the text string */ if ((lpmii->fMask & (MIIM_TYPE|MIIM_STRING)) && (MENU_ITEM_TYPE(menu->fType) == MF_STRING) && menu->text) { and so on... This works fine. It retrieves the text if either MIIM_TYPE or MIIM_STRING are set. But, in GetMenuItemInfo_common(): if (lpmii->fMask & MIIM_TYPE) { /* Get rid of old string. */ if (IS_STRING_ITEM(menu->fType) && menu->text) { HeapFree(GetProcessHeap(), 0, menu->text); menu->text = NULL; } /* make only MENU_ITEM_TYPE bits in menu->fType equal lpmii->fType */ menu->fType &= ~MENU_ITEM_TYPE(menu->fType); menu->fType |= MENU_ITEM_TYPE(lpmii->fType); menu->text = lpmii->dwTypeData; and so on... This sets the text only if MIIM_TYPE is set. I changed the first line to: if (lpmii->fMask & (MIIM_TYPE|MIIM_STRING)) { and menus that were drawing before as a long thin vertical line, started to show correctly. I'm not sure if this is the right way to fix this, but it works for me. I am using a wine version from 2004-04-08. BTW, I reported earlier a crash in menu.c. I did not hear anything back. Should I log this into Bugzilla? Thanks, Dan Timis Muse Research, Inc.

2 1

Re: cleanup a->w cross calls in advapi32/crypt.c
by Dmitry Timoshkov 30 Jul '04

30 Jul '04

"James Hawkins" <truiken(a)gmail.com> wrote: > This is a resubmit of my original patch that cleans up a->w cross > calls in crypt. > > Changelog > * cleanup a->w cross calls in advapi32/crypt.c > + static const WCHAR KEYSTR[] = { > + 'S','o','f','t','w','a','r','e','\\','\\', > + 'M','i','c','r','o','s','o','f','t','\\','\\', > + 'C','r','y','p','t','o','g','r','a','p','h','y','\\','\\', > + 'D','e','f','a','u','l','t','s','\\','\\', > + 'P','r','o','v','i','d','e','r','\\','\\',0 > + }; Remove double backslashes here and everywhere else. > - keyname = CRYPT_Alloc(strlen(KEYSTR) + strlen(pProvName) +1); > + keyname = CRYPT_Alloc(strlenW(KEYSTR) + strlenW(pProvName) + 1); Add '* sizeof(WCHAR)' and everywhere else where storage for unicode strings is allocated. > - keyname = CRYPT_Alloc( (user ? strlen(USERSTR) : strlen(MACHINESTR)) +1); > + keyname = CRYPT_Alloc( (user ? strlenW(USERSTR) : strlenW(MACHINESTR)) +1); Add '* sizeof(WCHAR)' > + static WCHAR nameW[] = {'N','a','m','e',0}; > + static WCHAR typeW[] = {'T','y','p','e',0}; > + static WCHAR imagePathW[] = {'I','m','a','g','e',' ','P','a','t','h',0}; > + static WCHAR signatureW[] = {'S','i','g','n','a','t','u','r','e',0}; > + static WCHAR sigInFileW[] = {'S','i','g','I','n','F','i','l','e',0}; Add 'const'. > - if ( !(provname = CRYPT_Alloc(strlen(pszProvider) +1)) ) > + if ( !(provname = CRYPT_Alloc(strlenW(pszProvider) +1)) ) Add '* sizeof(WCHAR)' > - len = ExpandEnvironmentStringsA(temp, NULL, 0); > + len = ExpandEnvironmentStringsW(temp, NULL, 0); > if ( !(imagepath = CRYPT_Alloc(len)) ) Add '* sizeof(WCHAR)' ... And lots of similar bugs. -- Dmitry.

1 0

Re: change the nt service pack version from 6 to 6a, correct win2k3 name
by Ivan Leo Puoti 30 Jul '04

30 Jul '04

>Easy, take several W2K3 system DLLs and kick them through winedump with what command line?

1 0

Re: add autodetect audio driver capability to winmm, second try
by Alexandre Julliard 29 Jul '04

29 Jul '04

James Hawkins <truiken(a)gmail.com> writes: > + /* try to detect arts */ > + argv_new[2] = "ps awx|grep artsd|grep -v grep|grep artsd > /dev/null"; > + if(!spawnvp(_P_WAIT, "/bin/sh", argv_new)) > + { > + driversFound[numFound] = "winearts.drv"; > + name[numFound] = "aRts"; > + numFound++; > + } This code does not belong in winmm. Autodetection in winmm should be done by having the drivers themselves fail to load if the corresponding support is missing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Test drive error
by sergio ojalvo 29 Jul '04

29 Jul '04

Hi I'm working on Debian Linux. I just install the wine packages and download sources for trying the test driver. Running Winemaker to winemine test project I note: that configure script was not created and Makefile is created instead of Makefile.in. (like wrote in the web page) I think is a new feature... I'm wrong? Anyway, I try to run make after that and that is the output: winebuild -o winemine.exe.dbg.c --debug -C. dialog.c main.c winegcc -c -mno-cygwin -I. -o winemine.exe.dbg.o winemine.exe.dbg.c winegcc -c -mno-cygwin -I. -o dialog.o dialog.c winegcc -c -mno-cygwin -I. -o main.o main.c wrc -I. -foEn.res En.rc En.rc:23:22: Error: syntax error make: *** [En.res] Error 1 After that I try with another 2 projects (win32 code) and I receive a lot of compilation errors like: In file included from /usr/include/c++/3.3/iosfwd:46, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/c++/3.3/i486-linux/bits/c++locale.h:53: error: `uselocale' was not declared in this scope In file included from /usr/include/c++/3.3/i486-linux/bits/c++io.h:35, from /usr/include/c++/3.3/bits/fpos.h:44, from /usr/include/c++/3.3/iosfwd:49, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/c++/3.3/cstdio:167: error: `snprintf' not declared /usr/include/c++/3.3/cstdio:168: error: `vfscanf' not declared /usr/include/c++/3.3/cstdio:169: error: `vscanf' not declared /usr/include/c++/3.3/cstdio:171: error: `vsscanf' not declared /usr/include/c++/3.3/cstdio:177: error: `snprintf' not declared /usr/include/c++/3.3/cstdio:178: error: `vfscanf' not declared /usr/include/c++/3.3/cstdio:179: error: `vscanf' not declared /usr/include/c++/3.3/cstdio:181: error: `vsscanf' not declared In file included from /usr/include/c++/3.3/i486-linux/bits/gthr-default.h:37, from /usr/include/c++/3.3/i486-linux/bits/gthr.h:98, from /usr/include/c++/3.3/i486-linux/bits/c++io.h:37, from /usr/include/c++/3.3/bits/fpos.h:44, from /usr/include/c++/3.3/iosfwd:49, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/pthread.h:651: error: type specifier omitted for parameter `clockid_t' /usr/include/pthread.h:651: error: parse error before `*' token In file included from /usr/include/c++/3.3/bits/fpos.h:45, from /usr/include/c++/3.3/iosfwd:49, from /usr/include/c++/3.3/ios:44, from /usr/include/c++/3.3/ostream:45, from /usr/include/c++/3.3/iostream:45, from midi2nokia.cpp:4: /usr/include/c++/3.3/cwchar:142: error: `fwide' not declared /usr/include/c++/3.3/cwchar:149: error: `mbsinit' not declared /usr/include/c++/3.3/cwchar:157: error: `vfwscanf' not declared /usr/include/c++/3.3/cwchar:159: error: `vswscanf' not declared /usr/include/c++/3.3/cwchar:161: error: `vwscanf' not declared /usr/include/c++/3.3/cwchar:176: error: `wcstof' not declared /usr/include/c++/3.3/cwchar:182: error: `wmemcmp' not declared /usr/include/c++/3.3/cwchar:183: error: `wmemcpy' not declared /usr/include/c++/3.3/cwchar:184: error: `wmemmove' not declared /usr/include/c++/3.3/cwchar:185: error: `wmemset' not declared /usr/include/c++/3.3/cwchar:213: error: `wmemchr' not declared /usr/include/c++/3.3/cwchar: In function `wchar_t* std::wmemchr(wchar_t*, wchar_t, unsigned int)': /usr/include/c++/3.3/cwchar:217: error: invalid conversion from `const wchar_t* ' to `wchar_t*' /usr/include/c++/3.3/cwchar: At global scope: /usr/include/c++/3.3/cwchar:233: error: `wcstold' not declared /usr/include/c++/3.3/cwchar:242: error: `wcstoll' not declared /usr/include/c++/3.3/cwchar:243: error: `wcstoull' not declared /usr/include/c++/3.3/cwchar:249: error: `wcstold' not declared /usr/include/c++/3.3/cwchar:250: error: `wcstoll' not declared /usr/include/c++/3.3/cwchar:251: error: `wcstoull' not declared etc, etc, etc.... I send you my gcc configuration: gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.4 (Debian 1:3.3.4-4) Any suggestion? Thanks a lot for your help. -- ____________________________ ________ _______________________________ | Sergio Ojalvo \ \ / | | Senior System Analyst \ \/ To bring IN-OVATION turn to | | mailto:sergio@ximpo.com /\ \ your open source of solutions | | Phone: +972-545-558586 / \ \ | | Fax: +972-151-545-558586 -------- http://www.ximpo.com/ | |__________________________ Ximpo Group _____________________________|

3 4

Re: [D3D] Added native and emulated S3TC support
by Lionel Ulmer 29 Jul '04

29 Jul '04

I have just a few comments on the patch (yeah, it would not have been fun if I had commented on wine-d3d first :-) ). But anyway, great work ! > +static BOOL DDRAW_bind_to_s3tc( void ) > +{ > + const char *s3tcname = SONAME_LIBS3TC; > + > + s3tc_handle = wine_dlopen(s3tcname, RTLD_NOW, NULL, 0); > + if (!s3tc_handle) { > + printf("Wine cannot find the S3TC software decompression library (%s).\n",s3tcname); Why did you use 'printf' here instead of WARN or ERR ? Moreover, with this, we will print an error at DirectX loading when the users do not have this library installed ... even if the game does never request any compressed mode textures. Would it not be better to somehow print the error message when the application wants to create a DXTN texture (ie somehow remember that we do not support this feature and keep the error message for later). > + return FALSE; > + } > + > +#define API_FUNCTION(f) \ > + if((f = wine_dlsym(s3tc_handle, #f, NULL, 0)) == NULL) \ > + { \ > + printf("Can't find symbol %s\n", #f); \ Same printf comment here (but this one can be kept here :-) ). > + goto sym_not_found; \ > + } > + API_FUNCTION(fetch_2d_texel_rgba_dxt1); > + API_FUNCTION(fetch_2d_texel_rgba_dxt3); > + API_FUNCTION(fetch_2d_texel_rgba_dxt5); > +#undef API_FUNCTION > + > + return TRUE; > + > +sym_not_found: > + WARN("Wine cannot find functions that are necessary for S3TC decompression\n"); > + wine_dlclose(s3tc_handle, NULL, 0); > + s3tc_handle = NULL; > + return FALSE; > +} > + (...) > > + if (src_pf->dwFlags & DDPF_FOURCC) { > + GLenum retVal; > + int size = surf_ptr->surface_desc.u1.dwLinearSize; > + int width = surf_ptr->surface_desc.dwWidth; > + int height = surf_ptr->surface_desc.dwHeight; > + LPVOID buffer = surf_ptr->surface_desc.lpSurface; > + > + switch (src_pf->dwFourCC) { > + case MAKE_FOURCC('D','X','T','1'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT; break; > + case MAKE_FOURCC('D','X','T','3'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT; break; > + case MAKE_FOURCC('D','X','T','5'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT; break; > + default: > + FIXME("FourCC Not supported\n"); > + return DD_OK; > + break; > + } > + GL_extensions.glCompressedTexImage2D(GL_TEXTURE_2D, current_level, retVal, width, height, 0, size, buffer); How are we sure that this code will never be called with the 'glCompressedTexImage2D' unset ? I.e. when we are in emulation mode, what happens here ? Is this because when we are in emulation mode, we do not advertise support for DTXN textures, this means that the application can create such textures, but will be automagically converted to RGB ones at Loading ? Anyway, I would still prefer a test here to prevent crashes for application which do not behave well :-) (...) > + if (current_surface->surface_desc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) { > + GLint retVal; > + int size = current_surface->surface_desc.u1.dwLinearSize; > + int width_ = current_surface->surface_desc.dwWidth; > + int height_ = current_surface->surface_desc.dwHeight; > + LPVOID buffer = current_surface->surface_desc.lpSurface; > + > + switch (current_surface->surface_desc.u4.ddpfPixelFormat.dwFourCC) { > + case MAKE_FOURCC('D','X','T','1'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT; break; > + case MAKE_FOURCC('D','X','T','3'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT; break; > + case MAKE_FOURCC('D','X','T','5'): retVal = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT; break; > + default: > + FIXME("Not supported\n"); > + return DD_OK; > + break; > + } > + /* GL_extensions.glCompressedTexSubImage2D(GL_TEXTURE_2D, current_level, xoffset, yoffset, width, height, retVal, (unsigned char*)temp_buffer); */ > + GL_extensions.glCompressedTexImage2D(GL_TEXTURE_2D, current_level, retVal, width_, height_, 0, size, buffer); Same here. > + } > + > + if (strstr(glExtensions, "GL_EXT_texture_compression_s3tc")) { > + TRACE(" - S3TC compression supported\n"); > + GL_extensions.s3tc_compressed_texture = TRUE; > + GL_extensions.glCompressedTexImage2D = pglXGetProcAddressARB("glCompressedTexImage2D"); > + GL_extensions.glCompressedTexSubImage2D = pglXGetProcAddressARB("glCompressedTexSubImage2D"); > } If I were pedantic, you should test for 'GL_ARB_texture_compression' to be able to get the 'glCompressedTexImage2DARB' and 'glCompressedTexSubImage2DARB' functions (which may be better than using the non-ARB versions which are, AFAIK, the ones in GL 1.4). And then to get 'GL_EXT_texture_compression_s3tc' to set 'GL_extensions.s3tc_compressed_texture' to TRUE. But as 'GL_EXT_texture_compression_s3tc' depends on 'GL_ARB_texture_compression', I will let you do this shortcut :-) > - /* We do not support for now compressed texture formats... */ > - if (ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) > + /* We support for now only DXT1, DXT3 & DXT5 compressed texture formats... */ > + if ((ddsd.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && > + (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','1')) && > + (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','3')) && > + (ddsd.u4.ddpfPixelFormat.dwFourCC != MAKE_FOURCC('D','X','T','5')) ) > { > return DDERR_INVALIDPIXELFORMAT; > } What to do here when neither hardware nor emulated support is present ? Maybe we should print an error (cf previous comment) and return INVALIDPIXELFORMAT, no ? Lionel (who goes testing NOFL :-) ) -- Lionel Ulmer - http://www.bbrox.org/

3 5

Re: Fix crash in dsound test
by Robert Reif 29 Jul '04

29 Jul '04

How did this fail in windows. Since it doesn't crash with wine, wine is doing something wrong. Lets try to figure out what is wrong and correct wine to have the same behavior as windows or at least notify someone that something is wrong. Is anyone working on getting direct sound into the windows port of our regression tests? Francois Gouget wrote: > > Changelog: > > * dlls/dsound/tests/dsound.c > > Francois Gouget <fgouget(a)codeweavers.com> > Call IDirectSound::Initialize() as per MSDN before using the > DirectSound object. Fixes a crash on Windows. > >------------------------------------------------------------------------ > >Index: dlls/dsound/tests/dsound.c >=================================================================== >RCS file: /var/cvs/wine/dlls/dsound/tests/dsound.c,v >retrieving revision 1.24 >diff -u -r1.24 dsound.c >--- dlls/dsound/tests/dsound.c 13 Jul 2004 23:35:09 -0000 1.24 >+++ dlls/dsound/tests/dsound.c 16 Jul 2004 16:23:51 -0000 >@@ -69,6 +69,9 @@ > if (rc==DS_OK) > IDirectSound8_Release(ds8); > >+ rc=IDirectSound_Initialize(dso,NULL); >+ ok(rc==DS_OK,"IDirectSound_Initialize(NULL) failed: %s\n",DXGetErrorString9(rc)); >+ > /* DSOUND: Error: Invalid caps buffer */ > rc=IDirectSound_GetCaps(dso,0); > ok(rc==DSERR_INVALIDPARAM,"GetCaps should have failed: %s\n",DXGetErrorString9(rc)); >@@ -168,6 +171,9 @@ > if (rc==DS_OK) > IDirectSound8_Release(ds8); > >+ rc=IDirectSound8_Initialize(dso,NULL); >+ ok(rc==DS_OK,"IDirectSound_Initialize(NULL) failed: %s\n",DXGetErrorString9(rc)); >+ > /* DSOUND: Error: Invalid caps buffer */ > rc=IDirectSound8_GetCaps(dso,0); > ok(rc==DSERR_INVALIDPARAM,"GetCaps should have failed: %s\n",DXGetErrorString9(rc)); > >

5 7

Question about mmap issues on FreeBSD/NetBSD
by Yorick Hardy 29 Jul '04

29 Jul '04

Just a question about the mmap issues experienced on FreeBSD, i.e. http://www.winehq.org/?issue=230#Wine%20on%20FreeBSD I encountered the same on NetBSD. It seems the error message is set from ld.elf_so in NetBSD and ld-elf.so.1 in FreeBSD, when the address space is mapped for the run time linking? Since MAP_NORESERVE is not documented (and not supported?) for mmap on FreeBSD and NetBSD, it would appear that wine and the ld.elf_so together require too much memory for all the mmap calls. Am I correct? Kind regards, -- Yorick Hardy

2 1

Re: Is bugzilla worth keeping?
by Dan Kegel 29 Jul '04

29 Jul '04

Mike Hearn wrote: > So are we misleading users by having a bugzilla into thinking that if > they file a bug there, it'll be fixed when it probably won't? Not at all. Just because not enough people are doing bug triage or fixing doesn't mean we should drop bugzilla. Somebody will eventually go through the bug reports, I think. > If we were to simply drop bugzilla, how would it impact the project? It would deprive us of long-term memory. For instance, I filed the bug report http://bugs.winehq.org/show_bug.cgi?id=1404 in January 2003 with a nice test case (but one that's hard to translate into a unit test). Without Bugzilla, we'd have a harder time remembering problems like that. (Unless cxtest really takes off, I suppose...) - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 3

Re: winetests/winrash
by Rolf Kalbermatter 29 Jul '04

29 Jul '04

Chris Morgan <cmorgan(a)alum.wpi.edu> wrote: >I wouldn't mind adding a systray icon. I wasn't really sure how that was >supposed to be done. I tried having the service add a systray icon without >much success, I don't believe services can interact with the desktop. That >may mean that a separate winrash monitor may have to be written that >communicates with the service. Services can interact with the desktop but not by default. It is a special option you specify when installing the service. The magic for this is in the dwServiceType parameter of the CreateService() to register a service object in the system. >From MSDN: SERVICE_FILE_SYSTEM_DRIVER File system driver service. SERVICE_KERNEL_DRIVER Driver service. SERVICE_WIN32_OWN_PROCESS Service that runs in its own process. SERVICE_WIN32_SHARE_PROCESS Service that shares a process with one or more other services. For more information, see Service Programs. If you specify either SERVICE_WIN32_OWN_PROCESS or SERVICE_WIN32_SHARE_PROCESS, and the service is running in the context of the LocalSystem account, you can also specify the following type. Type Meaning SERVICE_INTERACTIVE_PROCESS The service can interact with the desktop. Not sure how winrash is currently installed but if it is not through a small Win32 setup app but an InstallShield app, I'm sure it has according parameters to let it install as interactive service Rolf Kalbermatter

2 1

Fwd: Re: rsabase.dll
by Michael Jung 29 Jul '04

29 Jul '04

I'm sorry, if this mail appears three times on the wine-devel list. I've sent it twice already, but it doesn't seem to get forwarded to the wine-devel list. Is there a problem with the mailing list? Rob, could you give me a short notificaton, if you have received those mails? Thank, Michael ---------- Forwarded Message ---------- Subject: Re: rsabase.dll Date: Tuesday 27 July 2004 10:08 From: Michael Jung <mjung(a)iss.tu-darmstadt.de> To: wine-devel(a)winehq.org Cc: rob(a)codeweavers.com Rob, > I think there are many reasons to favour "real handles": If a long running > process is using rsabase (e.g. a webserver serving https: requests) with > many temporary connections and many keys, resource leakage is an issue. > Furthermore, since rsabase is a cryptographic service provider, it might be > important that a key, which is not referenced anymore is in fact destroyed > (and the > corresponding memory be nulled). I would think that otherwise you will > over time accumulate a lot of keys in your address space, which is probably > a security problem. Now, I'm aware that wine is not in a state today to be > used for security critical applications and first rsabase implementations > will probably have security issues more severe than this. However, sometime > I think rsabase will have to use real handles. Why not right from the > start? I've thought about this statement again and realized that I'm wrong and that I probably misunderstood you. I realized that one doesn't need "real handles" in user mode code at all to implement correct resource management. And I think I understand that one does need them in the kernel (aka wineserver) for objects, which are accessed from multiple threads. However, there are some instances of "real handle" implementations outside wineserver in wine (e.g. dlls/msi/handle.c). Do you (or anybody else on the mailing list) now what for? Some things, which I could imagine would still be easier to implement correctly with "real handles", are the INVALID_HANDLE_VALUE value, checking that a thread does not access a resource via an already released handle and in general checking in a precise manner if a handle value is valid (which, as I understand it, is often done in wine with a magic value at the beginning of the object.) Greetings, Michael -- Michael Jung, MSc Be liberal in what you accept, Integrated Circuits and Systems Lab and conservative in what you send. University of Technology, Darmstadt -- Jonathan Postel, Internet Pioneer phone: +49(6151)16-6692 / email: mjung(a)iss.tu-darmstadt.de

1 0

Is bugzilla worth keeping?
by Mike Hearn 29 Jul '04

29 Jul '04

One thing I notice about most other open source projects is that they have many more flamewars than we do. So, I thought I'd start one: It strikes me, looking at the wine-bugs list, that there is a huge disparity between the number of people maintaining it and the number of people filing bugs in it. It seems to be quite rare for communication on bugfixes to take place there, wine-devel is the more usual forum. So are we misleading users by having a bugzilla into thinking that if they file a bug there, it'll be fixed when it probably won't? If so, does it matter? If we were to simply drop bugzilla, how would it impact the project? Thoughts, anybody? thanks -mike

10 10

winetests/winrash
by James Hawkins 29 Jul '04

29 Jul '04

What is it exactly that winrash does? Is it running winetests using the native libraries of the Windows operating system that the user is running the tests on, or are the wine libraries being tested through some means? Is there a site where this information is readily available? I have one suggestion: users typically like to see results when they volunteer their computer time to a project such as this, which is understandable, so a future version might benefit from a system tray icon that can be opened up to see the test running and/or display results of the tests that have been run. -- James Hawkins

2 1

How do we handle unicode (utf-8) codepages?
by Shachar Shemesh 29 Jul '04

29 Jul '04

What do we do if the user requests a Unicode codepage? I've just had a conversation with a user on IRC where I believe things didn't work for him because LANG was set to es_ES.UTF-8. On one hand, I don't think we can force ANSI applications to work in Unicode. On the other hand, we cannot change the locale - it will mean noone (whether ANSI or not) will not be able to access non-ASCII file names and files. Comments? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

2 1

Re: Re: WineHQ:service.cgi: fix winrash option
by chmorgan＠charter.net 28 Jul '04

28 Jul '04

Which errors are you referring to? The most frequent ones lately are the ones where the winetest package isn't available on the sourceforge osdn mirror. We are still asking people to download the tests from this location for particular test releases. I'd imagine the fix is simply to point the downloads at valid mirror for the file. Chris > > From: Ferenc Wagner <wferi(a)afavant.elte.hu> > Date: 2004/07/26 Mon AM 07:57:51 EDT > To: wine-devel(a)winehq.org > CC: <wine-patches(a)winehq.com>, <cmorgan(a)alum.WPI.EDU> > Subject: Re: WineHQ:service.cgi: fix winrash option > > <chmorgan(a)charter.net> writes: > > > What is the service doing with winrash options btw? The > > installer stops, installs and starts the winrash service. > > > > The installer uses /S for silent installs, otherwise it > > will try to popup windows. Are you sure the service isn't > > calling the installer with /S? > > You are right, I was wrong. This patch is rubbish. I can't > really understand the errors on wine-test-results. Have you > got an idea what may have gone wrong? Aren't any functional > winrash instances running? Is something broken in the > service script? The documentation is somewhat scarce so I'm > doing a slow start... > -- > Feri. > >

2 1

Re: DCOM: Fix Ref Counting in StdMarshalImpl_MarshalInterface
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > > Mike Hearn <mh(a)codeweavers.com> > Fix ref counting in StdMarshalImpl_MarshalInterface for case where the > stub already exists. > >Index: wine/dlls/ole32/compobj_private.h >=================================================================== >RCS file: /home/wine/wine/dlls/ole32/compobj_private.h,v >retrieving revision 1.14 > Oops. Wrong patch. Rob

1 0

Re: COM RPC: Fix Infinite Loop
by Robert Shearman 28 Jul '04

28 Jul '04

Robert Shearman wrote: > Changelog: > Fix for infinite loop that could occur if _invoke_onereq failed. Please don't apply this patch. I'll submit a better and more complete one in a minute. Rob

1 0

Non-working patch for 3GB of memory allocation
by Shachar Shemesh 28 Jul '04

28 Jul '04

Ok, this patch would probably not be appropriate even if it did work. The surprising thing, however, is that it doesn't. The idea was simple. We use mmap as usual until mmap starts to fail with no memory. When that happens, we switch to allocating memory with malloc, which allegably knows how to use "brk" in order to allocate memory from the lower 1GB area. The patch is against 20040716. The attached program tries to repeatedly allocate ~100MB, until it fails. It is compiled for advanced server (i.e. - it has 3GB of address space, but that's besides the point). When actually run (through strace), one can see the mmaps being carried out and successful, and then the mmap that fails (no memory). Then malloc is attempted, which tries mmap, then brk, and then mmap again. All fail. This is the point where I stop understanding. Does anyone have any explanation as to why malloc fails? Does wine prevent large scale use of the lower area due to some reason? Any ideas would be appreciated. Shachar ? runconfig ? dlls/ntdll/.virtual.c.swp Index: dlls/ntdll/virtual.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/virtual.c,v retrieving revision 1.37 diff -u -r1.37 virtual.c --- dlls/ntdll/virtual.c 22 Jun 2004 03:02:35 -0000 1.37 +++ dlls/ntdll/virtual.c 26 Jul 2004 13:53:41 -0000 @@ -78,6 +78,7 @@ /* Per-view flags */ #define VFLAG_SYSTEM 0x01 /* system view (underlying mmap not under our control) */ #define VFLAG_VALLOC 0x02 /* allocated by VirtualAlloc */ +#define VFLAG_MALLOC 0x04 /* allocated using malloc */ /* Conversion from VPROT_* to Win32 flags */ static const BYTE VIRTUAL_Win32Flags[16] = @@ -168,9 +169,13 @@ DPRINTF( "View: %p - %p", addr, addr + view->size - 1 ); if (view->flags & VFLAG_SYSTEM) DPRINTF( " (system)\n" ); - else if (view->flags & VFLAG_VALLOC) - DPRINTF( " (valloc)\n" ); - else if (view->mapping) + else if (view->flags & VFLAG_VALLOC) { + DPRINTF( " (valloc" ); + if (view->flags & VFLAG_MALLOC) + DPRINTF( " using malloc)\n" ); + else + DPRINTF( ")\n" ); + } else if (view->mapping) DPRINTF( " %p\n", view->mapping ); else DPRINTF( " (anonymous)\n"); @@ -348,7 +353,12 @@ */ static void delete_view( struct file_view *view ) /* [in] View */ { - if (!(view->flags & VFLAG_SYSTEM)) unmap_area( view->base, view->size ); + if (!(view->flags & VFLAG_SYSTEM)) { + if( !(view->flags & VFLAG_MALLOC) ) + unmap_area( view->base, view->size ); + else + free( view->base ); + } list_remove( &view->entry ); if (view->mapping) NtClose( view->mapping ); free( view ); @@ -559,6 +569,7 @@ { void *ptr; NTSTATUS status; + int used_malloc=0; if (base) { @@ -602,7 +613,19 @@ { if ((ptr = wine_anon_mmap( NULL, view_size, VIRTUAL_GetUnixProt(vprot), 0 )) == (void *)-1) { - if (errno == ENOMEM) return STATUS_NO_MEMORY; + if (errno == ENOMEM) + { + /* mmap allocation failed. Let's see if we can try malloc, and whether it is going to be more lucky */ + FIXME("About to try malloc\n"); + if( /* Unix protection is not malloc compatible, or */ (ptr = malloc( size ))!=NULL ) + { + used_malloc=1; + goto memory_allocated; + } else { + FIXME("malloc failed\n"); + return STATUS_NO_MEMORY; + } + } return STATUS_INVALID_PARAMETER; } /* if we got something beyond the user limit, unmap it and retry */ @@ -623,8 +646,17 @@ munmap( (char *)ptr + size, view_size - size ); } +memory_allocated: status = create_view( view_ret, ptr, size, vprot ); - if (status != STATUS_SUCCESS) unmap_area( ptr, size ); + if( used_malloc && status==STATUS_SUCCESS ) + (*view_ret)->flags|=VFLAG_MALLOC; + else if (status != STATUS_SUCCESS) + { + if( !used_malloc ) + unmap_area( ptr, size ); + else + free( ptr ); + } return status; }

2 6

delayed unloading of .so in WINE
by Santosh Siddheshwar 28 Jul '04

28 Jul '04

Hi, Is there any way to specify in config file or any other place, a way to prevent/delay a shared object from being unloaded till the application using it terminates? In dlopen there is a flag RTLD_NODELETE which keeps the loaded shared object in memory even after dlclose is called. The shared object is unloaded only when the app exits. Do we have some way to do this in WINE? Or does any feature in Windows necessitate implementing this kind of behaviour in WINE? I can think of VC++ linker flags /DELAYLOAD and /DELAY:unload which might need the use of such mechanism. Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

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