wine-devel August 2004

122 participants
273 discussions

by Scott Snell

Hi Dimi, Thanks for helping out. I made the changes you suggested to the gcc-mingw.mak file for STLPort. When I go make it does a: wineg++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -mno-cygwin -O2 -D_STLP_USE_DYNAMIC_LIB dll_main.cpp -c -o ../lib/obj/MINGW32/ReleaseD/dll_main.o which throws up a world of errors, such as: In file included from ../stlport/cstdlib:25, from ../stlport/stl/debug/_debug.c:160, from ../stlport/stl/debug/_debug.h:418, from ../stlport/utility:40, from dll_main.cpp:35: /usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared /usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared /usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long int)': I'm sure its something simple but I'm still not comfortable around gcc/winegcc. thanks, Scott. > -----Original Message----- > From: Dimitrie O. Paun [SMTP:[email protected]] > > On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > > > > > Better go with gcc-mingw.mak, as threading and OS is more Windows than > > Linux. See if they have a -nocygwin variant. > > Yes, it should work with the gcc-mingw.mak by changing > gcc -> winegcc > g++ -> wineg++ > > > >adding a path pointing to /include/wine/MSVCRT. > > > > > No, you shouldn't need that. You just need to make sure you pass > the -mno-cygwin flag to winegcc/wineg++. > > -- > Dimi.

19 years, 8 months

Don't crash on failing DRIVER_FindFromHDrvr

by Uwe Bonnes

