August 2004 - Wine-Devel - list.winehq.org

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Mike Hearn

On Sat, 2004-08-07 at 16:00 -0700, Alexandre Julliard wrote: > It's missing because it violates namespace rules. The other debugstr > functions are here for historical reasons but we shouldn't add new > ones. OK, I suspected that might be the case but inside of Wines code why do we have to prefix things with wine? For Winelib (ie external) source I can understand that, but we already know there are no conflicts inside Wine.

Aug. 8, 2004

Re: Problem with ITypeInfo

by Dmitry Timoshkov

"jack" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -3265,6 +3266,7 @@ > return NULL; > } > *ppTypeInfoImpl = (ITypeInfoImpl*)ITypeInfo_Constructor(); > + pTypeLibImpl->ref++; Are you sure you need this piece of the patch? It causes the following test program to fail: #define COBJMACROS #include <stdarg.h> #include <stdio.h> #include <assert.h> #include "windef.h" #include "winbase.h" #include "oleauto.h" static void load_type_lib(LPCWSTR type_lib) { ITypeLib *iface; TLIBATTR *pTLibAttr; HRESULT hResult; ULONG ref_count; // DWORD dwWritten; printf("Loading: \"%ws\"\n", type_lib); hResult = LoadTypeLib(type_lib, &iface); printf("LoadTypeLib() = %08lx\n", hResult); assert(hResult == S_OK); hResult = ITypeLib2_GetLibAttr(iface, &pTLibAttr); printf("GetLibAttr() = %08lx\n", hResult); assert(hResult == S_OK); // fflush(stdout); // WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), pTLibAttr, sizeof(*pTLibAttr), &dwWritten, NULL); // printf("\n\n"); ITypeLib2_ReleaseTLibAttr(iface, pTLibAttr); ref_count = ITypeLib2_Release(iface); printf("ITypeLib2_Release() = %lu\n", ref_count); assert(ref_count == 0); } int main(void) { // load_type_lib(L"olepro32.dll"); // load_type_lib(L"msvbvm60.dll"); load_type_lib(L"stdole32.tlb"); return 0; } -- Dmitry.

Aug. 8, 2004

Re: Problem with ITypeInfo

by Jacek Caban

Dmitry Timoshkov wrote: >"jack" <jack(a)itma.pwr.wroc.pl> wrote: > > > >>@@ -3265,6 +3266,7 @@ >> return NULL; >> } >> *ppTypeInfoImpl = (ITypeInfoImpl*)ITypeInfo_Constructor(); >>+ pTypeLibImpl->ref++; >> >> > >Are you sure you need this piece of the patch? It causes the following >test program to fail: > > > No, I don't. In my case I need only this: /* this is where we are coming from */ + ITypeLib2_AddRef((ITypeLib*)pLibInfo); ptiRet->pTypeLib = pLibInfo; ptiRet->index=count; but I call ITypeLib_Release in ITypeInfo_Release so I thought I should increment ref here too. Thanks, Jacek

Aug. 7, 2004

Re: Add debugstr_rect alias for consistency with other debugging functions.

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > The lack of this confused me for a few minutes, might as well stick it in. It's missing because it violates namespace rules. The other debugstr functions are here for historical reasons but we shouldn't add new ones. -- Alexandre Julliard julliard(a)winehq.org

Aug. 7, 2004

Re: Take monospace fonts into account in default font selectionalgorithm.

by Alexandre Julliard

Mike Hearn <mike(a)navi.cx> writes: > On Sat, 2004-08-07 at 23:16 +0900, Dmitry Timoshkov wrote: >> This can't work because instead of logical boolean results you compare >> binary flags which are different: >> >> #define FT_FACE_FLAG_FIXED_WIDTH ( 1L << 2 ) >> >> #define MONO_FONT 0x08 > > You are right. I will watch out for this in future! Here is a fixed > patch. The correct way to compare booleans in C is to invert them, i.e. instead of (a == b) use (!a == !b). You must not rely on booleans being always 0 or 1. -- Alexandre Julliard julliard(a)winehq.org

Aug. 7, 2004

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by David D. Hagood

