October 2008 - Wine-devel - list.winehq.org

Re: [PATCH 4/4] jscript: Added possibility to run test scripts from file.
by winepatches＠kegel.com 02 Oct '08

02 Oct '08

> > With this patch it's possible to test scripts by running > wine jscript_test.exe.so run <file_name> > Although it's not what Wine tests are for, it proved to be very useful > for me. That's the second time in the last couple days that your patches confused patchwatcher's patch series detector. You resent patch 4/4 from a different series, and patchwatcher took that other 4/4 and used it in place of this one, leaving this patch as a stuck singleton. Tips: 1) never send two series of the same length on the same day (This confuses even humans.) 2) never partially resend patch series, always resend the whole series. (Eventually patchwatcher will handle this better.)

1 0

Detecting Wine
by Mark Wagner 02 Oct '08

02 Oct '08

What's the best way for an application to detect that it's running under Wine? As part of the installation process, under Windows our program does a full-disk search of all local hard drives, but ignoring network drives and removable media. Under Wine, this doesn't work too well, as there's not a one-to-one mapping between disks and drive letters, and there's usually at least one way to access the entire *nix filesystem. If someone's got a few network drives mounted, the installer could spend hours searching them. -- Mark Wagner

10 17

Be careful out there
by Juan Lang 02 Oct '08

02 Oct '08

Unfortunately, there is some Microsoft code available on the Internet. More unfortunately, Google has indexed some of it. I was searching for an undocumented function and ran across something that seemed to describe it. I clicked on the link, and fortunately the indexed page was just a reference to the actual source file, because the source file was Microsoft's. (The source file was also available. No, I didn't look at it.) Be very careful: reading Microsoft's source code is a clear way to taint yourself as a developer. --Juan

4 3

Fullscreen window in metacity hides owned window
by Michael Ost 02 Oct '08

02 Oct '08

We are seeing a problem in Metacity where a fullscreen window obscures a second created window that has a particular style: WS_DLGFRAME | WS_THICKFRAME. When window A is created fullscreen (WS_POPUP, size matches screen res) and window B is created as an "owned window" (WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED style with "A" as its parent) you cannot see "B" if Metacity is running. You can if other window managers are running. We tried kwin, xfce, fluxbox, enlightenment or fvvm. So the problem is something specific to Metacity. You can also see window "B" if you remove either the WS_DLGFRAME or WS_THICKFRAME bit from the style. Any hints about where to look within Wine or what could be happening? - mo PS: the code (ctrl+c to quit)... #include <windows.h> const char g_szClassName[] = "myWindowClass"; // Step 4: the Window Procedure LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch(msg) { case WM_CLOSE: DestroyWindow(hwnd); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hwnd, msg, wParam, lParam); } return 0; } int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { WNDCLASSEX wc; HWND hwnd, hwnd4; MSG Msg; //Step 1: Registering the Window Class wc.cbSize = sizeof(WNDCLASSEX); wc.style = 0; wc.lpfnWndProc = WndProc; wc.cbClsExtra = 0; wc.cbWndExtra = 0; wc.hInstance = hInstance; wc.hIcon = LoadIcon(NULL, IDI_APPLICATION); wc.hCursor = LoadCursor(NULL, IDC_ARROW); wc.hbrBackground = (HBRUSH)(COLOR_WINDOW+1); wc.lpszMenuName = NULL; wc.lpszClassName = g_szClassName; wc.hIconSm = LoadIcon(NULL, IDI_APPLICATION); if(!RegisterClassEx(&wc)) { MessageBox(NULL, "Window Registration Failed!", "Error!", MB_ICONEXCLAMATION | MB_OK); return 0; } // Step 2: Creating the Window int width = ::GetSystemMetrics(SM_CXSCREEN); int height = ::GetSystemMetrics(SM_CYSCREEN); hwnd = CreateWindowEx( WS_EX_CLIENTEDGE, g_szClassName, "A", WS_POPUP, CW_USEDEFAULT, CW_USEDEFAULT, width, height, NULL, NULL, hInstance, NULL); if(hwnd == NULL) { MessageBox(NULL, "Window Creation Failed!", "Error!", MB_ICONEXCLAMATION | MB_OK); return 0; } hwnd4 = CreateWindowEx( WS_EX_CLIENTEDGE, g_szClassName, "B", #if 1 // invisible WS_DLGFRAME|WS_THICKFRAME|WS_OVERLAPPED, #else // visible WS_THICKFRAME|WS_OVERLAPPED, #endif 300, 300, 240, 120, hwnd, NULL, hInstance, NULL); if(hwnd4 == NULL) { MessageBox(NULL, "Window Creation Failed!", "Error!", MB_ICONEXCLAMATION | MB_OK); return 0; } ShowWindow(hwnd, nCmdShow); ShowWindow(hwnd4, nCmdShow); UpdateWindow(hwnd); UpdateWindow(hwnd4); // Step 3: The Message Loop while(GetMessage(&Msg, NULL, 0, 0) > 0) { TranslateMessage(&Msg); DispatchMessage(&Msg); } return Msg.wParam; }

