January 2006 - Wine-Devel - list.winehq.org

New developer

by Segin

Hello! I am new to developing Wine, however, I am not new to using it (I know quite a bit about it already). I want to know what resources would I want to look at, please nothing obvious (bugzilla, MSDN, etc.), and what I can do to contribute. Thanks.

Jan. 31, 2006

Re: dx9 and shaders

by Roderick Colenbrander

> Is there a TODO or similar documentation on D3D8 & 9 for Wine? I don't > necessarily have much background in DirectX. Last time I used it was > when DirectX 3.0 was brand spanking new and was all the rave. I'm > willing to work, but don't know where to start and am limited on time > available to search for it. If someone has already begun some > organization of this, like a hit-list or something, that would be quite > helpful. > There's no todo list right now. Right now the best approach would be to finish the d3d8 to wined3d move so that both d3d8 and d3d9 share the same core. Then remaining bugs should be fixed so that more games work. After that performance tweaks should be added and more features like shaders. > Also, does anybody know what the status is compared to WineX/Cedega? Do > they have a more fully featured shader implementation? What's there > status/policy on porting back to Wine? A long time ago WineX/Cedega separated from Wine. In the beginning when Wine was X11 licensed they sometimes ported stuff back to Wine but these days they don't do that anymore. Wine's implementation of Direct3D is quite good but compared to cedega performance isn't optimal and our shader support is very basic but modern games like Halflife2 and others work. Roderick

Jan. 31, 2006

Re: dx9 and shaders

by Coleman Kane

On Tue, 2006-01-31 at 21:26 +0100, Roderick Colenbrander wrote: > There's some initial shader stuff in wine but not sure how well it works. I > don't know what the status on it is as we haven't heard anything from the guy > who was working on this. He was also working on moving the d3d8 code over to > wined3d. If you have time to help out, all help is usefull :) > One of the usefull things to do before starting to hack on shaders is to > finish the d3d8/d3d9 merge as both can then share the same shader code. > > Roderick > > > On Tuesday 31 January 2006 20:37, Coleman Kane wrote: > > Hi, > > > > What is the status on Shader support for DX9 in the latest WINE cvs, and > > the future projections of support in this area? > > > > I am working on a transition project, and am curious how far off support > > for this is in the WINE project, and perhaps where work needs to be > > done. Are there any people organizing this effort here? > > > > -- > > Coleman Kane Is there a TODO or similar documentation on D3D8 & 9 for Wine? I don't necessarily have much background in DirectX. Last time I used it was when DirectX 3.0 was brand spanking new and was all the rave. I'm willing to work, but don't know where to start and am limited on time available to search for it. If someone has already begun some organization of this, like a hit-list or something, that would be quite helpful. Also, does anybody know what the status is compared to WineX/Cedega? Do they have a more fully featured shader implementation? What's there status/policy on porting back to Wine? Any work that I do will fall right back in the Wine repo. -- Coleman Kane

Jan. 31, 2006

Re: dx9 and shaders

by Roderick Colenbrander

There's some initial shader stuff in wine but not sure how well it works. I don't know what the status on it is as we haven't heard anything from the guy who was working on this. He was also working on moving the d3d8 code over to wined3d. If you have time to help out, all help is usefull :) One of the usefull things to do before starting to hack on shaders is to finish the d3d8/d3d9 merge as both can then share the same shader code. Roderick On Tuesday 31 January 2006 20:37, Coleman Kane wrote: > Hi, > > What is the status on Shader support for DX9 in the latest WINE cvs, and > the future projections of support in this area? > > I am working on a transition project, and am curious how far off support > for this is in the WINE project, and perhaps where work needs to be > done. Are there any people organizing this effort here? > > -- > Coleman Kane

Jan. 31, 2006

dx9 and shaders

by Coleman Kane

Hi, What is the status on Shader support for DX9 in the latest WINE cvs, and the future projections of support in this area? I am working on a transition project, and am curious how far off support for this is in the WINE project, and perhaps where work needs to be done. Are there any people organizing this effort here? -- Coleman Kane

Jan. 31, 2006

Re: opengl: Sync a dibsection to its pixmap before drawing to it via opengl

by Huw D M Davies

