wine-devel

wine-devel@winehq.org

12 participants
84463 discussions

Qusetion From New Developer
by Uhmmmm 11 May '01

11 May '01

I've been using WINE for a while now, and I thought it was just about time to start helping out. I found some very easy things I can fix (a lot of the FIXMEs in the basic controls (botton, static, etc)). The only problem is that, I'm not sure how to submit the code once I've fixed it. If someone could let me know, I could start coding. Thanks in advance.

3 2

__compar_fn_t Linuxism in dlls/wineps/afm.c
by Gerald Pfeifer 11 May '01

11 May '01

I believe relying on __compar_fn_t in dlls/wineps/afm.c is a Linuxism recently added to dlls/wineps/afm.c (and only there), Ian. Given that __compar_fn_t is only used in that single file and nowhere else, I'd suggest to simply use a typedef of your own instead of the non-portable __compar_fn_t. -- Could you please have a look? Alexandre, in the mean-time please consider my patch below, which gets rid of the build failure at least. /usr/bin/gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o afm.o afm.c afm.c: In function `SortFontMetrics': afm.c:686: `__compar_fn_t' undeclared (first use in this function) afm.c:686: (Each undeclared identifier is reported only once afm.c:686: for each function it appears in.) afm.c:686: syntax error before `UnicodeGlyphByNameIndex' afm.c:698: syntax error before `UnicodeGlyphByNameIndex' afm.c:718: syntax error before `UnicodeGlyphByUV' afm.c:729: syntax error before `AFMMetricsByUV' afm.c:691: warning: `pug' might be used uninitialized in this function afm.c: At top level: afm.c:644: warning: `UnicodeGlyphByNameIndex' defined but not used afm.c:649: warning: `UnicodeGlyphByUV' defined but not used afm.c:654: warning: `AFMMetricsByUV' defined but not used gmake[2]: *** [afm.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/vexpert/files8/test/wine/dlls/wineps' gmake[1]: *** [wineps/libwineps.so] Error 2 Thanks, Gerald Index: afm.c =================================================================== RCS file: /home/wine/wine/dlls/wineps/afm.c,v retrieving revision 1.13 diff -u -3 -p -r1.13 afm.c --- afm.c 2001/05/09 17:11:59 1.13 +++ afm.c 2001/05/11 10:58:58 @@ -683,7 +683,7 @@ static BOOL SortFontMetrics() qsort(aglCopy, PSDRV_AdobeGlyphList.size, sizeof(UNICODEGLYPH), - (__compar_fn_t)UnicodeGlyphByNameIndex); + UnicodeGlyphByNameIndex); } for (i = 0; i < afm->NumofMetrics; ++i) @@ -695,7 +695,7 @@ static BOOL SortFontMetrics() pug = bsearch(&ug, aglCopy, PSDRV_AdobeGlyphList.size, sizeof(UNICODEGLYPH), - (__compar_fn_t)UnicodeGlyphByNameIndex); + UnicodeGlyphByNameIndex); if (pug == NULL) { WARN("Glyph '%s' in font '%s' does not have a UV\n", @@ -715,7 +715,7 @@ static BOOL SortFontMetrics() /* typecast avoids compiler warning */ qsort((void *)(afm->Encoding->glyphs), afm->Encoding->size, - sizeof(UNICODEGLYPH), (__compar_fn_t)UnicodeGlyphByUV); + sizeof(UNICODEGLYPH), UnicodeGlyphByUV); for (i = 0; i < afm->Encoding->size; ++i) if (afm->Encoding->glyphs[i].UV >= 0) @@ -726,7 +726,7 @@ static BOOL SortFontMetrics() } qsort(afm->Metrics, afm->NumofMetrics, sizeof(AFMMETRICS), - (__compar_fn_t)AFMMetricsByUV); + AFMMetricsByUV); for (i = 0; i < afm->NumofMetrics; ++i) if (afm->Metrics[i].UV >= 0)

3 2

Wine Logo ?
by Marcus Meissner 11 May '01

11 May '01

Hi, Is the WINE Logo as used by WineHQ available somewhere in higher resolution? I need it for preparation of LinuxTag 2001 :) Ciao, Marcus

1 0

win32 binary DLLs -> Unix wrappers?
by Peter Duthie 11 May '01

11 May '01

What I would like to do is take an existing windows DLL for which I have the SDK but not the source, and write/generate a C++ wrapper that accesses the code contained therein, and be linked with existing unix programs. Eg, say I have X.DLL, X.LIB and X.h Is there a way using wine that I can generate wrapper code (say X_wrapper.cc), so that I can link it with a unix program that I would write around the wrapper? Thus I would have the benefits of developing under the unix environment and libraries, while utilising a necessary proprietary windows DLL. Note, native windows applications that use this DLL work fine when run under wine regularly. I cannot find documentation for this in the mailing list archives, or the official docs, although Chapter 5 of the winelib users guide seems to be the right place to look, it appears to not be written yet. Can anyone please direct me to relevant documentation/examples/code? Thanks, -peter

3 2

Re: Add support for NOMINMAX
by Alexandre Julliard 11 May '01

11 May '01

Francois Gouget <fgouget(a)free.fr> writes: > Why? It doesn't make a big difference but after all, if min/max are > defined in their own header, why not take advantage of it to avoid > duplication? (I hate duplicating code :-) Because that's not how Windows does it. And I think it's a good thing to avoid unnecessary dependencies between the Windows headers and the MSVC ones. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Add support for NOMINMAX
by Francois Gouget 11 May '01

11 May '01

