- Wine-Devel - list.winehq.org

Patches for several bugs
by Sander van Leeuwen Dec. 26, 2001

Dec. 26, 2001

Hi, Here are the bug fixes I promised. There are more, but I can post those at a later time. - controls\button.c CB_Paint, line 806 hBrush = SendMessageW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); if (!hBrush) /* did the app forget to call defwindowproc ? */ hBrush = DefWindowProcW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); -> (Auto)Check, (Auto)Radio & (Auto)3State buttons send WM_CTLCOLORSTATIC instead of WM_CTLCOLORBTN (verified in NT4) (fixes opening dialog buttons in Opera 6 (choose interface)) - dll\user32\text.c TEXT_GrayString, line 499 if(!hdc) { DeleteDC(memdc); return FALSE; } -> DC leak - COMCTL32: Comboex, rebar, tooltips, toolbar: NEVER delete the font object received by WM_SETFONT -> See attached diff files for comboex, rebar & toolbar. Our tooltips has too many differences for diff to produce usable output, but the changes are similar to the other three. - COMCTL32: Tooltips: wrong COMCTL32_Free calls -> 4 calls with wrong pointer: COMCTL32_Free(&lpttsi); should be COMCTL32_Free(lpttsi); - user32: frame tracking * - Only draw changed track frame instead of clearing the old one and * drawing the new one (less flickering) * - Send WM_MOVING when moving a window * - Send WM_SIZING only when sizing a window * - Fixed handling of rectangles changed by WM_SIZING/MOVING -> Can't easily produce diff file. Too many changes. (check src\user32\wintrack.cpp in our CVS tree) - USER32: groupbox redrawing fixes -> I am not 100% sure the same happens in Wine, but it looks like that. When an application changes the font or the text of a groupbox (smaller font or fewer characters), then the old text has to be erase properly or else you'll still see part of it. If I remember correctly, that could be seen in Opera 5.12 (property dialogs) -> Again, too many changes to produce a diff file. (check src\user32\button.cpp, BUTTON_SetText & BUTTON_SetFont) - USER32: static control -> our version supports more styles (SS_CENTERIMAGE, SS_REALSIZEIMAGE) and features (SS_ENHMETAFILE) (src\user32\static.cpp) Sander

1 0

Re: DOS packing patch (fix)
by Lionel Ulmer Dec. 25, 2001

Dec. 25, 2001

Hi all, I am a bit worried by this patch : I looked at how "pshpack1.h" works, and it uses the '#pragma pack(1)' method when compiling with GCC. > +/* WARNING: one byte packed structs from here !! (i.e. not DWORD aligned) */ > +#include "pshpack1.h" > + And I wonder if this really works as with the latest versions of GCC (2.95.3 onwards AFAIK), '#pragma pack(1)' is ignored (at least on my self-compiled GCC :-) ) and you need to use the '__attribute((__packed__))' construction after each structure. But well, I may say completely stupid things as otherwise a lot of bugs would exist in Wine... Lionel PS: Merry Christmas all :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

16 bit comm issue
by Mike McCormack Dec. 24, 2001

Dec. 24, 2001

Hi, There's a problem with the current 16bit comm architecture which i'm not sure how to solve correctly. If a 16bit Windows programs uses EnableCommNotification to receive WM_COMMNOTIFY messages then sits in a message loop waiting for them, it will never receive them because there is no chance for APC that sends the message (COMM16_ReadComplete) to run. I have a patch for this problem which puts an alertable wait in GetMessage(16), which i posted in October. What is the problem with this method, and is there a better solution to the problem? Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

DOS stuff pretty much broken [Re: wine/ dlls/kernel/kernel_main.c dlls/kernel/wp ...]
by Andreas Mohr Dec. 24, 2001

Dec. 24, 2001