On Sun, Jan 29, 2006 at 07:45:39PM +0100, Lionel Ulmer wrote: > On Fri, Jan 27, 2006 at 03:48:00PM +0000, Huw D M Davies wrote: > > Huw Davies <huw(a)codeweavers.com> > > opengl: Sync a dibsection to its pixmap before drawing to it via opengl > > Was some benchmarks done to see if this change negatively impacted the > performance of applications doing only 'in-window' drawings (e.g. games) and > not 'in-dib' drawings ? In a word, 'no'. However it shouldn't be too bad, the 'in-window' path calls glXGetCurrentContext, get_context_from_GLXContext and GetObjectType. The first and last of these should be quick, as should the second unless there are loads of contexts floating about. Huw.

Jan. 31, 2006

Wine and Font rendering

by Roland Kaeser

Hello all I noticed a very strange font problem in Corel Draw using wine. On some systems (all SuSE 10) rotated fonts became invisible. An other problem is with text boxes on some systems text boxes (with floating text) are very strange rendered (the text appears multiple times, the cursor is not at the position where the character is printed while writing, some text is invisible while editing) Can somebody tell me which routines (system and wine) are responsible for font rendering in wine. Based on that all machines have the same graphics card and driver version, I'm pretty sure its not a driver or graphics card related problem but on some systems, online updates are made. If I could know about the internal work of font rendering in wine, I probably can figure out where this problem cames from. Many thanks Roland Kaeser

Jan. 31, 2006

Re: linux/capi.h: present but cannot be compiled

by Marcus Meissner