I noticed that you didn't apply this part of the minmax patch: --- cut here --- Index: include/windef.h =================================================================== RCS file: /home/cvs/wine/wine/include/windef.h,v retrieving revision 1.57 diff -u -r1.57 windef.h --- include/windef.h 2001/05/07 20:14:00 1.57 +++ include/windef.h 2001/05/11 01:17:37 @@ -14,6 +14,9 @@ #define WINVER 0x0500 #include "winnt.h" +#ifndef NOMINMAX +#include "minmax.h" +#endif #ifdef __cplusplus @@ -140,15 +143,6 @@ #define ADD_LOWORD(dw,val) ((dw) = ((dw) & 0xffff0000) | LOWORD((DWORD)(dw)+(val))) #endif -/* min and max macros */ -#ifndef NOMINMAX -#ifndef max -#define max(a,b) (((a) > (b)) ? (a) : (b)) -#endif -#ifndef min -#define min(a,b) (((a) < (b)) ? (a) : (b)) -#endif -#endif /* NOMINMAX */ #ifndef _MAX_PATH /* FIXME: These are supposed to be in stdlib.h only */ --- cut here --- Why? It doesn't make a big difference but after all, if min/max are defined in their own header, why not take advantage of it to avoid duplication? (I hate duplicating code :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...

1 0

[PATCH] Small SetParent fix
by gerard patel 10 May '01

10 May '01

Calling SetParent of a child window does not create a X counterpart in current Cvs if parent = 0. Fixes one at least of the 2 crashes I had pointed to with the User patch of 24 april. ChangeLog: * dlls/x11drv/window.c creates (again) a X counterpart for children windows reparented to 0

1 0

Re: GDB remote debugging
by Alexandre Julliard 10 May '01

10 May '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > I assume Alexandre isn't going to like some of the stuff in here, but I > suppose it's up to him whether to take it or leave it... How did you guess I wouldn't like it? ;-) Actually I think it's a neat hack, but it doesn't belong in the server at all. You should be able to do the same thing as a client-side process using the Win32 debugging API. It could be either a stand-alone Winelib app, or a special mode inside winedbg so that you can reuse some of the code in there. -- Alexandre Julliard julliard(a)winehq.com

3 2

Small Fixes
by kenon＠go2.pl 10 May '01

10 May '01

Hi, I had some problems with application Super Memo 8.0 . It is an old 16-bit app ( hard for debugging :-) ) written in Borland Delphi (I guess). I wrote a patch and posted to wine-patches two months ago ,but that patch was rejected :-( . Now I have much simpler and I think correct patch solving the problem. --- windows/painting.c_or Wed Mar 28 16:39:17 2001 +++ windows/painting.c Sat May 5 14:19:43 2001 @@ -1710,7 +1710,7 @@ { /* send palette change notification */ HWND hWnd = WindowFromDC( hDC ); - if (hWnd) SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); + if (hWnd) PostMessageA( HWND_BROADCAST, WM_PALETTECHANGED, hWnd, 0L); } return realized; } There is another bug. When I press <ENTER> the app runs in other way under wine than it runs under Windoze. My workaround ( only workaround ) is --- controls/edit.c_or Thu May 10 03:24:06 2001 +++ controls/edit.c Thu May 10 03:24:10 2001 @@ -849,7 +849,7 @@ case WM_GETDLGCODE: DPRINTF_EDIT_MSG32("WM_GETDLGCODE"); - result = DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS; + result = DLGC_HASSETSEL | DLGC_WANTCHARS | DLGC_WANTARROWS |DLGC_WANTMESSAGE; if (lParam && (((LPMSG)lParam)->message == WM_KEYDOWN)) { --

1 0

Is the DECIMAL variant type too long ?
by gerard patel 10 May '01

10 May '01

After the following patch : ChangeSet ID: 989259340138108821120113 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard@wine2. 01/05/07 14:15:40 Modified files: include : oleauto.h wtypes.h include/wine : obj_base.h obj_oleaut.h Log message: Francois Gouget <fgouget(a)codeweavers.com> Added support for the DECIMAL type. Names are no longer suffixed with 32! Removed it. Borland Builder 4 crashes while starting :-/ Tracing the crash shows that it hangs immediately after the *first* variant Api access : Call oleaut32.VariantCopyInd(405869b0,40586974) ret=405b2e6b tid=08065a10 trace:ole:VariantCopyInd (0x405869b0, 0x40586974) trace:ole:VariantCopy (0x405869b0, 0x40586974) trace:ole:VariantClear (0x405869b0) Ret oleaut32.VariantCopyInd() retval=00000000 ret=405b2e6b tid=08065a10 Call oleaut32.VariantChangeTypeEx(40586968,405869b0,00000400,00000000,00000003) ret=405b301c tid=08065a10 trace:ole:VariantInit (0x4058685c),stub trace:ole:VariantChangeTypeEx (0x40586968, 0x405869b0 (11), 1024, 0, 3),stub trace:ole:VariantClear (0x40586968) trace:ole:VarI4FromBool ( -1, 0x40586970 ), stub trace:ole:VariantClear (0x4058685c) Ret oleaut32.VariantChangeTypeEx() retval=00000000 ret=405b301c tid=08065a10 err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception. I have changed the trace slightly, the 11 listed for the VariantChangeTypeEx shows that the original type is a boolean. The call is trying to change a boolean (11) into an integer (3). The changes in include/wtypes.h are the important ones. Replacing the new DECIMAL type by typedef struct tagDEC { BYTE aa[2]; } DECIMAL; get rid of the crash. If I make the byte array 16 bytes long, same crash as the current Wine behaviour. If I make it 10 bytes long, access violation. If I make it 8 bytes long, it works too. Could the DECIMAL type be a pointer to the real data ?? Gerard

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