- Wine-Devel - list.winehq.org

CallWindowProc syntax
by Marco Bizzarri July 25, 2001

July 25, 2001

Hi all. While looking at the source code of wine, I looked into the synopsys of the CallWindowProc function. According to winproc.c, the hWnd parameter should be the handle to the window which has to receive the message. OTOH, if you look at MSDN, at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/hh/w… it looks like the hWnd is the windows procedure which should receive the message. Can anyone help? Thanks Marco Bizzarri m.bizzarri(a)icube.it

1 0

Re: Make built-in font data read-only
by Alexandre Julliard July 25, 2001

July 25, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > If all pointers have to be eliminated, I can't see any way to do it. > In order for the code to have any kind of sanity, built-in font metrics > and dynamically loaded font metrics have to use the same data model, and > I don't think it's even remotely practical to get rid of the pointers in > the case of the dynamically loaded metrics. Well, if it's not feasible so be it. But if it's at all possible I think it's worth some reasonable amount of trouble. > I'm open to suggestions, but I think that the effort involved in doing > this (assuming a sane way could be found) probably far outweighs the > benefit (less swap usage if the data is paged out; is there any other > benefit?). The main benefit is sharing between processes; so if you have 10 processes that want to print you only have one copy of the font data in memory. Plus it gets loaded on-demand so data that isn't used doesn't need to be loaded from disk at all. > Just in case I get inspired, though, what tool/command are you using to > determine read-only vs. read/write data sizes? Can I just go by what > objdump says about .data and .rodata? objdump is fine yes. size works too, though I seem to remember some versions not counting .rodata correctly. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Make built-in font data read-only
by Alexandre Julliard July 25, 2001

July 25, 2001

Ian Pilcher <ian.pilcher(a)home.com> writes: > Log message: > Ian Pilcher <ian.pilcher(a)home.com> > WINEPS: make built-in font data read-only Unfortunately the data still isn't stored in read-only memory even though it is declared const, because the structures contain pointers that require relocation. Would it be possible to store offsets instead of pointers? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: move 16bit COMM code to USER
by lawson_whitney＠juno.com July 25, 2001

July 25, 2001

On Tue, 24 Jul 2001 11:11:05 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_83577347 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > This patch completes the seperation of the 16bit COMM code from > KERNEL > and moves it to USER. Seems to work with Terminal from WFW 3.11. > > Mike If you get this, it seems to work for juno 1.49 too. Lawson ---oof--- > ChangeLog: > move 16-bit COMM code to USER dll > > ________________________________________________________________ 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

Microsoft source code releases - a danger to Wine?
by Ian Pilcher July 24, 2001

July 24, 2001

According to Slashdot, Microsoft has released the Windows CE source code under one of their "shared source" licenses. Needless to say, it would be an *extremely* bad idea for anyone associated with the Wine project to look at it. This leads me to wonder if anyone's ever thought of taking steps to protect Wine from "contamination" by Microsoft IP (legally, not tech- nically :-). As the number of programmers who have been exposed to MS source code grows the chances of this happening will increase. I believe that the FSF uses some type of form/statement before they will accept code, and it seems like the nature of this project would make it particularly beneficial. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================

5 6

Re: oleaut32 patch
by Alexandre Julliard July 24, 2001

July 24, 2001

Andreas Mohr <a.mohr(a)mailto.de> writes: > - changes OaBuildVersion() to always return a very high version value > (2.xx.0xffff), which can be overridden in the config file to deliver > an exact value instead Do we really need such an obscure parameter in the main config file? Are there actual cases where setting the version based on -winver is not enough? -- Alexandre Julliard julliard(a)winehq.com

1 0

Compile error, Please help!!!!!Thanks
by EriK W July 24, 2001

July 24, 2001

Hi gurus, Please help me out with the fatal compiling problem. I am using soalris8 x86 with wine-20010629, Any suggestion would be highly appreciated! /usr/openwin/include/X11/Xutil.h:56: warning: ignoring pragma: "@(#)Xutil.h 1.2 00/07/05 SMI gcc -Wl,-G -Wl,-h,/usr/local/lib/libwine_tsx11.so locking.o ts_xf86dga.o ts_xf86dga2.o ts_xf86vmode.o ts_xshm.o ts_xlib.o ts_xresource.o ts_xvideo.o ts_xutil.o ts_shape.o ts_xpm.o -o libwine_tsx11.so.1.0 rm -f libwine_tsx11.so && ln -s libwine_tsx11.so.1.0 libwine_tsx11.so LD_LIBRARY_PATH="../../unicode:$LD_LIBRARY_PATH" ../../tools/winebuild/winebuild -fPIC -L../../dlls -o ntdll.spec.c -spec ./ntdll.spec ld.so.1: ../../tools/winebuild/winebuild: fatal: /usr/local/lib/libwine_unicode.so: open failed: No such file or directory *** Error code 137 make: Fatal error: Command failed for target `ntdll.spec.c' Current working directory /export/home/ericw/system/wine-20010629/dlls/ntdll *** Error code 1 make: Fatal error: Command failed for target `ntdll/libntdll.so' Current working directory /export/home/ericw/system/wine-20010629/dlls *** Error code 1 make: Fatal error: Command failed for target `dlls'

1 0

Re: Function declaration fixes
by Francois Gouget July 23, 2001

July 23, 2001

