July 2004 - Wine-Devel - list.winehq.org

Re: Bug in menu.c

by Dmitry Timoshkov

"Dan Timis" <timis(a)museresearch.com> wrote: > 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. Please create a patch and send it to wine-patches. If you could write a test case that would be even better. -- Dmitry.

July 30, 2004

Re: WineHQ:service.cgi: fix winrash option

by Hans Leidekker

On Friday 30 July 2004 05:48, Robert Reif wrote: > Unfortunately someone must have copied my mistake and placed them in the > mingw dxguid.lib. So wine's code is now correct for wine and Windows but Well, not by mistake. I'm maintaining a version of MinGW (at http://mirzam.it.vu.nl/mingw) with a number of patches thrown in to make cross building Wine tests and dlls work. Adding missing guids was one of those patches. I could remove that one but Wine (dxsound) has progressed so much lately that more patching is needed for MinGW (it's w32api part, to be precise). These problems are bound to occur more often and although the proper solution seems to be to fix MinGW, reality has it that MinGW won't accept some of our patches. Now that we have our own SDK package on sourceforge, wine-w32api, I am contemplating using that instead of mingw-w32api, along with mingw-gcc and mingw-binutils. That would help us with issues like these but at the same time we would lose testing Wine builds with third-party headers and import libs, which turns up Wine bugs every once and a while. -Hans

July 30, 2004

Re: Question about mmap issues on FreeBSD/NetBSD

by Yorick Hardy

Thanks for the response. I must be doing something wrong, since wine-kthread gave the same error. Anything I may have missed? I copied wine-kthread from loader/wine-kthread. It does not appear to be correct, but is there any chance madvise(..., MADV_DONTNEED) could help? Also in libs/wine/mmap.c line 119 the result of mincore is never tested, should it not be if ( (mincore( (caddr_t)addr + i, pagesize, &vec ) != -1) && (vec&1) ) (with a slight variation for FreeBSD), although I think this will not resolve the current problem. >You need MAP_NORESERVE support otherwise we can't control the address >space correctly (unless you have a ton of virtual memory): if you run >wine-kthread directly it should still work though unless you have >execshield type address space randomisation active. > >On Thu, 29 Jul 2004 09:13:25 +0200, Yorick Hardy wrote: >> 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. Kind regards, -- Yorick Hardy

July 30, 2004

Re: RPCRT4_NdrClientCall2 stub (fixme)?

by Jeroen Janssen

Filip Navara wrote: > 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. Since I'm trying to run an application that is in the need of NdrClientCall2, I can probably do some tests with it (but I don't know what types are being used in it). I'm wondering when is a patch 'good enough' to be included? (both from an 'enduser', an author's point of view and from Alexandre's view (who eventually commits the patch)? Is there an official way to track that a patch submitted to wine-patches has been comitted? Also can I somehow find out which (interesting) patches have not been comitted yet? Also, I noticed there is currently only one person with CVS write permissions for Wine? Has this always been the case? --- Jeroen

July 30, 2004

for whoever maintinas winrash

by Ivan Leo Puoti

We've had the following complaints on wine-users. > I installed this on a windows 98se box. I can't say I like having the DOS > window open all the time (it's ugly). Can this not be written as a windows > programme, and sit in the system tray? > > Also, during the installation process, after I entered my email address, the > installer removed what it called 'invalid characters' - i.e., underscores. >All my main email addresses contain underscores, so I was forced to enter an > old one that is not very reliable. Ivan.

July 30, 2004

Re: cleanup a->w cross calls in advapi32/crypt.c

by Dmitry Timoshkov

"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.

July 30, 2004

Re: Wine and locales

by Alexandre Julliard

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > "Alexandre Julliard" <julliard(a)winehq.org> wrote: > >> > FindResourceA >> > FindResourceExA >> >> These ones have been well tested already. > > I don't see the tests for them in the CVS, especially part about LANGID > preference order. There's no automated test, because it's a bit tricky to switch locales under Windows since not all locales may be supported on a given install. I can assure you that it has been tested and that the behavior is correct (modulo UI language as mentioned already). >> I see no reason to revert the patch. It's going to make no difference >> for 99% of our users, and for the remaining 1% it's about as likely to >> fix things as it is to break them. > > OK, in the worst case perhaps I will need to send a custom version > of kernel32 with the patch reverted to the affected cxoffice users. If they really have configured LC_CTYPE in a way that breaks things, I would suggest to them to fix it instead, this way it will also fix their Unix setup. Now, if you really know of a case where there is a legitimate reason for someone to have an LC_CTYPE setup that breaks Wine, then of course that would be a good argument against the patch. -- Alexandre Julliard julliard(a)winehq.org

July 30, 2004

Re: WineHQ:service.cgi: fix winrash option

by Robert Reif

Kevin Koltzau wrote: >On Thursday 29 July 2004 05:10 am, Ferenc Wagner wrote: > > >>since I included dsound into winetest you don't seem to >>publish any more winetest versions on Sourceforge. Have you >>got problems compiling the dsound tests? Can you cope? >> >> > >multiple definition of `CLSID_DirectSoundPrivate' >multiple definition of `DSPROPSETID_DirectSoundDevice' > >I don't think I'll have time to check into this at least until next week > > > > These were included in dxguid.lib by me by mistake. They are not included in Windows dxguid.lib so I removed them and fixed the code in wine to define them. The wine dsound tests will now compile on Windows with a Microsoft compiler and libraries. Unfortunately someone must have copied my mistake and placed them in the mingw dxguid.lib. So wine's code is now correct for wine and Windows but mingw's dxguid.lib is causing the problem. We could revert my patch or add a mingw check in the code but the proper way is to fix mingw's dxguid.lib. I'm sorry the tests are broken. They have been very helpful to me in getting winmm more compatible and I would really like to see the same thing happen to dsound.

July 30, 2004

Re: WineHQ:service.cgi: fix winrash option

by Kevin Koltzau

On Thursday 29 July 2004 05:10 am, Ferenc Wagner wrote: > since I included dsound into winetest you don't seem to > publish any more winetest versions on Sourceforge. Have you > got problems compiling the dsound tests? Can you cope? multiple definition of `CLSID_DirectSoundPrivate' multiple definition of `DSPROPSETID_DirectSoundDevice' I don't think I'll have time to check into this at least until next week

July 30, 2004

Re: WineHQ:service.cgi: fix winrash option

by Kevin Koltzau

On Thursday 29 July 2004 02:26 am, Shachar Shemesh wrote: > Actually, running a gentoo mirror myself (il1.rsync.gentoo.org) the way > gentoo handles the mirrors is to sync the distro several days in advance > with permissions preventing anyone (except us :-D ) from getting it, and > then rsyncing just the permission change. > > This allows more or less simultaneous release on all mirrors. That's true for published ebuilds, but for an ebuild not yet in portage, or before the sync is complete, the method I described is what is used

July 30, 2004