wine-devel

wine-devel@winehq.org

3 participants
84471 discussions

re: Regression in ntdll/virtual.c
by Dan Kegel 14 Jan '06

14 Jan '06

>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

1 0

IWineD3DSurface::GetDC
by Stefan Dösinger 14 Jan '06

14 Jan '06

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(00000000), output lockedRect@0x7fbaf4a8, 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 memory@0x7dfa0020, 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 0x7dfa0000 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:7fce0000 EBX:7ffd5540 ECX:7e5c0250 EDX:7dfa0000 ESI:7e5c0248 EDI:7fce0040 Stack dump: 0x7fbaf714: 00000030 7fbaf754 7ff99c0b 7fce0000 0x7fbaf724: 7e5c0248 7f712cd0 00000000 00004f4c 0x7fbaf734: 7ff99294 7fd8fee8 7e5c0248 7ff8dffa 0x7fbaf744: 7f6edf2b 7ffd5540 00000030 00000030 0x7fbaf754: 7fbaf798 7ff9a954 7fce0000 00000030 0x7fbaf764: 7fbaf788 7f70253b 0000027c 00004f4c Backtrace: =>1 0x7ff99374 HEAP_FindSubHeap+0x14(heap=0x7fce0000, ptr=0x7e5c0248) [heap.c:375] in ntdll (0x7ff99374) 2 0x7ff99c0b HEAP_FindFreeBlock+0x7b(heap=0x7fce0000, size=0x30, ppSubHeap=0x7fbaf788) [/usr/src/wine-wined3d/dlls/ntdll/heap.c:390] in ntdll (0x7ff99c0b) 3 0x7ff9a954 RtlAllocateHeap(heap=0x7fce0000, 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: movl 0x0(%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 member of WineD3DSurface is taken from ddraw: typedef struct wineD3DSurface_DIB { HBITMAP DIBsection; void* bitmap_data; HGDIOBJ holdbitmap; BOOL client_memory; DWORD d3d_data[4]; /* room for Direct3D driver data */ } wineD3DSurface_DIB; Stefan

1 0

Re: x11drv: Allow WM to manage more windows.
by Dmitry Timoshkov 14 Jan '06

14 Jan '06

"Vitaliy Margolen" <wine-patch(a)kievinfo.com> 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.

2 1

[wined3d] Status update: Converting Wined3d to use WGL instead of GLX
by Aric Cyr 14 Jan '06

14 Jan '06

Hi all, Just wanted to chime in with a status update on my porting of wined3d to WGL. Basically, I am in the debug phase, and at this point most bugs have been ironed out. That is, for dx9 stuff. I soon ran into problems/regressions with dx8 or lower (including ddraw!). So I ended up repeating the (almost) exactly same work for d3d8 and ddraw... not a pretty sight, and a pain to debug them all. As a result this conversion has become a fairly large and invasive change affecting all versions of directx... [I can't wait for all these to be completely ported to wined3d]. For testing d3d8 I've been using 3DMark2001SE and some DirectX tutorial/demo apps. For d3d9 I use World of Warcraft (hehe) and more tutorial/demo apps. I forget what I used for d3d7 though... I'll have to double check that. Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent). Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps. I'm currently in the process of cleaning everything up and then I will post a patch on my site for people to download. Due to the scope of the changes, I really hope that people can help me test this sucker... once that's done I'll chop up the patch into logical pieces and submit them. That's all for now! - Aric P.S. If anyone wants, they can edit http://winehq.org/site/fun_projects and put me down for the "wined3d use wgl" project.

6 10

Valgrind and wine (was: re: Bug 4289: Debugging and dissasembly)
by Dan Kegel 14 Jan '06

14 Jan '06

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

2 1

Fwd: Bug 4289: Debugging and dissasembly
by James Trotter 14 Jan '06

14 Jan '06

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Jan 14, 2006 3:22 PM Subject: Re: Bug 4289: Debugging and dissasembly To: Eric Pouech <eric.pouech(a)wanadoo.fr> On 1/14/06, Eric Pouech <eric.pouech(a)wanadoo.fr> 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 > > [<addr>][,<addr>] 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:00000000 EFLAGS:00210246( - 00 -RIZP1) EAX:20202020 EBX:00000001 ECX:7facb450 EDX:00000000 ESI:7facb328 EDI:7beb4460 Stack dump: 0x7facaba4: 20202020 00002711 00000000 7facb328 0x7facabb4: 7facabe0 007aaf30 7facb218 7facaf60 0x7facabc4: 00000000 00002711 40c38800 7facb328 0x7facabd4: 7facac90 0084566a 00000007 7fd0e900 0x7facabe4: 0078e3ca 00000000 7facaf60 00400000 0x7facabf4: 7fd39206 7facaf60 00000000 7fd39206 0200: sel=1007 base=b7f81000 limit=00001f97 32-bit rw- Backtrace: =>1 0x007ab8f1 in iwd2 (+0x3ab8f1) (0x00000000) 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

2 3

Re: RFC: implementation of driver functionality in msacm (RESEND)
by Alex Villacís Lasso 14 Jan '06

14 Jan '06

Eric Pouech wrote: > Alex Villacís Lasso wrote: > >> Eric Pouech wrote: >> >>>> * Implementation of broadcasts to notification windows on driver >>>> add/remove, enabling/disabling, and priority changes >>> >>> >>> >>> - MSDN seems to state that differed notification is actually a >>> counter, not a simple boolean (whereas enable/disable is a boolean) >> >> >> >> I have just read the MSDN web page, and I see no remark that suggests >> that deferred notification should behave as a counter instead of a >> simple on/off flag. Or maybe I am reading the page incorrectly... > > well... > ACM_DRIVERPRIORITYF_END Calling task wants to reenable change > notification broadcasts. An application must call acmDriverPriority > with ACM_DRIVERPRIORITYF_END for each successful call with the > ACM_DRIVERPRIORITYF_BEGIN flag. Note that hadid must be NULL, > dwPriority must be zero, and only the ACM_DRIVERPRIORITYF_END flag can > be set. > ... then I need new glasses :-) >> >>>> * Fix for implementation quirks of acmDriverMessage() in order to >>>> allow native codecs to display configuration dialogs >>> >>> >>> >>> this seems rather hackish. did you actually tested this on Windows ? >>> Moreover, the size bits look especially suspicious. Where did you >>> get the 16 value from ? >> >> >> >> I tested the native msacm32.dll from Windows 98 SE on Wine, and it >> reported a 16-byte struct size to the winemp3 codec. > > how do you know it's a 16 byte struct? there's nothing in the passed > information that tells you it's 16 bytes AFAICS Yes, there is: (begin MSDN quote) DRV_CONFIGURE Directs the installable driver to display its configuration dialog box and let the user specify new settings for the given installable driver instance. *Parameters* /dwDriverId/ Identifier of the installable driver. This is the same value previously returned by the driver from the *DRV_OPEN* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drv_open.asp> message. /hdrvr/ Handle of the installable driver instance. /lParam1/ Handle of the parent window. This window is used as the parent window for the configuration dialog box. /lParam2/ Address of a *DRVCONFIGINFO* <http://msdn.microsoft.com/library/en-us/multimed/htm/_win32_drvconfiginfo_s…> structure or NULL. If the structure is given, it contains the names of the registry key and value associated with the driver. DRVCONFIGINFO Contains the registry key and value names associated with the installable driver. |typedef struct tagDRVCONFIGINFO { DWORD dwDCISize; LPCWSTR lpszDCISectionName; LPCWSTR lpszDCIAliasName; } DRVCONFIGINFO; | *Members* *dwDCISize* Size of the structure, in bytes. *lpszDCISectionName* Address of a null-terminated, wide-character string specifying the name of the registry key associated with the driver. *lpszDCIAliasName* Address of a null-terminated, wide-character string specifying the name of the registry value associated with the driver. (end MSDN quote) 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. Alex Villacís Lasso

2 1

Bug 4289: Debugging and dissasembly
by James Trotter 14 Jan '06

14 Jan '06

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 [<addr>][,<addr>] 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

1 0

FAQ outdated in one point
by CS 13 Jan '06

13 Jan '06

In the FAQ you write under "2.12. When will Wine be finished?": "Right now we are working on releasing Wine 0.9 our schedule has this release around September 30th 2005." maybe that should be updated or removed altogether so there don't need to be updates to this entry in the future. sorry that I can't do more to contribute :-) clem

2 1

RFC: pch support
by Steven Edwards 13 Jan '06

13 Jan '06

Hi, Alexandre did not like the needed changes required to add support for this but I figured I would throw it out for debate anyway in case anyone else can make him change his mind (duck). The issue is he does not like needing a single header per-program or per dll. After doing some research it seems to me that even MSVC does not support multiple PCH files per project so I don't know how it could be fixed in gcc to do it Microsoft has not figured it out. problem: ccache works great for speeding up compiles but seems to still have issue with some header changes. Also the ReactOS guys really want to add pch support to the Wine dlls that are shared so the job falls to me to sell it to Wine. Solution: Below are the benchmarks from my box and a patch. Simply patch your tree and then ./configure and cd to the regedit folder and do a 'time make','make clean','make pch', and 'time make' if you want to see the speedup on your box. I expect we could get a 2x speedup in fresh compiles of Wine with pch support Regedit compile without pch real 0m5.632s user 0m5.000s sys 0m0.524s Regedit compile with pch real 0m2.797s user 0m2.352s sys 0m0.428s -- 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

8 12

re: richedit's RTF writer writes only 8 kBi
by Dan Kegel 13 Jan '06

13 Jan '06

In June '05, Tobias Burnus complained in http://www.winehq.com/hypermail/wine-devel/2005/06/0536.html that there seemed to be an 8kB size limit on rich text output from richedit... but nobody replied to his message. Tobias, did you ever resolve that problem? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Regression in ntdll/virtual.c
by Markus G�mmel 13 Jan '06

13 Jan '06

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, so here is the diff result: 37a38 > #include <sys/stat.h> 837a839 > struct stat st; 859a862,866 > if (fstat( fd, &st ) == -1) > { > status = FILE_GetNtStatus(); > goto error; > } 860a868 > if (header_size > st.st_size) goto error; 999c1007,1009 < if (map_file_into_view( view, fd, sec->VirtualAddress, file_size, sec->PointerToRawData, --- > end = sec->PointerToRawData + file_size; > if (sec->PointerToRawData >= st.st_size || end > st.st_size || end < > sec->PointerToRawData || > map_file_into_view( view, fd, sec->VirtualAddress, file_size, > sec->PointerToRawData, The program can be downloaded for free at http://www.astroworld.de/ger/. Simply select "AW2001 v.6.2 (English)" in the first selection box and press "Download Demo". With the new version of aw61eng.exe it stuck somewhere at 22% with an error message like "~TMD61.tmp" is not a Win32 binary". With the old version the setup run ok. Thanks and regards Markus Gömmel m.goemmel(a)compulab.de

1 0

Re: winspool: updated some traces for bug 4268
by Huw D M Davies 13 Jan '06

13 Jan '06

On Fri, Jan 13, 2006 at 03:51:36PM +0100, Detlef Riekenberg wrote: > Changelog: > > - winspool: updated some traces for bug 4268 > > > -- > By By ... > ... Detlef > diff --git a/dlls/winspool/info.c b/dlls/winspool/info.c > index 9b1771d..a4caa39 100644 > --- a/dlls/winspool/info.c > +++ b/dlls/winspool/info.c > @@ -247,13 +247,16 @@ static BOOL CUPS_LoadPrinters(void) > HKEY hkeyPrinter, hkeyPrinters, hkey; > > cupshandle = wine_dlopen(SONAME_LIBCUPS, RTLD_NOW, NULL, 0); > + TRACE("%p: CUPS loaded (%s)\n", cupshandle, SONAME_LIBCUPS); > if (!cupshandle) > return FALSE; > - TRACE("loaded %s\n", SONAME_LIBCUPS); That's a very confusing TRACE. If wine_dlopen fails then why not print out something like "CUPS not loaded" ? > @@ -439,6 +442,8 @@ PRINTCAP_LoadPrinters(void) { > BOOL had_bash = FALSE; > > f = fopen("/etc/printcap","r"); > + TRACE("%p: using /etc/printcap\n", f); > + > if (!f) > return FALSE; > The same applies to this too. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Linuxtag 2006
by Uwe Bonnes 13 Jan '06

13 Jan '06

Hallo, has anybody interest in activly participating in a Wine booth in Linuxtag 2006 (http://www.linuxtag.org/2006/de/home/cfpro.html) in Wiesbaden from May 3 to May 6? Please let me know. Projects should have applied before Feb. 3. 2006. If needed, I can provide a place to sleep here in my flat in Darmstadt. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSection on top of DoInfInstall > I'm afraid this implementation isn't correct. DoInfInstall calls SetupInstallFromInfSection which only concerns the Install section of an INF file. SetupInstallFromInfSection and consequently DoInfInstall cannot provide enough functionality for LaunchINFSection/Ex. LaunchINFSection/Ex also takes into acount reg and file saves (see Reg/FileSaveRestore), per user sections (see SetPerUserSecValues), registering ocx's, extracting cabinets, and a whole mush of other intricacies. LaunchINFSection/Ex basically combines all the other functions of advpack into a monstrosity of functionality. I'm working my way towards fully implementing LaunchINFSection/Ex, but I've got to finish the lower levels first, so if you'd like to help in this direction, take a look at the stubs I've mentioned in advpack. I appreciate your effort in this implementation, but it will do more harm than good because we'll have to take it out when it comes time to fully implement LaunchINFSection. -- James Hawkins

2 2

Re: advpack: Implement LaunchINFSection on top of DoInfInstall
by Markus Amsler 13 Jan '06

13 Jan '06

James, I just saw your advpack patches. Only patch 4 (* Add stubs for the file save/restore functions), Makefile.in gets a merge conflict with mine first 1 (Move inf install functions to install.c ). The rest applies fine (some offset warnings), and builds without warning. Should I rediff against yours or you against mine? Is there a better way to coordinate our efforts? My LaunchINFSectionEx patch seems to improve bug 3636. Markus

1 0

New wannabe developer
by Dan Kegel 13 Jan '06

13 Jan '06

Zoe wrote: > Hi, I've got nothing better to do at the moment so I was wondering what > the best way to help move things forwards and contribute back to the > project. :-) Glad to meet you :-) I have a page that might help: http://kegel.com/wine/sweng/ Hope it helps. Let me know if there's anything unclear there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: Alexandre Julliard : server: Don't round up the header size for image mappings.
by Michael Jung 13 Jan '06

13 Jan '06

Hi, On Wednesday 11 January 2006 21:34, Alexandre Julliard wrote: > http://source.winehq.org/git/?p=wine.git;a=commit;h=b54e9e94e98624acde1bb00 > e10c2055dfed9c2d7 > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Jan 11 20:59:26 2006 +0100 > > server: Don't round up the header size for image mappings. This patch prevents certain executables (at least those generated with Borland C++ 5.02) from being loaded. I've attached a small example. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: advpack: Implement RunSetupCommand on top of DoInfInstall.
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement RunSetupCommand on top of DoInfInstall. > The same comments for LaunchINFSection apply here as well. If these three APIs just call DoInfInstall, then what's the point in having them? We need to implement these correctly the first time around. -- James Hawkins

1 0

Re: advpack: Implement LaunchINFSectionEx on top of DoInfInstall.
by James Hawkins 13 Jan '06

13 Jan '06

On 1/12/06, Markus Amsler <markus.amsler(a)oribi.org> wrote: > ChangeLog: > Implement LaunchINFSectionEx on top of DoInfInstall. > The same comments for LaunchINFSectionEx apply here as well. LaunchINFSectionEx also needs the backup and restore capabilities that DoInfInstall can't provide. -- James Hawkins

1 0

Trying to debug a crash
by Aaron Conole 13 Jan '06

13 Jan '06

I'm trying to figure out what's going on with my system, as I'm looking to get Steam + Counter Strike: Condition Zero working as correctly as possible under my system. After fighting with the Steam updater, I finally figured out exactly how Steam is doing updates, and can reliably get past the 26%/27% mark (I'll post something to the master wine-users list once I know how to solve the bulk of problems). So, steam now loads, I can activate my products, and for a while I was able to play CZ. That changed, however, and now I can't launch any games without a crash. The following is my wine ver, a backtrace, and register dump. If you could let me know what I should be looking for when I'm debugging this (like, how I can figure out whether I'm in a native or builtin library, etc..) it would be much appreciated. Thanks, Aaron Wine 20040813 ==================== Wine-dbg>bt Backtrace: 1 0xffffe410 (0x401feb4c) =>2 0x401dce63 .L133+0x23 in ntdll (0x401fecf8) 3 0x401dbc17 usr1_handler+0x47 in ntdll (0x401fed1c) 4 0xffffe420 (0x406fe6bc) 5 0x401dce63 .L133+0x23 in ntdll (0x406fe868) 6 0x401dd076 NtWaitForMultipleObjects+0x66 in ntdll (0x406fe890) 7 0x40515899 WaitForMultipleObjectsEx+0xc9 in kernel32 (0x406fe9c0) 8 0x40515ab8 WaitForSingleObject+0x38 in kernel32 (0x406fe9e0) 9 0x404d5a6f UnhandledExceptionFilter+0xa9f in kernel32 (0x406fec78) 10 0x014073f1 (0x406fec90) 11 0x0140390b (0x406fff20) 12 0x40504462 start_process+0xf2 in kernel32 (0x406ffff4) 13 0x40042db1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) ==================== Wine-dbg>info registers Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:ffffe410 ESP:401feb0c EBP:401feb4c EFLAGS:00200246( - 00 - IZP1) EAX:fffffe00 EBX:00000007 ECX:401feb38 EDX:00000008 ESI:401fd000 EDI:401feb38 ==================== Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000034 1 00000032 'C:\windows\system\winedbg.exe' 00000032 1 00000008 'C:\Program Files\Valve\Steam\SteamApps \orgcandman\condition zero\hl.exe' 00000008 34 00000000 'C:\Program Files\Valve\Steam\Steam.exe'

2 1

Re: advpack: Implement RunSetupCommand on top of DoInfInstall.
by Marcelo Duarte 13 Jan '06

13 Jan '06

Markus Amsler escreveu: > ChangeLog: > Implement RunSetupCommand on top of DoInfInstall. You forgot to remove "stub": > + TRACE("(%p, %s, %s, %s, %s, %p, 0x%08lx, %p): stub\n", > hWnd, debugstr_a(szCmdName), debugstr_a(szInfSection), > debugstr_a(szDir), debugstr_a(lpszTitle), > phEXE, dwFlags, pvReserved); >

1 0

Re: Still need help fixing deadlock (GDI/metafile)
by Cihan Altinay 13 Jan '06

13 Jan '06

Huw, I put you on Cc for this thread in the hope to get some information on this issue. Is there any side effect if undefining STRETCH_VIA_DIB? Also, do you know where the problem might be? Regards, Cihan Walt Ogburn wrote: > Hi Cihan, > > I'm glad it works. It looks like Huw D M Davies changed STRETCH_VIA_DIB > from being unset to set in 2002. I think he's still around at > huw(a)codeweavers.com. Maybe you could ask him whether it could be changed > back to the other method. > > - Walter > > On Thu, 12 Jan 2006, Cihan Altinay wrote: > > >>Hi Walter, >> >>Walt Ogburn wrote: >> >>>Hi Cihan, >>> >>>What happens if you comment out #define STRETCH_VIA_DIB in >>>dlls/gdi/mfdrv/bitblt.c? This will make it use GetBitmapBits instead of >>>GetDIBits. >> >>Indeed, this does the trick! >>No locking problems... Will try to look into that. >> >> >>>- Walter >> >>Thanks a lot, >>Cihan >> >> >>>On Wed, 11 Jan 2006, Cihan Altinay wrote: >>> >>> >>> >>>>Since nobody seems to be able to help me with this problem at the moment >>>>I opened a bug report[1] for it. I would appreciate if somebody with >>>>more knowledge could take a quick look at it. Thanks! >>>> >>>>Cihan >>>> >>>>[1] http://bugs.winehq.org/show_bug.cgi?id=4284 >>>> >>>> >>>>Cihan Altinay wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>I am still trying to finding the reason for PowerPoint 2000 causing a >>>>>deadlock if a file is opened that contains a preview which itself >>>>>contains a bitmap >90x90 pixels (ie. on the first slide). >>>>>After inserting some traces I feel I am pretty close but I'm >>>>>stuck since before the holidays. The problem is connected to GDI's >>>>>and/or metafile's StretchBlt (bitblt.c). >>>>>It calls MFDRV_StretchBlt and then the trouble begins as can be seen >>>> >>>>>from the output: >>>> >>>>><snip> >>>>>trace:bitblt:StretchBlt --Start-- >>>>>trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 >>>>>trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 >>>>>trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 >>>>>trace:dc:DC_GetDCPtr >>>>>trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 >>>>>trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 >>>>>PixYPM=3780 Caps=96 >>>>>trace:bitmap:GetDIBits >>>>>trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec >>>>>err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 >>>>></snip> >>>>> >>>>>Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. >>>>>There is a comment "FIXME: there is a race condition here". Could that >>>>>be the cause for the deadlock? >>>>>Btw. this might be the same problem as bug #3125 as both refer to the >>>>>preview and both cause a deadlock. >>>>> >>>>>Can somebody give me a hint on how to tackle this? It is really important >>>>>for us... If you need more output please let me know. >>>>> >>>>>Thanks a lot, >>>>>Cihan >>>>> >>>>> >>>>> >>>> >>>> >>>> >> >>

1 0

Mozilla ActiveX Control -- Browser not in a valid state
by Phil Lodwick 12 Jan '06

12 Jan '06

Hi, I have a Borland C++ Builder app that is a simple FORM with a TCppWebBrowser and a button. I have two callbacks, one when the form is created, and one when the user pushes the button. Both callbacks just navigate to google. ================================ __fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { CppWebBrowser1->Navigate(WideString("http://www.google.com")); } void __fastcall TForm1::DoIt1Click(TObject *Sender) { CppWebBrowser1->Navigate(WideString("http://www.google.com")); } ================================ On Windows this works as expected. When the form is displayed, google is displayed in the browser. Whenever you push the button the browser is reloaded. On Wine with the Mozilla ActiveX Control v1.7.12, when the form is first loaded nothing is displayed. WINEDEBUG=+ole shows "Browser is not in a valid state". Pushing the button subsequent times reloads the web site as expected. Before I start digging deeper, I was hoping somebody might have some insight to lead me down the correct path. Thanks! Phil

2 1

New wannabe developer
by Zoe Parsons 12 Jan '06

12 Jan '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've got nothing better to do at the moment so I was wondering what the best way to help move things forwards and contribute back to the project. :-) - -- Zoe Parsons | skype:mpsonscix zoe(a)theasylum.demon.co.uk | http://livejournal.com/~zoep mpsons(a)cix.compulink.co.uk | ICQ:97984995 aim:mpsonscix | yim:mpsons_cix | msn:zoe@theasylum.demon.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxqIAbbnfPjpiTWURArEMAKCWH2i3rAHqfPmcFLnZI78XjFJVNwCgh44G hGMVPYk008XHB34dJyr9Gik= =LJPa -----END PGP SIGNATURE-----

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel