wine-devel January 2008

wine-devel@winehq.org

126 participants
290 discussions

What happened to the Fedora packages?
by Neal Gompa 02 Aug '14

02 Aug '14

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg 09 Oct '13

09 Oct '13

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

Wine desktop integration: current directory of app launched with doubleclick?
by Dan Kegel 15 Feb '09

15 Feb '09

I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files. My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing. ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work. If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME. I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@" That worked better; it let ViewSel.exe launch the DICOM viewer. So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan

4 9

today's valgrind results online
by Dan Kegel 23 Jun '08

23 Jun '08

Online at http://kegel.com/wine/valgrind/20071002/ (I now include more info about memory leaks, but I still only report anything if there was an invalid memory reference.) The following tests were fixed in git yesterday, and no longer have any valgrind warnings: comctl32/rebar comctl32/status crypt32/chain crypt32/crl crypt32/msg cryptnet/cryptnet user32/msg wintrust/softpub Juan thinks nearly all of the remaining crypt32 errors can be suppressed (some are intentional). Here are the directories that still have warnings: advapi32 advpack cabinet comctl32 crypt32 d3d8 d3d9 d3dx8 dplayx dsound gdi32 gdiplus hlink kernel32 mlang msacm32 mscms mshtml msi msvcrt msxml3 netapi32 ntdll ole32 oleaut32 quartz riched20 riched32 rpcrt4 rsaenh setupapi shdocvw shell32 urlmon user32 usp10 wininet winmm wintrust - Dan

3 4

Re: ole32: Fix a failed call to DllGetClassObject while retrieving class object interface pointer.
by Robert Shearman 17 Jun '08

17 Jun '08

Huang, Zhangrong wrote: > See dlls/ole32/compobj.c, > > static HRESULT apartment_getclassobject(struct apartment *apt, LPCWSTR dllpath, > BOOL apartment_threaded, > REFCLSID rclsid, REFIID riid, > void **ppv) > { > ................... > if (SUCCEEDED(hr)) > { > .................. > TRACE("calling DllGetClassObject %p\n", > apartment_loaded_dll->dll->DllGetClassObject); > /* OK: get the ClassObject */ > hr = apartment_loaded_dll->dll->DllGetClassObject(rclsid, riid, ppv); > ^^^^ > if (hr != S_OK) > ERR("DllGetClassObject returned error 0x%08x\n", hr); > } > .............. > } > > Reference to http://msdn2.microsoft.com/en-us/library/ms680760.aspx, > > riid > > [in] Reference to the identifier of the interface that the caller > is to use to communicate with the class object. Usually, this is > IID_IClassFactory (defined in the OLE headers as the interface > identifier for IClassFactory). > This doesn't mean anything other than CoCreateInstance is usually used instead of CoGetClassObject (and CoCreateInstance always passes in IID_IClassFactory for the IID). > We can't pass riid to DllGetClassObject directly sometimes, causes some dlls' > DllGetClassObject (like native adsldp.dll) can only return reference-counted > pointer to class factory via IID_IClassFactory, for retrieving the > pointer to the > class object interface requested in riid, we must try another way. > Thank you for your patch, but this behaviour seems a little strange and needs a little more investigation before I am happy that it is correct. What parameters are being passed in to CoGetClassObject to cause the call to fail for you? -- Rob Shearman

5 12

Re: hhctrl.ocx: Parse HTML entities in the table of contents.
by Alexandre Julliard 15 Apr '08

15 Apr '08

Robert Shearman <rob(a)codeweavers.com> writes: > + p++; > + if ((*p == 'X') || (*p == 'x')) > + { > + /* hexadecimal entity */ > + while ((*p >= '0' && *p <= '9') || (*p >= 'a' && *p <= 'f') || > + (*p >= 'A' && *p <= 'F')) > + p++; > + ch = strtolW(start + 2, NULL, 16); > + } This is still broken. > + if (p - start - 1 <= sizeof(char_refs[0].name)) > + { > + for (i = 0; i < sizeof(char_refs)/sizeof(char_refs[0]); i++) > + if (!strncmpW(char_refs[i].name, start + 1, p - start - 1)) > + break; > + } This is still broken too. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: LoadStringW [1/2]
by Dmitry Timoshkov 09 Apr '08