On Tue, Jan 31, 2006 at 10:57:52PM +1100, Joshua Crawford wrote: > (I'm not on the devel list, so please Cc: replies either to me or the users > list.) > > After recently upgrading my distro (from Slackware 10.1 to Slackware 10.2 > with Freerock GNOME), configure (current CVS) now reports It will likely work nethertheless, see here: > configure: WARNING: linux/capi.h: present but cannot be compiled > configure: WARNING: linux/capi.h: check for missing prerequisite headers? > configure: WARNING: linux/capi.h: see the Autoconf documentation > configure: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" > configure: WARNING: linux/capi.h: proceeding with the preprocessor's result > configure: WARNING: linux/capi.h: in the future, the compiler will take precedence ... > configure:7252: WARNING: linux/capi.h: present but cannot be compiled > configure:7254: WARNING: linux/capi.h: check for missing prerequisite headers? > configure:7256: WARNING: linux/capi.h: see the Autoconf documentation > configure:7258: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" > configure:7260: WARNING: linux/capi.h: proceeding with the preprocessor's result > configure:7262: WARNING: linux/capi.h: in the future, the compiler will take precedence > configure:7274: checking for linux/capi.h > configure:7281: result: yes Ciao, Marcus

Jan. 31, 2006

Re: keyboard: fix the keyboard problem when using UTF-8 locales

by Dmitry Timoshkov

On Tue, 2006-01-31 at 14:36 +0000, Robert Shearman wrote: > Then how should Fatih's problem be fixed? I don't know. It works here just fine for ru_RU.UTF-8 and XLookupString apparently doesn't return UTF-8 encoded strings on keyboard detection, X11 sends UTF-8 encoded characters with KeyPress events though. -- Dmitry.

Jan. 31, 2006

Re: user: fix DrawTextExA/W on empty strings.

by Rein Klazes

On Fri, 27 Jan 2006 10:28:04 -0800, you wrote: >(Apart from the other discussion) are you sure that you really >mean that? >"If the length is explicitly stated to be zero then don't do the >calcrect but if the length is to be measured and happens to come >out as zero then do do the calcrect" >If so then I suggest at least a comment that it is deliberate; it >sounds counterintuitive to me. I thought I did even better by providing tests for each of those cases, which pass here under Win2k and XP. Other weird observations: the different behavior of the A and W functions; the "return 0" in that code are actually "return 1" on Win2k but not on XP. Rein.

Jan. 31, 2006

Re: Direct3D 8/9 status?

by Roderick Colenbrander

I quickly checked the beta of the d3d8 rewrite. The d3d8 cleanup itself looked quite ok but some changes in wined3d were needed. Those changes aren't very clean (lots of ifdefs and hacks). I might try to port this stuff over to wine cvs and perhaps someone can then help clean it up. Roderick On Tuesday 31 January 2006 13:28, H. Verbeet wrote: > On 31/01/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > optimizations. What's the status on all this and what areas of wined3d > > are safe to touch? > > Not sure, I don't think Oliver has posted here a lot lately. I would > guess that ddraw/d3d7 and d3d8 are a bit tricky to modify at the > moment, while d3d9 should probably be ok. As for wined3d, if either > Stefan or Oliver need to make changes to that for their respective > rewrites, I would hope that they will submit those to the main tree as > soon as those changes are stable enough. Either way, I don't actually > know.

Jan. 31, 2006

Re: wined3d: Fixed render states

by H. Verbeet

On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > H. Verbeet wrote: > > On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > > > >> wined3d: Fixed up render states > >> > > You probably want to split the patch up in smaller pieces. > > > How would I do this? The changes to eg. EDGEANTIALIAS and POINTSPRITENABLE don't depend on eachother, and aren't really related, except for both of them being renderstates, so you could probably split those changes up into separate patches. > > Same problem as with your patch for d3d8, wined3d doesn't currently > > check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > > > Will be submitted as a separate patch. Falls back to the EXT version for > now. I think it is preferrable to check in working code as much as possible. Although it doesn't directly break stuff, it would probably be best to submit the checks for ARB_POINT_PARAMETERS support before trying to use it. > >> - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ > >> - glDisable(GL_POINT_SMOOTH); > >> > > Did you verify that this isn't required anymore? Otherwise that's a > > potential regression. > > > This seems to be a bug with (some?) ATI hardware/drivers. > Point smoothing should normally be supported I believe. Well yes, but I doubt we want to break stuff that was previously working.

Jan. 31, 2006

Re: Fix Bug#: 4396: floating MFC-ToolBars get managed and can't be re-docked

by Robert Shearman

Tobias Loew wrote: >Changelog: > dlls/x11drv/window.c > > Tobias Loew <tobi(a)die-loews.de> > Fix Bug#: 4396: floating MFC-ToolBars get managed and can't be re-docked > don't manage top-level windows having the style WS_EX_TOOLWINDOW and WS_CAPTION > >Tobias Loew > > Hi Tobias, I'm afraid this patch isn't likely to be applied. The reason is that moving around the rules for being a managed window or not is likely to cause regressions. Alexandre has stated that the only real solution is to be able to switch between managed and non-managed on the fly and add new (and better) dynamic rules to control this. -- Rob Shearman

Jan. 31, 2006

Re: keyboard: fix the keyboard problem when using UTF-8 locales

by Robert Shearman

Dmitry Timoshkov wrote: >On Tue, 2006-01-31 at 13:11 +0200, Fatih Aşıcı wrote: > > > >>When using UTF-8 locale, I can't type some Turkish characters. >>I don't know whether it works with other languages. >>But it works at least in Turkish locale. >> >> > > > >>+ have_chars = XLookupString(&e2, bufC, 2, &keysym, NULL); >>+ if(have_chars > 1){ >>+ MultiByteToWideChar(CP_UNIXCP, 0, bufC, -1, bufW, -1); >>+ WideCharToMultiByte(CP_ACP, 0, bufW, -1, &ckey[i], 1, NULL, >> >> >NULL); > > >>+ } >> >> > >Probably it works for Turkish locale but it won't work in general. >Code pages often have characters which could not be be represented >in other code pages and therefore will be lost. > > Then how should Fatih's problem be fixed? -- Rob Shearman

Jan. 31, 2006

wine and xscanimage

by Roland Kaeser

Hello I recently tried to get a sane-scanner work with wine and noticed hat the xscanimage mostly is no longer part of the shipped sane frontends by actual distributions. It becomes harder and harder to get a update to date version of xscanimge. Wouldn't it be better to choose an other sane-frontend for the wine twain/sane integration? Kind regards Roland Kaeser

Jan. 31, 2006

Re: PATCH: Wine Turkish translations

by Mike McCormack

Fatih Aşıcı wrote: > Turkish resources for wine > > Changelog: > Fatih Asici <fasici(a)linux-sevenler.org> > - Turkish translations (includes all wine resources) Thanks for translating all these. Before Alexandre applies them, it's likely you'll need to split the patch up into smaller chunks, and submit them one per email. This makes it easier for reviewers to spot problems, and for Alexandre to apply the patches. eg. The following two patches should be sent together in one email: diff -Nur oldwine/dlls/commdlg/rsrc.rc wine/dlls/commdlg/rsrc.rc diff -Nur oldwine/dlls/commdlg/cdlg_Tr.rc wine/dlls/commdlg/cdlg_Tr.rc thanks, Mike

Jan. 31, 2006

Re: keyboard: fix the keyboard problem when using UTF-8 locales

by Dmitry Timoshkov

On Tue, 2006-01-31 at 13:11 +0200, Fatih Aşıcı wrote: > When using UTF-8 locale, I can't type some Turkish characters. > I don't know whether it works with other languages. > But it works at least in Turkish locale. > + have_chars = XLookupString(&e2, bufC, 2, &keysym, NULL); > + if(have_chars > 1){ > + MultiByteToWideChar(CP_UNIXCP, 0, bufC, -1, bufW, -1); > + WideCharToMultiByte(CP_ACP, 0, bufW, -1, &ckey[i], 1, NULL, NULL); > + } Probably it works for Turkish locale but it won't work in general. Code pages often have characters which could not be be represented in other code pages and therefore will be lost. -- Dmitry.

Jan. 31, 2006

Re: wined3d: Fixed render states

by Vitaly Budovski

H. Verbeet wrote: > On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > >> wined3d: Fixed up render states POINTSCALEENABLE, POINTSPRITENABLE, >> EDGEANTIALIAS, MULTISAMPLEANTIALIAS >> > You probably want to split the patch up in smaller pieces. > How would I do this? > >> + if(This->stateBlock->renderState[D3DRS_POINTSCALEENABLE]) { >> + att[0] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_A]) / >> + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); >> + att[1] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_B]) / >> + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); >> + att[2] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_C]) / >> + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); >> + } >> > You're not supposed to use D3DRS_ stuff in wined3d, rather use the > respective WINED3DRS_ defines, as the original code did. > Typo, I'll fix that. >> + if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { >> > Same problem as with your patch for d3d8, wined3d doesn't currently > check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > Will be submitted as a separate patch. Falls back to the EXT version for now. >> - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ >> - glDisable(GL_POINT_SMOOTH); >> > Did you verify that this isn't required anymore? Otherwise that's a > potential regression. > This seems to be a bug with (some?) ATI hardware/drivers. Point smoothing should normally be supported I believe. >> + checkGLcall("glEnable(Gl_LINE_SMOOTH)"); >> + checkGLcall("glDisable(Gl_LINE_SMOOTH)"); >> > That should probably say Gl_LINE_SMOOTH, but it's not really critical > Non-critical typo, but will be fixed when I resend the patch.

Jan. 31, 2006

Re: wined3d: Fixed render states

by H. Verbeet

On 31/01/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > wined3d: Fixed up render states POINTSCALEENABLE, POINTSPRITENABLE, > EDGEANTIALIAS, MULTISAMPLEANTIALIAS You probably want to split the patch up in smaller pieces. > + if(This->stateBlock->renderState[D3DRS_POINTSCALEENABLE]) { > + att[0] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_A]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + att[1] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_B]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + att[2] = *((float*)&This->stateBlock->renderState[D3DRS_POINTSCALE_C]) / > + (This->stateBlock->viewport.Height * This->stateBlock->viewport.Height); > + } You're not supposed to use D3DRS_ stuff in wined3d, rather use the respective WINED3DRS_ defines, as the original code did. > + if(GL_SUPPORT(ARB_POINT_PARAMETERS)) { Same problem as with your patch for d3d8, wined3d doesn't currently check for ARB_POINT_PARAMETERS support (in IWineD3DImpl_FillGLCaps). > - /* Doesn't work with GL_POINT_SMOOTH on on my ATI 9600, but then ATI drivers are buggered! */ > - glDisable(GL_POINT_SMOOTH); Did you verify that this isn't required anymore? Otherwise that's a potential regression. > + checkGLcall("glEnable(Gl_LINE_SMOOTH)"); > + checkGLcall("glDisable(Gl_LINE_SMOOTH)"); That should probably say Gl_LINE_SMOOTH, but it's not really critical.

