August 2004 - Wine-Devel - list.winehq.org

Re: W->A cleanup of DirectDrawEnumerateEx part 1

by James Hawkins

I guess this is one of the w->a cases that shouldnt be fixed if this is the case. On Sat, 28 Aug 2004 18:30:50 +0200, Lionel Ulmer <lionel.ulmer(a)free.fr> wrote: > On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > > Changelog > > * change szDriver and szDescription from char to WCHAR in > > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. > > Well, this seems completely wrong to me. Why Unicodify an API that has no > Unicode equivalent in Microsoft code ? > > If I look at the platform SDK, this structure is defined with a 'char', so I > wonder why you would choose to deviate from the standard ? > > Lionel > > -- > Lionel Ulmer - http://www.bbrox.org/ > > -- James Hawkins

Aug. 28, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 4

by Lionel Ulmer

On Sat, Aug 28, 2004 at 12:20:24PM -0400, James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx To continue with my other mail, you should have sent all this in one big patch as (from what I can see) it cannot work if you do not apply all 4 parts in one go. Anyway, the 'problem' in Wine is that it uses the DDDEVICEIDENTIFIER2 structure to hold driver information. But, as this information is also exported via API calls like the 'GetDeviceIdentifier' method from the DDraw COM object, you cannot just Unicodify it, you need to let it in ASCII (as there are no, AFAIK, Unicode versions of any of the DirectX < 8 APIs). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 28, 2004

Re: W->A cleanup of DirectDrawEnumerateEx part 1

by Lionel Ulmer

On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > Changelog > * change szDriver and szDescription from char to WCHAR in > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. Well, this seems completely wrong to me. Why Unicodify an API that has no Unicode equivalent in Microsoft code ? If I look at the platform SDK, this structure is defined with a 'char', so I wonder why you would choose to deviate from the standard ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 28, 2004

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars

by Jens Collin

Is there anything wrong with this patch? I can't see my changes taken place in CVS. Let me know and I'll fix 'em. /J -----Original Message----- From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin(a)winehq.org] On Behalf Of Jens Collin Sent: den 8 augusti 2004 17:55 To: wine-patches(a)winehq.org Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).

Aug. 28, 2004

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; }

Aug. 28, 2004

Re: working together on stdole.tlb and a end to dcom9x

by Mike Hearn

It basically involves implementing the ICreateTypeLib interfaces in our OLE dlls. Nyef did some great work on this but for stdole32.tlb we need the other version, I think. Once this is done maybe we can pull the stdole32.tlb generation program used in Crossover upstream. Right now it's pretty useless for Wine as it has to be run on Windows to work. On Fri, 27 Aug 2004 23:26:07 -0700, Steven Edwards wrote: > Hello, > Once again cross-posting because I would like to see if this is > something we can work together on. What is left to do for us to be able > to build and have a working implementation of stdole.tlb or any other > type libs? I ask because it seems Wines DCOM implementaton is almost > good enough for most apps except for this file and ReactOS is quickly > getting to the point that it can run most of the same stuff Wine can > without DCOM9x installed. > > Thanks > Steven > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush

Aug. 28, 2004

working together on stdole.tlb and a end to dcom9x

by Steven Edwards

Hello, Once again cross-posting because I would like to see if this is something we can work together on. What is left to do for us to be able to build and have a working implementation of stdole.tlb or any other type libs? I ask because it seems Wines DCOM implementaton is almost good enough for most apps except for this file and ReactOS is quickly getting to the point that it can run most of the same stuff Wine can without DCOM9x installed. Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Aug. 28, 2004

Re: Problem in mutex?

by Shachar Shemesh

Shachar Shemesh wrote: >> sun(a)sun:~/sources/wine/threadtest$ time ../wine/wine Debug/main.exe >> > /dev/null >> Program exit 299732 > > > Just for comparison, when running on Windows, I get as far as 298015, > but in less time. Just for the record, if all the threads run to completion, and the mutex do their job, the number should have been 300000. Any other number seems to indicate that there was a problem with the mutex. If a mutex failed to be granted we should have seen messages, which didn't happen either. This problem is for both Windows AND wine. I can only deduct that I'm doing something wrong. Maybe named mutexes are not shared like I thought they are? When I try to create the mutex only once and share the handle I get a lot of failed locking responses, also on Windows. Then again, when I use the original code, even on windows, the number is not a multiple of 1000, which suggests that not all increments happened. The only explanation is that there is a bug in the win32 code. But what? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 27, 2004

Re: more debugger issues

by Eric Pouech

Chipzz a écrit : > 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: > [...] > 10 0x408d9351 MsgWaitForMultipleObjects+0x41 in user32 (0x423bd148) > 11 0x4163b91a (0x40915980) this looks bad as a backtrace (the bp -in parenthesis- goes south). It could dbghelp not supporting modules with FPO (frame pointer omission). If you recompile wine, could you change the #if 0 in dlls/dbghelp/msc.c in function pe_load_debug_directory into a #if 1, and see what gives. Afterwards, the stack lookup goes wrong, hence the 16 bit addresses. I'm don't know what goes wrong afterwards after setting the breakpoint or not. Even the issues from above shouldn't impact the debuggee. > Also, ctrl-c doesn't work to stop the program being debugged. > Wien version is wine CVS Aug 23. I'm working on it. A+

Aug. 27, 2004

Re: Problem in mutex?

by Eric Pouech

> I find that there are several disturbing things here: > 1. There is only one process. How did that happen? you mean thread don't you ? > 2. The debugger cannot load the debug info for my winelib application. > What the....? did you compile your winelib app with -g or -gstabs as it's supposed to be ? A+

Aug. 27, 2004