Re: Frequent and annoying Wine bug
Hi, late response, been on holiday :). The patch from francios gougetdoesn't fix the error. I dug a little deeper into this:I had a knoppix live cd lying around and there bug is not present. A program like Neatimage (www.neatimage.com) startsup just fine there. I also did some tracing to see where the difference is. I'm quite noobish in this so correct me plz if i'm wrong: On knoppix running neatimage fine i see this: 0009:Ret user32.LoadStringA() retval=001b ret=00527b86 0009:Call kernel32.RaiseException(0eedfade,0001,0007,4067f930) ret=004aefac 0009:Call ntdll.RtlRaiseException(4067f7d8) ret=404a5393 fs=1007 eax=4067f7d8 ebx=40569244 ecx= edx=0018 esi=4067f94c edi=4067f808 ebp=4067f834 esp=4067f7d8 ds=002b es=002b gs= flags=00200216 trace:seh:EXC_RtlRaiseException code=eedfade flags=1 addr=0x404a5300 trace:seh:EXC_RtlRaiseException info[0]=004aefac trace:seh:EXC_RtlRaiseException info[1]=411d3068 trace:seh:EXC_RtlRaiseException info[2]=411d2fb0 trace:seh:EXC_RtlRaiseException info[3]=411d3058 trace:seh:EXC_RtlRaiseException info[4]=4067f974 trace:seh:EXC_RtlRaiseException info[5]=4067f964 trace:seh:EXC_RtlRaiseException info[6]=4067f94c trace:seh:EXC_RtlRaiseException eax=4067f7d8 ebx=40569244 ecx= edx=0018 esi=4067f94c edi=4067f808 trace:seh:EXC_RtlRaiseException ebp=4067f834 esp=4067f7d8 cs=0023 ds=002b es=002b fs=1007 gs= flags=00200216 trace:seh:EXC_CallHandler calling handler at 0x538243 code=eedfade flags=1 0009:Call ntdll.RtlUnwind(4067f990,0053916b,4067f7d8,) ret=0053916b fs=1007 eax=4067f990 ebx=4067f7d8 ecx=00549d68 edx=4067f7d8 esi=001c edi=4067f7d8 ebp=4067f0a4 esp=4067f040 ds=002b es=002b gs= flags=00200206 trace:seh:EXC_RtlUnwind code=eedfade flags=3 trace:seh:EXC_CallHandler calling handler at 0x538243 code=eedfade flags=3 trace:seh:EXC_CallHandler handler returned 1 trace:seh:EXC_CallHandler calling handler at 0x401ae2c0 code=eedfade flags=3 trace:seh:EXC_CallHandler handler returned 1 0009:Ret ntdll.RtlUnwind() retval= ret=0053916b fs=1007 eax= ebx=4067f7d8 ecx=00549d68 edx=4067f7d8 esi=001c edi=4067f7d8 ebp=4067f0a4 esp=4067f040 ds=002b es=002b gs= flags=00200206 0009:Call advapi32.RegSetValueExA(005c,411d3058 StartCount,,0004,4067f97c,0004) ret=004aef22 Looks to me as if an exception is thrown, wine is handling the exception and the program continues fine On my fc3 computer i see this: 000b:Ret user32.LoadStringA() retval=001b ret=00527b86 000b:Call kernel32.RaiseException(0eedfade,0001,0007,7fa9f93c) ret=004aefac 000b:Call ntdll.RtlRaiseException(7fa9f824) ret=7fcfe544 fs=003b eax=7fcec305 ebx=7fd5bacc ecx= edx=0eedfade esi=7fa9f958 edi=7fa9f854 ebp=7fa9f880 esp=7fa9f824 ds=007b es=007b gs=0033 flags=00200212 trace:seh:__regs_RtlRaiseException code=eedfade flags=1 addr=0x7fcfe4e0 trace:seh:__regs_RtlRaiseException info[0]=004aefac trace:seh:__regs_RtlRaiseException info[1]=7e4c32f4 trace:seh:__regs_RtlRaiseException info[2]=7e4c323c trace:seh:__regs_RtlRaiseException info[3]=7e4c32e4 trace:seh:__regs_RtlRaiseException info[4]=7fa9f980 trace:seh:__regs_RtlRaiseException info[5]=7fa9f970 trace:seh:__regs_RtlRaiseException info[6]=7fa9f958 trace:seh:__regs_RtlRaiseException eax=7fcec305 ebx=7fd5bacc ecx= edx=0eedfade esi=7fa9f958 edi=7fa9f854 trace:seh:__regs_RtlRaiseException ebp=7fa9f880 esp=7fa9f824 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00200212 trace:seh:EXC_CallHandler calling handler at 0x538243 code=eedfade flags=1 000b:Call kernel32.GetModuleFileNameA(,7fa9f0c8,0080) ret=00541424 000b:Call ntdll.RtlAllocateHeap(7fdb,,0100) ret=7fd06d22 000b:Ret ntdll.RtlAllocateHeap() retval=7fdef278 ret=7fd06d22 000b:Call ntdll.LdrLockLoaderLock(,,7fa9efdc) ret=7fd1638f 000b:Ret ntdll.LdrLockLoaderLock() retval= ret=7fd1638f 000b:Call ntdll.LdrFindEntryForAddress(0040,7fa9efd8) ret=7fd163a1 000b:Ret ntdll.LdrFindEntryForAddress() retval= ret=7fd163a1 000b:Call ntdll.LdrUnlockLoaderLock(,000b) ret=7fd163e5 000b:Ret ntdll.LdrUnlockLoaderLock() retval= ret=7fd163e5 000b:Call ntdll.RtlUnicodeToMultiByteN(7fa9f0c8,0080,7fa9efdc,7fdef278,0052) ret=7fcff857 000b:Ret ntdll.RtlUnicodeToMultiByteN() retval= ret=7fcff857 000b:Call ntdll.RtlFreeHeap(7fdb,,7fdef278) ret=7fd06d4a 000b:Ret ntdll.RtlFreeHeap() retval=0001 ret=7fd06d4a 000b:Ret kernel32.GetModuleFileNameA() retval=0029 ret=00541424 000b:Call kernel32.GetVersion() ret=005413a7 000b:Call ntdll.RtlGetVersion(7fa9eef8) ret=7fd3d280 000b:Ret ntdll.RtlGetVersion() retval= ret=7fd3d280 000b:Ret kernel32.GetVersion() retval=ca04 ret=005413a7 000b:Call kernel32.GetCurrentThreadId() ret=005413c6 000b:Ret kernel32.GetCurrentThreadId() retval=000b ret=005413c6 000b:Call user32.EnumThreadWindows(000b,00541388,7fa9f0b8) ret=005413cc
Re: Lostwages: howto.diff
On Mon, 2005-08-15 at 08:44, Tom Wickline wrote: Hello All, We have moved to winecfg.. Tom Changelog: spelling fix, doc update Hi Tom, you're patch shows: -pWine is currently in a transitionary phase. We are working on replacing the -cryptic configuration file with an easy to use graphical utility called winecfg. -In the meantime, however, we recommend that you use a handy program called +pIf your using an old version of Wine we recommend that you use a handy program called As winecfg is currently THE tool why not refer to this (and maybe also to Winetools) this way more and more people will use it (and make it better?). Cheers, Paul.
Re: Lostwages: howto.diff
On 8/15/05, Paul Vriens [EMAIL PROTECTED] wrote: As winecfg is currently THE tool why not refer to this (and maybe also to Winetools) this way more and more people will use it (and make it better?). for new versions of Wine winecfg is the default tool to setup/edit a setup. So I figured most people would use it in new versions. There is the possibility even probability new users won't know about winecfg... I was just recommending WineTools for people still using older versions of Wine. I'm sure the WineTools guys will fix there nifty tool to comply with the changes that have taken place. And I will be editing this page again to tell people to choose the front end of there choice. So do you think I should say if you use a version of Wine from 20050628 forward we recommend that you use winecfg, and for versions older than 20050628 use WineTools? Tom Cheers, Paul.
Re: dlls/shell32/pidl.c
Hi Ge,
On Saturday 13 August 2005 20:55, Ge van Geldorp wrote:
dwAttributes = SFGAO_FILESYSTEM;
hr = IShellFolder_GetAttributesOf(psfFolder, 1, pidlLast,
dwAttributes); -if (FAILED(hr) || !(dwAttributes SFGAO_FILESYSTEM))
return FALSE; +if (FAILED(hr) || !(dwAttributes SFGAO_FILESYSTEM)) {
+IShellFolder_Release(psfFolder);
+ILFree((LPITEMIDLIST) pidlLast);
+return FALSE;
+}
I had another look at this after realising that Alexandre did'nt apply the
patch. SHBindToParent does not allocate a new PIDL for pidlLast, but returns
a pointer to right location in pidl. This means you should not free it.
There's still the problem that the shell folder isn't released in failure
cases.
Sorry, I didn't realize this. Once again I'm impressed that Alexandre always
catches those things.
Bye,
--
Michael Jung
[EMAIL PROTECTED]
calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
Hello Ge and especially unicoders:
Alexandre, Dimi, Dmitry, Rob, Shachar, Troy and others.
I am not sure of how should be file operations implemented in winetest:
* On Sat, 13 Aug 2005, Ge van Geldorp wrote:
--- dlls/shell32/tests/shlfolder.c12 Aug 2005 10:33:37 - 1.29
+++ dlls/shell32/tests/shlfolder.c13 Aug 2005 18:49:59 -
...
+PathAddBackslashW(wszFileName);
+lstrcatW(wszFileName, wszTestFile);
+hTestFile = CreateFileW(wszFileName, GENERIC_WRITE, 0, NULL, CREATE_NEW,
0, NULL);
+ok(hTestFile != INVALID_HANDLE_VALUE, CreateFileW failed! Last error:
%08lx\n, GetLastError());
+if (hTestFile == INVALID_HANDLE_VALUE) {
+IShellFolder_Release(psfDesktop);
+return;
+}
+CloseHandle(hTestFile);
+
+hr = IShellFolder_ParseDisplayName(psfDesktop, NULL, NULL, wszTestFile,
NULL, pidlTestFile, NULL);
+ok (SUCCEEDED(hr), Desktop's ParseDisplayName failed to parse filename
hr = %08lx\n, hr);
+if (FAILED(hr)) {
+IShellFolder_Release(psfDesktop);
+DeleteFileW(wszFileName);
+IMalloc_Free(ppM, pidlTestFile);
+return;
+}
*FileW and *DirectoryW functions fail on every win9x box as they are
unimplemented here. They succeed only when app is linked to MS Layer for
Unicode (MSLU) and MSLU is installed. [1]
I was trying to replace every failing unicode function with its ascii
counterpart in one of the wt files [2], but that looked ugly to me.
Maybe it would be really nice and possible to link wt to unicows.lib on
windows. In this case we need a corresponding static lib in Wine too,
right? It probably will be empty because UNICOWS.DLL shouldn't be
loaded as Wine doesn't lack implementation of mentioned functions.
Though, I have no guess if this could be done easily.
What could be a clean and acceptable solution? Your comments, please.
[1] http://msdn.microsoft.com/msdnmag/issues/01/10/MSLU/default.aspx
[2] http://www.winehq.org/hypermail/wine-patches/2005/08/0267.html
Re: calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
Saulius Krasuckas wrote: *FileW and *DirectoryW functions fail on every win9x box as they are unimplemented here. Makes sense. They succeed only when app is linked to MS Layer for Unicode (MSLU) and MSLU is installed. [1] A royal pain. I was trying to replace every failing unicode function with its ascii counterpart in one of the wt files [2], but that looked ugly to me. Maybe it would be really nice and possible to link wt to unicows.lib on windows. In this case we need a corresponding static lib in Wine too, right? It probably will be empty because UNICOWS.DLL shouldn't be loaded as Wine doesn't lack implementation of mentioned functions. Though, I have no guess if this could be done easily. Unicows is a pain. First of all, in order to link with it, you will have to remove all standard links (kernel, gdi, advapi, etc), put unicows.lib at the beginning, and then put all standard library links again. Unicows takes over all of the function calls, and on NT and above just redirects them to the usual places. On Windows 98 it does ugly simulations of the actual original call. What I am most afraid of, if using Unicows, is that we will be destroying the validity of the tests. The main question, I guess, is whether these are Unicode tests (i.e. - tests meant to find out whether the Unicode functions are working correctly), or whether these are unrelated tests that merely use the Unicode interface. As for defining unicows.lib - we could do that, sure. We could either export everything there (Unicows.dll today is merely a redirection to the other functions), or we could make it a lib exporting nothing. The first is truer to what the real unicows.dll does (not 100% the same still, thankfully), but the second would probably work better. I would really prefer it if unicows.dll was only ever referenced by PE programs compiled on Windows. What could be a clean and acceptable solution? Your comments, please. The these are Unicode tests, use the Unicode interface. If these are just file system tests, I suggest you use the TCHAR functions. In other words, define your buffers as TCHAR buffer[] (rather than char or wchar), and call the functions without any prefix (neither W nor A). When compiling under NT, define a compiler variable UNICODE, which will map TCHAR to WCHAR. Now, I know that Wine code is forbidden from using the non-suffixed calls, but the wine tests are not Wine code, they are winelib applications. I don't think there is any problem in using these functions there. We could even run the tests both in ANSI and in Unicode mode, to compare results. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Lostwages: howto.diff
Hi, On Mon, Aug 15, 2005 at 05:39:39AM -0400, Tom Wickline wrote: On 8/15/05, Paul Vriens [EMAIL PROTECTED] wrote: As winecfg is currently THE tool why not refer to this (and maybe also to Winetools) this way more and more people will use it (and make it better?). for new versions of Wine winecfg is the default tool to setup/edit a setup. So I figured most people would use it in new versions. There is the possibility even probability new users won't know about winecfg... I was just recommending WineTools for people still using older versions of Wine. I'm sure the WineTools guys will fix there nifty tool to comply with the changes that have taken place. And I will be editing this page again to tell people to choose the front end of there choice. So do you think I should say if you use a version of Wine from 20050628 forward we recommend that you use winecfg, and for versions older than 20050628 use WineTools? I'd do it like that. winecfg can make use of some good testing, so we should trick people into using it... Just try to make sure that people won't get the impression that WineTools is simply a wine configuration tool, just like winecfg. It's a bit more than that, with its extension package installation (MSI, ODBC, IE, ...) and installation entries for common well-tested applications. Andreas
RE: dlls/shell32/pidl.c
From: Michael Jung SHBindToParent does not allocate a new PIDL for pidlLast, but returns a pointer to right location in pidl. This means you should not free it. There's still the problem that the shell folder isn't released in failure cases. Sorry, I didn't realize this. I feel a bit silly for not catching it either. MSDN is very clear about this. I've resubmitted a patch which only releases the interface pointer. Gé van Geldorp.
RE: calling *W functions in wt (Was: dlls/shell32/shfldr_desktop.c)
From: Saulius Krasuckas Hello Ge and especially unicoders: Alexandre, Dimi, Dmitry, Rob, Shachar, Troy and others. I am not sure of how should be file operations implemented in winetest: *FileW and *DirectoryW functions fail on every win9x box as they are unimplemented here. They succeed only when app is linked to MS Layer for Unicode (MSLU) and MSLU is installed. [1] Yeah, I see your point. I just followed the existing stuff in there, which was all Unicode. For routines which implement the Ansi function by calling the Unicode function with appropriate conversions, I guess it would be better to test the the Ansi function, since this implicitly tests the Unicode function too. Then again, this would make the test depend on internals of the functions, not good. So the only solution seems to be to test functions which have Ansi and Unicode implementations both ways (which is kind of boring to write) on NT and skip the Unicode tests on Win9x. Difficult stuff. I guess it's not an option to drop Win9x compatibility in Wine g. Ge van Geldorp.
Re: MSHMTL: Added QueryStatus implementation
Saulius Krasuckas wrote: * On Sun, 14 Aug 2005, Jacek Caban wrote: * Saulius Krasuckas wrote: Is something like this OK? I have borrowed boolean variable expect_SetActiveObject_active. Yes, it looks good. Does that mean by a chance it can to wine-patches? :-) Hello. Yes, it could, but I've tried to get other tests working on win 98, without success. It's possible that it won't work this way on 9x, so the best solution is to disable all tests after UIActivate fails. I'll do so today and send together with cleanup. Thanks, Jacek
Error on clean .wine for theming
Hi, just updated to current cvs and removed .wine: [EMAIL PROTECTED] paul]$ rm -rf .wine [EMAIL PROTECTED] paul]$ winecfg wine: creating configuration directory '/home/paul/.wine'... err:theming:THEMING_Initialize Could not re-register class LEdit: 582 wine: '/home/paul/.wine' created successfully. Error 582 (1410) is ERROR_CLASS_ALREADY_EXISTS. Is this really an ERR or should error 582 be ignored ? Cheers, Paul.
Re: Help with debugging needed
Hi, That thing gets more and more interesting: I was mislead by the belief that 'next' would behave as 'nexti' at the end of the known C code. But obviosly it doesn't. Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: First chance exception: page fault on read access to 0x in 32-bit code (0x). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP: ESP:7fc1fc58 EBP:7f2703e0 EFLAGS:00210293( - 00 RISA1C) EAX:7fe049f0 EBX:0001 ECX:7fe01b38 EDX:7803a11c ESI:7f288aa0 EDI:7f288acc Stack dump: 0x7fc1fc58: 7dbbd6d7 7fe049f0 7f288aa0 7f2703e0 0x7fc1fc68: 0001 7dbb1c20 7dbc59b4 0x7fc1fc78: 7f9f24fc 0001 7fa24015 7dbc5998 0x7fc1fc88: 7fa23451 7dbc5998 7f270838 0x7fc1fc98: 0002 7dbb9a14 7fa6bda1 0x7fc1fca8: 7fc1fd04 0052ba8b 5c575f20 Backtrace: =1 0x (0x7f2703e0) 2 0x (0x) 0x: addb%al,0x0(%eax) The surface to to release is in %eax and the 2nd element on the stack: 7fe049f0. From the log, a few lines before the crash: warn:ddraw:Main_DirectDrawSurface_ForceDestroy destroying surface 0x7fe049f0 with refcnt 1 The address of the function is taken from the surface structur and now points to 0x. (I do not expect a reply to this mail. I write it for a few reasons: *Someone might have seen something like this allready *Someone(maybe I) might search the archives sometimes and find this information usefull. If I shouldn't do so, just tell me)
Re: WLDAP32: implement ldap_result
Monday, August 15, 2005, 5:19:10, Hans Leidekker wrote: -Hans Changelog Implement ldap_result. This patch brakes cvs build: misc.c:58: error: `LDAP_NOT_SUPPORTED' undeclared (first use in this function) misc.c:58: error: (Each undeclared identifier is reported only once misc.c:58: error: for each function it appears in.) Vitaliy Margolen
Re: Help with debugging needed
Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: MSHTML: test cleanup
This time with the patch.
Changelog:
- Code cleanup
- Dissable tests after UIActivate failes (fixes tests win 9x)
Index: dlls/mshtml/tests/htmldoc.c
===
RCS file: /home/wine/wine/dlls/mshtml/tests/htmldoc.c,v
retrieving revision 1.8
diff -u -p -r1.8 htmldoc.c
--- dlls/mshtml/tests/htmldoc.c 15 Aug 2005 09:41:30 - 1.8
+++ dlls/mshtml/tests/htmldoc.c 15 Aug 2005 16:48:51 -
@@ -43,7 +43,6 @@
ok(called_ ## func, expected #func \n); \
expect_ ## func = called_ ## func = FALSE
-static IUnknown *htmldoc_unk = NULL;
static IOleDocumentView *view = NULL;
static HWND container_hwnd = NULL, hwnd = NULL, last_hwnd = NULL;
@@ -469,7 +468,7 @@ static HRESULT WINAPI DocumentSite_Activ
CHECK_EXPECT(ActivateMe);
ok(pViewToActivate != NULL, pViewToActivate = NULL\n);
-hres = IUnknown_QueryInterface(htmldoc_unk, IID_IOleDocument,
(void**)document);
+hres = IOleDocumentView_QueryInterface(pViewToActivate, IID_IOleDocument,
(void**)document);
ok(hres == S_OK, could not get IOleDocument: %08lx\n, hres);
if(SUCCEEDED(hres)) {
@@ -513,8 +512,15 @@ static HRESULT WINAPI DocumentSite_Activ
SET_EXPECT(SetActiveObject);
SET_EXPECT(ShowUI);
expect_SetActiveObject_active = TRUE;
+
hres = IOleDocumentView_UIActivate(view, TRUE);
+
+if(FAILED(hres)) {
+trace(UIActivate failed: %08lx\n, hres);
+return hres;
+}
ok(hres == S_OK, UIActivate failed: %08lx\n, hres);
+
CHECK_CALLED(CanInPlaceActivate);
CHECK_CALLED(GetWindowContext);
CHECK_CALLED(GetWindow);
@@ -796,14 +802,14 @@ static LRESULT WINAPI wnd_proc(HWND hwnd
return DefWindowProc(hwnd, msg, wParam, lParam);
}
-static void test_Persist()
+static void test_Persist(IUnknown *unk)
{
IPersistMoniker *persist_mon;
IPersistFile *persist_file;
GUID guid;
HRESULT hres;
-hres = IUnknown_QueryInterface(htmldoc_unk, IID_IPersistFile,
(void**)persist_file);
+hres = IUnknown_QueryInterface(unk, IID_IPersistFile,
(void**)persist_file);
ok(hres == S_OK, QueryInterface(IID_IPersist) failed: %08lx\n, hres);
if(SUCCEEDED(hres)) {
hres = IPersist_GetClassID(persist_file, NULL);
@@ -816,7 +822,7 @@ static void test_Persist()
IPersist_Release(persist_file);
}
-hres = IUnknown_QueryInterface(htmldoc_unk, IID_IPersistMoniker,
(void**)persist_mon);
+hres = IUnknown_QueryInterface(unk, IID_IPersistMoniker,
(void**)persist_mon);
ok(hres == S_OK, QueryInterface(IID_IPersistMoniker) failed: %08lx\n,
hres);
if(SUCCEEDED(hres)) {
hres = IPersistMoniker_GetClassID(persist_mon, NULL);
@@ -872,12 +878,18 @@ static const OLECMDF expect_cmds[OLECMDI
OLECMDF_SUPPORTED /* OLECMDID_GETPRINTTEMPLATE */
};
-static void test_OleCommandTarget(IOleCommandTarget *cmdtrg)
+static void test_OleCommandTarget(IUnknown *unk)
{
+IOleCommandTarget *cmdtrg;
OLECMD cmds[OLECMDID_GETPRINTTEMPLATE];
int i;
HRESULT hres;
+hres = IUnknown_QueryInterface(unk, IID_IOleCommandTarget,
(void**)cmdtrg);
+ok(hres == S_OK, QueryInterface(IIDIOleM=CommandTarget failed: %08lx\n,
hres);
+if(FAILED(hres))
+return;
+
for(i=0; iOLECMDID_GETPRINTTEMPLATE; i++) {
cmds[i].cmdID = i+1;
cmds[i].cmdf = 0xf0f0;
@@ -891,20 +903,63 @@ static void test_OleCommandTarget(IOleCo
ok(cmds[i].cmdf == expect_cmds[i+1], cmds[%d].cmdf=%lx, expected
%x\n,
i+1, cmds[i].cmdf, expect_cmds[i+1]);
}
+
+IOleCommandTarget_Release(cmdtrg);
}
-static void test_HTMLDocument(void)
+static void test_OleCommandTarget_fail(IUnknown *unk)
{
-IOleObject *oleobj = NULL;
-IOleClientSite *clientsite = (LPVOID)0xdeadbeef;
-IOleInPlaceObjectWindowless *windowlessobj = NULL;
-IOleInPlaceActiveObject *activeobject = NULL;
-IOleCommandTarget *cmdtrg = NULL;
-GUID guid;
-RECT rect = {0,0,500,500};
+IOleCommandTarget *cmdtrg;
+int i;
HRESULT hres;
-ULONG ref;
+OLECMD cmd[2] = {
+{OLECMDID_OPEN, 0xf0f0},
+{OLECMDID_GETPRINTTEMPLATE+1, 0xf0f0}
+};
+
+hres = IUnknown_QueryInterface(unk, IID_IOleCommandTarget,
(void**)cmdtrg);
+ok(hres == S_OK, QueryInterface(IIDIOleM=CommandTarget failed: %08lx\n,
hres);
+if(FAILED(hres))
+return;
+
+
+
+hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 0, NULL, NULL);
+ok(hres == S_OK, QueryStatus failed: %08lx\n, hres);
+
+hres = IOleCommandTarget_QueryStatus(cmdtrg, NULL, 2, cmd, NULL);
+ok(hres == OLECMDERR_E_NOTSUPPORTED,
+QueryStatus failed: %08lx, expected OLECMDERR_E_NOTSUPPORTED\n,
hres);
+ok(cmd[1].cmdID == OLECMDID_GETPRINTTEMPLATE+1,
+
Re: Help with debugging needed
Am Montag, 15. August 2005 17:07 schrieb Lionel Ulmer: Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Sure. The log can be found at www.doesi.gmxhome.de/ee-ddraw.log.gz (38KB) Stefan
Re: Help with debugging needed
Am Montag, 15. August 2005 17:07 schrieb Lionel Ulmer: Well, Empire Earth doesn't crash on return from Main_DirectDraw_Release, but quite a bit later in its own code. It tries to call Main_DirectDrawSurfaceRelease for an allready freed surface: From the crash dump: Could you put the +ddraw trace somewhere on the web ? This suspiciously looks like a reference counting issue either in the application or in the Wine code. Oh, I forgot to add that I've done a little change to the ddraw code. Empire Earth calls Main_DirectDraw_SetCooperativeLevel with cooplevel == DDSCL_SETFOCUSWINDOW and expects a successfull result. I don't think that this is related to the problem. I've also modified dlls/ntdll/heap.c to allways fill freed heap areas with 0x. Stefan Index: dlls/ddraw/ddraw_main.c === RCS file: /home/wine/wine/dlls/ddraw/ddraw_main.c,v retrieving revision 1.8 diff -u -r1.8 ddraw_main.c --- dlls/ddraw/ddraw_main.c 26 Jul 2005 20:10:51 - 1.8 +++ dlls/ddraw/ddraw_main.c 15 Aug 2005 17:18:55 - @@ -1120,6 +1120,7 @@ return DDERR_HWNDALREADYSET; */ +if(cooplevel == DDSCL_SETFOCUSWINDOW) return DD_OK; if (!(cooplevel (DDSCL_EXCLUSIVE|DDSCL_NORMAL))) return DDERR_INVALIDPARAMS;
Re: Help Please
How dumb icone of wine in kde? I want to place my image when to minimize it ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/
Re: lostwages/templates/en howto.template
Log message: Tom Wickline [EMAIL PROTECTED] spelling fix, doc update +pIf your using an old version of Wine we recommend that you use a handy program called Sorry to spot this once it has been committed :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
How dumb icone of wine in kde? I want to place my image when to minimize it
How dumb icone of wine in kde? I want to place my image when to minimize it ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/
Re: Lostwages: howto.diff #2
On Mon, Aug 15, 2005 at 05:14:27PM -0400, Tom Wickline wrote: Changelog: Spelling fix and doc update Note that the 'if your running' typo is still here. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
Robert Reif wrote:
Only the primary buffer supports hardware acceleration. The secondary
buffer(s) are implemented in software and mixed into the primary buffer.
The formats (mono/stereo, 8/16 bit samples, and sample rate) of the
primary and secondary buffers are totally independent and can be
anything.
One of the dsound tests keeps the primary buffer format constant and
iterates through all secondary buffer formats and another keeps the
secondary buffer format constant and iterates through all possible
primary formats.
This is probably what you are seeing. The secondary buffer format
has nothing to do with what is sent to the hardware.
The first test that fails with the ALSA driver is the so-called
reference tone, which, as far as I could see, is played with a primary
buffer, and no secondary buffer. The reference tone uses the hardware
position directly, which wraps around at a buffer size that changes
unexpectedly when switching playback formats. I have prepared a patch
that fixes this, by re-querying the buffer size in the case of a
primary buffer, and displaying a warning if it detects a buffer size
change. However, I don't know if the buffer size is supposed to remain
constant across buffer format changes. If it does, then the patch would
need to be modified to mark this as a TODO.
Changelog:
* Re-query buffer capabilities after format change, and display warning
if buffer size changed after format change. Fixes reference playback
with ALSA.
diff -uN wine-20050725-cvs/dlls/dsound/tests/ds3d8.c wine-20050725-cvs-patch/dlls/dsound/tests/ds3d8.c
--- wine-20050725-cvs/dlls/dsound/tests/ds3d8.c 2005-06-20 09:18:04.0 -0500
+++ wine-20050725-cvs-patch/dlls/dsound/tests/ds3d8.c 2005-08-13 11:35:55.0 -0500
@@ -254,6 +254,8 @@
ok(status==0,status=0x%lx instead of 0\n,status);
if (is_primary) {
+DWORD previous_buffer_size;
+
/* We must call SetCooperativeLevel to be allowed to call SetFormat */
/* DSOUND: Setting DirectSound cooperative level to DSSCL_PRIORITY */
rc=IDirectSound8_SetCooperativeLevel(dso,get_hwnd(),DSSCL_PRIORITY);
@@ -292,6 +294,29 @@
wfx.nChannels,wfx.nAvgBytesPerSec,wfx.nBlockAlign);
}
+/* Not all sound implementations guarantee that the buffer size will remain
+ unchanged after a successful SetFormat() call. For example, ALSA is known
+ to change buffer sizes when requested to change sound format. So the
+ buffer capabilities are re-queried in order to play the samples correctly.
+
+ TODO: is this a Windows DirectSound requirement? (bufsize constant across
+ format changes)
+ */
+previous_buffer_size = dsbcaps.dwBufferBytes;
+dsbcaps.dwSize=sizeof(dsbcaps);
+rc=IDirectSoundBuffer_GetCaps(dsbo,dsbcaps);
+ok(rc==DS_OK,IDirectSoundBuffer_GetCaps() failed: %s\n,
+ DXGetErrorString8(rc));
+if (rc==DS_OK winetest_debug 1) {
+trace(Caps (again): flags=0x%08lx size=%ld\n,dsbcaps.dwFlags,
+ dsbcaps.dwBufferBytes);
+}
+/* should the following check be marked as a TODO? */
+if (previous_buffer_size != dsbcaps.dwBufferBytes) {
+trace(buffer size changed after SetFormat() - previous size is %lu, current size is %lu\n,
+previous_buffer_size, dsbcaps.dwBufferBytes);
+}
+
/* Set the CooperativeLevel back to normal */
/* DSOUND: Setting DirectSound cooperative level to DSSCL_NORMAL */
rc=IDirectSound8_SetCooperativeLevel(dso,get_hwnd(),DSSCL_NORMAL);
diff -uN wine-20050725-cvs/dlls/dsound/tests/ds3d.c wine-20050725-cvs-patch/dlls/dsound/tests/ds3d.c
--- wine-20050725-cvs/dlls/dsound/tests/ds3d.c 2005-07-15 13:36:52.0 -0500
+++ wine-20050725-cvs-patch/dlls/dsound/tests/ds3d.c 2005-08-12 20:53:54.0 -0500
@@ -362,6 +362,8 @@
ok(status==0,status=0x%lx instead of 0\n,status);
if (is_primary) {
+DWORD previous_buffer_size;
+
/* We must call SetCooperativeLevel to be allowed to call SetFormat */
/* DSOUND: Setting DirectSound cooperative level to DSSCL_PRIORITY */
rc=IDirectSound_SetCooperativeLevel(dso,get_hwnd(),DSSCL_PRIORITY);
@@ -400,6 +402,29 @@
wfx.nChannels,wfx.nAvgBytesPerSec,wfx.nBlockAlign);
}
+/* Not all sound implementations guarantee that the buffer size will remain
+ unchanged after a successful SetFormat() call. For example, ALSA is known
+ to change buffer sizes when requested to change sound format. So the
+ buffer capabilities are re-queried in order to play the samples correctly.
+
+ TODO: is this a Windows DirectSound requirement? (bufsize constant across
+ format changes)
+ */
+previous_buffer_size = dsbcaps.dwBufferBytes;
+
Re: WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
Alex Villacís Lasso wrote: The first test that fails with the ALSA driver is the so-called reference tone, which, as far as I could see, is played with a primary buffer, and no secondary buffer. The reference tone uses the hardware position directly, which wraps around at a buffer size that changes unexpectedly when switching playback formats. I have prepared a patch that fixes this, by re-querying the buffer size in the case of a primary buffer, and displaying a warning if it detects a buffer size change. However, I don't know if the buffer size is supposed to remain constant across buffer format changes. If it does, then the patch would need to be modified to mark this as a TODO. Fix the wine ALSA driver rather than the test unless you can prove that the test fails on Windows.
Lines of code in Wine?
Hello, I was looking at our line count so I could update the history page and the FAQ with new up to date numbers. And my numbers come no where close to what has been reported in the past. anyone care to generate the current line count ? Here is the numbers I get if anyone is interested. Wine: ansic: 1025534 (96.99%) perl: 18339 (1.73%) yacc: 6503 (0.61%) sh:4064 (0.38%) lex: 2916 (0.28%) awk: 54 (0.01%) Total = 1,057,410 Lostwages: php: 1469 (100.00%) Total = 1,469 AppDB: php: 9034 (97.78%) perl: 185 (2.00%) sh: 20 (0.22%) Total = 9,239 Tools: perl: 3725 (81.71%) python: 572 (12.55%) exp:140 (3.07%) php:115 (2.52%) sh: 7 (0.15%) Total = 4,559 kernel-win32: ansic: 6269 (100.00%) Total = 6,269 Grand Total = 1,078,946 Tom
Re: Lines of code in Wine?
On 8/15/05, Tom Wickline [EMAIL PROTECTED] wrote: I was looking at our line count so I could update the history page and the FAQ with new up to date numbers. And my numbers come no where close to what has been reported in the past. anyone care to generate the current line count ? Alexandre mentioned we were rapidly approaching 1.4 million at WineConf and I'm sure we're past that now (avg = 700 /day). I'm not exactly sure how he calculated that number, but I'm inclined to believe it's right. -Brian
Re: [Bug 3220] New: PowerFinder now braindead checking for msvcrt.dll
I have narrowed this bug down to local configuration options for PowerFinder.exe. When msvcrt and msvcrt40 are both set to 'native' *or* 'native' then 'builtin', the application functions as expected. If there's any way I can help narrow this down for you, please let me know. Thanks.
Proposed interface for file operations by the file dialog code (dlls\commdlg\filedlg*.c)
References:
http://www.winehq.org/hypermail/wine-patches/2005/08/0265.html
http://www.winehq.org/hypermail/wine-devel/2005/08/0286.html
Background:
Work is currently proceeding on a branched version to create additional
APIs
for WINE that use UNIX path names rather than Windows ones. This is
useful
for Winelib apps and seeks to make them look more like they are native
apps,
thereby addressing some of the complaints that Winelib apps are somehow
of
lesser status than ports using other APIs. After some discussion, it was
decided that this would remain a branch until at least such time as the
implementation was proven to work in real-world situations.
Part of this involves producing file dialog APIs that operate
appropriately
in this context. That includes taking UNIX path names on input,
producing
UNIX path names on output and in callbacks to the application, and
browsing a
heirarchy that does not include windows-isms such as drive letters.
To make modifications directly in the existing code would result in a
set of
differences that would result in significant headaches for branch
maintenance
and any future merge-back to WineHQ. The objective is to reduce the
differences so as to improve compatibility between the branches.
The patch referenced above took a minimal-change approach to this
problem by
implementing an interface that mostly implemented the small operations
made
by the existing code, without even putting in local stubs (hence the
inconsistent calling conventions in the interface).
The general principle I have used is that path names should, as far as
possible, be opaque so that the file dialog code itself never examines
their
contents directly, but rather calls functions in the interface to
extract or
locate particular portions of the path, to modify or concatenate paths
or to
make use of the paths.
The minimalist interface:
typedef struct
{
UINTcode_page;
WCHAR sep_char;
HRESULT WINAPI (*get_top_folder)(IShellFolder **);
LPITEMIDLIST(*get_pidl_from_name)(IShellFolder *, LPWSTR);
BOOL(*get_display_name) (LPCITEMIDLIST, LPWSTR);
IShellFolder* (*get_folder_from_pidl)(LPITEMIDLIST);
BOOLWINAPI (*change_directory) (LPCWSTR);
UINTWINAPI (*get_directory)(UINT, LPWSTR);
void(*qualify_path) (LPWSTR, LPCWSTR);
void(*complete_path)(LPWSTR);
BOOL(*has_invalid_char) (LPCWSTR);
LPWSTR WINAPI (*find_next_component) (LPCWSTR);
LPWSTR WINAPI (*find_file_name) (LPCWSTR);
LPWSTR WINAPI (*find_extension) (LPCWSTR);
BOOLWINAPI (*file_exists) (LPCWSTR);
BOOLWINAPI (*is_directory) (LPCWSTR);
LPWSTR WINAPI (*add_dir_sep) (LPWSTR);
DWORD WINAPI (*get_full_path)(LPCWSTR, DWORD,
LPWSTR, LPWSTR*);
} FileDlgFileOps;
Minimalist interface vs ideal interface:
On IRC this morning Alexandre said he would prefer a well-designed
interface
to the minimalist approach, hence this discussion.
Since the interface is entirely internal to commdlg, I will use cdecl
calling
conventions.
Detailed discussion follows.
The code_page member was put there because the UNIX file name APIs may not use
the same code page as other A entry points. WINE uses CP_ACP (as does Windows
- although CP_THREAD_ACP is subject to further investigation) for most
purposes, but CP_UNIXCP for UNIX path names when translating them to UTF16.
Often CP_UNIXCP will be something like UTF8, or it may be ISO8859-1 in
situations where Windows would use CP1252. It may be that a Winelib
application should have CP_ACP set to be the UNIX code page, but they may not
(and unless they do something special will not.
So places where A-W or W-A conversions happen on path names need to make
sure they use the right code page in the context. The minimalist approach was
to make this a data member, but the ideal approach would be to have functions
which performed the appropriate conversions. Looking through the existing
code, the conversions are performed in some contexts where the output is
allocated, and others where the output is a fixed size buffer. If we want to
have just one conversion function for each direction, this would give us:
CHAR *filename_wtoa(WCHAR const *in, CHAR *out, int bufrange);
WCHAR *filename_atow(CHAR const *in, WCHAR *out, int bufrange);
in is the input buffer.
Re: [MSXML]xmlnode_get_nodeName Implementation
Hi Vijay, Vijay Kiran Kamuju wrote: i think it would be better if we put bstr_from_xmlChar in msxml_private.h need directions how to implement domdoc_get_nodeName I'll post a patch to move bstr_from_xmlChar and other utility functions somewhere else in the code later. please comment on the patch For now the basics of msxml3 aren't really decided (eg. how to map xmlNodePtr to IXMLDOMNode, etc), and how to manage the relationship between nodes. The way I'm managing node pointers will probably change again. What I really need is more test cases, so if you have any msxml test cases lying around, then let me know. Mike
Re: [MSXML]xmlnode_get_nodeName Implementation
Hi Mike, I am planning to write some tests for IXMLDOMNode. I need your help on how to write tests in the wine test framework and test on the windows framework. Thanks, Vijay On 8/16/05, Mike McCormack [EMAIL PROTECTED] wrote: Hi Vijay, Vijay Kiran Kamuju wrote: i think it would be better if we put bstr_from_xmlChar in msxml_private.h need directions how to implement domdoc_get_nodeName I'll post a patch to move bstr_from_xmlChar and other utility functions somewhere else in the code later. please comment on the patch For now the basics of msxml3 aren't really decided (eg. how to map xmlNodePtr to IXMLDOMNode, etc), and how to manage the relationship between nodes. The way I'm managing node pointers will probably change again. What I really need is more test cases, so if you have any msxml test cases lying around, then let me know. Mike
Re: [MSXML]xmlnode_get_nodeName Implementation
Vijay Kiran Kamuju wrote:
I am planning to write some tests for IXMLDOMNode.
I need your help on how to write tests in the wine test framework and
test on the windows framework.
I started a simple test case in dlls/msxml3/tests/domdoc.c. I modify it
a little bit to get it to compile under MSVC 6.0. I've attached the
diff from the version that compiles on Windows.
Mike
--- /home/mike/testprogs/xmltest/xmltest.c 2005-08-11 13:10:52.0 +0900
+++ /home/mike/wine/dlls/msxml3/tests/domdoc.c 2005-08-12 20:25:05.0 +0900
@@ -27,8 +27,7 @@
#include xmldom.h
#include stdio.h
-//#include wine/test.h
-#define ok(cond,str) do{ if(!(cond)) fprintf(stderr,line %d: %s,__LINE__,str); }while (0)
+#include wine/test.h
void test_domdoc( void )
{
@@ -80,7 +79,7 @@ void test_domdoc( void )
r = CoCreateInstance( CLSID_DOMDocument, NULL,
CLSCTX_INPROC_SERVER, IID_IXMLDOMDocument, (LPVOID*)doc );
-ok( r == S_OK, failed to create an xml dom doc\n );
+/* ok( r == S_OK, failed to create an xml dom doc\n ); */
if( r != S_OK )
return;
@@ -199,8 +198,7 @@ void test_domdoc( void )
ok( r == S_OK, failed to uninit com\n);
}
-//START_TEST(domdoc)
-main(int argc, char **argv)
+START_TEST(domdoc)
{
test_domdoc();
}
Re: [MSXML]xmlnode_get_nodeName Implementation
Hi Mike, Do we have to register the IXMLDOMNode to the registry? As you did in the test for domdoc. I think we need to add all other basic interface's CLSID's to the registry? Thanks, Vijay On 8/16/05, Mike McCormack [EMAIL PROTECTED] wrote: Vijay Kiran Kamuju wrote: I am planning to write some tests for IXMLDOMNode. I need your help on how to write tests in the wine test framework and test on the windows framework. I started a simple test case in dlls/msxml3/tests/domdoc.c. I modify it a little bit to get it to compile under MSVC 6.0. I've attached the diff from the version that compiles on Windows. Mike
Re: [MSXML]xmlnode_get_nodeName Implementation
Vijay Kiran Kamuju wrote: Do we have to register the IXMLDOMNode to the registry? As you did in the test for domdoc. I think we need to add all other basic interface's CLSID's to the registry? IXMLDOMNode is an interface, which has an IID, not a CLSID. We don't need to register interfaces for the moment, only CLSIDs. The other CLSID we might want to register is CLSID_XMLDocument, but there's no implementation of that for the moment. I have a stub in my tree, but I haven't submitted it as yet. Interfaces only need to be registered if we want OLE automation (eg. IXMLDOMNode-Invoke()) to work, and I think they can be registered automatically using oleaut32.RegisterTypeLib(). Mike
