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...
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
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
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
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
"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.
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