Jan. 31, 2006

Re: Direct3D 8/9 status?

by H. Verbeet

On 31/01/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > optimizations. What's the status on all this and what areas of wined3d are > safe to touch? Not sure, I don't think Oliver has posted here a lot lately. I would guess that ddraw/d3d7 and d3d8 are a bit tricky to modify at the moment, while d3d9 should probably be ok. As for wined3d, if either Stefan or Oliver need to make changes to that for their respective rewrites, I would hope that they will submit those to the main tree as soon as those changes are stable enough. Either way, I don't actually know.

Jan. 31, 2006

linux/capi.h: present but cannot be compiled

by Joshua Crawford

(I'm not on the devel list, so please Cc: replies either to me or the users list.) After recently upgrading my distro (from Slackware 10.1 to Slackware 10.2 with Freerock GNOME), configure (current CVS) now reports configure: WARNING: linux/capi.h: present but cannot be compiled configure: WARNING: linux/capi.h: check for missing prerequisite headers? configure: WARNING: linux/capi.h: see the Autoconf documentation configure: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/capi.h: proceeding with the preprocessor's result configure: WARNING: linux/capi.h: in the future, the compiler will take precedence configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to wine-devel(a)winehq.org ## configure: WARNING: ## ------------------------------------ ## It seems linux/capi.h requires linux/compiler.h (for __user). I tried simply putting linux/compiler.h above linux/capi.h in the AC_CHECK_HEADERS list, but that did't work, so I'll have to leave the fix to someone who actually knows something about autoconf. This is the relevant section from config.log: configure:7159: checking linux/capi.h usability configure:7171: gcc -c -g -O2 conftest.c >&5 In file included from conftest.c:76: /usr/include/linux/capi.h:80: error: variable or field `__user' declared void /usr/include/linux/capi.h:80: error: syntax error before '*' token /usr/include/linux/capi.h:115: error: syntax error before "capi_manufacturer_cmd" /usr/include/linux/capi.h:117: error: syntax error before '}' token configure:7177: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "0.9.6" | #define PACKAGE_STRING "Wine 0.9.6" | #define PACKAGE_BUGREPORT "wine-devel(a)winehq.org" | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define YYTEXT_POINTER 1 | #define HAVE_GETHOSTBYNAME 1 | #define HAVE_CONNECT 1 | #define HAVE_INET_ATON 1 | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_ALSA_ASOUNDLIB_H 1 | #define HAVE_ARPA_INET_H 1 | #define HAVE_ARPA_NAMESER_H 1 | #define HAVE_ASM_TYPES_H 1 | #define HAVE_CUPS_CUPS_H 1 | #define HAVE_CURSES_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_ELF_H 1 | #define HAVE_FLOAT_H 1 | #define HAVE_GETOPT_H 1 | #define HAVE_GIF_LIB_H 1 | #define HAVE_JPEGLIB_H 1 | #define HAVE_LBER_H 1 | #define HAVE_LCMS_H 1 | #define HAVE_LDAP_H 1 | #define HAVE_LINK_H 1 | /* end confdefs.h. */ | #include <stdio.h> | #if HAVE_SYS_TYPES_H | # include <sys/types.h> | #endif | #if HAVE_SYS_STAT_H | # include <sys/stat.h> | #endif | #if STDC_HEADERS | # include <stdlib.h> | # include <stddef.h> | #else | # if HAVE_STDLIB_H | # include <stdlib.h> | # endif | #endif | #if HAVE_STRING_H | # if !STDC_HEADERS && HAVE_MEMORY_H | # include <memory.h> | # endif | # include <string.h> | #endif | #if HAVE_STRINGS_H | # include <strings.h> | #endif | #if HAVE_INTTYPES_H | # include <inttypes.h> | #else | # if HAVE_STDINT_H | # include <stdint.h> | # endif | #endif | #if HAVE_UNISTD_H | # include <unistd.h> | #endif | #include <linux/capi.h> configure:7199: result: no configure:7203: checking linux/capi.h presence configure:7213: gcc -E conftest.c configure:7219: $? = 0 configure:7239: result: yes configure:7252: WARNING: linux/capi.h: present but cannot be compiled configure:7254: WARNING: linux/capi.h: check for missing prerequisite headers? configure:7256: WARNING: linux/capi.h: see the Autoconf documentation configure:7258: WARNING: linux/capi.h: section "Present But Cannot Be Compiled" configure:7260: WARNING: linux/capi.h: proceeding with the preprocessor's result configure:7262: WARNING: linux/capi.h: in the future, the compiler will take precedence configure:7274: checking for linux/capi.h configure:7281: result: yes -- Joshua 'bruce' Crawford ... http://www.geocities.com/mortarn The early bird may get the worm, but the second mouse gets the cheese.

Jan. 31, 2006

Direct3D 8/9 status?

by Roderick Colenbrander

Hi, Recently various people in the wine channels wanted to work on wine's direct3d8/9 code. Some just wanted to get their game working, others wanted to do performance tweaks and today some guy wanted to port d3d8 over to wined3d (he didn't know that oliver is/was working on it). We don't really know what to tell these people as we don't know the status of the direct3d8/9 work and we want to avoid code duplication. We know that Oliver is/was (?) working on moving direct3d8 over to wined3d and that he is working on optimizations. What's the status on all this and what areas of wined3d are safe to touch? Regards, Roderick