Mike Hearn wrote: > This is MS DAO. I do not know why your program has regressed but these > traces don't show why native DCOM doesn't work. > OK, that checks - I know the program does use DAO. As to native DCOM - when I tried to install it, it barfed. But... > Are you running Wine in NT mode by any chance? If so then there was a Yes, I am - I was under the impression that would give a better shot at compatability since, when there is a mutually exclusive choice between the 9X and the NT way, Wine tends to follow the NT way. > regression there lately if you use 9x DCOM but I think it's fixed now. > Easy enough to fix if not. > So you are suggesting that I attempt to re-install the Win98 DCOM package? Should I change the ole* overrides to "native,builtin", and if so, should I do so before or after installing the DCOM package? Should I also change the Winver to 98, and if so, should I do so for all programs, just the DCOM installer, or for the DCOM install + Mng6?

Aug. 7, 2004

Re: make crosstest fails

by Hans Leidekker

On Saturday 24 July 2004 01:18, Francois Gouget wrote: > Exactly. I got my libdxguid.a from the following URLs a couple of days > ago: > http://mirzam.it.vu.nl/mingw/ > > I thought that was the special 'Wine edition' MinGW library but > apparently not. Where can I find the special 'Wine edition'? I guess > it's more likely to be updated on short order... It *is* the special Wine edition, but it's only today that I found some time to bring it up to date. Essential changes: - update gcc to 3.4.1-20040711-1 - remove dxguids patch to w32api - add mlang uuids patch to w32api - update mingw-runtime to 3.3 - remove 2 patches to runtime accepted upstream I was able to cross compile all Wine tests in current CVS. Find it here: http://mirzam.it.vu.nl/mingw/ > Should we have a link pointing to these special tools on WineHQ? Maybe > on the resources page? > http://www.winehq.org/site/resources That's a good idea, though it's linked to already from here: http://winehq.org/site/docs/wine-devel/cross-compiling-tests > Or can we actually use this instead? > http://prdownloads.sourceforge.net/wine/wine-w32api-20040505.zip?download Yes I have thought about that too. Advantage is that Wine tests are more likely to compile and link. Disadvantage is that Wine get's less testing with 3rd party headers and/or import libraries. Maybe I should do a mingw-w32api *and* a wine-w32api rpm package... -Hans

Aug. 7, 2004

Re: Wine's OLE/COM doesn't work, and I can no longer use native COM

by Mike Hearn

On Sat, 07 Aug 2004 11:11:52 -0500, David D. Hagood wrote: > 0x5f8a41b8->{00025E15-0000-0000-C000-000000000046} > trace:ole:CoGetClassObject > CLSID: {00025e15-0000-0000-c000-000000000046}, > IID: {b196b28f-bab4-101a-b69c-00aa00341d07} This is MS DAO. I do not know why your program has regressed but these traces don't show why native DCOM doesn't work. Are you running Wine in NT mode by any chance? If so then there was a regression there lately if you use 9x DCOM but I think it's fixed now. Easy enough to fix if not.

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Steven Edwards

Hi Mike, --- Mike Hearn <mike(a)navi.cx> wrote: > Have I missed something here - I thought there was a native version > of > DOOM 3 for Linux? I dont think it is being released right away. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

Aug. 7, 2004

Wine's OLE/COM doesn't work, and I can no longer use native COM

by David D. Hagood