On Mon, 23 Jul 2001, Patrik Stridvall wrote: [...] > *** declarations > > * dlls/msvcrt/cpp.c, > dlls/msvcrt/exit.c, > dlls/msvcrt/mbcs.c, > dlls/msvcrt/msvcrt.h, > dlls/ntdll/signal_i386.c, > dlls/shell32/shlmenu.c, > include/wine/undocshell.h: > - Made sure that the files that contains the declarations > of the implementated functions are included. > - Corrected mismatching prototypes. > - Cleaned up the include section. You should not add a prototype for MSVCRT_isleadbyte and MSVCRT_realloc in wine/dlls/msvcrt/msvcrt.h. These are declared in include/msvcrt/wctype.h and include/msvcrt/malloc.h respectively. The correct fix is to include these headers where needed. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !

1 0

[PROBLEM REPORT] Edit control line scrolling
by Gerard Patel July 23, 2001

July 23, 2001

With programs using a multiline edit control, such as Notepad (I'm using Win3.11 version) or Eudora Light 1.5 with mails from the 'In' mailbox (this is a 32 bits application), scrolling down the edit buffer line by line mostly does not work. In fact, it works only if the edit buffer size is an exact multiple of the line height. In all other cases, the format rectangle is smaller than the client size, and when the edit control tries to redraw the last line, the update rectangle is wrong : only the lower part of the line is drawn. I think that this problem can be traced to the replacement of code in ScrollWindowEx by the call to ScrollDC. What is happening is that the client rectangle is scrolled, but the client rectangle is bigger than the formatting rectangle by a few pixels; these pixels are missing in the update region. In Wine previous version, the client rectangle was first ANDed with the so-called 'visible region' (hvisRgn), so the result was not bigger than the format rectangle before being scrolled, then diff-ed with it. The following patch works around this problem. I don't have time to investigate further as I am taking one week of holidays :-) but if someone is interested in the edit control.... Gerard Index: dlls/x11drv/scroll.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/scroll.c,v retrieving revision 1.2 diff -u -r1.2 scroll.c --- dlls/x11drv/scroll.c 2001/06/20 00:18:48 1.2 +++ dlls/x11drv/scroll.c 2001/07/22 22:12:06 @@ -114,7 +114,7 @@ hrgn2 = CreateRectRgnIndirect( &rect ); if (hrgn) SetRectRgn( hrgn, rClip.left, rClip.top, rClip.right, rClip.bottom ); else hrgn = CreateRectRgn( rClip.left, rClip.top, rClip.right, rClip.bottom ); - CombineRgn( hrgn, hrgn, hrgn2, RGN_AND ); + CombineRgn( hrgn2, hrgn, hrgn2, RGN_AND ); OffsetRgn( hrgn2, dx, dy ); CombineRgn( hrgn, hrgn, hrgn2, RGN_DIFF );

2 1

Why is this wrong?
by Bill Medland July 23, 2001

July 23, 2001

The code of "perfect_graphics" (attached) gives my system problems. The visible aspect of the problem is that the text in our application's listview doesn't get drawn properly. By experimentation I have narrowed it down to when perfect_graphics was edited. I observe that our application works correctly under the two following cases: 1. When the body of the function is removed and the value is hard-coded to true 2. When the "inline" is removed (which is the fix I am proposing and will submit in a moment) Since I do not like working without understanding I would like to know: Is there something wrong with the use of "inline" in this context? Or is there clearly something wrong with my build environment? Or is everyone else as confused by it as me? TIA Bill begin 600 e1 M+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ#0H@*B @(" @(" @(" @<&5R M9F5C=%]G<F%P:&EC<PT*("H-"B J($9A=F]R(&-O<G)E8W1N97-S(&]R('-P M965D/PT*("HO#0IS=&%T:6,@:6YL:6YE(&EN="!P97)F96-T7V=R87!H:6-S M*'9O:60I#0I[#0H@(" @<W1A=&EC(&EN="!P97)F96-T(#T(a)+3$[#0H@(" @ M:68@*'!E<F9E8W0@/3T(a)+3$I#0H@(" @>PT*"4A+15D@:&ME>3L-"@EC:&%R M(&)U9F9E<ELR,%T[#0H)+RH(a)9&5F875L="!V86QU92 J+PT*"7!E<F9E8W0@ M/2 P.PT*"6EF*"%296=/<&5N2V5Y02A(2T597TQ/0T%,7TU!0TA)3D4L(")3 M;V9T=V%R95Q<5VEN95Q<5VEN95Q<0V]N9FEG7%QX,3%D<G8B+" F:&ME>2DI M#0H)>PT*"2 @("!$5T]21"!T>7!E+"!C;W5N=" ]('-I>F5O9BAB=69F97(I M.PT*"2 @("!I9B(a)A4F5G475E<GE686QU945X02AH:V5Y+" B4&5R9F5C=$=R M87!H:6-S(BP@,"P@)G1Y<&4L(&)U9F9E<BP@)F-O=6YT*2D-"B @(" @(" @ M(" @('L-"B @(" @(" @(" @(" @("!C:&%R(&-H(#T(a)8G5F9F5R6S!=.PT* M(" @(" @(" @(" @(" @('!E<F9E8W0@/2 H8V@@/3T@)WDG('Q\(&-H(#T] M("=9)R!\?"!C:" ]/2 G="<@?'P(a)8V@@/3T@)U0G('Q\(&-H(#T]("<Q)RD[ M#0H@(" @(" @(" @("!]#0H)(" @(%)E9T-L;W-E2V5Y*&AK97DI.PT*"7T- @"B @("!]#0H@(" @<F5T=7)N('!E<F9E8W0[#0I]#0IY ` end

1 0