Repackaging Mozilla ActiveX control to include MSVCP60.DLL?
The Mozilla ActiveX control download feature is cool and all, but until we repackage the sucker to include MSVCP60.DLL to fix http://bugs.winehq.org/show_bug.cgi?id=4064 it's going to leave a lot of users scratching their heads as to why it keeps asking where its files are. I could have sworn I saw somebody post a note saying they had done said repackaging, but I can't find it now... Can somebody take care of this? It's kind of important. I would, but I'm zooming around getting my CS 130 project going, preparing a couple talks for Scale 4x, chasing after my two year old, and trying to hold down my day job... For the curious, my slids for the cs130 kickoff talk are up at http://kegel.com/wine/sweng/cs130/ I chose "add a feature to riched20.dll " as the basic task the students will be trying to carry out. No idea yet how it'll work out. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: winetest: Only test d3d9 if it is being built.
On 23/12/05, Yuval Fledel <[EMAIL PROTECTED]> wrote: > winetest: Only test d3d9 if it is being built. > > -- Yuval Fledel > > diff --git a/programs/winetest/Makefile.in b/programs/winetest/Makefile.in > index 4208b94..8602f66 100644 > --- a/programs/winetest/Makefile.in > +++ b/programs/winetest/Makefile.in > @@ -19,14 +19,15 @@ RC_BINSRC = winetest.rc > RC_BINARIES = wine.ico > > XFILES = ddraw_test.exe$(DLLEXT) > +OPENGLFILES = d3d9_test.exe$(DLLEXT) > > TESTBINS = \ > @XFILES@ \ > + @OPENGLFILES@ \ > advpack_test.exe$(DLLEXT) \ > advapi32_test.exe$(DLLEXT) \ > comctl32_test.exe$(DLLEXT) \ > crypt32_test.exe$(DLLEXT) \ > - d3d9_test.exe$(DLLEXT) \ > dinput_test.exe$(DLLEXT) \ > dsound_test.exe$(DLLEXT) \ > gdi32_test.exe$(DLLEXT) \ Would this prevent the tests from getting built on Windows?
Debugging a null pointer dereference
Hi! I'm new to this list, but a long time Wine user and regular WWN reader. The other day I decided to try out Semiolog, a free as-in-beer piece of software to create labels from electric equipment manufacturer Hager, under wine. The software can be downloaded from here: http://www.hager.se/files/download/0/482_1/0/SemiologSue40a.exe Unfortunately it doesn't work. So although I haven't been doing any Windows programming in the last 15 years I decided to try to do something useful and try find out why it doesn't work. I figured that this application would be a good thing to try to get to work as it is supposedly rather trivial. So what follows is a description of a newbies attempt at some wine debugging: The application installs and starts up just fine, but when I try to create a new document, I get a null pointer dereference in mfc42.dll. After messing around with with the mfc42 runtime, I managed to get a backtrace with debugging information, which looks like this: === wine: Unhandled page fault on read access to 0x003c at address 0x5f4056dd (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x003c in 32-bit code (0x5f4056dd). In 32 bit mode. fixme:dbghelp:sffip_cb NIY on 'E:\8168\vc98\mfc\mfc.bbt\src\mfc42.pdb' fixme:dbghelp:sffip_cb NIY on 'C:\hager\Semiolog\Apps\MFC42.PDB' fixme:dbghelp_msc:codeview_parse_type_table Not adding parameters' types to function signature fixme:dbghelp_msc:codeview_parse_type_table Unsupported type-id leaf a fixme:dbghelp_msc:dump : 06 00 0a 00 01 00 50 f1 ..P. fixme:dbghelp_msc:codeview_get_type Returning NULL symt for type-id 1053 [1000's of codeview_parse_type_table messages snipped] fixme:dbghelp_msc:codeview_snarf No current function for label $L101060 [1000's of codeview_snarf messages snipped] Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:5f4056dd ESP:7fc9d004 EBP:7fc9d0b8 EFLAGS:00010206( - 00 - RIP1) EAX: EBX:0001 ECX: EDX: ESI:00449180 EDI: Stack dump: 0x7fc9d004: 004125f2 7ff38140 0x7fc9d014: 7ff38140 0042bb1f 0001 0x7fc9d024: 004181b3 7ff38140 00030080 0x7fc9d034: 00418130 5f401e5c 0001 7ff38140 0x7fc9d044: 7ff38140 7ff38140 7ff0f300 0x7fc9d054: 201cc2f0 7fc9d728 7fc9d0e8 0200: sel=1007 base=7ffdc000 limit=1fff 32-bit rw- Backtrace: =>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in mfc42 (0x5f4056dd) 2 0x5f401b2c CDC::RectVisible+0x3(lpRect=0x5f401ab5) [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:647] in mfc42 (0x5f401b2c) 3 0x5f401ab5 CGdiObject::~CGdiObject+0x32 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:281] in mfc42 (0x5f401ab5) 4 0x5f401a3d CMDIChildWnd::MDIDestroy+0x8 [E:\8168\vc98\mfc\mfc\include\afxwin2.inl:938] in mfc42 (0x5f401a3d) 5 0x5f4019fc AfxGetMainWnd+0x12 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:32] in mfc42 (0x5f4019fc) 6 0x62a6cb2a WINPROC_wrapper+0x1a in user32 (0x62a6cb2a) 7 0x62a6d419 in user32 (+0x9d419) (0x62a6d419) 8 0x62a7336e CallWindowProcW+0x122 in user32 (0x62a7336e) 9 0x62a3ba2e in user32 (+0x6ba2e) (0x62a3ba2e) 10 0x62a3f8c2 SendMessageTimeoutW+0x186 in user32 (0x62a3f8c2) 11 0x62a3f91f SendMessageW+0x50 in user32 (0x62a3f91f) 12 0x62a2d1be in user32 (+0x5d1be) (0x62a2d1be) 13 0x62a2e4f7 DefMDIChildProcW+0x36e in user32 (0x62a2e4f7) 14 0x62a2e801 DefMDIChildProcA+0xf2 in user32 (0x62a2e801) 15 0x5f413511 COleControl::GetMetafileData+0x87(lpFormatEtc=0x22, lpStgMedium=0x0, hAttribDC=0x22, cy=0x0, hMF=0x22) [ctlcore.cpp:827] in mfc42 (0x5f413511) 16 0x5f401ab5 CGdiObject::~CGdiObject+0x32 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:281] in mfc42 (0x5f401ab5) 17 0x5f401a3d CMDIChildWnd::MDIDestroy+0x8 [E:\8168\vc98\mfc\mfc\include\afxwin2.inl:938] in mfc42 (0x5f401a3d) 18 0x5f4019fc AfxGetMainWnd+0x12 [E:\8168\vc98\mfc\mfc\include\afxwin1.inl:32] in mfc42 (0x5f4019fc) 19 0x62a6cb2a WINPROC_wrapper+0x1a in user32 (0x62a6cb2a) 20 0x62a6d419 in user32 (+0x9d419) (0x62a6d419) 21 0x62a70f2d CallWindowProcA+0x1b5 in user32 (0x62a70f2d) 22 0x62a3b99f in user32 (+0x6b99f) (0x62a3b99f) 23 0x62a3f674 SendMessageTimeoutA+0x226 in user32 (0x62a3f674) 24 0x62a3f72f SendMessageA+0x50 in user32 (0x62a3f72f) 25 0x59a9462e X11DRV_SetWindowPos+0xf33 in winex11 (0x59a9462e) 26 0x62a6bbe3 SetWindowPos+0xb1 in user32 (0x62a6bbe3) 27 0x62a6c63a BringWindowToTop+0x4d in user32 (0x62a6c63a) 28 0x5f408ae3 COleControlContainer::CreateControl+0x31(pWndCtrl=0x0, clsid=0x0, lpszWindowName=0x0, dwStyle=0x1, ppt=0x0, psize=0x7ff11458, nID=0x10026, pPersist=0x0, bStorage=0x0, bstrLicKey=0x62a086dc, ppNewSite=0x0) [occcont.cpp:175] in mfc42 (0x5f408ae3) 29 0x0001 (0x0001) 30 0x00418d70 in semiolog (+0x18d70) (0x00418d70) 0x5f4056dd CEnumOleVerb
Re: dlls/wined3d/device.c GetCreationParameters
Ack, after thinking about it and talking with people on IRC, I think I
did the wrong thing. New patch attached that just copies the
parameters one-by-one to the passed-in struct. Both methods work,
though, so this probably needs to be tested on Windows.
In any case, this one is probably safest for now.
-Al Tobey
On 1/14/06, Al Tobey <[EMAIL PROTECTED]> wrote:
> I'd just post to wine-patches, but I think this needs another set of
> eyes. According to MSDN, this just sets a pointer to the creation
> parameters.The attached patch makes this function work, but I'm
> not sure if returning a pointer to the original parameters is the
> right approach or if they should be copied first.
>
> This patch makes a bunch of the Ogre3d demos work, which are great for
> testing since you can run the same demo in OpenGL, D3D9, and D3D7
> modes.
>
> http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/reference/d3d/interfaces/idirect3ddevice9/GetCreationParameters.asp
>
> http://www.ogre3d.org/index.php?option=com_remository&Itemid=57&func=selectcat&cat=2
> http://easynews.dl.sourceforge.net/sourceforge/ogre/OgreDemos-1.0.4.zip
>
> I'm currently playing with compiling Ogre3d against winelib and
> finding it's shaking out a bunch of missing stuff in d3d9 - patches
> may follow.
>
> -Al Tobey
>
>
>
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index b057a36..8a3e09b 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -6137,13 +6136,13 @@ HRESULT WINAPI IWineD3DDeviceImpl_SetDia
HRESULT WINAPI IWineD3DDeviceImpl_GetCreationParameters(IWineD3DDevice *iface, D3DDEVICE_CREATION_PARAMETERS *pParameters) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
-
-FIXME("(%p) : stub\n", This);
-/* Setup some reasonable defaults */
-pParameters->AdapterOrdinal = 0; /* always for now */
-pParameters->DeviceType = D3DDEVTYPE_HAL; /* always for now */
-pParameters->hFocusWindow = 0;
-pParameters->BehaviorFlags =0;
+pParameters->AdapterOrdinal = This->createParms.AdapterOrdinal;
+pParameters->DeviceType = This->createParms.DeviceType;
+pParameters->hFocusWindow = This->createParms.hFocusWindow;
+pParameters->BehaviorFlags = This->createParms.BehaviorFlags;
+// this seems to work too, but probably isn't correct
+// eventually this should be tested out on windows
+// pParameters = &This->createParms;
return D3D_OK;
}
re: Regression in ntdll/virtual.c
>I mentioned that the setup program of AstroWorld will not work any longer >since a few days. Regression testing resulted in the change of >ntdll/virtual.c between 3.1.06 and 4.1.06. I didn't find any related entry >in wine.patches... Ah, but did you look in the archives of the wine-cvs mailing list? A little google search for the longest line of that change turned up: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
dlls/wined3d/device.c GetCreationParameters
I'd just post to wine-patches, but I think this needs another set of
eyes. According to MSDN, this just sets a pointer to the creation
parameters.The attached patch makes this function work, but I'm
not sure if returning a pointer to the original parameters is the
right approach or if they should be copied first.
This patch makes a bunch of the Ogre3d demos work, which are great for
testing since you can run the same demo in OpenGL, D3D9, and D3D7
modes.
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/reference/d3d/interfaces/idirect3ddevice9/GetCreationParameters.asp
http://www.ogre3d.org/index.php?option=com_remository&Itemid=57&func=selectcat&cat=2
http://easynews.dl.sourceforge.net/sourceforge/ogre/OgreDemos-1.0.4.zip
I'm currently playing with compiling Ogre3d against winelib and
finding it's shaking out a bunch of missing stuff in d3d9 - patches
may follow.
-Al Tobey
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index b057a36..cad4468 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -6132,23 +6132,18 @@
FIXME("(%p) Dialogs cannot be disabled yet\n", This);
}
return D3D_OK;
}
HRESULT WINAPI IWineD3DDeviceImpl_GetCreationParameters(IWineD3DDevice *iface, D3DDEVICE_CREATION_PARAMETERS *pParameters) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface;
-
-FIXME("(%p) : stub\n", This);
-/* Setup some reasonable defaults */
-pParameters->AdapterOrdinal = 0; /* always for now */
-pParameters->DeviceType = D3DDEVTYPE_HAL; /* always for now */
-pParameters->hFocusWindow = 0;
-pParameters->BehaviorFlags =0;
+pParameters = &This->createParms;
+FIXME("(%p) : Partially implemented ... probably needs some checks\n", This);
return D3D_OK;
}
void WINAPI IWineD3DDeviceImpl_SetGammaRamp(IWineD3DDevice * iface, UINT iSwapChain, DWORD Flags, CONST D3DGAMMARAMP* pRamp) {
IWineD3DSwapChain *swapchain;
HRESULT hrc = D3D_OK;
TRACE("Relaying to swapchain\n");
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Tony Lambregts wrote: It's been there a long time... http://www.winehq.org/site/forums look at [Archive 2] -- Tony Lambregts That's not very good from a usability standpoint. The gmane link is buried as Archive2. It's not at all clear that Archive1 (winehq pipermail) doesn't let you post new messages while Archive2 (gmane) does. And maybe a more experienced gmane user will correct me, but it doesn't look like there's any way to tell what posts are new since your last visit. Now actually having looked at gmane, I can say that it's not nearly as newb friendly as a real phpBB forum would be -- it wasn't even immediately obvious that I could post replies, and the option is labeled "Followup" a term which no modern forum/bulletin board uses anymore and people won't recognize. That, and the option is in the frame displaying the list of posts in the thread, and not in the frame containing the message body (the thing the user actually perceives they want to reply to). That the World of Warcraft thread in the Gentoo Gamer's and Players forum has become the center for discussion for running WoW under wine for ALL distributions I think says something about the newb friendliness of the mailing lists. Not to disparage the mailing lists -- they let developers use their preferred interface for writing text. But people are going to phpBB forums that aren't even for their own distro before they e-mail wine-devel. Even if the forum didn't get much developer participation there would at least be a place for all wine users to go, with some nice sticky posts detailing how to submit bugs and test against cvs, something other forums aren't doing. Wine could probably pick up a lot of good bug reports this way.
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Joseph Garvin wrote: Aric Cyr wrote: I don't have external mail or nntp access at work, so I just use http://news.gmane.org/gmane.comp.emulators.wine.devel I didn't think of that. What about posting a link to the 'Wine Forums' on winehq that goes there? It's been there a long time... http://www.winehq.org/site/forums look at [Archive 2] -- Tony Lambregts
IWineD3DSurface::GetDC
Hello,
I am trying to implement the GetDC method for wine d3d surfaces, as it is used
by much d3d7 apps to load the textures. I took the code from
ddraw/surface_dib.c and modified it, but I am stuck with a heap corruption.
Basically, what I am doing is:
1) Lock the surface
2) Create a DIB section with DIB_CreateDIBSection. Use the currentDesc.
{Width / Height} as the dimension and bytesPerPixel * 8 for the bitcount. The
memory for the DC is the pBits returned from LockRect()
3) Create a DC, and attach it to the dib section
4) Set the palette, if necessary.
In ReleaseDC I release the DC, destroy the DIB section and unlock the surface.
Looks nice so far, but it doesn't work.
I get a heap corruption eighter when using the DC or when deleting it. An
example winedbg output:
err:d3d_surface:IWineD3DSurfaceImpl_GetDC (0x7fd8fb08)->(0x7fbafd94): This
does not work yet
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) : rect@(nil)
flags(), output [EMAIL PROTECTED], memory@(nil)
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locked Rect (0x7fd8fb78) = l 0,
t 0, r 640, b 480
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Locking non-power 2 texture
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect locking an ordinarary surface
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect (0x7fd8fb08) Locking rect
trace:d3d_surface:IWineD3DSurfaceImpl_AddDirtyRect (0x7fd8fb08) : Dirty?1,
Rect:(0,0,640,480)
trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to
queryInterface 0x7fbaf3fc (nil)
trace:d3d_surface:IWineD3DSurfaceImpl_GetContainer (0x7fd8fb08) : Relaying to
queryInterface 0x7fbaf454 0xb7effbda
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect Surface is standalone, no need
to dirty the container
trace:d3d_surface:IWineD3DSurfaceImpl_LockRect returning [EMAIL PROTECTED],
pitch(4096) dirtyfied(1)
trace:d3d_surface:IWineD3DSurfaceImpl_GetDC Creating dip section 640x480x32.
memory at 0x7dfa0020 is 2097152 bytes of size
trace:d3d_surface:IWineD3DSurfaceImpl_GetDC returning 0x278
trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC (0x7fd8fb08)->(0x278)
trace:d3d_surface:IWineD3DSurfaceImpl_ReleaseDC Selecting the object DC
First chance exception: page fault on read access to 0x7dfa in 32-bit code
(0x7ff99374).
Register dump:
CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033
EIP:7ff99374 ESP:7fbaf714 EBP:7fbaf718 EFLAGS:00010206( - 00 - RIP1)
EAX:7fce EBX:7ffd5540 ECX:7e5c0250 EDX:7dfa
ESI:7e5c0248 EDI:7fce0040
Stack dump:
0x7fbaf714: 0030 7fbaf754 7ff99c0b 7fce
0x7fbaf724: 7e5c0248 7f712cd0 4f4c
0x7fbaf734: 7ff99294 7fd8fee8 7e5c0248 7ff8dffa
0x7fbaf744: 7f6edf2b 7ffd5540 0030 0030
0x7fbaf754: 7fbaf798 7ff9a954 7fce 0030
0x7fbaf764: 7fbaf788 7f70253b 027c 4f4c
Backtrace:
=>1 0x7ff99374 HEAP_FindSubHeap+0x14(heap=0x7fce, ptr=0x7e5c0248)
[heap.c:375] in ntdll (0x7ff99374)
2 0x7ff99c0b HEAP_FindFreeBlock+0x7b(heap=0x7fce, size=0x30,
ppSubHeap=0x7fbaf788) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:390] in ntdll
(0x7ff99c0b)
3 0x7ff9a954 RtlAllocateHeap(heap=0x7fce, flags=0x2, size=0x30)
[/usr/src/wine-wined3d/dlls/ntdll/heap.c:1163] in ntdll (0x7ff9a954)
q
4 0x7f263905 X11DRV_GetRegionData+0x55(hrgn=0x27c, hdc_lptodp=0x0)
[/usr/src/wine-wined3d/dlls/x11drv/../../include/winbase.h:2250] in winex11
(0x7f263905)
5 0x7f263aa6 X11DRV_SetDeviceClipping+0x56(physDev=0x7fd8fe68,
vis_rgn=0x280, clip_rgn=0x0)
[/usr/src/wine-wined3d/dlls/x11drv/clipping.c:118] in winex11 (0x7f263aa6)
6 0x7f6c6a1e CLIPPING_UpdateGCRegion+0xae(dc=0x7e1a0028) [clipping.c:80] in
gdi32 (0x7f6c6a1e)
7 0x7f6c84fa DC_InitDC+0x9a(dc=0x7e1a0028)
[/usr/src/wine-wined3d/dlls/gdi/dc.c:205] in gdi32 (0x7f6c84fa)
8 0x7f6c5c06 BITMAP_SelectObject(handle=0x6c, obj=0x7fce5d20, hdc=0x278)
[/usr/src/wine-wined3d/dlls/gdi/bitmap.c:568] in gdi32 (0x7f6c5c06)
9 0x7f6eea05 SelectObject(hdc=0x278, hObj=0x6c)
[/usr/src/wine-wined3d/dlls/gdi/gdiobj.c:1164] in gdi32 (0x7f6eea05)
10 0x7f5ecd10 IWineD3DSurfaceImpl_ReleaseDC+0x50(iface=0x7fd8fb08,
hDC=0x278) [/usr/src/wine-wined3d/dlls/wined3d/surface.c:1068] in wined3d
(0x7f5ecd10)
q
11 0x7fa7e0e8 IDirectDrawSurfaceImpl_ReleaseDC+0x38(iface=0x7fd8fa48,
hdc=0x278) [/usr/src/wine-wined3d/dlls/ddraw/surface.c:472] in ddraw
(0x7fa7e0e8)
12 0x7fbd5fe6 main in ddrawex (0x7fbd5fe6)
13 0x7fbd63a7 __wine_spec_exe_entry(peb=0x7ffdf540) [exe_entry.c:37] in
ddrawex (0x7fbd63a7)
14 0x7fc490a0 start_process(arg=0x0)
[/usr/src/wine-wined3d/dlls/kernel/process.c:1027] in kernel32 (0x7fc490a0)
15 0xb7f020fb wine_switch_to_stack+0x17 in libwine.so.1 (0xb7f020fb)
0x7ff99374 HEAP_FindSubHeap+0x14 [heap.c:375] in ntdll: movl0x0(%edx),%ecx
Unable to open file 'heap.c'
Wine-dbg>
I am lost here, can someone help me? Can this code work at all? I've attached
my copy of dlls/wined3d/surface.c, so you can see the code(Watch out, it
won't compile as such in the CVS tree).
The dib mem
Re: x11drv: Allow WM to manage more windows.
Saturday, January 14, 2006, 6:37:28 AM, Dmitry Timoshkov wrote:
> "Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>> @@ -67,6 +67,8 @@ static const char visual_id_prop[]=
>> inline static BOOL is_window_managed( HWND hwnd )
>> {
>> DWORD style, ex_style;
>> +char class_name[7];
>> +static const char menu_class[] = "#32768";
>> +/* menu windows are not managed */
>> +if (GetClassNameA(hwnd, class_name, sizeof(class_name)) &&
>> +!memcmp(class_name, menu_class, sizeof(menu_class)))
>> +return FALSE;
> This won't work for subclassed or custom (OfficeXP like) menus.
Yeah you are correct. And it looks like it's redundant anyway. I forgot
that all menus are WS_POPUP without WS_SYSMENU. And I already have a case
for this.
New patch sent.
Vitaliy
Re: [wined3d] Status update: Converting Wined3d to use WGL instead of GLX
On 1/14/06, Aric Cyr <[EMAIL PROTECTED]> wrote: > > > How about creating a temponary fork of the whole tree, so we can submit all > > our patches there without breaking wine. There's no need for this tree to > > work for any game at first, so broken patches are no problem. Once our > > patches coexist nicely, we can introduce them to main cvs. > > (The danger is, of course, that the differences take overhand and the > > forking > > can't be undone any more) > > > > What do you think about this? > > It's a lot of extra work for nothing really. There should be minimal > conflicts > with my patches and whatever you guys are working on. The only exception > would > be if you added or changes glX code. Even in the case of a conflict, it > should > be a trivial merge since wgl and glX are so similar. > > I'm willing to do the merge myself if you expect the ddraw and d3d8 code to be > submitted soon, otherwise I'll just submit my wgl stuff and leave it up to you > and Olvier to merge your patches. > > Anyways, I'm still bug hunting so I won't be submitting very soon. So hurry > up > with ddraw and d3d8! ;) > > Regards, > Aric > > > > I'm certainly in favor of having a temporary git fork for directx changes. So I can just pull the patch from there anytime instead of waiting for periodic test patches. The periodic patches haven't always applied cleanly either. These improvements are big changes and it would be nice if doing this would speed it up, since everyone could now work together.
Fwd: Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
On 1/14/06, Robert Shearman <[EMAIL PROTECTED] > wrote: Dan Kegel wrote:>Rob wrote:This very much looks like a use-after-free bug. The first two>>instructions are probably a COM *_Release call. Judging by the fact that>>this is a regression I would also guess that it is a Wine object. >>This sounds like a job for valgrind!>>But, er, does valgrind still work with wine? Rob said it did in March:> http://www.winehq.com/hypermail/wine-devel/2005/03/0397.html>It was too hard for one guy back in July:> http://www.winehq.com/hypermail/wine-devel/2005/07/0401.html >but that was probably because he didn't see Rob's message from March.>Maybe we need to put better instructions on how to use>Valgrind with Wine on winehq.org... or, dare I suggest it,>bundle valgrind with Wine so anybody could easily use it >be setting WINEDEBUG=+valgrind or something like that...>Valgrind 3.1.0 works with Wine with no Wine modifications needed.However, one patch to valgrind is required to generate meaningfulbacktraces and I've attached it to this message - I guess I should report this to the valgrind developers.--Rob Shearman I was really just considering using valgrind! I already have it installed, but I wasn't sure it would work very nicely, though. I was afraid there would be too much pointless output to wade through, but I'll try it tomorrow sometime. Cheers, James
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Aric Cyr wrote: I don't have external mail or nntp access at work, so I just use http://news.gmane.org/gmane.comp.emulators.wine.devel I didn't think of that. What about posting a link to the 'Wine Forums' on winehq that goes there?
Re: Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
Dan Kegel wrote:
Rob wrote:
This very much looks like a use-after-free bug. The first two
instructions are probably a COM *_Release call. Judging by the fact that
this is a regression I would also guess that it is a Wine object.
This sounds like a job for valgrind!
But, er, does valgrind still work with wine? Rob said it did in March:
http://www.winehq.com/hypermail/wine-devel/2005/03/0397.html
It was too hard for one guy back in July:
http://www.winehq.com/hypermail/wine-devel/2005/07/0401.html
but that was probably because he didn't see Rob's message from March.
Maybe we need to put better instructions on how to use
Valgrind with Wine on winehq.org... or, dare I suggest it,
bundle valgrind with Wine so anybody could easily use it
be setting WINEDEBUG=+valgrind or something like that...
Valgrind 3.1.0 works with Wine with no Wine modifications needed.
However, one patch to valgrind is required to generate meaningful
backtraces and I've attached it to this message - I guess I should
report this to the valgrind developers.
--
Rob Shearman
--- m_stacktrace.c.orig 2005-11-25 12:36:21.0 +
+++ m_stacktrace.c 2006-01-14 17:25:27.0 +
@@ -88,6 +88,7 @@
* offending stack traces only have one item. --njn, 2002-aug-16 */
/* vg_assert(fp_min <= fp_max);*/
+#if 0
if (fp_min + VG_(clo_max_stackframe) <= fp_max) {
/* If the stack is ridiculously big, don't poke around ... but
don't bomb out either. Needed to make John Regehr's
@@ -95,7 +96,8 @@
ips[0] = ip;
VGP_POPCC(VgpExeContext);
return 1;
- }
+ }
+#endif
/* Otherwise unwind the stack in a platform-specific way. Trying
to merge the x86, amd64 and ppc32 logic into a single piece of
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
Joseph Garvin kzoo.edu> writes: > > I actually prefer forums because there's less of a barrier to get > started. I can continue working through my browser, and I don't have to > setup a message filter. I don't have external mail or nntp access at work, so I just use http://news.gmane.org/gmane.comp.emulators.wine.devel For the most part this operates very similar to any of the forums I regularly visit. There are a couple of qwerks, but all in all very easy to use for the non-NNTP users out there. If it wasn't for this site I'd never be able to procrastinate in the office ;) > Even if there's not a forum where developers participate, but just a > forum on winehq for users to help each other, I think that would be much > better than no forum. More users have experience with forums than > mailing lists, so it's much more likely they'll sign up. A user forum might be useful. I'd have to admit there are a lot of new users who seem to easily manage to find Linux forums. I see this often on Rage3D's Linux forums as well as Ubuntu and Gentoo forums. The problem is that there are already well-established wine forums, currently in mailing list format, and they will never go away. So the most likely solution would be a web-nntp gateway, which is exactly what news.gmane.org is. Whether wine decides to host's its own gateway software or not I would leave up to the winehq admins. - Aric
Re: [wined3d] Status update: Converting Wined3d to use WGL instead of GLX
Stefan Dösinger gmx.at> writes: > The problem is that we are doing a lot of redundant work here. Oliver is > working in d3d8, I'm working on ddraw, and you are working on moving all of > them to wgl. At least your work on ddraw and d3d8 would be for nothing in the > long term, and could be avoided with a better cooperation. I'm fine with my ddraw and d3d8 stuff being thrown away in the future. I personally see it as a temporary fix to prevent regressions while ddraw and d3d8 are ported to wined3d. The real majority of work was in wined3d anyways, so it was just a matter of wash-rinse-repeat with dddraw and d3d8. It's just the testing that is a pain :) > One way would be to remove all WineD3D dependancy from today's ddraw and > d3d8, > so they remain untouched until Oliver and I replace them. But if ddraw is > really affected by changes to WineD3D, allthough it shouldn't to my > knowledge, this might be a more subtile problem. As I sent you off-list, 3DMark2001SE makes initial capability queries with ddraw, then uses d3d8 for everything else. I assume a similar thing could occur for d3d9 apps, so there really is no way we can guarantee a separation between ddraw/d3d8 and wined3d as far as I can tell. So it's gonna be all wgl or nothing if we don't want a lot of regressions. > How about creating a temponary fork of the whole tree, so we can submit all > our patches there without breaking wine. There's no need for this tree to > work for any game at first, so broken patches are no problem. Once our > patches coexist nicely, we can introduce them to main cvs. > (The danger is, of course, that the differences take overhand and the forking > can't be undone any more) > > What do you think about this? It's a lot of extra work for nothing really. There should be minimal conflicts with my patches and whatever you guys are working on. The only exception would be if you added or changes glX code. Even in the case of a conflict, it should be a trivial merge since wgl and glX are so similar. I'm willing to do the merge myself if you expect the ddraw and d3d8 code to be submitted soon, otherwise I'll just submit my wgl stuff and leave it up to you and Olvier to merge your patches. Anyways, I'm still bug hunting so I won't be submitting very soon. So hurry up with ddraw and d3d8! ;) Regards, Aric
Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
Rob wrote: >This very much looks like a use-after-free bug. The first two >instructions are probably a COM *_Release call. Judging by the fact that >this is a regression I would also guess that it is a Wine object. This sounds like a job for valgrind! But, er, does valgrind still work with wine? Rob said it did in March: http://www.winehq.com/hypermail/wine-devel/2005/03/0397.html It was too hard for one guy back in July: http://www.winehq.com/hypermail/wine-devel/2005/07/0401.html but that was probably because he didn't see Rob's message from March. Maybe we need to put better instructions on how to use Valgrind with Wine on winehq.org... or, dare I suggest it, bundle valgrind with Wine so anybody could easily use it be setting WINEDEBUG=+valgrind or something like that... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Problem with older wgl patch
Tim Savannah gmail.com> writes: > + DWORD type = GetObjectType(hdc);where that patch placed it in the file > allows opengl to work again. I think this is fixed in CVS already. Which version of wine are you trying with? Try out the latest CVS if you can. - Aric
Re: Bug 4289: Debugging and dissasembly
James Trotter wrote: 0x007ab8e6: pushl %eax 0x007ab8e7: call*0x8(%edx) 0x007ab8ea: movl%ebp,0x8(%esi) 0x007ab8ed: movl0x4(%esi),%eax 0x007ab8f0: pushl %eax 0x007ab8f1: movl0x0(%eax),%ecx This very much looks like a use-after-free bug. The first two instructions are probably a COM *_Release call. Judging by the fact that this is a regression I would also guess that it is a Wine object. Also, by knowing that it is a game it is probably a DirectDraw, Direct3D or DirectSound object. Try turning on tracing for these and seeing what it turns up. If you see a decrement to 0 just before the crash then the theory is probably correct. -- Rob Shearman
Re: Bug 4289: Debugging and dissasembly
On 1/14/06, James Trotter <[EMAIL PROTECTED]> wrote: -- Forwarded message --From: James Trotter < [EMAIL PROTECTED]>Date: Jan 14, 2006 3:22 PM Subject: Re: Bug 4289: Debugging and dissasemblyTo: Eric Pouech <[EMAIL PROTECTED]> On 1/14/06, Eric Pouech <[EMAIL PROTECTED]> wrote: James Trotter wrote:> Hi!>> A few days ago I filed this bug: http://bugs.winehq.org/show_bug.cgi?id=4289 >> Alexandre commented that there most likely was some stack corruption, > and that I should try and disassemble a few instructions before the> crash and look for API calls.>> Now, I haven't used gdb or winedbg that much before, and I'm a bit> uncertain what to do. I understand that using the disassemble > [][,] command, the debugger will disassemble that address> space. Given the stack trace as in the bug report, which addresses,> exactly, should I disassemble?before 0x007ab8f1 A+--Eric Pouech Sure, but how much before 0x007ab8f1? For instance, Is this helpful? WineDbg starting on pid 0xa In 32 bit mode. 0x7fcfba16 start_process+0xb6 [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/kernel/process.c:996] in kernel32: pushl %edi 996 ExitProcess( entry( peb ) ); Wine-dbg>cont First chance exception: page fault on read access to 0x20202020 in 32-bit code (0x007ab8f1). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7facaba4 EBP: EFLAGS:00210246( - 00 -RIZP1) EAX:20202020 EBX:0001 ECX:7facb450 EDX: ESI:7facb328 EDI:7beb4460 Stack dump: 0x7facaba4: 20202020 2711 7facb328 0x7facabb4: 7facabe0 007aaf30 7facb218 7facaf60 0x7facabc4: 2711 40c38800 7facb328 0x7facabd4: 7facac90 0084566a 0007 7fd0e900 0x7facabe4: 0078e3ca 7facaf60 0040 0x7facabf4: 7fd39206 7facaf60 7fd39206 0200: sel=1007 base=b7f81000 limit=1f97 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x) 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg>disassemble 0x007ab800, 0x007ab8f1 0x007ab800: addb %bh,0x0(%ebx) 0x007ab802: int $0x74 0x007ab804: pop %ss 0x007ab805: cmpl %ebx,0x390(%ecx) 0x007ab80b: jz 0x007ab81c 0x007ab80d: addl $0x394,%ecx 0x007ab813: pushl %ecx 0x007ab814: call *%edi 0x007ab816: movl 0x008cf6d8,%ecx 0x007ab81c: movl 0x13c(%esi),%eax 0x007ab822: cmpl %ebp,%eax 0x007ab824: jz 0x007ab838 0x007ab826: movl 0x0(%eax),%ecx 0x007ab828: pushl %eax 0x007ab829: call *0x8(%ecx) 0x007ab82c: movl %ebp,0x13c(%esi) 0x007ab832: movl 0x008cf6d8,%ecx 0x007ab838: cmpl %ebp,%ecx 0x007ab83a: jz 0x007ab84d 0x007ab83c: cmpl %ebx,0x390(%ecx) 0x007ab842: jz 0x007ab84d 0x007ab844: addl $0x394,%ecx 0x007ab84a: pushl %ecx 0x007ab84b: call *%edi 0x007ab84d: leal 0x128(%esi),%ecx 0x007ab853: call 0x007c22d0 0x007ab858: movl %ebp,0x140(%esi) 0x007ab85e: movl 0x008cf6d8,%eax 0x007ab863: cmpl %ebp,%eax 0x007ab865: jz 0x007ab87b 0x007ab867: cmpl %ebx,0x390(%eax) 0x007ab86d: jz 0x007ab87b 0x007ab86f: addl $916,%eax 0x007ab874: pushl %eax 0x007ab875: call *0x8472c8 -> 0x7beb4180 RtlLeaveCriticalSection [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/ntdll/critsection.c:407] in ntdll 0x007ab87b: cmpl %ebp,0x90(%esi) 0x007ab881: jz 0x007ab8a4 0x007ab883: leal 0x84(%esi),%edi 0x007ab889: movl %edi,%ecx 0x007ab88b: call 0x007fbe77 0x007ab890: cmpl %ebp,%eax 0x007ab892: jz 0x007ab89c 0x007ab894: movl 0x0(%eax),%edx 0x007ab896: pushl %ebx 0x007ab897: movl %eax,%ecx 0x007ab899: call *0x4(%edx) 0x007ab89c: cmpl %ebp,0x90(%esi) 0x007ab8a2: jnz 0x007ab889 0x007ab8a4: cmpl %ebp,0xac(%esi) 0x007ab8aa: jz 0x007ab8d8 0x007ab8ac: leal 0xa0(%esi),%ebx 0x007ab8b2: movl %ebx,%ecx 0x007ab8b4: call 0x007fbe77 0x007ab8b9: movl %eax,%edi 0x007ab8bb: movl 0x58(%edi),%eax 0x007ab8be: cmpl %ebp,%eax 0x007ab8c0: jz 0x007ab8cb 0x007ab8c2: movl 0x0(%eax),%ecx 0x007ab8c4: pushl %eax 0x007ab8c5: call *0x8(%ecx) 0x007ab8c8: movl %ebp,0x58(%edi) 0x007ab8cb: cmpl %ebp,0xac(%esi) 0x007ab8d1: jnz 0x007ab8b2 0x007ab8d3: movl $0x1,%ebx 0x007ab8d8: cmpl %ebp,0x4(%esi) 0x007ab8db: jz 0x007ab8f9 0x007ab8dd: movl 0x8(%esi),%eax 0x007ab8e0: cmpl %ebp,%eax 0x007ab8e2: jz 0x007ab8ed 0x007ab8e4: movl 0x0(%eax),%edx 0x007ab8e6: pushl %eax 0x007ab8e7: call *0x8(%edx) 0x007ab8ea: movl %ebp,0x8(%esi) 0x007ab8ed: movl 0x4(%esi),%eax 0x007ab8f0: pushl %eax 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg> Thanks, James Alright, here is a disassembly of 0x007a to 0x007ab8f1. There are a lot of calls to RtlEnterCriticalSection and RtlLeaveCriticalSection, but also some other calls, e.g. SendMessageA, SetRect, Sle
Fwd: Bug 4289: Debugging and dissasembly
-- Forwarded message --From: James Trotter <[EMAIL PROTECTED]>Date: Jan 14, 2006 3:22 PM Subject: Re: Bug 4289: Debugging and dissasemblyTo: Eric Pouech <[EMAIL PROTECTED]>On 1/14/06, Eric Pouech <[EMAIL PROTECTED]> wrote: James Trotter wrote:> Hi!>> A few days ago I filed this bug: http://bugs.winehq.org/show_bug.cgi?id=4289 >> Alexandre commented that there most likely was some stack corruption, > and that I should try and disassemble a few instructions before the> crash and look for API calls.>> Now, I haven't used gdb or winedbg that much before, and I'm a bit> uncertain what to do. I understand that using the disassemble > [][,] command, the debugger will disassemble that address> space. Given the stack trace as in the bug report, which addresses,> exactly, should I disassemble?before 0x007ab8f1 A+--Eric Pouech Sure, but how much before 0x007ab8f1? For instance, Is this helpful? WineDbg starting on pid 0xa In 32 bit mode. 0x7fcfba16 start_process+0xb6 [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/kernel/process.c:996] in kernel32: pushl %edi 996 ExitProcess( entry( peb ) ); Wine-dbg>cont First chance exception: page fault on read access to 0x20202020 in 32-bit code (0x007ab8f1). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:007ab8f1 ESP:7facaba4 EBP: EFLAGS:00210246( - 00 -RIZP1) EAX:20202020 EBX:0001 ECX:7facb450 EDX: ESI:7facb328 EDI:7beb4460 Stack dump: 0x7facaba4: 20202020 2711 7facb328 0x7facabb4: 7facabe0 007aaf30 7facb218 7facaf60 0x7facabc4: 2711 40c38800 7facb328 0x7facabd4: 7facac90 0084566a 0007 7fd0e900 0x7facabe4: 0078e3ca 7facaf60 0040 0x7facabf4: 7fd39206 7facaf60 7fd39206 0200: sel=1007 base=b7f81000 limit=1f97 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x) 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg>disassemble 0x007ab800, 0x007ab8f1 0x007ab800: addb %bh,0x0(%ebx) 0x007ab802: int $0x74 0x007ab804: pop %ss 0x007ab805: cmpl %ebx,0x390(%ecx) 0x007ab80b: jz 0x007ab81c 0x007ab80d: addl $0x394,%ecx 0x007ab813: pushl %ecx 0x007ab814: call *%edi 0x007ab816: movl 0x008cf6d8,%ecx 0x007ab81c: movl 0x13c(%esi),%eax 0x007ab822: cmpl %ebp,%eax 0x007ab824: jz 0x007ab838 0x007ab826: movl 0x0(%eax),%ecx 0x007ab828: pushl %eax 0x007ab829: call *0x8(%ecx) 0x007ab82c: movl %ebp,0x13c(%esi) 0x007ab832: movl 0x008cf6d8,%ecx 0x007ab838: cmpl %ebp,%ecx 0x007ab83a: jz 0x007ab84d 0x007ab83c: cmpl %ebx,0x390(%ecx) 0x007ab842: jz 0x007ab84d 0x007ab844: addl $0x394,%ecx 0x007ab84a: pushl %ecx 0x007ab84b: call *%edi 0x007ab84d: leal 0x128(%esi),%ecx 0x007ab853: call 0x007c22d0 0x007ab858: movl %ebp,0x140(%esi) 0x007ab85e: movl 0x008cf6d8,%eax 0x007ab863: cmpl %ebp,%eax 0x007ab865: jz 0x007ab87b 0x007ab867: cmpl %ebx,0x390(%eax) 0x007ab86d: jz 0x007ab87b 0x007ab86f: addl $916,%eax 0x007ab874: pushl %eax 0x007ab875: call *0x8472c8 -> 0x7beb4180 RtlLeaveCriticalSection [/home/james/development/wine/regression_testing/2005-07-18/wine/dlls/ntdll/critsection.c:407] in ntdll 0x007ab87b: cmpl %ebp,0x90(%esi) 0x007ab881: jz 0x007ab8a4 0x007ab883: leal 0x84(%esi),%edi 0x007ab889: movl %edi,%ecx 0x007ab88b: call 0x007fbe77 0x007ab890: cmpl %ebp,%eax 0x007ab892: jz 0x007ab89c 0x007ab894: movl 0x0(%eax),%edx 0x007ab896: pushl %ebx 0x007ab897: movl %eax,%ecx 0x007ab899: call *0x4(%edx) 0x007ab89c: cmpl %ebp,0x90(%esi) 0x007ab8a2: jnz 0x007ab889 0x007ab8a4: cmpl %ebp,0xac(%esi) 0x007ab8aa: jz 0x007ab8d8 0x007ab8ac: leal 0xa0(%esi),%ebx 0x007ab8b2: movl %ebx,%ecx 0x007ab8b4: call 0x007fbe77 0x007ab8b9: movl %eax,%edi 0x007ab8bb: movl 0x58(%edi),%eax 0x007ab8be: cmpl %ebp,%eax 0x007ab8c0: jz 0x007ab8cb 0x007ab8c2: movl 0x0(%eax),%ecx 0x007ab8c4: pushl %eax 0x007ab8c5: call *0x8(%ecx) 0x007ab8c8: movl %ebp,0x58(%edi) 0x007ab8cb: cmpl %ebp,0xac(%esi) 0x007ab8d1: jnz 0x007ab8b2 0x007ab8d3: movl $0x1,%ebx 0x007ab8d8: cmpl %ebp,0x4(%esi) 0x007ab8db: jz 0x007ab8f9 0x007ab8dd: movl 0x8(%esi),%eax 0x007ab8e0: cmpl %ebp,%eax 0x007ab8e2: jz 0x007ab8ed 0x007ab8e4: movl 0x0(%eax),%edx 0x007ab8e6: pushl %eax 0x007ab8e7: call *0x8(%edx) 0x007ab8ea: movl %ebp,0x8(%esi) 0x007ab8ed: movl 0x4(%esi),%eax 0x007ab8f0: pushl %eax 0x007ab8f1: movl 0x0(%eax),%ecx Wine-dbg> Thanks, James
Re: RFC: implementation of driver functionality in msacm (RESEND)
... then I need new glasses :-) [snip] I examined the DRVCONFIGINFO structure prepared by native msacm32.dll to codecs, in particular the dwDCISize field. Even when the sum of all fields in the structure declaration yields 12 bytes, dwDCISize holds a value of 16 when supplied by native msacm32.dll. So, I used the same value in order to mimic native as close as possible. lend me your glasses, please but, it means then than msacm32 sends a 16 bit structure, likely by extending DRVCONFIGINFO and adding a new field it's a bad thing IMO to pass 16 for the size, and not store a good value at offset 16. A+ -- Eric Pouech
Re: x11drv: Allow WM to manage more windows.
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
@@ -67,6 +67,8 @@ static const char visual_id_prop[]=
inline static BOOL is_window_managed( HWND hwnd )
{
DWORD style, ex_style;
+char class_name[7];
+static const char menu_class[] = "#32768";
+/* menu windows are not managed */
+if (GetClassNameA(hwnd, class_name, sizeof(class_name)) &&
+!memcmp(class_name, menu_class, sizeof(menu_class)))
+return FALSE;
This won't work for subclassed or custom (OfficeXP like) menus.
--
Dmitry.
Problem with older wgl patch
On the newest wine, trying to start opengl programs such as World of Warcraft yields an error such as this:trace:opengl:wine_glCullFace (1029)trace:opengl:wine_glMatrixMode (5889)trace:opengl:wine_glLoadMatrixf (0x7fbafbb8) trace:opengl:wglMakeCurrent (0x368,0x7fd7b7d0)trace:opengl:create_glxpixmap return 1800054trace:opengl:wglMakeCurrent make current for dis 0x7c01baf8, drawable 0x1800054, ctx 0x7c1c01d8X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 412 Current serial number in output stream: 413I don't know enough about wgl to offer any suggestions to the problem, other than the source seems to be this patch: http://cvs.winehq.org/cvsweb/wine/dlls/opengl32/wgl.c.diff?r1=1.71&r2=1.72&sortby=dateReverting that patch and adding + DWORD type = GetObjectType(hdc);where that patch placed it in the file allows opengl to work again.
Bug 4289: Debugging and dissasembly
Hi! A few days ago I filed this bug: http://bugs.winehq.org/show_bug.cgi?id=4289 Alexandre commented that there most likely was some stack corruption, and that I should try and disassemble a few instructions before the crash and look for API calls. Now, I haven't used gdb or winedbg that much before, and I'm a bit uncertain what to do. I understand that using the disassemble [][,] command, the debugger will disassemble that address space. Given the stack trace as in the bug report, which addresses, exactly, should I disassemble? Thanks, James
RE: pch support
Just FYI here are some tests I made in November: http://www.reactos.org/archives/public/ros-dev/2005-November/006273.html Casper -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Edwards Sent: 13. januar 2006 17:01 To: Rolf Kalbermatter Cc: wine-devel@winehq.org; Marcus Meissner Subject: Re: pch support Hi, On 1/13/06, Rolf Kalbermatter <[EMAIL PROTECTED]> wrote: > This solution has been starting to form in my mind as well. It is even > portable to MSVC it seems with a few small modifications to winapi/msvcmaker. I came up with a much more generic solution that will work on all compilers and does not cause a dependancy issue. It requires some minor code adjustments and there is a slight issue if you have errors in linking. The error location is wrong so you need to have a way to disable this if you have a real error to track the problem down, but once I fixed ReactOS shell32.dll to use my hack my compile times on gcc4 went from 30+ secs down to 9sec. MSVC went from 22 to less than 1 secound. In short each module would have its own autogenerated master C file that would include all of the others like the one I have attached. Minus the #define hacks. I personally think its more of a nasty hack but a configure switch could be added like --enable-compilation-units Because each header is only processed once, it give the same effect as PCH. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