On Tue, Dec 04, 2001 at 02:54:50PM -0500, Alexandre Julliard wrote: > ChangeSet ID: 1007495689308334133587778 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine2. 01/12/04 14:54:50 > > Modified files: > dlls/kernel : kernel_main.c wprocs.spec > dlls/ntdll : Makefile.in ntdll.spec > dlls/winedos : Makefile.in dosvm.c int09.c module.c > winedos.spec > graphics : dispdib.c > include : callback.h miscemu.h > miscemu : main.c > msdos : Makefile.in dosmem.c dpmi.c int20.c int21.c > int2f.c interrupts.c ioports.c > Added files: > dlls/winedos : devices.c dosaspi.c dosexe.h int10.c int16.c > int17.c int19.c int20.c int21.c int29.c int31.c > int33.c ioports.c vga.c vga.h xms.c > Removed files: > include : dosexe.h vga.h > msdos : devices.c dosaspi.c int10.c int16.c int17.c > int19.c int29.c int33.c vga.c xms.c > > Log message: > Moved most of the real-mode stuff to dlls/winedos. > > Patch: http://cvs.winehq.com/patch.py?id=1007495689308334133587778 This one probably breaks a whole heap of older Win3.x apps. When I started the Win98 setup.exe for fun, it choked on int 0x21 "list of lists" (DOS_LOLSeg not initialized). Trouble is that we initialize DOS variables in case of DOS programs *only*. This is rather fatal IMHO, especially in the case of List Of Lists, which is a pretty important structure with lots of information that some Win 3.x programs might rely on. Thus DOS stuff should be reorganized somehow. Any suggestions ? IMHO probably winedos should get loaded as soon as DOS3Call() gets called even once. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
by Laurent Pinchart Dec. 24, 2001

Dec. 24, 2001

When trying to install The Longest Journey (an adventure game), I ran into a problem with modal message boxes. The installer displays at some point a task modal message box, but for some reason the box disapears almost instantly, and I'm stuck with a focused installshield screen on which I can't do anything as the task modal msgbox is invisible and unfocused. I'd like to implement the modal message boxes to fix my problem, but I don't know where to start. Could someone give me a few indication about what would be required to achieve a proper behaviour or modal message boxes ? Thanks. Laurent Pinchart

4 8

Terrible bug: WinExec16, DOS programs
by Andreas Mohr Dec. 24, 2001

Dec. 24, 2001

Hi all, I just found out that WinExec16 doesn't even support starting DOS programs. Whereas LoadModule16 doesn't seem to support loading DOS programs (error 22, which is not documented for LoadModule16), WinExec16 definitely does launch command.com on Win98SE. Not so when using Wine. What to do about that ? More specifically, which functions to change how exactly to support this ? (the whole interoperation between WinExec, WinExec16, LoadModule*, LoadLibrary*,CreateProcess etc. is highly problematic). This thing makes me get slightly worried about our Win16/DOS compatibility as a whole... :-\ -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Windows screensaver.
by gleb＠nbase.co.il Dec. 24, 2001

Dec. 24, 2001

Hello all, Perhaps this was asked before, but I didn't find the answer. Is it possible to run windows screensaver in linux using wine? If not, how hard it will be to write support for this? Thanks, -- Gleb.

2 2

Re: License debate conclusion
by James Tabor Dec. 23, 2001

Dec. 23, 2001

Dan Kegel wrote: > > Roger Fujii wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > Wine against companies that want to take it and never contribute code > back. Its protection might not be airtight -- but it would clearly > communicate the spirit. And my impresson was that the majority of > Wine developers agree. > > > - Dan Hum????????? Like the ODIN Project! James

1 0

Re: License debate conclusion
by Dan Kegel Dec. 23, 2001

Dec. 23, 2001

James wrote: > > Dan Kegel wrote: > > I'm sad. The LGPL seems like the clearest hope we have of protecting > > Wine against companies that want to take it and never contribute code > > back. Its protection might not be airtight -- but it would clearly > > communicate the spirit. And my impresson was that the majority of > > Wine developers agree. > > Like the ODIN Project! Good point. The ODIN project's license is at http://odin.netlabs.org/License.phtml There was some talk of sharing code between Wine and Odin in 1999; see http://www.winehq.com/News/1999-50.html#0 We might want to update http://www.winehq.com/others.html to reflect the current status and license of the Odin project. I'm not quite sure whether the Odin license is compatible with the LGPL. It looks fairly GPL compatible, but I didn't look hard. - Dan

1 0

Re: License debate conclusion
by Roger Fujii Dec. 23, 2001

Dec. 23, 2001

Alexandre Julliard <julliard(a)winehq.com> wrote: > > My conclusion is that there clearly isn't enough support in the > developers community to justify changing the license. So I'm not going > to proceed with any change, either now or in the foreseeable future. hurrah. before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs. This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license. -r

6 6