One of the few Windows programs I use is Delorme's MapNGo (versions 4 and 6). Under older versions of Wine wherein I could use the native Windows OLE/COM implementation it worked fairly well, but with the new Wine it does not. The symptoms are that the program cannot create the initial document object - this ususally is an indication that the DLLS implementing the COM classes for the MapNGo object are not registered correctly with the system. However, I have taken a system running an older version of Wine that could successfully run Mng6 and upgraded it to the latest CVS of Wine, and it broke the app. Not being a wiz at COM, I am not sure where to go from here, other than to report the results of tracing the run: WINDEBUG=+ole,+com wine ./Mng6 fixme:ole:CoRegisterMessageFilter stub err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! [wowbaggr(a)surfer AAAMNG6]$ [wowbaggr(a)surfer AAAMNG6]$ WINDEBUG=+ole,+com wine ./Mng6.mdb wine: cannot determine executable type for L"D:\\AAAMNG6\\Mng6.mdb" [wowbaggr(a)surfer AAAMNG6]$ WINDEBUG=+ole,+com wine ./mng mng6.cnt mng6.exe mng6.hlp mngfeat.hlp [wowbaggr(a)surfer AAAMNG6]$ WINDEBUG=+ole,+com wine ./mng6.exe fixme:ole:CoRegisterMessageFilter stub err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! [wowbaggr(a)surfer AAAMNG6]$ [wowbaggr(a)surfer AAAMNG6]$ WINDEBUG=+all wine ./mng6.exe fixme:ole:CoRegisterMessageFilter stub err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! [wowbaggr(a)surfer AAAMNG6]$ [wowbaggr(a)surfer AAAMNG6]$ WINEDEBUG=+ole,+com wine ./mng6.exe trace:ole:DllMain 0x40c00000 0x1 0x1 trace:ole:DllMain (0x40e30000,1,0x1) trace:ole:CoInitializeEx ((nil), 2) trace:ole:CoInitializeEx () - Initializing the COM libraries trace:ole:RunningObjectTableImpl_Initialize () trace:ole:OleInitialize ((nil)) trace:ole:CoInitializeEx ((nil), 2) trace:ole:OleInitialize () - Initializing the OLE libraries trace:ole:OLEClipbrd_Initialize () fixme:ole:CoRegisterMessageFilter stub trace:ole:WINE_StringFromCLSID 0x49d964->{F4B4E540-7F32-11CE-AC56-0000C0496D91} trace:ole:WINE_StringFromCLSID 0x487530->{D97A6266-C342-11D2-A562-A313798CEB30} trace:ole:WINE_StringFromCLSID 0x4071f3bc->{D97A6266-C342-11D2-A562-A313798CEB30} trace:ole:CoGetClassObject CLSID: {d97a6266-c342-11d2-a562-a313798ceb30}, IID: {b196b28f-bab4-101a-b69c-00aa00341d07} trace:ole:COMPOBJ_DLLList_Add trace:ole:CoInitializeEx ((nil), 2) trace:ole:WINE_StringFromCLSID 0x5f8a41b8->{00025E15-0000-0000-C000-000000000046} trace:ole:CoGetClassObject CLSID: {00025e15-0000-0000-c000-000000000046}, IID: {b196b28f-bab4-101a-b69c-00aa00341d07} trace:ole:COMPOBJ_DLLList_Add trace:ole:CreateErrorInfo (0x4071f38c): stub: trace:ole:IErrorInfoImpl_QueryInterface (0x40252658)->( IID: {22f03340-547d-101b-8e65-08002b2bd119},0x4071f38c) trace:ole:ICreateErrorInfoImpl_AddRef (0x40252658) trace:ole:IErrorInfoImpl_AddRef (0x40252658)->(count=1) trace:ole:IErrorInfoImpl_QueryInterface -- Interface: (0x4071f38c)->(0x4025265c)trace:ole:IErrorInfoImpl_Release (0x40252658)->(count=2) trace:ole:ICreateErrorInfoImpl_QueryInterface (0x40252658) trace:ole:IErrorInfoImpl_QueryInterface (0x40252658)->( IID: {1cf2b120-547d-101b-8e65-08002b2bd119},0x4071f390) trace:ole:IErrorInfoImpl_AddRef (0x40252658)->(count=1) trace:ole:IErrorInfoImpl_QueryInterface -- Interface: (0x4071f390)->(0x40252658)trace:ole:ICreateErrorInfoImpl_SetGUID (0x40252658)->({00000000-0000-0000-0000-000000000000}) trace:ole:ICreateErrorInfoImpl_SetSource (0x40252658) trace:ole:ICreateErrorInfoImpl_SetDescription (0x40252658) trace:ole:ICreateErrorInfoImpl_SetHelpContext (0x40252658) trace:ole:SetErrorInfo (0, 0x40252658) trace:ole:IErrorInfoImpl_AddRef (0x40252658)->(count=2) trace:ole:IErrorInfoImpl_Release (0x40252658)->(count=3) trace:ole:ICreateErrorInfoImpl_Release (0x40252658) trace:ole:IErrorInfoImpl_Release (0x40252658)->(count=2) err:msg:DispatchMessageW BeginPaint not called on WM_PAINT for hwnd 0x1003a! (this last message usually happens when Mng tries to show an error dialog at startup.) When I've tried re-installing Mng6, I get messages from Wine about "Registering a non-oleautomation interface" - I do not know if this is significant or not. So, any pointers on where to go from here?

Aug. 7, 2004

