XEmbed systray patch bugs
Hi Mike and Rob, I tried your patch for XEmbed systray support, and I'm pretty impressed with it. I think it's about time someone finally dusted this one off and tried to get it committed. But, I've noticed some issues: 1. The Wine-Systray window is still showing up. I've been able to fix this by getting rid of the WS_VISIBLE style when creating the window in systray.c, and then manually showing the window after it's been docked. 2. The rightmost edges of systray icons are cut off. The previous fix seemed to work for this problem too. I think it has something to do with painting/updating the embedded window. 3. Sometimes, systray icons don't show up at all. I notice this when exiting a program that uses systray and then starting it again. On the second consecutive run, the icon doesn't show up at all. It must be some kind of window-management problem, because I still see the Wine-systray window after after the program I'm using exits. I can only make it go away after restarting my window manager (Metacity with the GNOME desktop) Looks like some kind of cleanup issue. I'm working on this one. For reference, the two programs I've been using for testing are Palm Hotsync and Steam. When I get some more free time, I'll put together a simpler test case to nail down that third problem. All that aside, good work guys! :) James
Re: Fwd: amblksize definition
* On Mon, 19 Sep 2005, Vijay Kiran Kamuju wrote: amblksize definition in msvcrt. Wouldn't it be nice to establish a real variable somewhere in the msvcrt code?
Re: DDRAW: Fix reference counting
Hi, Why do you increase the refcount by 2? Since you add and release them in the same functions, it is not really necessary and just adds complexity to the code. Well, Windows does so for some reason, and after what I've seen with Empire Earth, I suspect that there are some apps out there which depend on things like this. It's unlikely, but I would not be surprised if that happens. if (!FAILED(hr)) - if (SUCCEEDED(hr)) Could have guesses this one. Thanks. Thanks, for your suggestions, Stefan
Re: Fwd: amblksize definition
I will be initializing that variable to 16, in msvcrt's heap.c In that way it would be in msvcrt's code. There are some diffreneces between the value returned and the documentation.On 9/19/05, Saulius Krasuckas [EMAIL PROTECTED] wrote:* On Mon, 19 Sep 2005, Vijay Kiran Kamuju wrote: amblksize definition in msvcrt. Wouldn't it be nice to establish a real variable somewhere in the msvcrtcode?
Re: hhctrl: Correctly draw the navigation pane
Robert Shearman [EMAIL PROTECTED] wrote: @@ -149,7 +144,7 @@ static void HH_RegisterChildWndClass(HHI wcex.hInstance = pHHInfo-hInstance; wcex.hIcon = LoadIconW(NULL, (LPCWSTR)IDI_APPLICATION); wcex.hCursor= LoadCursorW(NULL, (LPCWSTR)IDC_ARROW); -wcex.hbrBackground = (HBRUSH)(COLOR_3DFACE); +wcex.hbrBackground = (HBRUSH)(COLOR_MENU); This doesn't seem right. You're not registering a menu-like class. Moreover, when using COLOR_xxx constants in the place of a brush one needs to increase the value by 1 in order to make it work. dlls/msi/dialog.c, dlls/shlwapi/ordinal.c, programs/notepad/main.c have the same problem. -- Dmitry.
Re: Fwd: amblksize definition
please ignore this patch, i'll be sending a more correct patch.On 9/19/05, Vijay Kiran Kamuju [EMAIL PROTECTED] wrote:I will be initializing that variable to 16, in msvcrt's heap.c In that way it would be in msvcrt's code. There are some diffreneces between the value returned and the documentation.On 9/19/05, Saulius Krasuckas [EMAIL PROTECTED] wrote:* On Mon, 19 Sep 2005, Vijay Kiran Kamuju wrote: amblksize definition in msvcrt. Wouldn't it be nice to establish a real variable somewhere in the msvcrtcode?
Re: msvcrt spec changes
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: added reference to kernel32.GetLocalTime to _getsystime stub function (support.microsoft.com/default.aspx?scid=kb;en-us;99456) -@ stub _getsystime #(ptr) +@ cdecl _getsystime(ptr) kernel32.GetLocalTime You can't just forward _getsystime to GetLocalTime, they accept different arguments: struct tm * vs. SYSTEMTIME *. Have a look at your MSVC docs. -- Dmitry.
Re: msvcrt spec changes
I couldnt get the necessary info on it from msdn. Ill be sending a new patch for with the change for _getsystemtimeOn 9/19/05, Dmitry Timoshkov [EMAIL PROTECTED] wrote:Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: added reference to kernel32.GetLocalTime to _getsystime stub function (support.microsoft.com/default.aspx?scid=kb;en-us;99456 ) -@ stub _getsystime #(ptr) +@ cdecl _getsystime(ptr) kernel32.GetLocalTimeYou can't just forward _getsystime to GetLocalTime, they accept differentarguments: struct tm * vs. SYSTEMTIME *. Have a look at your MSVC docs. --Dmitry.
Re: msvcrt spec changes
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: I couldnt get the necessary info on it from msdn. MinGW should have all the necessary info as well. -- Dmitry.
Take 2: DDRAW: Fix reference counting
Hello,
This patch increases the reference count of a DirectDraw object when a Surface
is created, like Windows does. It also adds a test which tests this
functionality.
This time with the !FAILED() - SUCCEEDED() suggestion from
Robert Shearman. I kept adding a secound refcount in case of DDSCAPS_TEXTURE
surfaces to achieve more compatiblity with Windows.
Stefan
Index: dlls/ddraw/ddraw_main.c
===
RCS file: /home/wine/wine/dlls/ddraw/ddraw_main.c,v
retrieving revision 1.9
diff -u -r1.9 ddraw_main.c
--- dlls/ddraw/ddraw_main.c 12 Sep 2005 14:12:47 - 1.9
+++ dlls/ddraw/ddraw_main.c 19 Sep 2005 12:57:07 -
@@ -697,8 +697,10 @@
}
else if (pDDSD-ddsCaps.dwCaps DDSCAPS_TEXTURE)
{
- /* create texture */
+ /* create texture. This increases the DD refcount by 2 */
hr = create_texture(This, pDDSD, ppSurf, pUnkOuter);
+ if(SUCCEEDED(hr))
+ IDirectDraw7_AddRef(iface); /* Plus the increase at the end of the function */
}
else if ( (pDDSD-ddsCaps.dwCaps DDSCAPS_ZBUFFER)
!(pDDSD-ddsCaps.dwCaps DDSCAPS_OFFSCREENPLAIN)) /* Support DDSCAPS_SYSTEMMEMORY */
@@ -724,6 +726,9 @@
return hr;
}
+/* Finally, increase the reference count of the DD interface */
+IDirectDraw7_AddRef(iface);
+
return DD_OK;
}
Index: dlls/ddraw/surface_main.c
===
RCS file: /home/wine/wine/dlls/ddraw/surface_main.c,v
retrieving revision 1.5
diff -u -r1.5 surface_main.c
--- dlls/ddraw/surface_main.c 12 Sep 2005 14:12:47 - 1.5
+++ dlls/ddraw/surface_main.c 19 Sep 2005 12:57:10 -
@@ -124,6 +124,8 @@
{
IDirectDrawSurfaceImpl *This = (IDirectDrawSurfaceImpl *)iface;
ULONG ref = InterlockedDecrement(This-ref);
+LPDIRECTDRAW7 lpDD = (LPDIRECTDRAW7) This-ddraw_owner;
+DWORD dwCaps = This-surface_desc.ddsCaps.dwCaps;
TRACE((%p)-(): decreasing from %ld\n, This, ref + 1);
@@ -133,6 +135,12 @@
This-aux_release(This-aux_ctx, This-aux_data);
Main_DirectDrawSurface_Destroy(This);
+/* Release the DirectDraw owner */
+IDirectDraw7_Release(lpDD);
+/* A secound release for DDSCAPS_TEXTURE surfaces */
+if(dwCaps DDSCAPS_TEXTURE)
+IDirectDraw7_Release(lpDD);
+
TRACE(released surface %p\n, This);
return 0;
Index: dlls/ddraw/tests/Makefile.in
===
RCS file: /home/wine/wine/dlls/ddraw/tests/Makefile.in,v
retrieving revision 1.5
diff -u -r1.5 Makefile.in
--- dlls/ddraw/tests/Makefile.in 7 Jun 2005 21:34:59 - 1.5
+++ dlls/ddraw/tests/Makefile.in 19 Sep 2005 12:57:10 -
@@ -9,7 +9,8 @@
CTESTS = \
d3d.c \
ddrawmodes.c \
- dsurface.c
+ dsurface.c \
+ refcount.c
@MAKE_TEST_RULES@
--- /dev/null 2005-09-01 15:22:32.0 +0200
+++ dlls/ddraw/tests/refcount.c 2005-09-18 21:57:52.0 +0200
@@ -0,0 +1,197 @@
+/*
+ * Unit tests for DirectDraw refcounts
+ *
+ * Copyright (C) 2005 Stefan Dösinger
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include assert.h
+#include wine/test.h
+#include ddraw.h
+
+static LPDIRECTDRAW7 lpDD = NULL;
+static WNDCLASS wc;
+static HWND hwnd;
+
+static void CreateDirectDraw(void)
+{
+wc.style = CS_HREDRAW | CS_VREDRAW;
+wc.lpfnWndProc = DefWindowProcA;
+wc.cbClsExtra = 0;
+wc.cbWndExtra = 0;
+wc.hInstance = GetModuleHandleA(0);
+wc.hIcon = LoadIconA(wc.hInstance, IDI_APPLICATION);
+wc.hCursor = LoadCursorA(NULL, IDC_ARROW);
+wc.hbrBackground = (HBRUSH) GetStockObject(BLACK_BRUSH);
+wc.lpszMenuName = NULL;
+wc.lpszClassName = TestWindowClass;
+if(!RegisterClassA(wc))
+assert(0);
+
+hwnd = CreateWindowExA(0, TestWindowClass, TestWindowClass,
+WS_POPUP, 0, 0,
+GetSystemMetrics(SM_CXSCREEN),
+GetSystemMetrics(SM_CYSCREEN),
+NULL, NULL, GetModuleHandleA(0), NULL);
+assert(hwnd != NULL);
+
+ShowWindow(hwnd, SW_HIDE);
+UpdateWindow(hwnd);
+SetFocus(hwnd);
+
+HRESULT rc;
+
+rc = DirectDrawCreateEx(NULL, (LPVOID *) lpDD, IID_IDirectDraw7, NULL);
+ok(rc==DD_OK,DirectDrawCreateEx returned: %lx\n,rc);
+
+rc = IDirectDraw7_SetCooperativeLevel(lpDD, hwnd,
Re: server: Try2: add case-sensitivity comparison flag to find_object co
Vitaliy Margolen [EMAIL PROTECTED] writes: I guess this one got lost. Resend it. Or is there anything wrong with it? Well, you didn't change create_named_object, which looks suspicious. Also I'd really like to see some regression tests for the behavior of the various objects. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DDRAW: Fix reference counting
On Mon, Sep 19, 2005 at 09:27:05AM +0200, Stefan D?singer wrote: Hi, Why do you increase the refcount by 2? Since you add and release them in the same functions, it is not really necessary and just adds complexity to the code. Well, Windows does so for some reason, and after what I've seen with Empire Earth, I suspect that there are some apps out there which depend on things like this. It's unlikely, but I would not be surprised if that happens. In that case, it would be really beneficial with a unit test. Both as documentation and to see what Windows does. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News
Re: comctl32.dll: Running siap and modules under wine, first steps
On Saturday 17 September 2005 20:45, Robert Shearman wrote: Start the program with WINEDEBUG=+treeview wine program.exe treeview.log and send the treeview log to the list (compressed if it is over 50kB). It's about 31 Kb, it gets to the line 272 to open the main window and showing the treeview, as shown in the screenshot. The rest is just the program closing. I don't know if this could actually help but, I've noticed, after looking fiercely at the log, that the tree is being set to expand, but the Paint seems to only be calling DrawItem to the root (twice), but looking at the code I can't tell wheter the TREEVIEW_Expand is not setting the siblings to visible or if TREEVIEW_Paint is just failling. -- Saludos, /\/\ /\ `/ trace:treeview:TREEVIEW_Register err:statusbar:StatusWindowProc unknown msg 2210 wp=0001 lp=00010036 fixme:time:GetCalendarInfoA (0409,0001,2030,(nil),0,0x7fb9ee58): quarter-stub fixme:time:GetCalendarInfoW (0409,0001,2030,(nil),0,0x7fb9ee58): quarter-stub err:statusbar:StatusWindowProc unknown msg 2210 wp=0001 lp=0001006a trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0081 wp= lp=7fb9f4d4 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0083 wp= lp=7fb9f294 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0001 wp= lp=7fb9f4d4 trace:treeview:TREEVIEW_Create wnd 0x2007c, style 4622 trace:treeview:TREEVIEW_NotifyFormat (hwndFrom=0x10068, nCommand=4) trace:treeview:TREEVIEW_NotifyFormat format=1 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0030 wp=0b84 lp= trace:treeview:TREEVIEW_SetFont 0xb84 0 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1107 wp=000d lp= trace:treeview:TREEVIEW_SetIndent trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0005 wp= lp=009d0172 trace:treeview:TREEVIEW_SetFirstVisible (nil): null item trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0003 wp= lp=00890002 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 2210 wp=0001 lp=0002007c trace:treeview:TREEVIEW_WindowProc Unknown msg 2210 wp=0001 lp=0002007c trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0018 wp=0001 lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0046 wp= lp=7fb9f204 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0047 wp= lp=7fb9f204 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0085 wp=0001 lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0014 wp=00a8 lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1109 wp= lp= trace:treeview:TREEVIEW_SetImageList 0,(nil) trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1106 wp= lp= trace:treeview:TREEVIEW_GetIndent trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1107 wp=0013 lp= trace:treeview:TREEVIEW_SetIndent trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 000f wp=00a8 lp= trace:treeview:TREEVIEW_Paint trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 0014 wp=0148 lp= trace:treeview:TREEVIEW_SendCustomDrawNotify drawstage:1 hdc:0xa8 trace:treeview:TREEVIEW_SendRealNotify wParam=0, lParam=2142893472 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 000f wp=00a8 lp= trace:treeview:TREEVIEW_Paint trace:treeview:TREEVIEW_SendCustomDrawNotify drawstage:1 hdc:0xa8 trace:treeview:TREEVIEW_SendRealNotify wParam=0, lParam=2142893472 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1109 wp= lp= trace:treeview:TREEVIEW_SetImageList 0,(nil) trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1109 wp= lp=7ff54800 trace:treeview:TREEVIEW_SetImageList 0,0x7ff54800 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1101 wp= lp= trace:treeview:TREEVIEW_DeleteItem TVI_ROOT trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_ValidItem invalid item (nil) trace:treeview:TREEVIEW_SetFirstVisible (nil): null item trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 000b wp= lp= trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1100 wp= lp=7fb9f68c trace:treeview:TREEVIEW_InsertItemT parent 0x7ff3a018 position 0x0002: callback trace:treeview:TREEVIEW_DoSetItemT item 0x7ff57518 trace:treeview:TREEVIEW_DoSetItemT setting callback, item 0x7ff57518 trace:treeview:TREEVIEW_InsertItemT new item 0x7ff57518; parent 0x7ff3a018, mask 27 trace:treeview:TREEVIEW_UpdateDispInfo mask 1 callbackMask 23 trace:treeview:TREEVIEW_SendRealNotify wParam=0, lParam=2142892700 trace:treeview:TREEVIEW_UpdateDispInfo same buffer str , len=1, buflen=260 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 110d wp= lp=7fb9f6c8 trace:treeview:TREEVIEW_SetItemT item 1,mask 4 trace:treeview:TREEVIEW_DoSetItemT item 0x7ff57518 trace:treeview:TREEVIEW_WindowProc hwnd 0x2007c msg 1100 wp= lp=7fb9f68c
Re: server: Try2: add case-sensitivity comparison flag to find_object co
Vitaliy Margolen [EMAIL PROTECTED] writes: Ah, I see. I new I was missing something. As far as regression testing - most of the named objects created from kernel32 and they are case insensitive. I purposely left it case sensitive to keep it same way as it was before. I know of at least named pipes that fail with current code, if I start mixing case - which does work on windows. That's why we need regression tests. If things currently fail you can add todo_wine, but we need to know what the exact behavior is supposed to be. -- Alexandre Julliard [EMAIL PROTECTED]
Re: DDRAW: Fix reference counting
Hello,
In that case, it would be really beneficial with a unit test.
Both as documentation and to see what Windows does.
Excuse my ignorance, but what exactly is meant with 'unit test'? As far as
I've learned, it's a small piece of code which uses this functionality and
checks the results. My patch includes such a test:
--- /dev/null 2005-09-01 15:22:32.0 +0200
+++ dlls/ddraw/tests/refcount.c 2005-09-18 21:57:52.0 +0200
...
+/* Create a Texture. Increases the refcount by 2!!!*/
+memset(ddsd, 0, sizeof(ddsd));
+ddsd.dwSize = sizeof(ddsd);
+ddsd.dwFlags = DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH | DDSD_PIXELFORMAT;
+ddsd.ddsCaps.dwCaps = DDSCAPS_TEXTURE;
...
+rc = IDirectDraw7_CreateSurface( lpDD, ddsd, lpDDS, NULL );
+ok(rc == DD_OK, CreateSurface for a mipmap surface returned %lx\n, rc);
+if(rc == DD_OK)
+{
+newref = IDirectDraw_AddRef(lpDD) - 1;
+IDirectDraw_Release(lpDD);
+ok( (newref - oldref) == 2, DD reference count increased by %d
during creation of a mipmap surface\n, newref - oldref);
+oldref = newref;
+
+newref = IDirectDrawSurface_AddRef(lpDDS) - 1;
+IDirectDrawSurface_Release(lpDDS);
+ok(newref == 1, Initial surface reference count of a mipmap surface
is %d\n, newref);
+
+/* Release the surface */
+IDirectDrawSurface_Release(lpDDS);
+
+newref = IDirectDraw_AddRef(lpDD) - 1;
+IDirectDraw_Release(lpDD);
+ok( (newref - oldref) == -2, DD reference count decreased by %d
during releasing a mipmap surface\n, newref - oldref);
+}
Is that enought? This test succeeds in Windows 2000 and Windows 95.
Stefan
Re: server: Try2: add case-sensitivity comparison flag to find_object co
Vitaliy Margolen wrote: Monday, September 19, 2005, 7:47:08 AM, Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: I guess this one got lost. Resend it. Or is there anything wrong with it? Well, you didn't change create_named_object, which looks suspicious. Also I'd really like to see some regression tests for the behavior of the various objects. Ah, I see. I new I was missing something. As far as regression testing - most of the named objects created from kernel32 and they are case insensitive. I purposely left it case sensitive to keep it same way as it was before. I know of at least named pipes that fail with current code, if I start mixing case - which does work on windows. Something like this should test the behaviour (written in MSVC so will need some cleaning up before adding to a Wine test): WCHAR buffer1[] = L\\BaseNamedObjects\\Test; WCHAR buffer2[] = L\\BaseNamedObjects\\test; WCHAR buffer3[] = L\\BaseNamedObjects\\TEst; HANDLE Event, Mutant, h; NTSTATUS status; OBJECT_ATTRIBUTES attr; attr.Length = sizeof(attr); attr.RootDirectory = NULL; attr.ObjectName = HeapAlloc(GetProcessHeap(), 0, sizeof(UNICODE_STRING)); attr.Attributes = 0; attr.SecurityDescriptor = NULL; attr.SecurityQualityOfService = NULL; attr.ObjectName-Buffer = buffer2; attr.ObjectName-Length = wcslen(buffer2) * sizeof(WCHAR); attr.ObjectName-MaximumLength = (wcslen(buffer2) + 1) * sizeof(WCHAR); status = NtCreateMutant(Mutant, GENERIC_ALL, attr, FALSE); attr.ObjectName-Buffer = buffer1; attr.ObjectName-Length = wcslen(buffer1) * sizeof(WCHAR); attr.ObjectName-MaximumLength = (wcslen(buffer1) + 1) * sizeof(WCHAR); status = NtCreateEvent(Event, GENERIC_ALL, attr, FALSE, FALSE); attr.Attributes = OBJ_CASE_INSENSITIVE; attr.ObjectName-Buffer = buffer3; attr.ObjectName-Length = wcslen(buffer3) * sizeof(WCHAR); attr.ObjectName-MaximumLength = (wcslen(buffer3) + 1) * sizeof(WCHAR); status = NtOpenMutant(h, GENERIC_ALL, attr); ok(status == STATUS_OBJECT_TYPE_MISMATCH, NtOpenMutant should have failed with STATUS_OBJECT_TYPE_MISMATCH because of case-insensitive search finding an event object\n); return 0; -- Rob Shearman
riched versions
trying to get recent (winecfg) wine versions to run a program and it shows an error saying riched20.dll version unspecified is found and it requires 5.2.. I would have thought that the build-in is probably fine , it is just a version check that is failing. Is there a way to con it or is the only way to pull in a versioned native dll? TIA
Re: Empire Earth continued
Hello Lionel, Now that I think that the refcount crash is solved and I'm waiting for the patch I've sent to be reviewed and commited, I've looked into the OpenGL crash: I know the following cases *Hardware accellerated, with fglrx: Crash in fglrx[1] *Hardware accellerated, other implementation: Crash in some DDraw DIP function *No hardware accelleration: No crash, Main Menu finally starts, but only with a black screen[2] I've uploaded two logs to my homepage, [1] and [2], if you want to look at them. Well I noticed 2 things: *Empire Earth starts using a new thread to do ddraw things. *Sigh* *There's some problem due to a missing Z Buffer Is the first thing likely to cause problems? You told me so some time ago, but it doesn't look like it in the logs. The Z buffer thing is more suspicious to me, but the code path with leads to the crash seems to be prepared for this. Do you have any suggestions? When I start the game without hw accel, I can take screen shots with the game's screen shot functionality. They show text elements and the mouse pointer. The background and the button decorations are not drawn. See [3]. I can control the menu with the keyboard and start the map editor, which has the in-game graphics. It's basically the same as the menu, text and mouse pointer only, but luckily no further crash :-) Thanks for taking the time, Stefan [1] http://doesi.gmxhome.de/ee.fglrx-crash.bz2 [2] http://doesi.gmxhome.de/ee.mesa.bz2 [3] http://doesi.gmxhome.de/EE000.jpg
OLE file close problem in win32s mathcad 5.0
Since some work is occurring in OLE I will mention this bug. http://bugs.winehq.org/show_bug.cgi?id=3154 When you start mathcad one New blank file is opened. Trying to close any file does not work and my guess some Ole stub return value is preventing it. This application has had this problem of not closing for several years. What other traces do I need to generate? Open file splash.mcd then close it and it does not close. bash-3.00$ WINEDEBUG=+ole wine mcad Loading required GL library /usr/X11R6/lib/libGL.so.1.2 trace:ole:DllMain 0x7b7c 0x1 0x1 fixme:ole:OleRegisterServer (Mathcad,0x7bc9f330,0x7bc9f334,0x40,1): stub! fixme:psdrv:PSDRV_ExtEscape QUERYESCSUPPORT(24) - not supported. fixme:ole:OleRegisterClientDoc (Mathcad document,\Untitled:1,...): stub fixme:ole:OleRegisterServerDoc (1,\Untitled:1): stub fixme:ole:OleRegisterClientDoc (Mathcad document,C:\WINMCAD\handbook\deskref\splash.mcd,...): stub fixme:ole:OleRegisterServerDoc (1,C:\WINMCAD\handbook\deskref\splash.mcd): stub fixme:ole:OleRevokeClientDoc (2): stub fixme:ole:OleRevokeServerDoc (3): stub
scared! freedce-win32 in a cvs repository near you
right. 48 hours later, i've got a first version of freedce-win32 to try out, which i'm actually a bit frightened of running. just in case it works :) thank goodness for pthreads-win32, otherwise i'd be up small creek. major things todo: in ipnaf.c (actually ipnaf_linux.c or even better ipnaf_win32.c) it's necessary to write an IP-interface-enumeration function. this function presumably will call GetIpAddrTable and go over all the addresses including netmasks and broadcast addresses returning information that the rpc runtime can then listen on - one by one. no, freedce doesn't go listening on 0.0.0.0 it binds to all towers whatever they're called. because i've commented this code out (stubbed) i am not expecting freedce-win32 to work straight off. once this is working, putting it in place of rpcrt4 should be relatively straightforward (and mostly very very mind numbingly boring) - a matter of back-converting and following the lead of dceport.h - microsoft's wrapper header file that allows application developers to port DCE/RPC applications to MSRPC. i say lead because it's woefully inadequate, representing about 10% of the functions and structs that actually need converting, because dceport.h contains the publicly accessible functions. once _that's_ done, then there will be two remaining tasks: 1) check that pthreads-win32 works under wine (!) and if so, job done, otherwise it's _yet_ another emulation layer to write, but at least the source code of pthreads-win32 represents a damn good starting point 2) mash freedce's typelib output to be compatible with MSRPC binaries. this latter is no small task (but at least it could be considered). the data structures have been _totally_ mashed, by microsoft. gotta run. later. l. -- -- a href=http://lkcl.net;http://lkcl.net/a --
Wine on NetBSD?
I was enquiring as to whether or not Wine is compatible with NetBSD, or if any other port of Wine is compatible with NetBSD. If not are there any plans to make this so? Regards, Bryce Robilliard
Re: resubmit: implement hlink.dll
Aric Stewart wrote:
+if (r == S_OK);
I don't think you want to put a semi colon there.
+{
+if (pwzLocation)
+IHlink_SetStringReference(*(IHlink**)ppvObj, HLINKSETF_LOCATION,
+NULL, pwzLocation);
+if (pwzFriendlyName)
+IHlink_SetFriendlyName(*(IHlink**)ppvObj, pwzFriendlyName);
+if (pihlsite)
+IHlink_SetHlinkSite(*(IHlink**)ppvObj, pihlsite, dwSiteData);
+if (pimkTrgt)
+IHlink_SetMonikerReference(*(IHlink**)ppvObj, 0, pimkTrgt,
+pwzLocation);
Rather than continually casting ppvObj, why not make a temporary
variable of type IHlink?
+static HRESULT WINAPI IHlink_fnGetMonikerReference(IHlink* iface,
+DWORD dwWhichRef, IMoniker **ppimkTarget, LPWSTR *ppwzLocation)
+{
+IHlinkImpl *This = (IHlinkImpl*)iface;
+
+TRACE((%p) - (%li %p %p)\n,This, dwWhichRef, ppimkTarget, ppwzLocation);
+
+if(ppimkTarget)
+{
+if (This-Moniker)
+*ppimkTarget = This-Moniker;
+else if (This-Site)
+IHlinkSite_GetMoniker(This-Site, This-SiteData,
+OLEGETMONIKER_FORCEASSIGN, OLEWHICHMK_CONTAINER,
+(LPVOID)ppimkTarget);
+}
+
+return S_OK;
+}
The above function doesn't look right. You don't use dwWhichRef or
ppwzLocation, and you unconditionally return S_OK even when *ppimkTarget
is uninitialized or IHlinkSite_GetMoniker fails.
Mike
Burning CDs under Wine?
What is the current state of support for burning CDs under Wine? I checked the appdb, but can't find any recent reports of CD burning programs working. It seems to have worked at some point in the past: http://appdb.winehq.org/appview.php?appId=639 http://www.winehq.org/hypermail/wine-users/2002/09/0164.html http://www.winehq.org/hypermail/wine-devel/2001/05/0263.html But some people are having trouble now: http://www.winehq.org/hypermail/wine-users/2005/05/0100.html http://www.winehq.org/pipermail/wine-users/2005-July/018475.html The doc at http://www.winehq.org/site/docs/wine-user/config-scsi-support looks pretty old. Maybe it's time for a refresh. -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: question about the status of the wine printing system
In http://www.winehq.org/hypermail/wine-devel/2005/01/0111.html, Francois Gouget wrote: If you're trying to print stuff from Acrobat Reader (now called Adobe Reader), then that's known not to work. What are the problems? How much work is left before printing in Wine is more or less working with most major applications (like, say, Photoshop and Acrobat Reader)? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: Burning CDs under Wine?
Monday, September 19, 2005, 6:07:58 PM, Dan Kegel wrote: What is the current state of support for burning CDs under Wine? I checked the appdb, but can't find any recent reports of CD burning programs working. It seems to have worked at some point in the past: http://appdb.winehq.org/appview.php?appId=639 http://www.winehq.org/hypermail/wine-users/2002/09/0164.html http://www.winehq.org/hypermail/wine-devel/2001/05/0263.html But some people are having trouble now: http://www.winehq.org/hypermail/wine-users/2005/05/0100.html http://www.winehq.org/pipermail/wine-users/2005-July/018475.html The doc at http://www.winehq.org/site/docs/wine-user/config-scsi-support looks pretty old. Maybe it's time for a refresh. There were few changes to wine's aspi and related code. Can you do regression testing to see when your program stopped working? Or did it ever worked at all with Wine? Or is it a problem with your Linux kernel that you can't load ide-scsi emulation driver? Vitaliy.
Re: Installers freezing - ole, games
Hi,
I still can't install GTA - in case this is useful, I've attached the
portion of a
trace (+ole +oleaut +seh +tid), which includes only the messages after I
press
Next on the last installer screen (which is where the installer freezes).
This is today's CVS. maybe Olver can compare aganst his copy...
000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)-ref was 490
000b:trace:ole:ITypeInfo_fnAddRef (0x7f3e0d58)-ref is 55
000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 0
000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 1
000b:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid 40
Name(0x7fc95148) DocString((nil)) HelpContext((nil)) HelpFile((nil))
000b:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid -1
Name(0x7fc95144) DocString((nil)) HelpContext((nil)) HelpFile((nil))
000b:trace:ole:ITypeInfo_fnGetNames (0x7f3e0d58) memid=0x0028 Maxname=10
000b:trace:ole:serialize_param (tdesc.vt 3)
000b:trace:ole:ClientRpcChannelBuffer_GetBuffer
(0x7f47ce88)-(0x7fc950c4,{94f4a332-a2ae-11d3-8378-00c04f59fbe9})
000b:trace:ole:ClientRpcChannelBuffer_GetBuffer -- 0
000b:trace:ole:RpcChannelBuffer_SendReceive (0x7fc950c4) iMethod=21
000b:trace:ole:apartment_addref a000d: before = 1
000b:trace:ole:stub_manager_int_addref before 1
000b:trace:ole:get_stub_manager_from_ipid found 0x7f47cc30 for ipid
{0004-000d-000a-c687-000f3dada1bc}
000b:trace:ole:TMStubImpl_AddRef (0x7f47d420)-(ref before=1)
000b:trace:ole:stub_manager_int_release after 1
000b:trace:ole:RpcChannelBuffer_SendReceive Calling apartment thread
0x000d...
000b:trace:ole:apartment_release a000d: after = 1
000b:trace:ole:CoWaitForMultipleHandles (0x, 0x, 1, 0x7ff58b74,
0x7fc95048)
000b:trace:ole:CoWaitForMultipleHandles waiting for rpc completion or window
message
000d:trace:ole:TMStubImpl_Invoke ...
000d:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)-ref was 491
000d:trace:ole:ITypeInfo_fnAddRef (0x7f3e0d58)-ref is 56
000d:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 0
000d:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 1
000d:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid 40
Name(0xe806848) DocString((nil)) HelpContext((nil)) HelpFile((nil))
000d:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid -1
Name(0xe806844) DocString((nil)) HelpContext((nil)) HelpFile((nil))
000d:trace:ole:ITypeInfo_fnGetNames (0x7f3e0d58) memid=0x0028 Maxname=10
000d:trace:ole:deserialize_param vt 3 at 0x7ff69eec
000d:trace:ole:_invoke Calling 0x3d41345e(7ebe0208,00080032,)
000d:trace:ole:_invoke returns
000d:trace:ole:serialize_param (tdesc.vt 3)
000d:trace:ole:ITypeInfo_fnRelease (0x7f3e0d58)-(55)
000d:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)-(491)
000d:trace:ole:TMStubImpl_Invoke returning
000d:trace:ole:TMStubImpl_Release (0x7f47d420)-(ref before=2)
000b:trace:ole:CoWaitForMultipleHandles waiting for rpc completion or window
message
000b:trace:ole:CoWaitForMultipleHandles -- 0x
000b:trace:ole:RpcChannelBuffer_SendReceive RPC call status: 0x0
000b:trace:ole:RpcChannelBuffer_SendReceive -- 0x
000b:trace:ole:ITypeInfo_fnRelease (0x7f3e0d58)-(54)
000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)-(490)
000b:trace:ole:ITypeInfo_fnInvoke
(0x7f3ce0b0)(0x7f4fa378,id=25,flags=0x0003,0x7fca11a8,0x7fca1208,0x7fca1128,0x7fca116c)
partial stub!
000b:trace:ole:dump_DispParms args=2 named args=0
000b:trace:ole:dump_Variant 0x7e9ae090-{VT_I4|VT_BYREF,0x7e9ae0bc}
000b:trace:ole:dump_Variant 0x7e9ae0a0-{VT_BSTR|VT_BYREF,0x7e9ae108}
000b:trace:ole:ITypeInfo2_fnGetFuncIndexOfMemId (0x7f3ce0b0) memid 0x0019
invKind 0x0003 - SUCCESS
000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3ce0b0) index 0
000b:trace:ole:ITypeInfo_fnInvoke invoking:
memid is 0019
Param 0:
tdesc.vartype 8 (VT_BSTR)
u.parmadesc.flags 1
u.parmadesc.lpex (nil)
Param 1:
tdesc.vartype 11 (VT_BOOL)
u.parmadesc.flags 1
u.parmadesc.lpex (nil)
Param 2:
tdesc.vartype 26 (ptr to VT_BSTR)
u.parmadesc.flags a
u.parmadesc.lpex (nil)
funckind: 1 (pure virtual)
invkind: 2 (property get)
callconv: 4 (stdcall)
oVft: 56
cParamsOpt: 0
wFlags: 0
elemdescFunc (return value type):
tdesc.vartype 25 (VT_HRESULT)
u.parmadesc.flags 0
u.parmadesc.lpex (nil)
000b:fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion
from 0x4003 - 0xb)
000b:trace:ole:_invoke Calling 0x37a93b3c(7f4fa378,7e8c1b3c,,7e8b7d48,)
000b:trace:ole:_invoke returns
000b:trace:ole:ITypeInfo_fnInvoke varresult:
0x7fca106c-{VT_BSTR|VT_BYREF,0x7e8b7d48}
000b:trace:ole:ITypeInfo_fnReleaseFuncDesc (0x7f3ce0b0)-(0x7f3ce1e0)
000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)-ref was 490
000b:trace:ole:ITypeInfo_fnAddRef (0x7f3ce0b0)-ref is 242
RE : OLEAUT32: add full multiplication/division support for DECIMAL, with tests
Hi Alex,I think your VarBstrFromDec fails with my testcases, and you should not hardcode the decimal format seperator.And your patch fails my tests.Check my patch for VarBstrFromDec(for my implementation and tests), my implementation is partial.You did a gr8 job implemeting the DECIMAL stuff in oleaut32.I have been sending and resending my patch since a month. I hope yours gets commited soon.byeVijay
Re: Burning CDs under Wine?
Vitaliy Margolen wrote: Monday, September 19, 2005, 6:07:58 PM, Dan Kegel wrote: What is the current state of support for burning CDs under Wine? I checked the appdb, but can't find any recent reports of CD burning programs working. ... There were few changes to wine's aspi and related code. Can you do regression testing to see when your program stopped working? Or did it ever worked at all with Wine? Good question. The app is Picasa 2. I am going by the comments at http://appdb.winehq.org/appview.php?versionId=2786 which say Burning CDs (Create a Gift CD and Backup CD) does not work (keeps on saying it needs a blank CD or DVD). I haven't tested it myself yet. I'll try to do that when I get back from vacation in a week. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