Hallo, I sent a patch to prevent wine from crashing last friday. It happend, when DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that patch before last year. Eric answered > this doesn't seem right to me: either the loading fails and we shouldn't > get a valid handle, or it succeeds and we should be able to find it > there's must be something wrong elsewhere > could you please send a -debugmsg +driver,+module,+winmm to see what > happens ? and like before, I can't reproduce the error after reverting the patch: > the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. > > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other usage of DRIVER_FindFromHDrvr is like if ((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL) Why should expecting a NULL return be wrong? It happens, as the the crashes show. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

19 years, 8 months

Wine bug with delphi Menus

by Robert van Herk

Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working, when the program is run under Wine. Behind the screens, the setVisible of a menu item calls MenuChanged. This seems to put the menu in such a state that, in wine, all menu components stop doing anything. I've written a small application (455 kb EXE) to show what goes wrong. Would anybody be interested to help me in solving this bug? Would a message trace from Winsight (for example) be of any help? Greetings, Robert

19 years, 8 months

regression: listbox stays disabled in created dialog-window

by Saulius Krasuckas

The [1] patch brings some regression. I have filled a bugreport: [2]. Here are two png screenshots: [3] [4], one made before the patch is applied, another made after the patch is applied. [1] http://www.winehq.org/hypermail/wine-cvs/2004/08/0341.html [2] http://bugs.winehq.org/show_bug.cgi?id=2454 [3] http://bugs.winehq.org/attachment.cgi?id=681&action=view [4] http://bugs.winehq.org/attachment.cgi?id=682&action=view

19 years, 8 months

Richedit control

by Mike McCormack

Hi All, I'm going to play with the richedit control to try get it to draw RTF documents with formatting. My plan is to write a program that can display but not edit, then let somebody else add the editting functionality afterwards :) Once I can get the attached program to work, the plan is to change the code in text-writer.c to add the formatting information to the richedit control via standard richedit messages. If anybody is already working on it, or wants to have a go, let me know. Mike #include <stdio.h> #include <windows.h> #include <winuser.h> #include <richedit.h> void fill_richedit( HWND hwnd ) { PARAFORMAT pf; CHARFORMAT cf; SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "this is a test\n"); // add text on the right memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_RIGHT; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "right\n"); // add text in the center memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_CENTER; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "centre\n"); // add text on the left memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_LEFT; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "left\n"); // add bold text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_BOLD; cf.dwEffects = CFE_BOLD; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "bold "); // add italic text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD; cf.dwEffects = CFE_ITALIC; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "italic "); // add underlined text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE; cf.dwEffects = CFE_UNDERLINE; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "underline "); // add strikeout text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE | CFM_STRIKEOUT; cf.dwEffects = CFE_STRIKEOUT; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "strikeout"); // add normal text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_BOLD | CFM_ITALIC | CFM_UNDERLINE | CFM_STRIKEOUT; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) " normal\n"); // add red text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(255,0,0); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "red "); // add green text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(0,255,0); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "green "); // add blue text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(0,0,255); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "blue\n"); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE | CFM_SIZE; cf.yHeight = 300; strcpy(cf.szFaceName, "Tahoma"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "tahoma "); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE; strcpy(cf.szFaceName, "Helvetica"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Helvetica "); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE; strcpy(cf.szFaceName, "Courier"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Courier "); } LRESULT WINAPI ParentWindowProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { RECT r; HWND hwndRichedit = (HWND) GetWindowLong( hWnd, 0 ); char *cls; //cls = RICHEDIT_CLASS; //cls = "RICHEDIT10A"; cls = "RICHEDIT"; switch(msg) { case WM_CREATE: GetClientRect( hWnd, &r ); hwndRichedit = CreateWindow( cls, "", WS_CHILD | WS_VISIBLE | ES_MULTILINE | ES_SUNKEN, 0, 30, r.right-r.left, r.bottom - r.top - 30, hWnd, NULL, NULL, NULL ); fill_richedit( hwndRichedit ); SetWindowLong( hWnd, 0, (LONG) hwndRichedit ); break; case WM_CLOSE: DestroyWindow(hWnd); break; case WM_LBUTTONDOWN: InvalidateRect( hWnd, NULL, TRUE ); break; case WM_DESTROY: PostQuitMessage( 0 ); break; } return DefWindowProc(hWnd,msg,wParam,lParam); } /*********************************************************************** * * WinMain */ int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR cmdline, int show) { WNDCLASS cls; char className[] = "parentclass"; /* To make sure className >= 0x10000 */ char winName[] = "Richedit control"; HWND hWnd; MSG msg; LoadLibrary("riched32"); cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; cls.lpfnWndProc = ParentWindowProc; cls.cbClsExtra = 0; cls.cbWndExtra = 4; cls.hInstance = 0; cls.hIcon = LoadIcon (0, IDI_APPLICATION); cls.hCursor = LoadCursor (0, IDC_ARROW); cls.hbrBackground = GetStockObject (WHITE_BRUSH); cls.lpszMenuName = 0; cls.lpszClassName = className; if (!RegisterClass (&cls)) return FALSE; /* Setup windows */ hWnd = CreateWindow (className, winName, WS_OVERLAPPEDWINDOW , CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, NULL, hInstance, 0); ShowWindow (hWnd, show); UpdateWindow (hWnd); /* now enter mesage loop */ while( 0 != GetMessage( &msg, 0, 0, 0 ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); } return 0; }

19 years, 8 months

Re: Wine Emulation: Swapping functions

by Alexandre Julliard

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Hi Alexandre, > > This patch allows to load a PE exe to memory. You may notice that > there is no "mass" byte swapping. The technics used here is a bit > developer here: > http://stegefin.free.fr/wine/ > You might prefer a more conventional way of doing the byte swapping, > in this case tell me. We might still need this approach since it could > efficient for sharing data accross the LE exe and the BE winelib. It doesn't seem very efficient to trap on every memory access... Besides, I don't see how this can possibly work, there is no guarantee that the compiler is going to generate accesses that always match the size of the requested type, memcpy() being the obvious example. I think you are going in the wrong direction with this; the right way IMO is to compile Wine for x86 and run the whole Wine+app under the CPU emulator. Otherwise you'll have to write wrappers for each of the 15,000 APIs. -- Alexandre Julliard julliard(a)winehq.org

19 years, 8 months

more debugger issues

by Chipzz

Hi all! As a saw a few updates to the debugger a couple of days ago, I decided to give the debugger another go. The problem with the stack trace is gone now, but now I get another problem when I attach to a running process, set a breakpoint and continue, the program crashes. When I in- stead don't set a breakpoint and continue, the program keeps running "fine": When setting the breakpoint: chipzz@Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000008 4 00000000 'H:\.wine-clean\win\dotnet.inst\install.exe' Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>bt Backtrace: =>1 0x40107b4b __read+0x4b in libc.so.6 (0x40307c54) 2 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x40307cf8) 3 0x401ca9dc vm86_return_end+0xc55 in ntdll (0x40307d1c) 4 0x40067678 (0x423bcc4c) 5 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x423bccf0) 6 0x401cc4e6 NtWaitForMultipleObjects+0x66 in ntdll (0x423bcd18) 7 0x404e25a5 WaitForMultipleObjectsEx+0xb5 in kernel32 (0x423bce48) 8 0x40cd54cc X11DRV_MsgWaitForMultipleObjectsEx+0x5c in x11drv (0x423bcf80) 9 0x408d9294 MsgWaitForMultipleObjectsEx+0x134 in user32 (0x423bd128) 10 0x408d9351 MsgWaitForMultipleObjects+0x41 in user32 (0x423bd148) 11 0x4163b91a (0x40915980) 12 0x7d8920ec (0x83e58955) fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) 13 0x8000:0x0000 (0x11b7:0x0800) 14 0x8000:0x0800 (0x11b7:0x0000) Wine-dbg>break MessageBoxA err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file ole32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file oleaut32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file rpcrt4.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 53445352 in module msvcr80 fixme:dbghelp:symt_get_info Unsupported sym-tag SymTagPublicSymbol for get-type Many symbols with name 'MessageBoxA', choose the one you want (<cr> to abort): [1]: 0x408db030 MessageBoxA in user32 [2]: 0x40ad7760 MessageBoxA in shell32 [3]: 0x40107b00 __libc_read in libc.so.6 => 1 Breakpoint 1 at 0x408db030 MessageBoxA in user32 Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:11af GS:0000 EIP:4281009e ESP:423be038 EBP:423be0a4 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:77710800 EDX:00000000 ESI:00000000 EDI:000000a0 Stack dump: 0x423be038: 79655066 796fc52b 00000000 000000a0 0x423be048: 00000000 00000000 40340000 00000002 0x423be058: 00000034 404bec3f 00000007 423be084 0x423be068: 70a948ad 00000409 00000001 403b62f8 0x423be078: ffffffff 79670df4 ffffffff 423be0b8 0x423be088: 70a95755 00000001 354ae8a4 423be044 0235: sel=11af base=40306000 limit=00001fff 32-bit rw- Backtrace: =>1 0x4281009e (0x423be0a4) 2 0x796fc558 (0x423be0dc) 3 0x796fc705 (0x423be12c) 4 0x796fd494 (0x423be1d0) 5 0x00750073 (0x00690056) 6 0x00000000 (0x00000000) 0x4281009e: movl 0x40(%eax),%eax Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). ... etc. When not setting the breakpoint: chipzz@Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>c Also, ctrl-c doesn't work to stop the program being debugged. Wien version is wine CVS Aug 23. Any help is appreciated! kr, Chipzz AKA Jan Van Buggenhout PS: Please cc me as I'm not on the list. -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

19 years, 8 months

WineHQ - Hosted by PayPal

by Tero Tamminen

Hi! Sorry if this is wrong list or something, but I saw this bug (if this is feature, not a bug, ignore this mail) in front page of WineHQ. Also with quick search with Google I didn't find this reported before. On the right side, there is "Hosted by" and empty link to codeweavers (<a href="http://www.codeweavers.com/"></a>). After that there is PayPal link. Because <a href="http://www.codeweavers.com/"></a> is empty, it seems that this site is hosted by PayPal (which should come after codeweavers, I think). This could be said more clearly I think, but if you go to the front page, you'll notice it. Anyway, have a nice day and so on... -- Tero Tamminen

19 years, 8 months

Re: wine/ windows/painting.c dlls/user/painting.c

by Rein Klazes

On Wed, 25 Aug 2004 19:46:11 -0500, you wrote: > Log message: > GetUpdateRgn should clip the returned region to the client area. > Changed GetUpdateRect and ExcludeUpdateRgn to call GetUpdateRgn. > Moved these 3 functions to dlls/user/painting.c. This has the effect that a program that like agent does this: case WM_PAINT: if( GetUpdateRect(hWnd, ...) { hdc = BeginPaint(hWnd,...); } causes a lot of: err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 0x1002c! Is it not possible to restrict the update region to the client area in the first place? Rein. -- Rein Klazes rklazes(a)xs4all.nl

19 years, 8 months

Re: Binary relocatability part 1

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > +dnl This is used for binary relocatability > +if echo $libdir | grep '^\${exec_prefix}' >/dev/null; then > + RPATH="-Wl,-rpath,'\$\${ORIGIN}/..'`echo $libdir | sed 's/\${exec_prefix}//'`" > +fi This is still making assumptions about the contents of bindir and libdir. What you need is a generic way to find a relative path from any directory to any other. Also this needs to be done at make time, not in configure. -- Alexandre Julliard julliard(a)winehq.org

19 years, 8 months

Jump to page:

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 August 2004