09 Apr '08

"Christopher" <raccoonone(a)procyongames.com> wrote: > +static void test_LoadStringW(void) > +{ > + HINSTANCE hInst = GetModuleHandle(NULL); > + WCHAR copiedstring[128], returnedstring[128], *resourcepointer = NULL; > + int strlen, strlen2; > + > + /* Check that the string which is returned by LoadStringW matches > + the string at the pointer returned by Load StringW when called with buflen = 0 */ > + strlen = LoadStringW(hInst, 2, (WCHAR *) &resourcepointer, 0); /* get pointer to resource. */ > + ok(strlen > 0, "LoadStringW failed to get pointer to resource 2, ret %d, err %d \n", strlen, GetLastError()); > + > + strlen2 = LoadStringW(hInst, 2, returnedstring, sizeof(returnedstring) /sizeof(WCHAR)); > + ok(strlen == strlen2, "LoadStringW returned different values dependent on buflen. ret1 %d, ret2 %d \n", > + strlen, strlen2); > + ok(strlen2 > 0, "LoadStringW failed to load resource 2, ret %d, err %d \n", strlen2, GetLastError()); > + > + if(resourcepointer != NULL) > + { > + memcpy(copiedstring, resourcepointer, strlen * sizeof(WCHAR)); > + copiedstring[strlen] = '\0'; > + } > + /* check that strings match */ > + ok(!memcmp(copiedstring, returnedstring, (strlen + 1)*sizeof(WCHAR)), > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ > + returnedstring = %ls, copiedstring = %ls", returnedstring, copiedstring); > +} It's not clear what this test is supposed to show. If the 1st call to LoadStringW is supposed to set resourcepointer to not NULL, why don't you test it? Then 'if(resourcepointer != NULL)' check and copying to copiedstring are not needed. Also, if the test depends on a later patch to not fail, the test should be included in the patch. -- Dmitry.

4 15

"winefix" - interesting wrapper for wine
by Dan Kegel 19 Mar '08

19 Mar '08

Tom W. found and publicized a script called "winefix" by an ubuntu forums user named "deadlydeathcone": http://digg.com/linux_unix/Winefix_improved_desktop_integration_for_Wine http://wine-review.blogspot.com/2007/10/winefix-improved-desktop-integratio… http://ubuntuforums.org/showthread.php?s=6e904c1df87d3fd1698ab5d7bbdbf664&t… It's got a bunch of interesting stuff. I wonder if we could get him to join wine-devel and start contributing to wine itself... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

Re: user32: Test destroying the cursor of a parent process.
by Eric Pouech 18 Mar '08

18 Mar '08

Andrew Riedi a écrit : > changelog: user32: Test destroying the cursor of a parent process. > > -- > Andrew Riedi > ------------------------------------------------------------------------ > > From 25a6a6a2eee92c4325d730ff85bd7cdf01bf2ace Mon Sep 17 00:00:00 2001 > From: Andrew Riedi <andrewriedi(a)gmail.com> > Date: Tue, 8 Jan 2008 05:03:55 -0800 > Subject: [PATCH] user32: Test destroying the cursor of a parent process. > > --- > dlls/user32/tests/cursoricon.c | 201 ++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 201 insertions(+), 0 deletions(-) > > diff --git a/dlls/user32/tests/cursoricon.c b/dlls/user32/tests/cursoricon.c > index 781282c..c2beffa 100644 > --- a/dlls/user32/tests/cursoricon.c > +++ b/dlls/user32/tests/cursoricon.c > @@ -32,6 +32,205 @@ > #include "wingdi.h" > #include "winuser.h" > > +static char **test_argv; > +static int test_argc; > +static HWND child = 0; > +static HWND parent = 0; > +static HANDLE child_process; > + > +#define PROC_INIT (WM_USER+1) > + > +LRESULT CALLBACK callback_child(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) > +{ > + BOOL ret; > + DWORD error; > + > + switch (msg) > + { > + /* Destroy the cursor. */ > + case WM_USER+1: > + SetLastError(0xdeadbeef); > + ret = DestroyCursor((HCURSOR) lParam); > + error = GetLastError(); > + todo_wine { > + ok(!ret, "DestroyCursor on the active cursor succeeded.\n"); > + ok(error == ERROR_DESTROY_OBJECT_OF_OTHER_THREAD, > + "Last error: 0x%08x\n", error); > + } > + return TRUE; > + case WM_DESTROY: > + PostQuitMessage(0); > + return 0; > + } > + > + return DefWindowProc(hwnd, msg, wParam, lParam); > +} > + > +LRESULT CALLBACK callback_parent(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) > +{ > + if (msg == PROC_INIT) > + { > + child = (HWND) wParam; > + return TRUE; > + } > + > + return DefWindowProc(hwnd, msg, wParam, lParam); > +} > + > +static void do_child(void) > +{ > + WNDCLASS class; > + MSG msg; > + BOOL ret; > + > + /* Register a new class. */ > + class.style = CS_GLOBALCLASS; > + class.lpfnWndProc = callback_child; > + class.cbClsExtra = 0; > + class.cbWndExtra = 0; > + class.hInstance = GetModuleHandle(NULL); > + class.hIcon = NULL; > + class.hCursor = NULL; > + class.hbrBackground = NULL; > + class.lpszMenuName = NULL; > + class.lpszClassName = "cursor_child"; > + > + SetLastError(0xdeadbeef); > + ret = RegisterClass(&class); > + ok(ret, "Failed to register window class. Error: %d\n", GetLastError()); > + > + /* Create a window. */ > + child = CreateWindowA("cursor_child", "cursor_child", WS_POPUP | WS_VISIBLE, > + 0, 0, 200, 200, 0, 0, 0, NULL); > + ok(child != 0, "CreateWindowA error %d\n", GetLastError()); > + > + /* Let the parent know our HWND. */ > + PostMessage(parent, PROC_INIT, (WPARAM) child, 0); > + > + /* Receive messages. */ > + while ((ret = GetMessage(&msg, child, 0, 0))) > + { > + ok(ret != -1, "GetMessage failed. Error: %d\n", GetLastError()); > + TranslateMessage(&msg); > + DispatchMessage(&msg); > + } > +} > + > +static void do_parent(void) > +{ > + char path_name[MAX_PATH]; > + PROCESS_INFORMATION info; > + STARTUPINFOA startup; > + WNDCLASS class; > + MSG msg; > + BOOL ret; > + > + /* Register a new class. */ > + class.style = CS_GLOBALCLASS; > + class.lpfnWndProc = callback_parent; > + class.cbClsExtra = 0; > + class.cbWndExtra = 0; > + class.hInstance = GetModuleHandle(NULL); > + class.hIcon = NULL; > + class.hCursor = NULL; > + class.hbrBackground = NULL; > + class.lpszMenuName = NULL; > + class.lpszClassName = "cursor_parent"; > + > + SetLastError(0xdeadbeef); > + ret = RegisterClass(&class); > + ok(ret, "Failed to register window class. Error: %d\n", GetLastError()); > + > + /* Create a window. */ > + parent = CreateWindowA("cursor_parent", "cursor_parent", WS_POPUP | WS_VISIBLE, > + 0, 0, 200, 200, 0, 0, 0, NULL); > + ok(parent != 0, "CreateWindowA error %d\n", GetLastError()); > + > + /* Start child process. */ > + memset(&startup, 0, sizeof(startup)); > + startup.cb = sizeof(startup); > + startup.dwFlags = STARTF_USESHOWWINDOW; > + startup.wShowWindow = SW_SHOWNORMAL; > + > + sprintf(path_name, "%s cursoricon %x", test_argv[0], (unsigned int) parent); > + ok(CreateProcessA(NULL, path_name, NULL, NULL, FALSE, 0L, NULL, NULL, &startup, &info), "CreateProcess failed.\n"); > + child_process = info.hProcess; > + > + /* Wait for child window handle. */ > + while ((child == 0) && (ret = GetMessage(&msg, parent, 0, 0))) > + { > + ok(ret != -1, "GetMessage failed. Error: %d\n", GetLastError()); > + TranslateMessage(&msg); > + DispatchMessage(&msg); > + } > +} > + > +static void init(void) > +{ > + test_argc = winetest_get_mainargs(&test_argv); > + > + /* Child process. */ > + if (test_argc >= 3) > + { > + sscanf (test_argv[2], "%x", (unsigned int *) &parent); > + > + ok(parent != NULL, "Parent not found.\n"); > + if (parent == NULL) > + exit(1); > + > + do_child(); > + exit(0); > + } > + else > + { > + do_parent(); > + } > +} > + > +static void finish_process(void) > +{ > + DWORD exit_code; > + BOOL ret; > + > + SendMessage(child, WM_CLOSE, 0, 0); > + ok(WaitForSingleObject(child_process, 30000) == WAIT_OBJECT_0, "Child process termination failed.\n"); > + > + ret = GetExitCodeProcess(child_process, &exit_code); > + ok(ret, "GetExitCodeProcess() failed. Error: 0x%08x\n", GetLastError()); > + ok(exit_code == 0, "Exit code == %d.\n", exit_code); > +} > + > +static void test_child_process(void) > +{ > + static const BYTE bmp_bits[4096]; > + HCURSOR cursor; > + ICONINFO cursorInfo; > + UINT display_bpp; > + HDC hdc; > + > + /* Create and set a dummy cursor. */ > + hdc = GetDC(0); > + display_bpp = GetDeviceCaps(hdc, BITSPIXEL); > + ReleaseDC(0, hdc); > + > + cursorInfo.fIcon = FALSE; > + cursorInfo.xHotspot = 0; > + cursorInfo.yHotspot = 0; > + cursorInfo.hbmMask = CreateBitmap(32, 32, 1, 1, bmp_bits); > + cursorInfo.hbmColor = CreateBitmap(32, 32, 1, display_bpp, bmp_bits); > + > + cursor = CreateIconIndirect(&cursorInfo); > + ok(cursor != NULL, "CreateIconIndirect returned %p.\n", cursor); > + > + SetCursor(cursor); > + > + /* Destroy the cursor. */ > + SendMessage(child, WM_USER+1, (WPARAM) parent, (LPARAM) cursor); > + > + /* Finish the child process. */ > + finish_process(); > +} > + > static void test_CopyImage_Check(HBITMAP bitmap, UINT flags, INT copyWidth, INT copyHeight, > INT expectedWidth, INT expectedHeight, WORD expectedDepth, BOOL dibExpected) > { > @@ -471,6 +670,7 @@ static void test_DestroyCursor(void) > > START_TEST(cursoricon) > { > + init(); > test_CopyImage_Bitmap(1); > test_CopyImage_Bitmap(4); > test_CopyImage_Bitmap(8); > @@ -480,4 +680,5 @@ START_TEST(cursoricon) > test_initial_cursor(); > test_CreateIcon(); > test_DestroyCursor(); > + test_child_process(); > } > > ------------------------------------------------------------------------ > > > IMO, the ok() tests in the child process are a bad idea (they won't be counted, nor returned as errors, by the parent process) all the tests should be done in parent, see kernel32/tests/process.c for some example on how to do it properly A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

3 2

Re: dlls/user32/edit.c -- remove superflous check (RESEND)
by Alexandre Julliard 19 Feb '08

19 Feb '08

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > dwBufLen already indictes that this variable is of type DWORD and > thus always positive. I also looked at the implementation of > ImmGetCompositionStringW() and we do not seem to return a negative > value (such as -1). Maybe the implementation doesn't, but the function returns a LONG, and can (and probably should) return negative values on error. -- Alexandre Julliard julliard(a)winehq.org

2 2

Jump to page:

2025

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 January 2008