- Wine-Devel - list.winehq.org

Re: FreeType autoconf checks
by Ian Pilcher June 4, 2001

June 4, 2001

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 June 4, 2001

June 4, 2001

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 June 4, 2001

June 4, 2001

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 June 4, 2001

June 4, 2001

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 June 4, 2001

June 4, 2001

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 June 4, 2001

June 4, 2001

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 June 3, 2001

June 3, 2001

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 June 3, 2001

June 3, 2001

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 June 3, 2001

June 3, 2001

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 June 3, 2001

June 3, 2001

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