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

Re: Pango for BiDi

by Mike Hearn

On Sat, 2004-07-03 at 11:47 +0300, Shachar Shemesh wrote: > No, that won't solve the problem. For a package to be included in > Debian, for example, it needs to be reconstructible by doing "apt-get > source wine; apt-get build-dep wine" To be frank I think that's Debians problem, or to more accurate the problem of those who insist on using apt-get for everything. If WineHQ provides high quality tested binaries with ICU included, they can use that if they want BiDi. There will *always* be random distros that have packaging policy that conflicts with Wine, I don't think we should let that dictate our choice of libraries. If we switch to FriBiDi maybe that fixes the Debian case but breaks the Mandrake case, or whatever. thanks -mike

July 3, 2004

Assertion in dlls/ntdll/loader.c

by Jon Griffiths

Hi, I'm experimenting with native vs builtin comctl32 for an app and whenever I set this dll to native I hit this assert in init_system_dir(): assert( mod->Flags & LDR_WINE_INTERNAL ); This happens on a 2.6 and a 2.4 system. I suspect its not related to comctl32 per-se, but merely loading a native dll at all (since this is the only native dll I'm using). Using all builtins does not hit this assert. I don't really grok what this function is doing, but commenting it out allows the app the start up with no ill efects. Any ideas? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

July 3, 2004

Re: Pango for BiDi

by Shachar Shemesh

Jonathan Wilson wrote: >> Maybe we can get our supplied packages to be BiDi enabled, but so >> long as we use ICU, and ICU has this horrible linking policy, we >> can't really > > What linking policy? > > I checked the IBM ICU website (http://oss.software.ibm.com/icu/ and > specifically > http://oss.software.ibm.com/cvs/icu/~checkout~/icu/license.html and it > appears to be under the X11 licence which is GPL compatible. > > IANAL but unless there is something I missed, I see no reason why > debian couldnt include ICU (and hence WINE with ICU support) in the > debian package system. > The problem is not a legal one. The problem is a technological one. ICU is mangling the library's version into the symbols, making it impossible to dynamically link the library. As a result, most distros don't carry ICU as a package. Shachar

July 3, 2004

Re: [wine] Re: Fw: [Mono-list] System.Windows.Forms plans.

by Shachar Shemesh

David Lee Lambert wrote: > The smaller said native-interaction API is, the easier it will be to > >keep stable. > > > But aside from init and loading a library, what else do we need? Shachar

July 3, 2004

Re: Pango for BiDi

by Shachar Shemesh

Mike Hearn wrote: >OK. Well, that can be solved by WineHQ providing high quality binary >packages that work anywhere. When I get around to this (maybe in a few >months) I'll let you know and you can kick me if I get ICU >integration wrong :) > >thanks -mike > > No, that won't solve the problem. For a package to be included in Debian, for example, it needs to be reconstructible by doing "apt-get source wine; apt-get build-dep wine", and then simply CDing into the proper directory and running the build script. If there is no half-way modern ICU version in Debian, Ove can't really build wine with BiDi. Maybe we can get our supplied packages to be BiDi enabled, but so long as we use ICU, and ICU has this horrible linking policy, we can't really get it wide-spread. Since I want it widespread, fribidi is where I'm headed. Shachar

July 3, 2004

Re: [wine] Re: IE6 installation error. would you please give me a suggession

by David Lee Lambert

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jul 02, 2004 at 12:42:02PM -0400, Andrei Barbu wrote: > Can't the wine installer chmod a-w all of those right when it sets > things up? This won't work if the WINDOWS\\SYSTEM directory is on a VFAT partition. > > solution is to this. Maybe preventing the Wine FS code writing to symlinks > > if they are inside the windows directory or something equally hackish - - or > > just ensuring that the exe.so files are always readonly. > It'd solve the problem more elegantly than having to add extra code that > might break other programs. It might be simplest to simply reinstall Wine after installing IE. Or, if we can get Wine to run the native REGSRVR32.EXE with no trouble, it shouldn't be a problem when the Wine version gets overwritten with the native version. Someone who wants a Microsoft-free installation won't install IE anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA5meJkeetBuAdnkIRAspQAJ9ua13goN8NnhRGlzK4eqjSKPfNAACgpllS 15rpfMNwCTvauB61uUpGEOA= =aDxt -----END PGP SIGNATURE----- -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

July 3, 2004

Re: [wine] Re: Fw: [Mono-list] System.Windows.Forms plans.

by David Lee Lambert

On Fri, Jul 02, 2004 at 10:48:57PM +0800, Jonathan Wilson wrote: > Bascily, there should be 3 sorts of APIs exported in WINE. ... > and 3.external WINE apis. There should be a limited set of special APIs > which are made available to enable projects like mono and others wanting to > interact with win32 code and/or the windows API implementation in WINE. > These should be specificly documented and made stable (as in, we wont > changer the prototype and we wont change the basic idea of what these > functions do). In other words, what Wine needs is not so much a stable API as a stable meta-API to determine what is actually supported. > For example, ... > If these were made stable, then apps that use them could be gauranteed that > things wont break. Then, the only thing they need versioning for is to > identify if a certain windows API is present or not. If it is, > WineGetProcAddress (or whatever it is) will return an appropriate address. > If its not, it would return an arror and you could work around it. (which > may mean prompting the user to upgrade WINE). The smaller said native-interaction API is, the easier it will be to keep stable. -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

July 3, 2004

Re: collation tables

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)altlinux.ru> wrote: > > Could you post a couple of examples what exactly differences > > do you observe? And what hacks do you propose? > There is attached the sorted (ordered) symbols from codepage > cp1251. I get it from output 3.c program runned in win2003, wine > and wine with collate from crossover. Yes, there are some difference, but I wouldn't call them fatal. All national characters are sorted correctly. If 1C does a binary sort using lstrcmpA and does comparisons with hard coded results then it's a really broken app. In order to "fix" the app we have to patch the whole unicode range, not just cyrillic char map. > I guess do hack for 8bit stpcmp functions (non-Unicode) for > cp1251 only. I'm afraid that hack could not be accepted under any circumstances for inclusion into the Wine tree. My guess is that we have to maintain collation weights for the whole unicode range (or at least some unicode ranges) on our own, and base a patch for unicode.org collation tables on that. That's a huge and very tedious work, I know that, since I'm the author of the collation table patch in Crossover. -- Dmitry.

July 3, 2004

Re: collation tables

by Vitaly Lipatov

On Friday 02 July 2004 18:08, Dmitry Timoshkov wrote: > "Vitaly Lipatov" <lav(a)altlinux.ru> wrote: > > I guess I can resolve it only for cp1251 encoding... It will > > hack, in no universal way... :( > > Could you post a couple of examples what exactly differences > do you observe? And what hacks do you propose? There is attached the sorted (ordered) symbols from codepage cp1251. I get it from output 3.c program runned in win2003, wine and wine with collate from crossover. I guess do hack for 8bit stpcmp functions (non-Unicode) for cp1251 only. -- Lav Vitaly Lipatov Saint-Petersburg GNU! ALT Linux Team! LaTeX! LyX!

July 2, 2004

Re: taskmgs hangs on edit debug channels

by Eric Pouech

> Any ideas? > I'm not quite versed enough in wine to know what's happening too well. I > realise it's a thread waiting for another that apparently never > finishes.. or I think it is, and I'm kind of lost from there. that's (another) bug in dbghelp. fix should be sent RSN to wine-patches A+

July 2, 2004