Jan. 31, 2006

Re: Fun with VB6. Crashes in OLE gunk...

by Marcus Meissner

On Mon, Jan 30, 2006 at 08:27:48PM -0800, Dan Kegel wrote: > I finally broke down and bought a copy of VB6 Pro. > To install it, I had to pick "win98" mode in winecfg, > and ignore a few errors. > > While playing around with it, running a test app, I got Wine > to crash on a COM problem of some sort. In several ways. > Here's one: > > fixme:ole:OleLoadPictureEx > (0x7d5216b4,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x7fe7c2c0), > partially implemented. > fixme:ole:OleLoadPictureEx > (0x7d5216b4,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x7fe7c428), > partially implemented. > fixme:ole:OLEFontImpl_IPersistStreamInit_InitNew (0x7cb055bc), stub! > err:ole:ITypeInfo_fnInvoke failed to convert param 0 to > VT_VARIANT|VT_BYREF from VT_BSTR|VT_BYREF Here is the bad error. > fixme:ole:OLEPictureImpl_get_hPal unimplemented for type 3. Returning 0 palette. > fixme:ole:OLEPictureImpl_get_hPal unimplemented for type 3. Returning 0 palette. > fixme:ole:OLEPictureImpl_Render Not quite correct implementation of > rendering icons... > fixme:ole:MSFT_ReadValue BSTR length = -1? > fixme:ole:MSFT_ReadValue BSTR length = -1? > fixme:ole:ITypeLib2_fnGetDocumentation2 (0x7baa2fb0) index -1 lcid 0 > half implemented stub! > fixme:typelib2:ICreateTypeLib2_fnSetHelpContext (0x7bac0ee8,280000), stub! > fixme:ole:ITypeInfo_fnRelease destroy child objects > fixme:font:WineEngCreateFontInstance Untranslated charset 255 > fixme:ole:DllDebugObjectRPCHook stub > wine: Unhandled page fault on read access to 0x00000000 at address > 0x7f700844 (thread 0009), starting debugger... > WineDbg starting on pid 0x8 > Unhandled exception: page fault on read access to 0x00000000 in 32-bit > code (0x7f700844). > In 32 bit mode. > Register dump: > CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 > EIP:7f700844 ESP:7fb1f5bc EBP:7fb1f5d4 EFLAGS:00210202( - 00 - -RI1) > EAX:00000000 EBX:7f751784 ECX:00000000 EDX:7baeb278 > ESI:7baeb268 EDI:00000000 > Stack dump: > 0x00000000: 00000000 00000000 00000000 00000000 > 0x00000010: 00000000 00000000 00000000 00000000 > 0x00000020: 00000000 00000000 00000000 00000000 > 0x00000030: 00000000 00000000 00000000 00000000 > 0x00000040: 00000000 00000000 00000000 00000000 > 0x00000050: 00000000 00000000 00000000 00000000 > Backtrace: > =>1 0x7f700844 OLEFontImpl_put_Name+0x64(iface=0x7baeb268, name=0x0) > [/home/dank/wine/dlls/oleaut32/../../include/winbase.h:2069] in > oleaut32 (0x7f700844) A NULL ptr check might help, if (!name) return E_POINTER; or so... Ciao, Marcus