Re: Take monospace fonts into account in default font selectionalgorithm.

by Dmitry Timoshkov

"Mike Hearn" <mike(a)navi.cx> wrote: > + (*insertface)->fixed_width = ft_face->face_flags & FT_FACE_FLAG_FIXED_WIDTH; ... > - if(csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) > + if((csi.fs.fsCsb[0] & family->FirstFace->fs.fsCsb[0]) && > + (family->FirstFace->fixed_width == (lf.lfPitchAndFamily & MONO_FONT))) This can't work because instead of logical boolean results you compare binary flags which are different: #define FT_FACE_FLAG_FIXED_WIDTH ( 1L << 2 ) #define MONO_FONT 0x08 -- Dmitry.

Aug. 7, 2004

Re: suse patch for wineprefixcreate

by Mike Hearn

Is there any way to generalise the CD drive detection code so it works on all distros, maybe by parsing the output of "mount" or the fstab? On Sat, 07 Aug 2004 14:43:07 +0200, Marcus Meissner wrote: > Hi, > > This is the patch I use at SUSE for wineprefixcreate. > > Mike wanted to see it ;) > > $dlldir/config is the sample config file with just minimal local suse changes. > > Ciao, Marcus

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Dr. Uwe Girlich

Hello Lionel! Here comes the requested output of glxinfo: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.3 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample, GLX_NV_float_buffer client glx vendor string: NVIDIA Corporation client glx version string: 1.3 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, GLX_NV_swap_group, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, GLX_ARB_multisample, GLX_NV_float_buffer, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce FX 5900XT/AGP/SSE/3DNOW! OpenGL version string: 1.5.1 NVIDIA 61.11 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_shared_texture_palette, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_copy_depth_to_color, GL_NV_depth_clamp, GL_NV_fence, GL_NV_float_buffer, GL_NV_fog_distance, GL_NV_fragment_program, GL_NV_fragment_program_option, GL_NV_half_float, GL_NV_light_max_exponent, GL_NV_multisample_filter_hint, GL_NV_occlusion_query, GL_NV_packed_depth_stencil, GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_primitive_restart, GL_NV_register_combiners, GL_NV_register_combiners2, GL_NV_texgen_reflection, GL_NV_texture_compression_vtc, GL_NV_texture_env_combine4, GL_NV_texture_expand_normal, GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2, GL_NV_texture_shader3, GL_NV_vertex_array_range, GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NV_vertex_program2, GL_NV_vertex_program2_option, GL_SGIS_generate_mipmap, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SUN_slice_accum glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r y . 8 8 8 0 0 16 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 0 0 16 0 16 16 16 16 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 0 16 0 16 16 16 16 0 0 None 0x2a 24 tc 0 32 0 r y . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x2b 24 tc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x2c 24 tc 0 32 0 r . . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x2d 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x2e 24 tc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 2 1 Ncon 0x2f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 2 1 Ncon 0x30 24 tc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 4 1 Ncon 0x31 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 4 1 Ncon 0x32 24 tc 0 32 0 r y . 8 8 8 0 0 16 0 16 16 16 16 2 1 Ncon 0x33 24 tc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 2 1 Ncon 0x34 24 tc 0 32 0 r y . 8 8 8 0 0 16 0 16 16 16 16 4 1 Ncon 0x35 24 tc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 4 1 Ncon 0x36 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x37 24 dc 0 32 0 r . . 8 8 8 0 0 24 8 16 16 16 16 0 0 None 0x38 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 None 0x39 24 dc 0 32 0 r y . 8 8 8 0 0 16 0 16 16 16 16 0 0 None 0x3a 24 dc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 0 0 None 0x3b 24 dc 0 32 0 r . . 8 8 8 0 0 16 0 16 16 16 16 0 0 None 0x3c 24 dc 0 32 0 r . . 8 8 8 8 0 16 0 16 16 16 16 0 0 None 0x3d 24 dc 0 32 0 r y . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x3e 24 dc 0 32 0 r y . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x3f 24 dc 0 32 0 r . . 8 8 8 0 0 0 0 16 16 16 16 0 0 None 0x40 24 dc 0 32 0 r . . 8 8 8 8 0 0 0 16 16 16 16 0 0 None 0x41 24 dc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 2 1 Ncon 0x42 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 2 1 Ncon 0x43 24 dc 0 32 0 r y . 8 8 8 0 0 24 8 16 16 16 16 4 1 Ncon 0x44 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 4 1 Ncon 0x45 24 dc 0 32 0 r y . 8 8 8 0 0 16 0 16 16 16 16 2 1 Ncon 0x46 24 dc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 2 1 Ncon 0x47 24 dc 0 32 0 r y . 8 8 8 0 0 16 0 16 16 16 16 4 1 Ncon 0x48 24 dc 0 32 0 r y . 8 8 8 8 0 16 0 16 16 16 16 4 1 Ncon In DOOM 3 a similar output with the list of extensions comes from the console command gfxInfo: GL_VENDOR: NVIDIA Corporation GL_RENDERER: GeForce FX 5900XT/AGP/SSE/3DNOW! GL_VERSION: 1.5.1 NVIDIA 61.11 GL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_ shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_ clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_ compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_po int_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_fu ncs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_textu re_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_tex ture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_o bject GL_EXT_vertex_array GL_HP_occlusion_test GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_ buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_half_float GL_NV_light_max_e xponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_ran ge GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texg en_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_te xture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_array_range G L_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_pr ogram2_option GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice _accum WGL_EXTENSIONS: WGL_ARB_extensions_string WGL_EXT_extensions_string GL_MAX_TEXTURE_SIZE: 4096 GL_MAX_TEXTURE_UNITS_ARB: 4 GL_MAX_TEXTURE_COORDS_ARB: 8 GL_MAX_TEXTURE_IMAGE_UNITS_ARB: 16 PIXELFORMAT: color(32-bits) Z(24-bit) stencil(8-bits) MODE: 4, 800 x 600 fullscreen hz:N/A CPU: AMD CPU with MMX & 3DNow! & SSE ARB path ENABLED NV10 path ENABLED NV20 path ENABLED R200 path disabled ARB2 path ENABLED (ACTIVE) Exp path ENABLED Cg path ENABLED ------- glFinish not forced swapInterval not forced Using two sided stencil Vertex cache is fast Toggling speakers > > Almost all computer terminals in the game show static black & white noise > > (instead of some animated computer screen image). > I suppose this is where NP2 textures are used. No idea why the fallback dose > not work. Exactly this is the problem. As the picture I see on screen is not completely random (so if someone forgot to put real data in the memory) but is a nice animated picture of a TV screen without a tuned in channel I assume this is the fallback. It makes the game unplayable, as valuable information must be read from and typed in such screens. > > I suspect, that this has something to do with the missing 'Cg' support in > > Wine (DOOM3 cannot find cg.dll & cgGL.dll). > Did you try to install the native versions using Wine (I have no idea how > NVIDIA packages the Cg libraries though) ? Native Cg works. I installed cg.dll and cgGL.dll (downloaded them from http://toybox.150m.com/2003-05-02/cg_dlls.zip) and (as you can see above) DOOM 3 is happy about Cg. It did not change the overall behaviour. Bye, Uwe

Aug. 7, 2004

suse patch for wineprefixcreate

by Marcus Meissner

Hi, This is the patch I use at SUSE for wineprefixcreate. Mike wanted to see it ;) $dlldir/config is the sample config file with just minimal local suse changes. Ciao, Marcus Index: wineprefixcreate.in =================================================================== RCS file: /home/wine/wine/tools/wineprefixcreate.in,v retrieving revision 1.4 diff -u -r1.4 wineprefixcreate.in --- wineprefixcreate.in 14 May 2004 00:43:50 -0000 1.4 +++ wineprefixcreate.in 7 Aug 2004 12:40:57 -0000 @@ -86,8 +86,10 @@ if [ -d "$WINEPREFIX" ] || mkdir "$WINEPREFIX"; then : else - echo "Could not create $WINEPREFIX, aborting" - exit 1 +fi + +if [ ! -f "$WINEPREFIX/config" ]; then + cp $dlldir/config "$WINEPREFIX/config" fi WINEPREFIX=`cd "$WINEPREFIX" && pwd` @@ -124,6 +126,35 @@ [ -d "$i" ] || mkdir "$i" done +# Create the drive symlinks +if [ ! -d "$WINEPREFIX/dosdevices" ] +then + mkdir "$WINEPREFIX/dosdevices" + ln -s "../drive_c" "$WINEPREFIX/dosdevices/c:" + ln -s "/" "$WINEPREFIX/dosdevices/z:" + ln -s "/tmp" "$WINEPREFIX/dosdevices/x:" + if [ -d "$HOME" ]; then + ln -s "$HOME" "$WINEPREFIX/dosdevices/y:" + if [ ! -f "$HOME/.windows-label" ]; then + echo "HOME" > "$HOME/.windows-label" + fi + fi + # autodetect CD-ROMS on SUSE. + drive=D + for i in /media/* ; do + bn=`basename $i` + if [ "$i" = "/media/floppy" ]; then + ln -s /media/floppy "$WINEPREFIX/dosdevices/a:" + ln -s /dev/fd0 "$WINEPREFIX/dosdevices/a::" + fi + if echo $bn| grep -E -v "^(sd|usb-storage|floppy)" >/dev/null; then + ln -s /media/$bn "$WINEPREFIX/dosdevices/"`echo $drive|tr "[A-Z]" "[a-z]"`: + ln -s /dev/$bn "$WINEPREFIX/dosdevices/"`echo $drive|tr "[A-Z]" "[a-z]"`:: + drive=`echo $drive|tr "D-L" "E-M"` + fi + done +fi + # Create the application symlinks link_app()

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Vincent Béron

