Advice on how to proceed - XKB keyboard handling
Hi all, I put up an intermediate version of my XKB patch. It is the last attachment for bug #735 (http://bugs.winehq.org/show_bug.cgi?id=735). The patch, as is, solves bug 735, as can be tested by compiling the test program. However, it does not play well with other areas of the keyboard handling. I'm posting this here partly to draw attention for those who need bug #735 fixed and can live with the regression, and partly to get feedback on how best to proceed. Thanks, Shachar
Richedit URL hyperlink bug
Hi, I run an app (Blitzin2) that displays scrolling text with various highlightings in a rich edit control. When displaying hyperlinks comprising normal words, they are rendered in blue and underlined, and whatever follows is rendered appropriately. However, if the displayed link text happens to constitute a URL, the blue-underlining doesn't get switched off at the end of the link, so all subsequent text is rendered in blue and underlined. Examples: This is a _link_ to somewhere. (This renders fine.) Visit _www.winehq.org_ to learn about a great piece of software. (This stays blue-underlined after the link.) I thought I would post this here first, in case anyone knows exactly where that is. Thanks, -- Andy.
Re: [01/10] wined3d: Handle FBO attachments slightly more efficiently
Am Montag 09 April 2007 01:53 schrieb H. Verbeet: The idea here is to only update FBO attachments when the FBO is being used to draw to, since apparently binding an incomplete FBO is rather slow. Changelog: - Handle FBO attachments slightly more efficiently Is there a reason why you do not do that in ActivateContext? Without that, you will have to take care of things like Clearing, Locking, Blits, etc. pgpTMF5EsLPAY.pgp Description: PGP signature
Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.
Sorry to jump into the discussion at this late date, but while I run Wine occasionally for some software I get in my email - no, not viruses, thank goodness! - and some other software that I get with family photo CDs, etc, I haven't done anything with it lately, apart from installing an old Win32 compiler I was given. I still don't know whether it works properly - I know most of lcc-win32 and OpenWatcom work happily :-) I was wondering, there is Wine, there is CrossOver, and there is Cedega. CrossOver I know contribute their source back, I don't know about Cedega, and I (apparently) can't run both Wine and CrossOver at one and the same time, I can't even install both (apparently - I could be wrong on this ;). Is there any project to solve the Wine/CrossOver dual installation problem/question? Any for a putative Wine/Cedega dual installation? Any suggestions? Thanks Wesley Parish On Friday 30 March 2007 07:21, Stefan Dösinger wrote: Hi, Getting common applications working is NOT the goal of wine. The goal of wine is to write an open source reimplementation of the Win32 api. Those two goals are related, but not exactly the same. The difference is how to deal with hacks that are known to be incorrect but happen to fix an application. Those are not accepted into wine, no matter which application they fix. CrossOver uses Wine under its hood, and CrossOver's wine tree contains some hacks to make Microsoft Office and other popular applications happy. However, CodeWeavers contributes patches back and employs many major developers to work on various parts of wine, including Alexandre Julliard, Robert Shearman, Jakec Caban, me, and many others. Neither Wine nor CrossOver are specifically targeted at games or office applications. CrossOver supports some games(like Half-Life 1 and 2, World of Warcraft, Prey), and my job is to work on Wine's Direct3D support. I won't be able to convice you that the whole thing is not a conspicary because I am a codeweavers employee, but maybe searching the wine changelog for @codeweavers.com can convice you? (Though many codeweavers employees use their own private mail address to send patches). Regarding the hacks to get Microsoft Office running, the modified Wine source in CrossOver is publically available at http://www.codeweavers.com/products/source . You are welcome to locate the hacks that fix Microsoft Office(I think their authors will kindly assist you with that), clean them up and send them to wine-patches for inclusion. (on a sidenode, a few weeks ago I noticed that some mirror had a broken copy of the archive which did not unpack completely. I think it should be fixed by now. So if the archive doesn't unzip its not conspiracy, it is a fault of the provider of our mirrors) Hope my explanations answer your questions, Stefan -- Clinersterton beademung, with all of love - RIP James Blish - Gaul is quartered into three halves. Things which are impossible are equal to each other. Guerrilla warfare means up to their monkey tricks. Extracts from Schoolboy Howlers - the collective wisdom of the foolish. - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.
Re: [01/10] wined3d: Handle FBO attachments slightly more efficiently
On 09/04/07, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Montag 09 April 2007 01:53 schrieb H. Verbeet: The idea here is to only update FBO attachments when the FBO is being used to draw to, since apparently binding an incomplete FBO is rather slow. Changelog: - Handle FBO attachments slightly more efficiently Is there a reason why you do not do that in ActivateContext? Without that, you will have to take care of things like Clearing, Locking, Blits, etc. No strong reason, but applying the FBO state should only happen when clearing or drawing to an offscreen render target. Blitting and Locking doesn't apply for FBOs because that should just work with the texture. It appears a bit hard to detect that in ActivateContext, mainly because IWineD3DDeviceImpl_Clear calls ActivateContext with CTXUSAGE_RESOURCELOAD rather than CTXUSAGE_DRAWPRIM (should it?). Either way though, I'd rather change that after this gets applied, to avoid breaking too much at once.
Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.
On Mon, Apr 09, 2007 at 10:06:19PM +1200, Wesley Parish wrote: I was wondering, there is Wine, there is CrossOver, and there is Cedega. CrossOver I know contribute their source back, I don't know about Cedega Since wine 0.9 someone with transgaming in the author field got 3 patches into wine. They don't publish some of their source and/or part of their published source is not under LGPL or another free software licence (both is legally allowed in that case). , and I (apparently) can't run both Wine and CrossOver at one and the same time, I can't even install both (apparently - I could be wrong on this ;). You can install multiple Wine installations, a crossover install and a cedega install on the same machine without problems (though it's some time ago that I verified it for the later two). Jan
Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.
You can install multiple Wine installations, a crossover install and a cedega install on the same machine without problems (though it's some time ago that I verified it for the later two). Yes, this is supposed to work(CrossOver and Wine at least). But note, that running wine on the command line does never run crossover. The main way to run something with Crossover is to install it using the installation wizard, then use the menu entries created to run it. You can also run something manually using ~/cxoffice/bin/wine or /opt/cxoffice/bin/wine, whereever crossover is installed. I don't know how this works with cedega, but I'd be really surprised if you can't install cedega additionally. pgp631N99VUXC.pgp Description: PGP signature
Re: [06/10] wined3d: Use the framebuffer blit extension to implement StretchRect
Hi, I can't compile wine with this patch. Here is error log:
device.c: In function ‘stretch_rect_fbo’:
device.c:5311: error: ‘WineD3D_GL_Info’ has no member named
‘glBlitFramebufferEXT’
device.c:5314: error: ‘WineD3D_GL_Info’ has no member named
‘glBlitFramebufferEXT’
make[2]: *** [device.o] Error 1
make[2]: Leaving directory
`/root/.WineCVS/sources/cvswine/wine/dlls/wined3d'
make[1]: *** [wined3d] Error 2
make[1]: *** Waiting for unfinished jobs
Mirek
H. Verbeet napsal(a):
Although this patch is somewhat similar to Fabian's, it's not actually
based on it.
Changelog:
- Use the framebuffer blit extension to implement StretchRect
---
dlls/wined3d/device.c | 77
dlls/wined3d/surface.c | 12 --
dlls/wined3d/wined3d_private.h |5 +++
3 files changed, 90 insertions(+), 4 deletions(-)
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c
index 506b61c..580fcd0 100644
--- a/dlls/wined3d/device.c
+++ b/dlls/wined3d/device.c
@@ -181,6 +181,12 @@ static ULONG WINAPI
IWineD3DDeviceImpl_Release(IWineD3DDevice *iface) {
if (This-fbo) {
GL_EXTCALL(glDeleteFramebuffersEXT(1, This-fbo));
}
+if (This-src_fbo) {
+GL_EXTCALL(glDeleteFramebuffersEXT(1, This-src_fbo));
+}
+if (This-dst_fbo) {
+GL_EXTCALL(glDeleteFramebuffersEXT(1, This-dst_fbo));
+}
HeapFree(GetProcessHeap(), 0, This-render_targets);
HeapFree(GetProcessHeap(), 0, This-fbo_color_attachments);
@@ -5242,6 +5248,77 @@ void apply_fbo_state(IWineD3DDevice *iface) {
check_fbo_status(iface);
}
+static BOOL is_onscreen(IWineD3DSurface *target) {
+HRESULT hr;
+void *tmp;
+
+hr = IWineD3DSurface_GetContainer(target, IID_IWineD3DSwapChain, tmp);
+if (SUCCEEDED(hr)) {
+IWineD3DSwapChain_Release((IUnknown *)tmp);
+return TRUE;
+}
+
+return FALSE;
+}
+
+void stretch_rect_fbo(IWineD3DDevice *iface, IWineD3DSurface *src_surface,
const WINED3DRECT *src_rect,
+IWineD3DSurface *dst_surface, const WINED3DRECT *dst_rect, const
WINED3DTEXTUREFILTERTYPE filter, BOOL flip) {
+IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
+GLbitfield mask = GL_COLOR_BUFFER_BIT; /* TODO: Support blitting
depth/stencil surfaces */
+GLenum gl_filter;
+
+TRACE((%p) : src_surface %p, src_rect %p, dst_surface %p, dst_rect %p, filter
%s (0x%08x)\n,
+This, src_surface, src_rect, dst_surface, dst_rect,
debug_d3dtexturefiltertype(filter), filter);
+
+switch (filter) {
+case WINED3DTEXF_LINEAR:
+gl_filter = GL_LINEAR;
+break;
+
+default:
+FIXME(Unsupported filter mode %s (0x%08x)\n,
debug_d3dtexturefiltertype(filter), filter);
+case WINED3DTEXF_NONE:
+case WINED3DTEXF_POINT:
+gl_filter = GL_NEAREST;
+break;
+}
+
+/* Attach src surface to src fbo */
+if (is_onscreen(src_surface)) {
+GL_EXTCALL(glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, 0));
+flip = !flip;
+} else {
+IWineD3DSurface_PreLoad(src_surface);
+bind_fbo(iface, GL_READ_FRAMEBUFFER_EXT, This-src_fbo);
+attach_surface_fbo(This, GL_READ_FRAMEBUFFER_EXT, 0, src_surface);
+}
+
+/* Attach dst surface to dst fbo */
+if (is_onscreen(dst_surface)) {
+GL_EXTCALL(glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, 0));
+flip = !flip;
+} else {
+IWineD3DSurface_PreLoad(dst_surface);
+bind_fbo(iface, GL_DRAW_FRAMEBUFFER_EXT, This-dst_fbo);
+attach_surface_fbo(This, GL_DRAW_FRAMEBUFFER_EXT, 0, dst_surface);
+}
+
+if (flip) {
+GL_EXTCALL(glBlitFramebufferEXT(src_rect-x1, src_rect-y1, src_rect-x2,
src_rect-y2,
+dst_rect-x1, dst_rect-y2, dst_rect-x2, dst_rect-y1, mask,
gl_filter));
+} else {
+GL_EXTCALL(glBlitFramebufferEXT(src_rect-x1, src_rect-y1, src_rect-x2,
src_rect-y2,
+dst_rect-x1, dst_rect-y1, dst_rect-x2, dst_rect-y2, mask,
gl_filter));
+}
+
+if (This-render_offscreen) {
+bind_fbo(iface, GL_FRAMEBUFFER_EXT, This-fbo);
+} else {
+GL_EXTCALL(glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0));
+checkGLcall(glBindFramebuffer());
+}
+}
+
static HRESULT WINAPI IWineD3DDeviceImpl_SetRenderTarget(IWineD3DDevice
*iface, DWORD RenderTargetIndex, IWineD3DSurface *pRenderTarget) {
IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface;
WINED3DVIEWPORT viewport;
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 8b7b47d..5db1aa0 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -2752,8 +2752,7 @@ static HRESULT
IWineD3DSurfaceImpl_BltOverride(IWineD3DSurfaceImpl *This, RECT *
}
/* Blt is a pretty powerful call, while glCopyTexSubImage2D is
Re: [06/10] wined3d: Use the framebuffer blit extension to implement StretchRect
On 09/04/07, Mirek [EMAIL PROTECTED] wrote: Hi, I can't compile wine with this patch. Here is error log: device.c: In function 'stretch_rect_fbo': device.c:5311: error: 'WineD3D_GL_Info' has no member named 'glBlitFramebufferEXT' device.c:5314: error: 'WineD3D_GL_Info' has no member named 'glBlitFramebufferEXT' make[2]: *** [device.o] Error 1 make[2]: Leaving directory `/root/.WineCVS/sources/cvswine/wine/dlls/wined3d' make[1]: *** [wined3d] Error 2 make[1]: *** Waiting for unfinished jobs Mirek That should have been added by dcd416edbe63939bf73b5725ed8a29030f9ae260. Is your wine version up to date with current git?
A Study on Free/Open Source Software Defect Management
Dear Wine Contributots, I am really thankful to Free/Open Source Software development community for their overwhelming response to the survey on practices and problems of defect management in Free/Open Source Software projects. The Online Questionnaire is available at: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey I hope you have found all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. The results of study will soon be communicated to you.If you have not participated ealier, you may spend a few minutes now too. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Richedit URL hyperlink bug
Hi, The problem is most likely in that there's two kinds of links happening at once - the automatically detected one and the manually specified one. The automatic detection is done in ME_AutoURLDetect at the very bottom of editor.c. I don't really have time to look at it myself until this weekend (yay exams). I did notice one strangeness really quick though: curf_ef = cur_format.dwEffects link.dwEffects; def_ef = default_format.dwEffects link.dwEffects; link_ef = link.dwEffects link.dwEffects; Usually you're supposed to check that a dwEffect is included in the dwMask before using it. Also, that third line does... nothing? :) A better way might be: curf_ef = (cur_format.dwEffects cur_format.dwMask) CFE_LINK; def_ef = (default_format.dwEffects default_format.dwMask) CFE_LINK; link_ef = (link.dwEffects link.dwMask) CFE_LINK; I don't know if that's related to your problem, I can look into it this weekend if it's still needed. If you don't find the problem yourself, make sure to make a bug report and link to an executable that demonstrates this :) --Matt Finnicum On 4/9/07, Andrew Talbot [EMAIL PROTECTED] wrote: Hi, I run an app (Blitzin2) that displays scrolling text with various highlightings in a rich edit control. When displaying hyperlinks comprising normal words, they are rendered in blue and underlined, and whatever follows is rendered appropriately. However, if the displayed link text happens to constitute a URL, the blue-underlining doesn't get switched off at the end of the link, so all subsequent text is rendered in blue and underlined. Examples: This is a _link_ to somewhere. (This renders fine.) Visit _www.winehq.org_ to learn about a great piece of software. (This stays blue-underlined after the link.) I thought I would post this here first, in case anyone knows exactly where that is. Thanks, -- Andy.
configure using deprecated alsa header.. ?
I just downloaded and configured wine 0.9.34 and looking thru the config.log (didnt do this on prior versions, so I'm pretty sure it's not a regression), there is a warning about needing to use alsa/asoundlib.h instead of sys/asoundlib.h .. I made bug 7997 about it: http://bugs.winehq.org/show_bug.cgi?id=7997 Could someone look into this and make a patch? I honestly dont know if it is causing any problems the way it is currently, but the warning is a little unsettling. In case it's needed: Slackware x86 11.0 with the alsa that is included with the distro. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
SoC Deadline: 07:00 UTC on April 10th
### 2. Make sure that all the applications that you *really* want have mentors assigned to them as quickly as possible, certainly no later than 12 midnight Pacific / 07:00 UTC on April 10th. ### Do we have assigned a mentor for all possible slots? -- By by ... Detlef
Re: configure using deprecated alsa header.. ?
As a side I looked thru config.log a little further up and saw the test for asla/asoundlib.h which succeeded. So in the case that both headers exist, which one are we using? On 4/9/07, Tom Spear [EMAIL PROTECTED] wrote: I just downloaded and configured wine 0.9.34 and looking thru the config.log (didnt do this on prior versions, so I'm pretty sure it's not a regression), there is a warning about needing to use alsa/asoundlib.h instead of sys/asoundlib.h .. I made bug 7997 about it: http://bugs.winehq.org/show_bug.cgi?id=7997 Could someone look into this and make a patch? I honestly dont know if it is causing any problems the way it is currently, but the warning is a little unsettling. In case it's needed: Slackware x86 11.0 with the alsa that is included with the distro. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373from=power-email
Re: err:ddraw:IDirectDrawImpl_QueryInterface (0x1bdd28)
Am Sonntag, 8. April 2007 12:55 schrieben Sie: Hi, Interestingly this application does nothing that would make ddraw return a failure. Can you send a ddraw,d3d7 trace WITH the registry key set as a reference? As far as I can see, this application is on its way to set up a Direct3D Device for a surface which does NOT have DDSCAPS_3DDEVICE set - which is not allowed, as far as I know, but I'd have to test that. But it stops right before really creating the device by just exiting. Maybe it does not like our 3DDevice's GUID. Hi Stefan, attached you find the trace. I am wondering why it so much smaller. I was also able to get a proper callstack of the crash. thanks, Klaus ALSA lib seq_hw.c:456:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory fixme:d3d:IWineD3DImpl_FillGLCaps 0x501 from extension detection @ directx.c / 825 fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x1be720) : stub, simulating 64MB for now, returning 64MB left fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x1bdb20)-(0x10026,0011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:d3d:IWineD3DImpl_FillGLCaps 0x501 from extension detection @ directx.c / 825 wine: Unhandled page fault on read access to 0x00d20002 at address 0x7e42f2e9 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00d20002 in 32-bit code (0x7e42f2e9). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e42f2e9 ESP:0034f218 EBP:0034f2f0 EFLAGS:00010202( - 00 - -RI1) EAX:7d1916e4 EBX:7e55b118 ECX:00d20004 EDX:0400 ESI:0139 EDI:7d191200 Stack dump: 0x0034f218: 0002 7c0a33e4 00b40020 0400 0x0034f228: 0400 1908 1401 0x0034f238: 7e9c84a0 7e9c5bff 0x0034f248: b7dcfadc b7dd1320 fff0 0034f270 0x0034f258: 01d0a411 b7dd1320 00400204 0155b118 0x0034f268: 0200 7c6e9838 0034f280 7e3fdb8d Backtrace: =1 0x7e42f2e9 _mesa_texstore_argb+0x63e() in i915_dri.so (0x0034f2f0) 2 0x7e433c7e _mesa_store_texsubimage2d+0xfa() in i915_dri.so (0x0034f350) 3 0x7e3b492c in i915_dri.so (+0x4092c) (0x0034f3a0) 4 0x7e422670 _mesa_TexSubImage2D+0x1a8() in i915_dri.so (0x0034f400) 5 0x7e59c4da glTexSubImage2D+0x62() in libgl.so.1 (0x0034f430) 6 0x7d7c9213 surface_upload_data+0xb3(This=register ESI not in topmost frame, width=0x400, height=register EDI not in topmost frame, format=register EAX not in topmost frame, type=register EAX not in topmost frame, data=0xb40020) [/home/klaus/make/wine/dlls/wined3d/surface.c:190] in wined3d (0x0034f470) 7 0x7d7d3ebb IWineD3DSurfaceImpl_LoadTexture+0x33c(iface=0x9aeaf0) [/home/klaus/make/wine/dlls/wined3d/surface.c:1922] in wined3d (0x0034f8f0) 8 0x7d7c9b8e IWineD3DSurfaceImpl_PreLoad+0x127(iface=register EDI not in topmost frame) [/home/klaus/make/wine/dlls/wined3d/surface.c:404] in wined3d (0x0034f940) 9 0x7d7cfd23 IWineD3DSurfaceImpl_LockRect+0x8f6(iface=0x9aeaf0, pLockedRect=0x34f9dc, pRect=0x0, Flags=0x0) [/home/klaus/make/wine/dlls/wined3d/surface.c:817] in wined3d (0x0034f9a0) 10 0x7e9fe8c6 IDirectDrawSurfaceImpl_Lock+0xb7(iface=0x9aea10, Rect=0x0, DDSD=register EDI not in topmost frame, Flags=0x0, h=register EAX not in topmost frame) [/home/klaus/make/wine/dlls/ddraw/surface.c:569] in ddraw (0x0034f9f0) 11 0x7ea023ab IDirectDrawSurface3Impl_Lock+0x53(This=0x9aea14, pRect=register EAX not in topmost frame, pDDSD=register EAX not in topmost frame, dwFlags=register EAX not in topmost frame, h=register EAX not in topmost frame) [/home/klaus/make/wine/dlls/ddraw/surface_thunks.c:293] in ddraw (0x0034fa20) 12 0x0048153f in mathe2 (+0x8153f) (0x0034fb1c) 13 0x004224b8 in mathe2 (+0x224b8) (0x0034fb74) 14 0x0046635b in mathe2 (+0x6635b) (0x0034fc30) 15 0x00575e1a in mathe2 (+0x175e1a) (0x0034fc90) 16 0x0047d80e in mathe2 (+0x7d80e) (0x0034fd28) 17 0x0047d75c in mathe2 (+0x7d75c) (0x0034fd84) 18 0x0048838f in mathe2 (+0x8838f) (0x0034fdf8) 19 0x004d8ae8 in mathe2 (+0xd8ae8) (0x0034fe78) 20 0x0059a996 in mathe2 (+0x19a996) (0x0034ff08) 21 0x7ee5050f start_process+0xe3(arg=0x0) [/home/klaus/make/wine/dlls/kernel32/process.c:821] in kernel32 (0x0034ffe8) 22 0xb7e08397 wine_switch_to_stack+0x17() in libwine.so.1 (0x) 0x7e42f2e9 _mesa_texstore_argb+0x63e in i915_dri.so: movzbl 0xfffe(%ecx),%edx Modules: Module Address Debug info Name (70 modules) PE 40-6f4000 Export mathe2 ELF 7bf0-7bf03000 Deferredwine-loader ELF 7d5f2000-7d5fc000 Deferredlibgcc_s.so.1 ELF 7d6d1000-7d747000 Deferredlibglu.so.1 ELF 7d761000-7d81a000 Dwarf wined3delf \-PE 7d77-7d81a000 \ wined3d ELF 7d92b000-7d951000 Deferredmsacm32elf \-PE 7d93-7d951000 \ msacm32 ELF 7d951000-7da06000 Deferred
Re: err:ddraw:IDirectDrawImpl_QueryInterface (0x1bdd28)
Am Sonntag, 8. April 2007 01:14 schrieb Vitaliy Margolen: Do not strip Wine when you debuggin it, _especially_ when you sending your traces to wine-devel. Properly compiling Wine would help. This is invalid. Please visit wiki page(s) for gentoo that state which flags you should and which flags you _can not_ use. Btw what is the bug # for this problem? Vitaliy Hi Vitaly, I did not strip the symbols. The callstack with the missing symbols I sent was one of my first tries after experiencing the crash. Today I noticed that sometimes I get proper callstacks with symbols sometimes not. I not yet created a bugzilla entry but will do it later. Best regards, Klaus ALSA lib seq_hw.c:456:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory fixme:d3d:IWineD3DImpl_FillGLCaps 0x501 from extension detection @ directx.c / 825 fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x1be720) : stub, simulating 64MB for now, returning 64MB left fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x1bdb20)-(0x10026,0011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:d3d:IWineD3DImpl_FillGLCaps 0x501 from extension detection @ directx.c / 825 wine: Unhandled page fault on read access to 0x00d20002 at address 0x7e42f2e9 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00d20002 in 32-bit code (0x7e42f2e9). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e42f2e9 ESP:0034f218 EBP:0034f2f0 EFLAGS:00010202( - 00 - -RI1) EAX:7d1916e4 EBX:7e55b118 ECX:00d20004 EDX:0400 ESI:0139 EDI:7d191200 Stack dump: 0x0034f218: 0002 7c0a33e4 00b40020 0400 0x0034f228: 0400 1908 1401 0x0034f238: 7e9c84a0 7e9c5bff 0x0034f248: b7dcfadc b7dd1320 fff0 0034f270 0x0034f258: 01d0a411 b7dd1320 00400204 0155b118 0x0034f268: 0200 7c6e9838 0034f280 7e3fdb8d Backtrace: =1 0x7e42f2e9 _mesa_texstore_argb+0x63e() in i915_dri.so (0x0034f2f0) 2 0x7e433c7e _mesa_store_texsubimage2d+0xfa() in i915_dri.so (0x0034f350) 3 0x7e3b492c in i915_dri.so (+0x4092c) (0x0034f3a0) 4 0x7e422670 _mesa_TexSubImage2D+0x1a8() in i915_dri.so (0x0034f400) 5 0x7e59c4da glTexSubImage2D+0x62() in libgl.so.1 (0x0034f430) 6 0x7d7c9213 surface_upload_data+0xb3(This=register ESI not in topmost frame, width=0x400, height=register EDI not in topmost frame, format=register EAX not in topmost frame, type=register EAX not in topmost frame, data=0xb40020) [/home/klaus/make/wine/dlls/wined3d/surface.c:190] in wined3d (0x0034f470) 7 0x7d7d3ebb IWineD3DSurfaceImpl_LoadTexture+0x33c(iface=0x9aeaf0) [/home/klaus/make/wine/dlls/wined3d/surface.c:1922] in wined3d (0x0034f8f0) 8 0x7d7c9b8e IWineD3DSurfaceImpl_PreLoad+0x127(iface=register EDI not in topmost frame) [/home/klaus/make/wine/dlls/wined3d/surface.c:404] in wined3d (0x0034f940) 9 0x7d7cfd23 IWineD3DSurfaceImpl_LockRect+0x8f6(iface=0x9aeaf0, pLockedRect=0x34f9dc, pRect=0x0, Flags=0x0) [/home/klaus/make/wine/dlls/wined3d/surface.c:817] in wined3d (0x0034f9a0) 10 0x7e9fe8c6 IDirectDrawSurfaceImpl_Lock+0xb7(iface=0x9aea10, Rect=0x0, DDSD=register EDI not in topmost frame, Flags=0x0, h=register EAX not in topmost frame) [/home/klaus/make/wine/dlls/ddraw/surface.c:569] in ddraw (0x0034f9f0) 11 0x7ea023ab IDirectDrawSurface3Impl_Lock+0x53(This=0x9aea14, pRect=register EAX not in topmost frame, pDDSD=register EAX not in topmost frame, dwFlags=register EAX not in topmost frame, h=register EAX not in topmost frame) [/home/klaus/make/wine/dlls/ddraw/surface_thunks.c:293] in ddraw (0x0034fa20) 12 0x0048153f in mathe2 (+0x8153f) (0x0034fb1c) 13 0x004224b8 in mathe2 (+0x224b8) (0x0034fb74) 14 0x0046635b in mathe2 (+0x6635b) (0x0034fc30) 15 0x00575e1a in mathe2 (+0x175e1a) (0x0034fc90) 16 0x0047d80e in mathe2 (+0x7d80e) (0x0034fd28) 17 0x0047d75c in mathe2 (+0x7d75c) (0x0034fd84) 18 0x0048838f in mathe2 (+0x8838f) (0x0034fdf8) 19 0x004d8ae8 in mathe2 (+0xd8ae8) (0x0034fe78) 20 0x0059a996 in mathe2 (+0x19a996) (0x0034ff08) 21 0x7ee5050f start_process+0xe3(arg=0x0) [/home/klaus/make/wine/dlls/kernel32/process.c:821] in kernel32 (0x0034ffe8) 22 0xb7e08397 wine_switch_to_stack+0x17() in libwine.so.1 (0x) 0x7e42f2e9 _mesa_texstore_argb+0x63e in i915_dri.so: movzbl 0xfffe(%ecx),%edx Modules: Module Address Debug info Name (70 modules) PE 40-6f4000 Export mathe2 ELF 7bf0-7bf03000 Deferredwine-loader ELF 7d5f2000-7d5fc000 Deferredlibgcc_s.so.1 ELF 7d6d1000-7d747000 Deferredlibglu.so.1 ELF 7d761000-7d81a000 Dwarf wined3delf \-PE 7d77-7d81a000 \ wined3d ELF 7d92b000-7d951000 Deferredmsacm32elf \-PE 7d93-7d951000 \ msacm32 ELF 7d951000-7da06000 Deferred
Re: Winehq's wiki table problem
On So, 2007-04-08 at 11:06 -0600, Vitaliy Margolen wrote: Does anyone else see the problem with the tables not aligned properly? Yes, it's broken in firefox, but displayed readable in dillo (but many html-errors are detected by dillo). Tested with FrontPage and Developer-Hints Mozilla Firefox 1.5.0.11, Copyright (c) 1998 - 2007 mozilla.org Dillo 0.8.5-i18n-misc On ubuntu-dapper -- By by ... Detlef
Re: respect unicode _ILCreateFromFindData
Aric Stewart [EMAIL PROTECTED] wrote:
+if (fs)
+{
+FileTimeToDosDateTime( (stffile-ftLastWriteTime),
+ fs-uFileDate, fs-uFileTime);
+fs-dwFileSize = stffile-nFileSizeLow;
+fs-uFileAttribs = (WORD)stffile-dwFileAttributes;
+
+memcpy(fs-szNames, name_buff, name_len);
+TRACE(-- Set Value: %s\n,debugstr_a(fs-szNames));
+}
Indentation above is not consistent.
LPITEMIDLIST _ILCreateFromFindDataW( WIN32_FIND_DATAW *wfd )
{
-/* FIXME: should make unicode PIDLs */
-WIN32_FIND_DATAA fda;
+charbuff[MAX_PATH + 14 +1]; /* see WIN32_FIND_DATA */
+char * pbuff = buff;
+size_t len, len1, wlen, alen;
+LPITEMIDLIST pidl;
+PIDLTYPE type;
+
+if (!wfd)
+return NULL;
+
+TRACE((%s, %s)\n,debugstr_w(wfd-cAlternateFileName),
debugstr_w(wfd-cFileName));
+
+/* prepare buffer with both names */
+len = WideCharToMultiByte(CP_ACP,0,wfd-cFileName,-1,NULL,0,NULL,NULL) + 1;
+WideCharToMultiByte(CP_ACP,0,wfd-cFileName,-1, pbuff, len, NULL, NULL);
+pbuff += len;
Looks like 2 WideCharToMultiByte calls can be replaced by 1.
+
+len1 = WideCharToMultiByte(CP_ACP,0,wfd-cAlternateFileName,-1, NULL, 0,
NULL, NULL) +1;
+WideCharToMultiByte(CP_ACP,0,wfd-cAlternateFileName,-1, pbuff, len1,
NULL, NULL);
+alen = len + len1;
Same here.
+
+type = (wfd-dwFileAttributes FILE_ATTRIBUTE_DIRECTORY) ? PT_FOLDER :
PT_VALUE;
+
+/*
+ * FileStruct already has one byte for the first name, so use len - 1 in
+ * size calculation
+ */
+wlen = lstrlenW(wfd-cFileName);
+pidl = _ILAlloc(type, sizeof(FileStruct) + (alen - 1) + (alen 0x1) +
+sizeof(FileStructW) + wlen * sizeof(WCHAR) + sizeof(WORD)) ;
What (alen 0x1) is for?
--
Dmitry.
Re: configure using deprecated alsa header.. ?
Tom Spear schreef: I just downloaded and configured wine 0.9.34 and looking thru the config.log (didnt do this on prior versions, so I'm pretty sure it's not a regression), there is a warning about needing to use alsa/asoundlib.h instead of sys/asoundlib.h .. I made bug 7997 about it: http://bugs.winehq.org/show_bug.cgi?id=7997 Looking through it it seems configure.ac first tries to include alsa/asoundlib in its test and if that fails sys/asoundlib.h, so it doesn't look like a bug to me.
