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

Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT

by Phil Krylov

On Fri, 24 Feb 2006 10:48:47 -0800 Lei Zhang <leiz(a)ucla.edu> wrote: > On Friday 24 February 2006 04:39 am, Phil Krylov wrote: > > On Fri, 24 Feb 2006 12:24:45 +0100 > > > > Alexandre Julliard <julliard(a)winehq.org> wrote: > > > Phil Krylov <phil(a)newstar.rinet.ru> writes: > > > > On Tue, 21 Feb 2006 14:08:38 -0800 > > > > > > > > Lei Zhang <leiz(a)ucla.edu> wrote: > > > >> Hi Phil, > > > >> > > > >> Ya, it's a typo. Thanks for catching it. > > > > > > > > Could you kindly fix it then? As this patch was accepted unfixed. > > > > > > I accepted the patch because I don't see how pCurItem could be NULL > > > in that loop (or rather, it could be NULL, but in that case we'll > > > crash before coming back to the loop test). Am I missing something? > > > > Yes, you're right. It can't be NULL because of an earlier test: > > > > para->member.para.nCharOfs + item->member.run.nCharOfs + nEnd - nLen > > >= nMin > > > > But this is very inevident. > > > > -- Ph. > > Hi Phil, Alex > > Yes, it can become NULL, here's how: > > Inside while (ME_CharCompare(pCurItem->.... ) > the last if() block assigns a new value to pCurItem, which may be NULL. It may but it won't... ME_FindItemBack(pCurItem) will return NULL only if pCurItem is the first text run in the document. But the if() condition (nCurEnd - nMatched == 0) is TRUE only if the search string is longer than nCurEnd. This does not happen for the first document run because of the condition of the exterior loop which checks if we have enough characters for comparison. --Ph.

Feb. 24, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Kuba Ober

> To be strictly, there is no needs in rpath using if libwine placed in > standard place as /usr/lib > > I got follow broken requires when build rpm package: > > /usr/bin/../lib/libwine.so.1(WINE_1.0) > /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) Is that an error during building of the rpm, or during installing it? Could you post the exact message and the .spec file used to build it? I reckon there's other software out there that does the same thing and somehow rpm handles it fine . . . Interesting. Kuba

Feb. 24, 2006

Re: riched20: Implements FR_MATCHCASE for EM_FINDTEXT

by Lei Zhang

On Friday 24 February 2006 04:39 am, Phil Krylov wrote: > On Fri, 24 Feb 2006 12:24:45 +0100 > > Alexandre Julliard <julliard(a)winehq.org> wrote: > > Phil Krylov <phil(a)newstar.rinet.ru> writes: > > > On Tue, 21 Feb 2006 14:08:38 -0800 > > > > > > Lei Zhang <leiz(a)ucla.edu> wrote: > > >> Hi Phil, > > >> > > >> Ya, it's a typo. Thanks for catching it. > > > > > > Could you kindly fix it then? As this patch was accepted unfixed. > > > > I accepted the patch because I don't see how pCurItem could be NULL > > in that loop (or rather, it could be NULL, but in that case we'll > > crash before coming back to the loop test). Am I missing something? > > Yes, you're right. It can't be NULL because of an earlier test: > > para->member.para.nCharOfs + item->member.run.nCharOfs + nEnd - nLen > >= nMin > > But this is very inevident. > > -- Ph. Hi Phil, Alex Yes, it can become NULL, here's how: Inside while (ME_CharCompare(pCurItem->.... ) the last if() block assigns a new value to pCurItem, which may be NULL. Sorry I didn't patch this earlier, I'll do it today. - Lei

Feb. 24, 2006

Re: Debugging

by Stefan Dösinger

Hi, > As such, I'm looking for a little advice on debugging issues when apps > don't work (yes, I've read what's on winehq.) I have the application > KeePass (keepass.sourceforge.net) which installs just fine. When I go to > run it, it just drops me right back to the prompt. Pardon my ignorance, but why don't you use the Linux version instead? http://keepass.sourceforge.net/download.php lists a Linux port. If you have the necessary tools to compile keepass, you can build the Win32 version from source and put a few debugging printfs into it, to see where it stops. This could shorten the debug time greatly. (Of course this doesn't work for apps where the source isn't available)

Feb. 24, 2006

Re: Palm Desktop conduits through Wine?

by Stefan Dösinger

Am Freitag, 24. Februar 2006 04:29 schrieb Rich Gilson: > Has there every been any luck/attempts at running Palm Desktop conduits > through wine? I'd drop Palm Desktop altogether, but I have Documents-To-Go > and Passwords Plus, which both only run through Palm Desktop. You can write a sort of Palm Desktop replacement, which loads the conduit dlls and offers the Palm Desktop API to them. The calls can be forwarded to a Linux app, e.g. pilot-link. This way you can replace Palm Desktop by pilot-link + a Winelib app which links the conduit and pilot-link. I think such a program/lib would be out of Wine's scope, as Palm Desktop isn't a part of Windows, instead it would belong more to pilot-link. I've played with this idea some time ago, but I dropped it because of a lack of time. Palm Desktop sort of works in Wine. You can't run the Palm.exe app, but hotsync works. USB doesn't work, but you can do a network sync. Configure your palm to sync with 127.0.0.1, tell hotsync to listen to that port, and start pi-nredir(part of pilot-link) to forward the USB connection to the network. Installing Palm Desktop is not easy, because you need to install MSIE 6. Documents-To-Go needed a native Microsoft Installer the last time I installed it. This was a few months ago, so this is most likely not true today. (If you search the mailing list archives, you'll find a more detailed description) Syncing works quite good, the biggest problem I found was that DocsToGo doesn't support the OpenOffice formats, so I had to convert all documents to the MS Office format and vice versa. The ultimate solution would be a replacement for the DocsToGo application which understands OpenDocument. Or to ask DataViz for a Linux converter ;)

Feb. 24, 2006

Re: Prepare the unicodification of advpack.dll

by Francois Gouget

On Fri, 24 Feb 2006, James Hawkins wrote: > On 2/24/06, Francois Gouget <fgouget(a)free.fr> wrote: >> >> All functions that manipulate strings should have an Ansi and a >> Unicode variant. > > Does it matter that native advpack only has Ansi functions? That's changing in the latest Windows PSDK. Hence the patch... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

Feb. 24, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > To be strictly, there is no needs in rpath using if libwine placed in standard > place as /usr/lib > > I got follow broken requires when build rpm package: > > /usr/bin/../lib/libwine.so.1(WINE_1.0) > /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) > > and find any methods to disable new feature with rpath when I build package. It sounds like rpm needs a good whack on the head if it is unable to cope with this. Anyway, you could always build with make LDEXERPATH="". -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Vitaly Lipatov

В сообщении от 24 февраля 2006 20:53 Alexandre Julliard написал(a): > Vitaly Lipatov <lav(a)etersoft.ru> writes: > > We need a --disable-rpath option in configure for rpath disable. > > Rpaths is not useful when WINE building for distribution. > > Why is it not useful? Sorry for my English. It is useful when we run wine from the source tree. To be strictly, there is no needs in rpath using if libwine placed in standard place as /usr/lib I got follow broken requires when build rpm package: /usr/bin/../lib/libwine.so.1(WINE_1.0) /usr/bin/../lib/libwine_unicode.so.1(WINE_1.0) and find any methods to disable new feature with rpath when I build package. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

Feb. 24, 2006

Re: Problem with virtual memory rlimits

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > If you limit the virtual memory size using "ulimit -v 1400000" for > instance, wine will only crash. > > The problem is, that VIRTUAL_alloc_teb() tries to allocate a memory > area within the acceptable userspace ... but it does so much mmap()s > that it runs out of available mmap space before. > > I was only able to reproduce this on AMD64 machines up to now, > which pass out memory starting from 0xf7fffffff somewhere. > > Any clue how to solve this? I don't think you can. We are using MAP_NORESERVE, which could be argued should not count against the limit, but if it does then we need a limit high enough to reserve everything above 0x80000000. -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > We need a --disable-rpath option in configure for rpath disable. > Rpaths is not useful when WINE building for distribution. Why is it not useful? -- Alexandre Julliard julliard(a)winehq.org

Feb. 24, 2006