Re: Second Listview status update
On October 18, 2002 08:02 pm, Rizsanyi Zsolt wrote: > And what have to be applied to the current cvs? Its enough if I only apply > the T0-4 patches? Yes. But latest CVS should be fine now. > I dont really know where Alexandre has reached with applying your pathes. > Maybe he should add the codename of the patch to the cvs commits. He applied all the Ts. I know, I thought about adding the codename to the logs myself, but I got lazy... :) -- Dimi.
DECLARE_OLD_HANDLE ?
Hello Alexandre, any reason why you haven't removed DECLARE_OLD_HANDLE? It's now with the per dll -DSTRICT compilation IMO useless. Changing the remaining DECLARE_OLD_HANDLE's to DECLARE_HANDLE didn't changed the compile output. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12545/pgp0.pgp Description: PGP signature
Re: Second Listview status update
On Friday 18 October 2002 22:29, you wrote: > On October 18, 2002 11:53 am, Rizsanyi Zsolt wrote: > > 'Properties' is a simple listview which is tied to a 'preview' window, > > which does not show preview, but some properties of the document. > > Though its a simple listview as the 'List', but it has this bug, while > > 'List' does not have... > > Thanks for the explanation. Try T0-4, they should solve it. > If not, please let me know. And what have to be applied to the current cvs? Its enough if I only apply the T0-4 patches? I dont really know where Alexandre has reached with applying your pathes. Maybe he should add the codename of the patch to the cvs commits. Regards Zsolt
Re: problem with --debugmsg +relay
"Medland, Bill" <[EMAIL PROTECTED]> writes: > Does anyone know of a problem with +relay? > > I've never been able to use it effectively because turning it on crashes the > program I am working on. > > Anyway, I've just got an indication that either it is modifying arguments or > damaging memory. > > Is this a known issue? If so then what are the circumstances? Usually this is because a spec file entry doesn't specify the right parameters. There is also a known issue with register functions that may cause exception handling to go slightly wrong. If it's neither of these you may have found a new bug -- Alexandre Julliard [EMAIL PROTECTED]
Re: DSTRICT: cast1
Michael Stefaniuc <[EMAIL PROTECTED]> writes: > Michael Stefaniuc <[EMAIL PROTECTED]> > - silence some warnings due to casts between pointer and > intergers of different size Note that HINSTANCE handles in general cannot be converted by simply truncating the handle, so the places where we do that should be fixed properly. The fact that we get warnings for them with -DSTRICT is a feature, so please don't silence them without making sure the code is right first. -- Alexandre Julliard [EMAIL PROTECTED]
Re: new wine, me whining
> > =>0 0x402acdc7 (NTDLL.DLL.memcpy+0x27 in libc.so.6) (ebp=406a29e4) > > 1 0x40c90844 (DIB_DirectDrawSurface_BltFast+0x51c(iface=0x403c2da8, > > dstx=0x28, dsty=0x23, src=0x403c3878, rsrc=0x406a2b8c, trans=0x10) > > [dib.c:870] in ddraw.dll.so) (ebp=406a2b34) > > 2 0x40c937df (IDirectDrawSurface3Impl_BltFast+0x47(This=0x403c2dac, > > x=0x28, y=0x23, pSrcSurf=0x403c387c, prcSrc=0x406a2b8c, dwTrans=0x10) > > [thunks.c:94] in ddraw.dll.so) (ebp=406a2b5c) > > 3 0x0044ecfe (Panzer3d.exe..text+0x4dcfe in > > C:\games\pgiiid\Panzer3d.exe) (ebp=406a2b9c) > > Well, could you either send me a +ddraw log of the problem or create a bug > on Bugzilla and attach the log there. Ok, now because I don't have really much time to spend on debugging (hope that will change soon), here is the full log with +ddraw debugmsg set on. But before I will really debug this thingy, I will first try to complete about the bugfix for wizardry 8 I mentioned about a month before (and have also written a workaround for this game only). mIc P.S.: be aware that the log.txt has 3.7MB after decompressing it. PPS: No problem with the mail beeing harsh, in fact my first mail about this _WAS_ useless log.txt.bz2 Description: Binary data
problem with --debugmsg +relay
Does anyone know of a problem with +relay? I've never been able to use it effectively because turning it on crashes the program I am working on. Anyway, I've just got an indication that either it is modifying arguments or damaging memory. Is this a known issue? If so then what are the circumstances? Bill
Re: winedbg
On October 18, 2002 02:19 pm, Eric Pouech wrote: > > That's a bit of a problem, isn't it... :) > > not as long as use a decent screen buffer size ;-)) But I want to be able to scroll back 1 lines! -- Dimi.
Re: winedbg
> That's a bit of a problem, isn't it... :) not as long as use a decent screen buffer size ;-)) A+
Re: [PATCH] Re: [PATCH] some dc:LockWindowUpdate work
Christian Neumair <[EMAIL PROTECTED]> writes: > I see a reason: FIXME denotes that something should be fixed, but in > this place we don't need to fix anything. I prepared a really small > patch, have a look at it and tell me if you still find the cleanup > obsolete. And I think it's not a good idea to tell the users that > something has gone wrong (stub) while the desired action was taken > without any problems. But no desired action has taken place at all! All we do is store the window in an internal variable, but we don't lock the window updates at all, which is the whole point of the function. So a fixme is definitely appropriate. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH] some dc:LockWindowUpdate work
Am Fre, 2002-10-18 um 00.19 schrieb Alexandre Julliard: > Christian Neumair <[EMAIL PROTECTED]> writes: > > > this patch improves dc:LockWindowUpdate (windows/dce.c); locking > > other windows still not possible, though. > > Apart from removing the fixme this doesn't appear to change anything > at all. What were you trying to fix? -/* Unlock lockedWnd */ -/* FIXME: Do something */ + /* Unlock lockedWnd */ + lockedWnd = 0; + + USER_Unlock(); + return TRUE; The version in HEAD actually doesn't unlock the window inside the function but just exits the if loop. The patch adds an unlock function (see msdn, when not passing hwnd, the active window should be unlocked) and moves the stub to the place where it belongs. Basically this makes the code easier to read. If you want we can remove the whole if (!hwnd) code because if hwnd is 0, lockedWnd = hwnd does the right thing, too. regs, Chris
[PATCH] Re: [PATCH] some dc:LockWindowUpdate work
Am Fre, 2002-10-18 um 17.34 schrieb Alexandre Julliard:
> Christian Neumair <[EMAIL PROTECTED]> writes:
>
> > The version in HEAD actually doesn't unlock the window inside the
> > function but just exits the if loop. The patch adds an unlock function
> > (see msdn, when not passing hwnd, the active window should be unlocked)
> > and moves the stub to the place where it belongs. Basically this makes
> > the code easier to read. If you want we can remove the whole if (!hwnd)
> > code because if hwnd is 0, lockedWnd = hwnd does the right thing, too.
>
> Well, it already does the right thing today, so I don't see why you
> need to change it. If it's just to make it more readable OK, but I
> don't see much point given that this function is completely wrong
> anyway. And I definitely don't see a reason for removing the fixme
> message.
I see a reason: FIXME denotes that something should be fixed, but in
this place we don't need to fix anything. I prepared a really small
patch, have a look at it and tell me if you still find the cleanup
obsolete. And I think it's not a good idea to tell the users that
something has gone wrong (stub) while the desired action was taken
without any problems.
regs,
Chris
/*
* USER DCE functions
*
* Copyright 1993 Alexandre Julliard
* 1996,1997 Alex Korobka
*
* 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
*
*
* Note: Visible regions of CS_OWNDC/CS_CLASSDC window DCs
* have to be updated dynamically.
*
* Internal DCX flags:
*
* DCX_DCEEMPTY- dce is uninitialized
* DCX_DCEBUSY - dce is in use
* DCX_DCEDIRTY- ReleaseDC() should wipe instead of caching
* DCX_KEEPCLIPRGN - ReleaseDC() should not delete the clipping region
* DCX_WINDOWPAINT - BeginPaint() is in effect
*/
#include
#include "dce.h"
#include "win.h"
#include "gdi.h"
#include "user.h"
#include "wine/debug.h"
#include "windef.h"
#include "wingdi.h"
#include "wine/winbase16.h"
#include "wine/winuser16.h"
WINE_DEFAULT_DEBUG_CHANNEL(dc);
static DCE *firstDCE;
static HDC defaultDCstate;
static void DCE_DeleteClipRgn( DCE* );
static INT DCE_ReleaseDC( DCE* );
/***
* DCE_DumpCache
*/
static void DCE_DumpCache(void)
{
DCE *dce;
USER_Lock();
dce = firstDCE;
DPRINTF("DCE:\n");
while( dce )
{
DPRINTF("\t[0x%08x] hWnd 0x%04x, dcx %08x, %s %s\n",
(unsigned)dce, dce->hwndCurrent, (unsigned)dce->DCXflags,
(dce->DCXflags & DCX_CACHE) ? "Cache" : "Owned",
(dce->DCXflags & DCX_DCEBUSY) ? "InUse" : "" );
dce = dce->next;
}
USER_Unlock();
}
/***
* DCE_AllocDCE
*
* Allocate a new DCE.
*/
DCE *DCE_AllocDCE( HWND hWnd, DCE_TYPE type )
{
DCE * dce;
if (!(dce = HeapAlloc( GetProcessHeap(), 0, sizeof(DCE) ))) return NULL;
if (!(dce->hDC = CreateDCA( "DISPLAY", NULL, NULL, NULL )))
{
HeapFree( GetProcessHeap(), 0, dce );
return 0;
}
if (!defaultDCstate) defaultDCstate = GetDCState16( dce->hDC );
/* store DCE handle in DC hook data field */
SetDCHook( dce->hDC, DCHook16, (DWORD)dce );
dce->hwndCurrent = WIN_GetFullHandle( hWnd );
dce->hClipRgn= 0;
if( type != DCE_CACHE_DC ) /* owned or class DC */
{
dce->DCXflags = DCX_DCEBUSY;
if( hWnd )
{
LONG style = GetWindowLongW( hWnd, GWL_STYLE );
if (style & WS_CLIPCHILDREN) dce->DCXflags |= DCX_CLIPCHILDREN;
if (style & WS_CLIPSIBLINGS) dce->DCXflags |= DCX_CLIPSIBLINGS;
}
SetHookFlags16(dce->hDC,DCHF_INVALIDATEVISRGN);
}
else dce->DCXflags = DCX_CACHE | DCX_DCEEMPTY;
USER_Lock();
dce->next = firstDCE;
firstDCE = dce;
USER_Unlock();
return dce;
}
/***
* DCE_FreeDCE
*/
DCE* DCE_FreeDCE( DCE *dce )
{
DCE **ppDCE, *ret;
if (!dce) return NULL;
USER_Lock();
ppDCE = &firstDCE;
while (*ppDCE && (*ppDCE != dce)) ppDCE = &(*ppDCE)->next;
if (*ppDCE == dce) *ppDCE = dce->next;
ret = *ppDCE;
USER_Unlock();
SetDCHook(dce->hDC, NULL, 0L);
DeleteDC( dce->hDC );
if( dce->hClipRgn && !(dce->DCXflags & DCX_KEEPCLIPRGN) )
DeleteObj
[PATCH] Re: [PATCH] some dc:LockWindowUpdate work, second attempt
Sorry, I sent the whole file where I modified some other stuff to play
around :/.
Please try this patch.
regs,
Chris
Index: dce.c
===
RCS file: /home/wine/wine/windows/dce.c,v
retrieving revision 1.72
diff -u -r1.72 dce.c
--- dce.c 9 Jul 2002 01:57:28 - 1.72
+++ dce.c 18 Oct 2002 15:33:24 -
@@ -654,25 +658,21 @@
{
static HWND lockedWnd;
-FIXME("(%x), partial stub!\n",hwnd);
-
USER_Lock();
-if (lockedWnd)
-{
-if (!hwnd)
-{
-/* Unlock lockedWnd */
-/* FIXME: Do something */
-}
-else
+
+if (lockedWnd && hwnd)
{
/* Attempted to lock a second window */
/* Return FALSE and do nothing */
+FIXME("(%x), stub!\n", hwnd);
+
USER_Unlock();
return FALSE;
}
-}
+
+/* (un-)lock hwnd */
lockedWnd = hwnd;
+
USER_Unlock();
return TRUE;
}
Re: winedbg
On October 18, 2002 12:31 pm, Eric Pouech wrote: > set a much smaller screen-buffer > 120,3000 will create a way too big screenbuffer (i mean the bitmap to > render it) Thanks, that works. > (as of today, the full sb is stored in a unique bitmap... and here the > bmp allocation fails) That's a bit of a problem, isn't it... :) -- Dimi.
Re: winedbg
> On October 17, 2002 04:23 pm, Eric Pouech wrote: > > can you send me a -debugmsg +wineconsole,+wc_font trace TIA > > Sure, I run it like this: set a much smaller screen-buffer 120,3000 will create a way too big screenbuffer (i mean the bitmap to render it) (as of today, the full sb is stored in a unique bitmap... and here the bmp allocation fails) A+
Re: [PATCH] some dc:LockWindowUpdate work
Christian Neumair <[EMAIL PROTECTED]> writes: > The version in HEAD actually doesn't unlock the window inside the > function but just exits the if loop. The patch adds an unlock function > (see msdn, when not passing hwnd, the active window should be unlocked) > and moves the stub to the place where it belongs. Basically this makes > the code easier to read. If you want we can remove the whole if (!hwnd) > code because if hwnd is 0, lockedWnd = hwnd does the right thing, too. Well, it already does the right thing today, so I don't see why you need to change it. If it's just to make it more readable OK, but I don't see much point given that this function is completely wrong anyway. And I definitely don't see a reason for removing the fixme message. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Second Listview status update
On Fri, 18 Oct 2002 09:46:18 -0400, you wrote: > On October 18, 2002 03:35 am, Rein Klazes wrote: > > It does. Now it crashes again like it did after the change in rev. > > BTW, how did you get it to crash? It starts up, and load newsgroups > just fine here... Select a newsgroup, right click and choose "download latest headers" The newsgroup listview then clears and the program crashes. Aparently when it is rebuilding the display again. Using newsbin 4.05. Wine with no native system dll's. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Second Listview status update
On October 18, 2002 08:22 am, Rizsanyi Zsolt wrote: > Ok. I have updated cvs, and the double click problem went away :) At least there is _some_ good news :) > But I have tested more toroughly the open dialog of Word97 and found out > that it has some update problems when changing beetwen different view > modes. Duh! > Like when you change from Details view to Properties view, then the header > of the Details view (where the Name, Size, Type, ... is written) stays > there. If you change back to List view and then directly to Properties, > then the Properties view is ok. WTH is "Properties"? I don't have Office97, so can you please send me a sceenshot with it OK, and with the problem? -- Dimi.
Re: Second Listview status update
On October 18, 2002 03:35 am, Rein Klazes wrote: > It does. Now it crashes again like it did after the change in rev. BTW, how did you get it to crash? It starts up, and load newsgroups just fine here... -- Dimi.
Re: Second Listview status update
On Fri, 18 Oct 2002 09:33:14 -0400, you wrote: > On October 18, 2002 03:35 am, Rein Klazes wrote: > > It does. > > Finally! I had nightmares about it... :) > > > Now it crashes again like it did after the change in rev. 210 > > You mean that 209 worked fine, and 210 crashes?!? 209 does not crash and 210 crashes. I checked again to be sure. > That was supposed to be a noop change... I looked at it again, > and there's not much to it. > > Listen, I need your help to fix it, as I'm running out of time. > Can you take 209, and then apply bits of the changes until you > find which one does it? If you don't know how to do that, let > me know, and I'll try to come up with some patches. No problem. Hopefully I can do that later today. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Second Listview status update
On October 18, 2002 03:35 am, Rein Klazes wrote: > It does. Finally! I had nightmares about it... :) > Now it crashes again like it did after the change in rev. 210 You mean that 209 worked fine, and 210 crashes?!? That was supposed to be a noop change... I looked at it again, and there's not much to it. Listen, I need your help to fix it, as I'm running out of time. Can you take 209, and then apply bits of the changes until you find which one does it? If you don't know how to do that, let me know, and I'll try to come up with some patches. -- Dimi.
Re: Second Listview status update
On Wednesday 16 October 2002 17:59, Rizsanyi Zsolt wrote: > On Wednesday 16 October 2002 14:39, Dimitrie O. Paun wrote: > > On October 16, 2002 06:16 am, Rizsanyi Zsolt wrote: > > > But the double click selection do not work eg in the MSOffice file open > > > dialogs. > > > > Did you apply the R-series? > > I'm using the cvs from about 5 hours ago (12:00 CET). Ok. I have updated cvs, and the double click problem went away :) But I have tested more toroughly the open dialog of Word97 and found out that it has some update problems when changing beetwen different view modes. Like when you change from Details view to Properties view, then the header of the Details view (where the Name, Size, Type, ... is written) stays there. If you change back to List view and then directly to Properties, then the Properties view is ok. Another problem, is that when you change from Properties view to List view, then the icons are not loaded correctly, but every item gets the same (unknown file) icon . But if you change the directory (and back), then everything is normal. In the Details view, the header is weird. If you scroll to right, then the name of the first column appears in the header. Mouse wheel scrolling do not work (tough I dont know if it should, but it would be nice). And in the date column (in Details view), instead of date only the date format (M/d/) is shown. Maybe not all of that is a listview issue, but you maybe I could help some... Regards Zsolt
Re: new wine, me whining
> here it comes: > =>0 0x402acdc7 (NTDLL.DLL.memcpy+0x27 in libc.so.6) (ebp=406a29e4) > 1 0x40c90844 (DIB_DirectDrawSurface_BltFast+0x51c(iface=0x403c2da8, > dstx=0x28, dsty=0x23, src=0x403c3878, rsrc=0x406a2b8c, trans=0x10) > [dib.c:870] in ddraw.dll.so) (ebp=406a2b34) > 2 0x40c937df (IDirectDrawSurface3Impl_BltFast+0x47(This=0x403c2dac, > x=0x28, y=0x23, pSrcSurf=0x403c387c, prcSrc=0x406a2b8c, dwTrans=0x10) > [thunks.c:94] in ddraw.dll.so) (ebp=406a2b5c) > 3 0x0044ecfe (Panzer3d.exe..text+0x4dcfe in > C:\games\pgiiid\Panzer3d.exe) (ebp=406a2b9c) Well, could you either send me a +ddraw log of the problem or create a bug on Bugzilla and attach the log there. Lionel PS: sorry to have been a bit harsh in my first reply, but 'useless' debug reports are annoying me :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: new wine, me whining
On Fri, Oct 18, 2002 at 09:44:17AM +0200, [EMAIL PROTECTED] wrote: > > > 1. when will this be fixed ? > > > fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or > > > DDBLT_ASYNC: can't handle right now. > > > > Did you actually read any DirectX doc before complaining ? These flags are > > completely useless when emulating a blit and have sense only when doing it > > in hardware. > > Ok, i did not and I should have done it before :( > > > > wine: Unhandled exception, starting debugger... > > > > Did you send us a backtrace of the problem ? A trace ? > > here it comes: > =>0 0x402acdc7 (NTDLL.DLL.memcpy+0x27 in libc.so.6) (ebp=406a29e4) > 1 0x40c90844 (DIB_DirectDrawSurface_BltFast+0x51c(iface=0x403c2da8, > dstx=0x28, dsty=0x23, src=0x403c3878, rsrc=0x406a2b8c, trans=0x10) > [dib.c:870] in ddraw.dll.so) (ebp=406a2b34) > 2 0x40c937df (IDirectDrawSurface3Impl_BltFast+0x47(This=0x403c2dac, > x=0x28, y=0x23, pSrcSurf=0x403c387c, prcSrc=0x406a2b8c, dwTrans=0x10) OK, that very much sounds like we've got some graphics geometry wrong and the memcpy() done by DIB_DirectDrawSurface_BltFast() thus catches a wrong number of bytes to copy... Try finding out why that graphics buffer copying uses the wrong size arguments... -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php
Re: multithreading winelib app
On Thu, Oct 17, 2002 at 05:29:27PM -0700, Francois Gouget wrote: > On Fri, 18 Oct 2002, Malte Starostik wrote: > > > Hi, > > > > before I make some major mistakes: can a winelib app safely use pthreads and > > run WinAPI functions from multiple threads or will it have to use Windows > > threads? > > Winelib applications cannot use pthreads. They should not even be linked > with the pthread library. The obligatory question: is it in the Winelib Users Guide ? ;-) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: Find the main winelib app with GetModuleHandle
On Thu, Oct 17, 2002 at 02:44:09PM -0700, Alexandre Julliard wrote: > Malte Starostik <[EMAIL PROTECTED]> writes: > > > Check if the name passed to GetModuleHandle() is the name > > of the main executable. As those normally don't have an extension > > ".DLL" was appended and the search failed. > > Actually you should give your executable a .exe extension, there are a > number of places where we expect that (the Unix wrapper script doesn't > need an extension of course, but the .so does). Is there *anything* that we can do to automatically print a warning message during some stage ? Would be quite helpful, don't'cha think ? -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://mohr.de.tt
Re: new wine, me whining
> > 1. when will this be fixed ? > > fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or > > DDBLT_ASYNC: can't handle right now. > > Did you actually read any DirectX doc before complaining ? These flags are > completely useless when emulating a blit and have sense only when doing it > in hardware. Ok, i did not and I should have done it before :( > > wine: Unhandled exception, starting debugger... > > Did you send us a backtrace of the problem ? A trace ? here it comes: =>0 0x402acdc7 (NTDLL.DLL.memcpy+0x27 in libc.so.6) (ebp=406a29e4) 1 0x40c90844 (DIB_DirectDrawSurface_BltFast+0x51c(iface=0x403c2da8, dstx=0x28, dsty=0x23, src=0x403c3878, rsrc=0x406a2b8c, trans=0x10) [dib.c:870] in ddraw.dll.so) (ebp=406a2b34) 2 0x40c937df (IDirectDrawSurface3Impl_BltFast+0x47(This=0x403c2dac, x=0x28, y=0x23, pSrcSurf=0x403c387c, prcSrc=0x406a2b8c, dwTrans=0x10) [thunks.c:94] in ddraw.dll.so) (ebp=406a2b5c) 3 0x0044ecfe (Panzer3d.exe..text+0x4dcfe in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2b9c) 4 0x0041e30d (Panzer3d.exe..text+0x1d30d in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2bdc) 5 0x0044e86f (Panzer3d.exe..text+0x4d86f in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2c00) 6 0x00421ba2 (Panzer3d.exe..text+0x20ba2 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2c14) 7 0x004036e8 (Panzer3d.exe..text+0x26e8 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2c30) 8 0x0041e648 (Panzer3d.exe..text+0x1d648 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2c4c) 9 0x00404e08 (Panzer3d.exe..text+0x3e08 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2c68) 10 0x0040c3a8 (Panzer3d.exe..text+0xb3a8 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2c84) 11 0x00403024 (Panzer3d.exe..text+0x2024 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2ca4) 12 0x00421218 (Panzer3d.exe..text+0x20218 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2cd8) 13 0x00421716 (Panzer3d.exe..text+0x20716 in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2d00) 14 0x407b4787 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=406a2d24) 15 0x407b481d (WINPROC_CallWndProc+0x8d(proc=0x4215b9, hwnd=0x10021, msg=0x202, wParam=0x0, lParam=0x1b0026a) [winproc.c:183] in user32.dll.so) (ebp=406a2d54) 16 0x407ba958 (CallWindowProcA+0x88(func=0x413e06c8, hwnd=0x10021, msg=0x202, wParam=0x0, lParam=0x1b0026a) [winproc.c:2788] in user32.dll.so) (ebp=406a2d7c) 17 0x4079d451 (DispatchMessageA+0x121(msg=0x406a2ddc) [message.c:1079] in user32.dll.so) (ebp=406a2dc0) 18 0x00421fad (Panzer3d.exe..text+0x20fad in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2e08) 19 0x0047db2e (Panzer3d.exe.EntryPoint+0x15e in C:\games\pgiiid\Panzer3d.exe) (ebp=406a2e9c) 20 0x400b4120 (start_process+0x21c [process.c:564] in libntdll.dll.so) (ebp=406a2f38) 21 0x400b829d (call_on_thread_stack+0x1d(func=0x400b3f04) [sysdeps.c:112] in libntdll.dll.so) (ebp=406a2ff4) 22 0x400b8430 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=) 0x402acdc7 (NTDLL.DLL.memcpy+0x27 in libc.so.6): repe movsl (%esi),%es:(%edi) > > 5. what can i do to speed up development? > > Start coding ? > I did about 4 month ago and asked questions about how to go on patching wine to get wizardry 8 running (i got it running on my system, but with wine patched this way nothing else runs with it). mIc
Re: Second Listview status update
On Thu, 17 Oct 2002 23:55:59 -0400, you wrote: > On October 17, 2002 01:49 am, Rein Klazes wrote: > > Uploaded to www.xs4all.nl/~rklazes/temp/nb3.log.bz2 > > Fine. That didn't work... :/ But I think I fixed now: > please try T0, and T1. If that doesn't work... It does. Now it crashes again like it did after the change in rev. 1.210: | Unhandled exception: page fault on read access to 0x4e8880d8 in 32-bit code |(0x004092ed). | In 32-bit mode. | 0x004092ed (nbpro.exe..text+0x82ed in H:\binw\nbpro\nbpro.exe): call *0x20(%eax) | Backtrace: | =>0 0x004092ed (nbpro.exe..text+0x82ed in H:\binw\nbpro\nbpro.exe) (ebp=004c7470) | 1 0x2bdce900 (LIBFILTER.DLL..reloc+0x1bd8b900) (ebp=4e8880b8) | *** Invalid address 0x4e8880b8 (_end+0xc2c0718) | A fresh message log uploaded as www.xs4all.nl/~rklazes/temp/nb4.log.bz2 Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Marshalling code for me to use?
On Thursday 17 October 2002 03:19 pm, Ove Kaaven wrote: > On Thu, 17 Oct 2002, Greg Turner wrote: > > Before I go off and duplicate a bunch of work somebody already did, > > I wanted to verify that wine has no existing implementation of NDR data > > marshalling? I don't know of such a thing, but I don't necessarily have > > the big picture. rpcrt4 needs this for somewhat obvious reasons, and the > > format is well documented by OpenGroup if we need to start an > > implementation from scratch. > > The format may be standard, but the API that rpcrt4 use is pretty > undocumented (apart from the self-documenting function names and pretty > complete header files). I was planning to work on this stuff again soon, my goodness, tell me about it! at least some of them have entertaining names like I_RpcTransServerMaxFrag ;) > but haven't yet written any more code than what you've merged (and I would > probably begin spending time mapping more RPC format chars by writing some > IDL, feeding it through MIDL, studying the output, and update > include/wine/rpcfc.h, or I would spend time typing in stuff like a Wine > version of wtypes.idl, so might take even longer before I got to write any > marshalling code), the format chars have a bit of documentation in MSDN Library. It's a little confusing and terse but much better than nothing, and, so far, consistent with what I see coming from MIDL. Kinda surprising that they bothered to document the format since they don't document what to do with it :) BTW, I assume that MIDL-generated code can't go into wine? I plan to avoid the issue by generating proxy/stub code in wetware, with corresponding IDL so we can eventually replace wetware-generated proxy/stub code with widl-generated equivalents... Anyhoo... I don't like to bang out code without being able to run it and see that it works. So I'm leaning towards an incremental approach. That's why I've been playing with "hello world" and the unit-testing framework. OTOH, I don't want to pile crap on the foundation you've built, so I will tread with caution. > and I don't know about anyone else working on it > (Juergen Schmied is probably busy with other stuff). So if you want to > start on it, go ahead, I'll give you all the help I can (as long as time > permits, and the license of your work remains ReWind-compatible), my > employer wants to see a functional RPC/DCOM infrastructure in Wine... It would be unfortunate for both of us to work on the same parts of this at the same time and create a merge situation, so let me know if you start diving into it and we'll work out some way not to step on each other's toes. I appreciate your offer to help out, I won't hesitate to take you up on it! If ignorance is bliss, I should be a happy guy... As for licensing, I will release everything as X11 for now. X11 seems to allow all the major wine forks to absorb my code, which would be my preference. -- gmt
Re: new wine, me whining
> 1. when will this be fixed ? > fixme:ddraw:DIB_DirectDrawSurface_Blt dwFlags DDBLT_WAIT and/or > DDBLT_ASYNC: can't handle right now. Did you actually read any DirectX doc before complaining ? These flags are completely useless when emulating a blit and have sense only when doing it in hardware. > wine: Unhandled exception, starting debugger... Did you send us a backtrace of the problem ? A trace ? > 3. where can i get the old wine sources (not with first implementation of > dx8) CVS is your friend. > 4. why not split development of wine and DX so, that anyone can install > the DX version he wants. Well, what would be the advantage of that ? Do you know other implementations of DX than the one in Wine ? > 5. what can i do to speed up development? Start coding ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