Le sam 07/08/2004 à 08:04, Mike Hearn a écrit : > Have I missed something here - I thought there was a native version of > DOOM 3 for Linux? The binaries are not yet available to my knowledge, although iD says they will be "soon after the game ships". So for people wanting to play it now, Wine is a better option than waiting. Plus it might prove to some people that Wine can be used with cutting-edge software, which is always good. Vincent

Aug. 7, 2004

msvideo 16bit codec question

by Mike Hearn

Hey Mike, I've been trying to make Maxis Marble Drop work in my non-connected spare time in the evenings, and the intro video doesn't render right. Examination of the code revealed that it had been patched to output pixel blocks in the right direction for the 8 bit decoder but the 16 bit decoder hadn't been modified. So, I copied across the changes to the 16 bit decoder as well, unfortunately it doesn't work. Something is going wrong, and the codec trashes the heap arena, so I'm guessing there's something in the maths that is different for 16 bit videos than 8 bit. Got any ideas? thanks -mike

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Mike Hearn

Have I missed something here - I thought there was a native version of DOOM 3 for Linux?

Aug. 7, 2004

Re: wine debugger

by Mike Hearn

Unfortunately since to the move to the dbghelp DLL winedbg has been rather unstable. One thing you can do is attach to the debugger with regular gdb, and when it crashes see if you can figure out what's going wrong. On Sun, 01 Aug 2004 17:10:42 +0200, Chipzz wrote: > Hi all, > > for some reason, the wine debugger just doesn't seem to work for me. > > wine: Unhandled exception (thread 000f), starting debugger... > fixme:console:SetConsoleCtrlHandler (0x405ae990,1) - no error checking or testing yet > WineDbg starting on pid 0xe > In 32 bit mode. > Wine-dbg>bt > Backtrace: > =>1 0x40107b08 __read+0x28 in libc.so.6 (0x40032c54) > 2 0x401cc022 > Exception c0000005 > > The backtrace it shows appears to be from the debugger itself, not from > the program? Or am I wrong in assuming this? I am getting this same > backtrace for each and every program... > Also, the ctrl-c key doesn't work as advertised (just does nothing). > > Wine is wine cvs from 07/31, gdb is 6.1-3 from debian unstable. > > Anyone got some pointers? > > kr, > > Chipzz AKA > Jan Van Buggenhout

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Shachar Shemesh

