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
========================================================================
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
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'
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 !
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 );
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@+3$[#0H@(" @
M:68@*'!E<F9E8W0@/3T@+3$I#0H@(" @>PT*"4A+15D@:&ME>3L-"@EC:&%R
M(&)U9F9E<ELR,%T[#0H)+RH@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@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@8G5F9F5R6S!=.PT*
M(" @(" @(" @(" @(" @('!E<F9E8W0@/2 H8V@@/3T@)WDG('Q\(&-H(#T]
M("=9)R!\?"!C:" ]/2 G="<@?'P@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
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
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.
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 ----------