Jan. 31, 2006

Fun with VB6. Crashes in OLE gunk...

by Dan Kegel

I finally broke down and bought a copy of VB6 Pro. To install it, I had to pick "win98" mode in winecfg, and ignore a few errors. While playing around with it, running a test app, I got Wine to crash on a COM problem of some sort. In several ways. Here's one: fixme:ole:OleLoadPictureEx (0x7d5216b4,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x7fe7c2c0), partially implemented. fixme:ole:OleLoadPictureEx (0x7d5216b4,0,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=16,y=16,f=0,0x7fe7c428), partially implemented. fixme:ole:OLEFontImpl_IPersistStreamInit_InitNew (0x7cb055bc), stub! err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT|VT_BYREF from VT_BSTR|VT_BYREF fixme:ole:OLEPictureImpl_get_hPal unimplemented for type 3. Returning 0 palette. fixme:ole:OLEPictureImpl_get_hPal unimplemented for type 3. Returning 0 palette. fixme:ole:OLEPictureImpl_Render Not quite correct implementation of rendering icons... fixme:ole:MSFT_ReadValue BSTR length = -1? fixme:ole:MSFT_ReadValue BSTR length = -1? fixme:ole:ITypeLib2_fnGetDocumentation2 (0x7baa2fb0) index -1 lcid 0 half implemented stub! fixme:typelib2:ICreateTypeLib2_fnSetHelpContext (0x7bac0ee8,280000), stub! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:font:WineEngCreateFontInstance Untranslated charset 255 fixme:ole:DllDebugObjectRPCHook stub wine: Unhandled page fault on read access to 0x00000000 at address 0x7f700844 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x7f700844). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7f700844 ESP:7fb1f5bc EBP:7fb1f5d4 EFLAGS:00210202( - 00 - -RI1) EAX:00000000 EBX:7f751784 ECX:00000000 EDX:7baeb278 ESI:7baeb268 EDI:00000000 Stack dump: 0x00000000: 00000000 00000000 00000000 00000000 0x00000010: 00000000 00000000 00000000 00000000 0x00000020: 00000000 00000000 00000000 00000000 0x00000030: 00000000 00000000 00000000 00000000 0x00000040: 00000000 00000000 00000000 00000000 0x00000050: 00000000 00000000 00000000 00000000 Backtrace: =>1 0x7f700844 OLEFontImpl_put_Name+0x64(iface=0x7baeb268, name=0x0) [/home/dank/wine/dlls/oleaut32/../../include/winbase.h:2069] in oleaut32 (0x7f700844) 2 0x7f702a99 OLEFontImpl_IPersistPropertyBag_Load(iface=0x7baeb278, pPropBag=0x7e7d4924, pErrorLog=0x0) [/home/dank/wine/dlls/oleaut32/olefont.c:1922] in oleaut32 (0x7f702a99) err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file VB6.dbg ("VB6.dbg") 3 0x0044c9e2 in vb6 (+0x4c9e2) (0x0044c9e2) 4 0x004106f9 in vb6 (+0x106f9) (0x004106f9) ... -- Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 31, 2006

Re: [frick <at> sc-networks.de: wined3d: support for WINED3D_A8B8G8R8]

by Aric Cyr

Christoph Frick <frick <at> sc-networks.de> writes: > > hiho, > > could someone enlighten me, what is wrong with that patch? > I don't know the real reason, but from looking at it I have the following concerns. Have you tested the colour output from your patch? I'm guessing it wouldn't output the correct colours due to OpenGL not having default support for ABGR textures, and the formats you specify are not quite right to accomplish it. You should probably check for the GL_EXT_abgr extension and use the GL_ABGR_EXT format type to get correct output. Here's some references for you: http://www.opengl.org/resources/code/glut/glut_examples/examples/abgr.c http://oss.sgi.com/projects/ogl-sample/registry/EXT/abgr.txt Regards, Aric

Jan. 31, 2006