Ove Kaaven wrote: >>BTW, DOOM 3 crashes at program start in Cedega, you made it better! >> >> > >here's a howto from someone who did make it start with Cedega CVS: > >http://www.linux-militia.net/howtos/doom3/doom3.html > >Since there's some level of pbuffer support in Cedega, it might provide >better graphics. > > http://linux.israel.net/linuxgames/modules.php?name=News&file=article&sid=55 Translated into English: War games: Yes, it's true, Wine can run the new DOOM3 Several days ago I installed Mandrake 9.2 and was very impressed with Wine. This little program really does wonders. So i said to myself "it can run small Windows apps, but there is no way it can run Doom 3". I did this: cd /mnt/win_f/Doom3 and wrote "wine Doom3.exe", and what did my eyes see? Yes, it is Doom3 running on my computer!!! And with pretty nice graphics Linux should not be ashamed of, to boost! Only one little detail - the in games movies won't work. It probably has something to do with Windows' Direct X. So there you have it. I hope that it will work for you as it has for me!!!! There is also a screen shot there. So, if you want me to relay any questions to the user regarding how he did it? :-) -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Ove Kaaven

fre, 06.08.2004 kl. 23.58 skrev Lionel Ulmer: > > Couldn't find proc address for: wglSwapIntervalEXT > > I do not know any equivalent GLX extension for this. GLX_SGI_swap_control is almost equivalent, it just doesn't have a query function. It's probably not critical functionality though. > > Couldn't find proc address for: wglBindTexImageARB > > Couldn't find proc address for: wglReleaseTexImageARB > > Would need to study what these are for and if there is an equivalent GLX > extension. Sounds like WGL_ARB_render_texture. No GLX equivalent yet. It's possible to fall back to ordinary glCopyTexImage stuff, which I suspect the game should be smart enough to do if it can't find these. > > GL_ARB_texture_non_power_of_two not found > > What kind of NVIDIA card do you have ? Wine should report all extensions > reported by the Linux card to the Windows application. nvidia just doesn't seem to support this on the cards we have here either. They just have GL_NV_texture_rectangle. The game could probably fall back to this too if ARB_texture_non_power_of_two doesn't exist. > > Almost all computer terminals in the game show static black & white noise > > (instead of some animated computer screen image). > > I suppose this is where NP2 textures are used. No idea why the fallback dose > not work. Or perhaps where pbuffers are used. And since the original poster said: > BTW, DOOM 3 crashes at program start in Cedega, you made it better! here's a howto from someone who did make it start with Cedega CVS: http://www.linux-militia.net/howtos/doom3/doom3.html Since there's some level of pbuffer support in Cedega, it might provide better graphics.

