- Wine-devel - list.winehq.org

Re: move 16bit COMM code to USER
by lawson_whitney＠juno.com 25 Jul '01

25 Jul '01

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 25 Jul '01

25 Jul '01

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 25 Jul '01

25 Jul '01

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 24 Jul '01

24 Jul '01

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 24 Jul '01

24 Jul '01

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 24 Jul '01

24 Jul '01

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 23 Jul '01

23 Jul '01

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

Re: Executable permissions on .exe/.com files
by Alexandre Julliard 23 Jul '01

23 Jul '01

Bernhard Rosenkraenzer <bero(a)redhat.de> writes: > Since some people will probably want to use BINFMT_MISC or similar > functionality to run wine transparently, I think we need the possibility > to set executable permissions on wine-generated (e.g. by "wine setup.exe") > .exe/.com files. > > This patch implements this (optionally - new configure switch). I have applied it, but without the configure switch. I think it should be OK to always set the permissions, and if it turns out to cause trouble we should add a run-time option, not a compile-time one. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: implement BuildCommDCB16 using BuildCommDCB
by lawson_whitney＠juno.com 23 Jul '01

23 Jul '01

On Mon, 23 Jul 2001 16:59:35 +1000 Mike McCormack <mike_mccormack(a)start.com.au> writes: > This is a multi-part message in MIME format > > ------=_NextPart_000_80675836 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > > This (untested) patch completes the COMM16 code seperation. The > COMM16 > code can now be moved into USER (i think). > > Mike Juno 1.49 finds no fault with this, but AFAICS from a comm trace, the app doesn't use the DCB functions, so this is not such a conclusive test. Anybody else have any 16 bit comms apps? Lawson ---oof--- > ChangeLog: > rewrite BuildCommDCB16 to depend on BuildCommDCB, not vice-versa > ________________________________________________________________ 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

Still problems with snoop
by Uwe Bonnes 23 Jul '01

23 Jul '01

Hallo, some days ago I reported early crashes when running with the snoop debug option. E.g. vc98 msedv.exe is a good example. Running with "+snoop" crashes early. Running with "-snoop=devshl" lets the program succeed much further. Running without snoop gets even substancial further. So I think there must be something wrong with snoop. I tried to look hard at relay32/snoop.c, but didn't see anything fishy. So perhaps somebody else has some idea what's going wrong. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2