2 3

Re: (try 2)version: check for out of memory when VerInstallFileA/W converstion. (response to coverity 635)
by Rob Shearman 02 Oct '08

02 Oct '08

2008/10/2 Aric Stewart <aric(a)codeweavers.com>: > @@ -543,34 +543,50 @@ DWORD WINAPI VerInstallFileW( > len = WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, NULL, 0, NULL, NULL ); > if ((wsrcf = HeapAlloc( GetProcessHeap(), 0, len ))) > WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, wsrcf, len, NULL, NULL ); > + else > + ret = VIF_OUTOFMEMORY; > } > - if (srcdir) > + if (srcdir && !ret) Remove the extra space here. > + static const CHAR szSrcDir[] = "C:\\windows\\temp"; > + static const CHAR szDestDir[] = "C:\\windows\\temp\\test"; > + static const CHAR szCurDir[] = "C:\\"; This isn't exactly what I meant. C:\Windows might not even exist on NT4/Win2000 and the temp directory might not be in %WINDIR%\temp. You should use GetTempPath instead. (Hard-coding C:\ is also something to be avoided if at all possible.) -- Rob Shearman

2 2

Re: gdi32: if a font substitution is given then only match to that substitution not to the original family name.
by Dmitry Timoshkov 02 Oct '08

02 Oct '08

Aric Stewart <aric(a)codeweavers.com> wrote: > LIST_FOR_EACH(family_elem_ptr, &font_list) { > family = LIST_ENTRY(family_elem_ptr, Family, entry); > - if (!strcmpiW(family->FamilyName, FaceName) || > - (psub && !strcmpiW(family->FamilyName, psub->to.name))) > + if ((!psub && !strcmpiW(family->FamilyName, FaceName)) || > + ( psub && !strcmpiW(family->FamilyName, psub->to.name))) > { > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > face = LIST_ENTRY(face_elem_ptr, Face, entry); Changing the order of 2 comparisons in the 'if' block would be clear IMO, and would help avoiding to check psub twice. -- Dmitry.

1 0

Re: version: check for out of memory when VerInstallFileA/W converstion. (response to coverity 635)
by Rob Shearman 02 Oct '08

02 Oct '08

2008/10/2 Aric Stewart <aric(a)codeweavers.com>: > @@ -543,34 +543,50 @@ DWORD WINAPI VerInstallFileW( > len = WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, NULL, 0, NULL, NULL ); > if ((wsrcf = HeapAlloc( GetProcessHeap(), 0, len ))) > WideCharToMultiByte( CP_ACP, 0, srcfilename, -1, wsrcf, len, NULL, NULL ); > + else if (len) > + ret = VIF_OUTOFMEMORY; IIRC HeapAlloc(..., 0) returns a non-NULL value, so the "if (len)" part is not needed. ... > + rc = VerInstallFileA(0x0, "in.txt", "out.txt", "C:\\windows\\temp", "C:\\windows\\temp\\test\\", "C:\\", tmpname, &size); > + ok (rc == 0x10000 && tmpname[0]==0," expected return 0x10000 and no tempname, got %08x/\'%s\'\n",rc,tmpname); You shouldn't hard-code paths such as this. -- Rob Shearman

1 0

Re: gdiplus: Stub GdipRecordMetafileFileName andGdipRecordMetafileFileNameI
by Alistair Leslie-Hughes 02 Oct '08

02 Oct '08

"Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:48DCB2A0.9070405(a)hotmail.com... > Hi, > > Changelog: > gdiplus: Stub GdipRecordMetafileFileName and GdipRecordMetafileFileNameI > Was there anything wrong with this patch? Best Regards Alistair Leslie-Hughes

2 1

Re: msi: Implement the DROP TABLE sql command.
by James Hawkins 02 Oct '08

02 Oct '08

Hold off on this patch. There's a missing debugstr_w and a crash on patchwatcher. -- James Hawkins

1 0

Re: [PATCH] wintrust: Add a stub for OpenPersonalTrustDBDialog
by Juan Lang 01 Oct '08

01 Oct '08

Hi Detlef, I'm not sure why this wasn't committed, but my hunch is this: + * RETURNS + * Success: TRUE (The Dialog was opened) + * Failure: FALSE + * + */ +BOOL WINAPI OpenPersonalTrustDBDialog(HWND hwnd) +{ + FIXME("(%p) stub\n", hwnd); + return TRUE; Shouldn't it return FALSE instead? In any case, this is a very simple function to implement: it calls cryptui:CryptUIDlgCertMgr. I'll send in a patch that implements it, if you don't mind. --Juan

1 0