wine-devel

wine-devel@winehq.org

84463 discussions

stack limit
by Stephen Crowley 04 Jun '01

04 Jun '01

What is the correct way to increase the default stack size for winelib applications? Also, are there any drawbacks to making the value fairly large? -- Stephen Crowley Software Engineer Placemark Investments 972.404.8100 x28

2 1

Re: stack limit
by Alexandre Julliard 04 Jun '01

04 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > What is the proper way to increase the stack size for winelib > applications? There seems to be a limit of around 2^20 bytes right now. There is no way to do this at the moment; but it shouldn't be too hard to add support for a 'stack' statement in the application spec file. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: fixup bogus SetLastError()
by Alexandre Julliard 04 Jun '01

04 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > Now that's where I disagree ! > The caller can *not* always set it to another value. > If it does and the program intends to read the LastError of a *previously* > executed API that failed, then the LastError will be reset even though > it shouldn't have been ! Then the caller needs to save/restore it across the GDI_GetObjPtr call. That's trivial to do. > In short: the SetLastError behaviour needs to match Windows behaviour very, > very closely. Definitely; but it's not clear to me that not setting last error is anywhere closer to Windows than setting it to INVALID_HANDLE. GDI_GetObjPtr should do what most callers need, and IMO this means setting it. I may be wrong, I haven't checked the error returns of all GDI functions (and of course this is nowhere documented). > This would be SelectObject() in this case, BTW. Which case? Do you have evidence that a SelectObject() with an invalid handle must not set last error? If so then of course it needs fixing. -- Alexandre Julliard julliard(a)winehq.com

2 1

stack limit
by Stephen Crowley 04 Jun '01

04 Jun '01

What is the proper way to increase the stack size for winelib applications? There seems to be a limit of around 2^20 bytes right now. -- Stephen Crowley Software Engineer Placemark Investments 972.404.8100 x28

1 0

tan not exported by msvcrt, ntdll
by Francois Gouget 04 Jun '01

04 Jun '01

I tried compiling Winelib applications without '-lm' (btw, the comment in configure.in is incorrect, it concerns Linux too, not just BeOS). But I had undefined symbol errors for applications that use tan and a couple other math functions. The reason is that both ntdll and msvcrt declare them with '-noimport': * msvcrt.spec: @ forward -noimport tan ntdll.tan * ntdll.spec: @ cdecl -noimport tan(double) tan So a Winelib application that imports msvcrt and ntdll does not get tan and thus must link with libm in the Unix sense. sin, cos and most others were ok though! Changelog: * dlls/msvcrt/msvcrt.spec Remove some '-noimport' for math functions -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

AnimateWindow() calls SetWindowPos() on a timer???
by Bobby Bingham 04 Jun '01

04 Jun '01

Forgot a detail ... Every time it send the messages it tells it not to move, size, redraw, activate, or change z-order. I could see the reason for these if if didn't tell it not to do anything, but ... ?? Bobby Bingham uhmmmm(a)ameritech.net

1 0

AnimateWindow() calls SetWindowPos() on a timer???
by Bobby Bingham 04 Jun '01

04 Jun '01

I am implementing AnimateWindow(), and I recorded all the messages win98 sent to my window when I called AnimateWindow(). It send a lot of groups of WM_WINDOWPOSCHANGING, WM_NCCALCSIZE, and WM_WINDOWPOSCHANGED. The number of times it sends these seems to correspond to how long I tell it to make the animation, almost as if it were on a timer. It looks like it calls SetWindowPos() on the window a lot, but I don't see why they would do this. Does anyone know?? I can supply my test app once I clean it up a little. Bobby Bingham uhmmmm(a)ameritech.net

1 0

off topic: Windows 98 and binutils
by Brian Craft 03 Jun '01

03 Jun '01

Hey -- Sorry for the OT post, but I suspect someone here will know the answer to this. I'm trying to objdump some Windows 98 device drivers & dlls. Last time I did something like this it was user-mode code from 95 or NT (not sure which), and I just configured binutils for i386-pe. Only this same configuration won't read the Windows 98 files -- it says the file format isn't recognised. I can still read the old Windows binaries with this config. I also tried i386-msdos, for good measure. What's the scoop? 98 has a new format? Is there a binutils target that will do the job? b.c.

2 1

Re: PATCH: set_thread_buffer fixed
by Gerard Patel 03 Jun '01

03 Jun '01

At 07:19 PM 02/06/2001 +0200, you wrote: <snip> >I have now changed config.h to only enable 64bit support for glibc 2.2 >or better. After applying your patch to current cvs, rm config.cache, ./configure, make depend && make Wine crashes as before. Did you leave something to for Alexandre Julliard implicit (he certainly knows about this stuff, I don't) ? I don't understand why _FILE_OFFSET_BITS is still defined in config.h.in. Gerard

3 2

Re: PATCH: set_thread_buffer fixed
by Alexandre Julliard 03 Jun '01

03 Jun '01

Marcus Meissner <marcus(a)jet.franken.de> writes: > Enable 64bit file operations on Linux only for glibc 2.2 or better, > since mmap64 is broken on glibc 2.1. It would be much better to do a configure check. Including features.h from config.h is very ugly IMO (not to mention that mmap64 seems to work fine on my glibc 2.1.3...) -- Alexandre Julliard julliard(a)winehq.com

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