Aug. 7, 2004

Re: DOOM 3 misses some opengl32 wgl* and Cg functions

by Lionel Ulmer

> Couldn't find proc address for: wglSwapIntervalEXT I do not know any equivalent GLX extension for this. > Couldn't find proc address for: wglGetPixelFormatAttribivARB > Couldn't find proc address for: wglGetPixelFormatAttribfvARB > Couldn't find proc address for: wglChoosePixelFormatARB > Couldn't find proc address for: wglCreatePbufferARB > Couldn't find proc address for: wglGetPbufferDCARB > Couldn't find proc address for: wglReleasePbufferDCARB > Couldn't find proc address for: wglDestroyPbufferARB > Couldn't find proc address for: wglQueryPbufferARB > Couldn't find proc address for: wglSetPbufferAttribARB This is part of one of my 'todo' project: adding support for PBuffers in the WineHQ tree (I once started to study both the GLX and WGL extension set to see how it could be done). Now that I know one 'high profile' application that needs them, maybe it will motivate me more :-) > Couldn't find proc address for: wglBindTexImageARB > Couldn't find proc address for: wglReleaseTexImageARB Would need to study what these are for and if there is an equivalent GLX extension. > GL_ARB_texture_non_power_of_two not found What kind of NVIDIA card do you have ? Wine should report all extensions reported by the Linux card to the Windows application. This means that if your card supports NP2 textures in Linux it should also in Windows. An output of the 'glxinfo' would be nice (see below). > GL_ATI_fragment_shader not found (this is expected, I have a nvidia card) > Cg not available. I would need to study if 'native' Cg works in Wine. > Almost all computer terminals in the game show static black & white noise > (instead of some animated computer screen image). I suppose this is where NP2 textures are used. No idea why the fallback dose not work. > I suspect, that this has something to do with the missing 'Cg' support in > Wine (DOOM3 cannot find cg.dll & cgGL.dll). Did you try to install the native versions using Wine (I have no idea how NVIDIA packages the Cg libraries though) ? Anyway, it would be nice to have a Bugzilla bug-report to track this (at least as long as the demo is not out so that I could debug it myself :-) ). What would be needed is the output of 'glxinfo' as said before and a +opengl log of the application (the terminal problem will be hard to track this way though). Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 6, 2004

DOOM 3 misses some opengl32 wgl* and Cg functions

by Dr. Uwe Girlich

