September 2007 - Wine-Devel

Re: [PATCH] [2/2] winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUse

by Peter Oberndorfer

On Wednesday 26 September 2007, Peter Oberndorfer wrote: > --- > dlls/winhttp/main.c | 25 +++++++++++++++++++++++++ > dlls/winhttp/winhttp.spec | 2 +- > 2 files changed, 26 insertions(+), 1 deletions(-) > There is a 'r' missing in the patch title. it should be: winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUser Greetings Peter

Sept. 26, 2007

Re: Total bidi regression

by Shachar Shemesh

Maarten Lankhorst wrote: > > If you want it back try replacing this in font.c: > WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR > change FORCE to LOOSE, it should work then. > I'm not sure what you are suggesting. WINE_GCPW_FORCE_RTL only appear on line 1089 of bidi.c, which reads: > case WINE_GCPW_FORCE_RTL: forcedir = R; baselevel = 1; break; I'm not sure what you are suggesting I do with it. Either way, the change you are suggesting will only affect (if I understand the code correctly) the paragraph direction setting, where as I'm experiencing total lack of BiDi reordering of any kind. All codes taken from latest git. > Cheers, > Maarten > Thanks, Shachar

Sept. 26, 2007

Re: [PATCH 2/2] configure: Build wine-kthread on FreeBSD.

by Tijl Coosemans

On Wednesday 26 September 2007 19:24:24 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.

Sept. 26, 2007

Re: [PATCH 1/2] loader: Reduce data segment size in wine-pthread/kthread on FreeBSD.

by Tijl Coosemans

On Wednesday 26 September 2007 19:17:44 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.

Sept. 26, 2007

Re: [5/5] WineD3D: Add sincos support to arb shaders

by H. Verbeet

On 26/09/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* dst.w = src[0].w * 1 / (src.x^2 + src.y^2 + src.z^2)^(1/2) according to msdn*/ That comment looks a bit out of place for sincos. Copy-paste from nrm?

Sept. 26, 2007

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size (try 2)

by Alexandre Julliard

a_villacis(a)palosanto.com writes: > I considered doing this at first, but ME_ToCF2W is used in three other > places beside handling EM_SETCHARFORMAT (all in style.c), and those places > might get a null-pointer exception instead of an assert if something went > wrong. A null-pointer exception serves the same purpose as an assert, and they both result in a debugger backtrace, so there's no reason to add more asserts here. -- Alexandre Julliard julliard(a)winehq.org

Sept. 26, 2007

address space layout

by Tijl Coosemans

Hi all! I had a user running FreeBSD 6.2, Xorg 7.3, ATI r200 DRI driver report a problem where running Warcraft3 crashed because it ran out of malloc heap space. The error was: Assertion failed: (texObj->DriverData != NULL), function r200BindTexture, file r200_tex.c, line 1098. fixme:ntdll:FILE_GetNtStatus Converting errno 12 to STATUS_UNSUCCESSFUL This error happens inside the r200 driver, errno 12 means ENOMEM. There was a bug report with a patch over at http://bugs.freedesktop.org/show_bug.cgi?id=12184 The patch gets rid of the assertion failure by doing proper error checking, but it doesn't solve the underlying problem of course, causing a NULL pointer dereference in Wine somewhat later: wine: Unhandled page fault on read access to 0x00000058 at address 0x7e99cc84 (thread 0009), starting debugger... This isn't the first time such a problem appears, especially with games, so ultimately a solution has to be found. The problem is that the way Wine wants to setup the address space is really somewhat incompatible with the way FreeBSD mmap and malloc work. FreeBSD mmap allocates from the end of a process data segment upwards towards the stack. Linux mmap allocates from the stack downwards. FreeBSD (<7.x) malloc doesn't fall back to mmap when it runs out of space in the data segment. Linux malloc does (I've been told). Because the wine process loads itself at 0x7bf00000, this means on FreeBSD with mmap going up, both the data segment and all shared objects (like builtin dlls) sit squeezed between that address and 0x80000000 since addresses above 0x80000000 can't be used for builtin dlls. It's about 64Mb which is currently split 50/50 between heap space and shared objects. This works in a lot of cases, but sometimes a 32Mb heap isn't enough like in the example above, where I assume it's been taken up by textures and other graphics data. Linux doesn't have this problem because mmap allocates shared objects from 0x80000000 downwards and can go beyond the address where wine is loaded if necessary. It can allocate extra heap space this way too when needed. Alexandre and I discussed this a couple weeks ago, but didn't really come up with anything. The problem back then (WoW) has since gone away (turned out to be a memory leak somewhere) so everything was left the way it was. Now it has turned up again however with a different program on a different setup, so it's something that really needs to be looked at. It could again be a memory leak in some other project's code, but then that just means the current situation isn't robust enough to deal with that, since it all does work on Linux. It appears that the only solution is to locate wine somewhere after 0x80000000 instead of at 0x7bf00000 and to allow mmap to allocate memory there. Then the data segment size limit can be set to 256Mb or something instead of 32Mb. The problem is then that builtin dlls are mmapped (by the runtime linker) well beyond 0x80000000. Now I'm thinking, would it be possible to load dummy dlls somewhere in the first 2Gb of address space? Through which API calls can a program determine a dll is above 0x80000000 by the way?

Sept. 26, 2007

Re: Total bidi regression

by Maarten Lankhorst

Shachar Shemesh schreef: > Hi Maarten, > > It seems that since your last changes to the Bidi implementation, BiDi > suffered total regression. At least on my system, no BiDi related text > (neither Hebrew nor Arabic) gets reordered, at all. Placing breakpoints > suggest that BIDI_Reorder is still getting called, so I can only assume > that the problem is somewhere inside it (or in the classification) > > I haven't traced inside to see where things went wrong, nor do I know > whether your work on that matter is done. I just wanted to point out > that Wine, at the moment, performs no BiDi at all as far as the user is > concerned. > > Shachar > If you want it back try replacing this in font.c: WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR change FORCE to LOOSE, it should work then. Cheers, Maarten

Sept. 26, 2007

Re: Cannot compile wine due to recent changes

by Chris Robinson

Hi. Thanks, I sent a patch to wine-patches which should fix this. If anyone has an older version of XOrg with XComposite and can verify there's no other missing functions, that'd be great.

Sept. 26, 2007

Total bidi regression

by Shachar Shemesh

Hi Maarten, It seems that since your last changes to the Bidi implementation, BiDi suffered total regression. At least on my system, no BiDi related text (neither Hebrew nor Arabic) gets reordered, at all. Placing breakpoints suggest that BIDI_Reorder is still getting called, so I can only assume that the problem is somewhere inside it (or in the classification) I haven't traced inside to see where things went wrong, nor do I know whether your work on that matter is done. I just wanted to point out that Wine, at the moment, performs no BiDi at all as far as the user is concerned. Shachar

Sept. 26, 2007