wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Re: PATCH: set_thread_buffer fixed
by lawson_whitney＠juno.com 05 Jun '01

05 Jun '01

On Sun, 3 Jun 2001, Marcus Meissner wrote: > Is this the case where set_thread_buffer fails or not? > Okay, it is not. It crashes in debug_printf or dump_exports (pe_image.c). However, it is so too a glibc-2.1.3 problem. I think. Sort of. The same Wine that crashes with kernel 2.4.4 and 2.4.5 works fine with kernel 2.2.14, and I bet later 2.2.x kernels when (if) I get around to building them. I think I might not be smart enough to debug it in detail. Maybe I should just send www4mail after glibc-2.2 instead. > I don't see a failure message here. > > Also, could you try to run the attached test program and see if it fails? success with either kernel version. Hmmm, do I have 2.0.30 still lying around? 1.3.18? > > Ciao, Marcus > Lawson Constants aren't, and variables won't. ---cut--- ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: FreeType autoconf checks
by Alexandre Julliard 04 Jun '01

04 Jun '01

Ian Pilcher <ian.pilcher(a)home.com> writes: > One thing to keep in mind, however. The FreeType headers themselves > use relative paths to include one another, so this is an issue that > we're not going to be able to completely eliminate. This is why I > had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER > tries to preprocess the header file, so it has to be able to find any > subsidiary headers. (Is this what you mean by finding a way to check > that #include <freetype/freetype.h> works?) Yes; we should be using only relative paths in AC_CHECK_HEADER, since this is what we will use in the code. I don't think C_INCLUDE_PATH is portable either. Did you try setting CPPFLAGS instead? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: FreeType autoconf checks
by Ian Pilcher 04 Jun '01

04 Jun '01

Alexandre Julliard wrote: > > Well, I don't like it much, but I haven't had time to look into a > better solution yet. Basically I think it's dangerous to check for the > file name with an absolute path and then include it with a relative > path, since there is no guarantee we'll get the same file. I think we > should really find a way to check that #include <freetype/freetype.h> > works given the right C flags. Also I'm not sure about the portability > of the ${FREETYPEINCL#-I} construct. > I see your point. Now that I think about it, I probably would have been bitten by it if anyone will. I run Red Hat 7.1 which has: /usr/include/freetype/freetype.h (from FreeType 1.x) /usr/include/freetype2/freetype/freetype.h (from FreeType 2.x) I just checked the gcc documentation, and directories specified with '-I' options on the command line are checked first. I have no idea, however, if other compilers behave in a similar manner. Using absolute paths for the FreeType headers would be non-trivial, but probably doable. We would have to use autoconf to define macros that include the complete path name of the headers we want to include; then #include those macros instead of the file names. Somehow, I don't think you're going to want to do that. One thing to keep in mind, however. The FreeType headers themselves use relative paths to include one another, so this is an issue that we're not going to be able to completely eliminate. This is why I had to mess around with the C_INCLUDE_PATH variable; AC_CHECK_HEADER tries to preprocess the header file, so it has to be able to find any subsidiary headers. (Is this what you mean by finding a way to check that #include <freetype/freetype.h> works?) I also had the same thought about the ${FREETYPEINCL#-I} construct. According to http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html#tag_001_006_002 it seems to be OK. Frankly, I share your distaste for this whole mess. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

1 0

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

04 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > objects/gdiobj.c really has no business dealing with SetLastError(). > SetLastError() is a mechanism to communicate errors to external programs, > so it should definitely not be used for highly internal functions. You didn't include the gdiobj.c patch, but I disagree with it anyway... There can be many good reasons for setting last error in internal functions; for instance setting it inside GDI_GetObjPtr avoids having to set it in every single caller. And in the very rare case where this is not what we want, the caller can always set it to another value. -- Alexandre Julliard julliard(a)winehq.com

3 2

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

Jump to page:

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