Hello all! I just tested out DOOM 3 (no-cd-cracked version) with the current Wine (CVS from 1 hour ago) and found the following problems on the game console: Couldn't find proc address for: wglSwapIntervalEXT Couldn't find proc address for: wglGetPixelFormatAttribivARB Couldn't find proc address for: wglGetPixelFormatAttribfvARB Couldn't find proc address for: wglChoosePixelFormatARB Couldn't find proc address for: wglCreatePbufferARB Couldn't find proc address for: wglGetPbufferDCARB Couldn't find proc address for: wglReleasePbufferDCARB Couldn't find proc address for: wglDestroyPbufferARB Couldn't find proc address for: wglQueryPbufferARB Couldn't find proc address for: wglBindTexImageARB Couldn't find proc address for: wglReleaseTexImageARB Couldn't find proc address for: wglSetPbufferAttribARB GL_ARB_texture_non_power_of_two not found GL_ATI_fragment_shader not found (this is expected, I have a nvidia card) Cg not available. Are these wgl* function difficult to implement? Almost all computer terminals in the game show static black & white noise (instead of some animated computer screen image). I suspect, that this has something to do with the missing 'Cg' support in Wine (DOOM3 cannot find cg.dll & cgGL.dll). On the other hand, the rendering paths (r_renderer nv10, nv20, arb, and arb2) are all more or less working (besides the noise and the too bright lighting in nv10). BTW, DOOM 3 crashes at program start in Cedega, you made it better! Bye, Uwe

Aug. 6, 2004

Re: winedos: TSR (was MCB implementation)

by Alexandre Julliard

markus.amsler(a)oribi.org writes: > Now, what should happen, if you start a TSR programm in a win32 shell (like > wcmd,Reactos cmd.exe or Windows cmd.exe)? Spawn FreeCOM, implement TSR somehow > in win32 (shell or ntdll) or no TSR support in win32 shells? No, TSR support doesn't make sense in Win32. What do you need it for? -- Alexandre Julliard julliard(a)winehq.org

Aug. 6, 2004

Re: Do more tests in non-interactive mode (resubmit)

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > This way we exercise almost as much of the API as in interactive mode > without disturbing users, and the tests still run fast. The slowest one > is the winmm test which takes 16 seconds on my machine which supports > all the tested sound formats (but has only one sound card). Given that > winetest's timeout is two minutes this gives a wide margin. The capture test takes about 80 seconds here with the ALSA driver, which is a bit long. It also fails with the OSS driver: capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=512, should be 800 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags capture.c:130: Test failed: frag.dwBytesRecorded=1024, should be 1600 capture.c:128: Test failed: WaitForSingleObject failed for header capture.c:129: Test failed: WHDR_DONE not set in frag.dwFlags etc. Also the wave test makes a lot of noise here, both with ALSA and OSS drivers. -- Alexandre Julliard julliard(a)winehq.org

Aug. 6, 2004

FW: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier

by Krishna Murthy

Alexandre, I am resending this patch. There exists a defect 2388. Also confirmed that it fixes one of the Katia's defect found. Please let us know about your thoughts. Thanks, Krishna -----Original Message----- From: Krishna Murthy Sent: Tuesday, June 22, 2004 2:56 PM To: 'Alexandre Julliard'; Krishna Murthy Cc: wine-devel(a)winehq.org Subject: RE: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Alexandre, Please find attached modified patch. The method DEFDLG_SetDefButton() now accepts the BOOL bSetDefID parameter to adapt for both DM_SETDEFID and WM_NEXTDLGCTL. Thanks, Krishna -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Friday, June 18, 2004 10:30 AM To: Krishna Murthy Cc: wine-devel(a)winehq.org Subject: Re: FW: WM_NEXTDLGCTL changes the default button ID and does not rest ore default control identifier Krishna Murthy <Krishna.Murthy(a)guptaworldwide.com> writes: > No, it is required. The DEFDLG_SetDefButton() is also called from > message DM_SETDEFID. In this case idResult should set to the default > button ID passed. And the current logic of DEFDLG_SetDefButton() does > what is required for DM_SETDEFID. Well, of course you'd need to adapt the DM_SETDEFID handling to the change. I think that's better than sending duplicate messages. -- Alexandre Julliard julliard(a)winehq.org

Aug. 6, 2004