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

Re: wglMakeCurrent

by Wino Rojo

Hi Raphael, >No it's use the "best visual" who match asked capacities - is this "best visual" the same as the one returned by "glxinfo -b" ? - the capacities asked by who? at this point we haven't call ChoosePixelFormat or SetPixelFormat yet >No your problem don't seems to be here. >can you send you glxinfo output. I presume you don't have glx1.3 support >In this case wine don't be able to get a fb config compatible with wine >window >(one day we'll fix the wine init ...) > This is the output of my 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, GLX_ARB_fbconfig_float 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_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float 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_fbconfig_float, GLX_ARB_get_proc_address OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: NV41/PCI/SSE2/3DNOW! OpenGL version string: 2.0.0 NVIDIA 76.76 OpenGL extensions: GL_ARB_color_buffer_float, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_half_float_pixel, 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_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, 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_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 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_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_mirror_clamp, 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_fragment_program2, 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_NV_vertex_program3, GL_NVX_conditional_render, 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 4 24 8 16 16 16 16 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x23 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x26 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x27 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x2a 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x2b 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x2c 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x2d 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x2e 24 tc 0 32 0 r y . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x2f 24 tc 0 32 0 r y . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x30 24 tc 0 32 0 r . . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x31 24 tc 0 32 0 r . . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x32 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x33 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x34 24 tc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x35 24 tc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x36 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x37 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x38 24 tc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x39 24 tc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x3a 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x3b 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x3c 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x3d 24 tc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x3e 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x3f 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x40 24 tc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x41 24 tc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x42 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x43 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x44 24 tc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x45 24 tc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon 0x46 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x47 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x48 24 tc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x49 24 tc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon 0x4a 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x4b 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 0 0 None 0x4c 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 0 0 None 0x4d 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x4e 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x4f 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 0 0 None 0x50 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 0 0 None 0x51 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x52 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x53 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 0 0 None 0x54 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 0 0 None 0x55 24 dc 0 32 0 r y . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x56 24 dc 0 32 0 r y . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x57 24 dc 0 32 0 r . . 8 8 8 0 4 0 0 16 16 16 16 0 0 None 0x58 24 dc 0 32 0 r . . 8 8 8 8 4 0 0 16 16 16 16 0 0 None 0x59 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x5a 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x5b 24 dc 0 32 0 r y . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x5c 24 dc 0 32 0 r y . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x5d 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 2 1 Ncon 0x5e 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 2 1 Ncon 0x5f 24 dc 0 32 0 r . . 8 8 8 0 4 24 0 16 16 16 16 4 1 Ncon 0x60 24 dc 0 32 0 r . . 8 8 8 8 4 24 0 16 16 16 16 4 1 Ncon 0x61 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x62 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x63 24 dc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x64 24 dc 0 32 0 r y . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x65 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 2 1 Ncon 0x66 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 2 1 Ncon 0x67 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon 0x68 24 dc 0 32 0 r . . 8 8 8 8 4 24 8 16 16 16 16 4 1 Ncon 0x69 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x6a 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x6b 24 dc 0 32 0 r y . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x6c 24 dc 0 32 0 r y . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon 0x6d 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 2 1 Ncon 0x6e 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 2 1 Ncon 0x6f 24 dc 0 32 0 r . . 8 8 8 0 4 16 0 16 16 16 16 4 1 Ncon 0x70 24 dc 0 32 0 r . . 8 8 8 8 4 16 0 16 16 16 16 4 1 Ncon According to this, I do have glx 1.3 Thanks, W. PS. Guys, I'm sorry if I'm asking too many basic questions. I know about OpenGL and some X-Window programming, but I'm just learning wine, and I'd like to contribute to this amazing project, especially with the OpenGL/3D graphics stuff. _________________________________________________________________ Scan and help eliminate destructive viruses from your inbound and outbound e-mail and attachments. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 16, 2006

Re: [RESEND] riched20: Fixed crash when the window procedure is called with NULL hWnd

by Alexandre Julliard

Phil Krylov <phil(a)newstar.rinet.ru> writes: > > ChangeLog: > > riched20: Fixed crash when the window procedure is called with NULL hWnd. You should check that you got a valid pointer from GetWindowLong, NULL is not the only invalid window handle you can get here. -- Alexandre Julliard julliard(a)winehq.org

March 16, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Tony Lambregts

Philip V. Neves wrote: > What I'm seeing here with the whole debate with wine and winetools is > that its a configuration management issue. The project is getting into > the stage where testing needs to be accomodated and so does getting > things working. I think whats currently available for managing > configurations to wine is innadequate. Even winecfg provides an > interface that is innadequate for making many changes in terms of dll > overrides. Plus it doesn't provide a mechanism for rolling those > changes back. Or even managing multiple configurations or modes so that > problems can be issolated. I think whats is comming out of the > winetools debate is better tools are needed for configuration > management. This isn't very revolutionary. Its a natural part of the > software development life cycle. As a project starts emerging from the > development phase ways to provide better configuration management start > showing themselves. > > Something that interfaces with the AppDB would be good. It would make > things easier. I think, given the complaints given by the developers are > also valid but so are the complaints made by the people trying to use > the program and even the testers. Most other projects don't need such > tools but this one does given what its trying to accomplish and the > complexity of whats being accomplished. Besides even windows XP has a > roll back feature now to fix problems. Why doesn't wine considering its > attempting a bug for bug compatibility with windows. This would be a > wise thing to implement just for sanities sake. > [Snip] > Something that allows the AppDB maintainers to distribute tweeks to > the configuration changes in the AppDB to users. So that even if we > aren't installing the programs on the system. The tweeks can still be > made on the fly. This would eliminate having to blow away the .wine > directory all the time. Blowing away the .wine directory is not a > desirable. A way for wine developers to distribute a test configuration > would also be a useful thing. That way we can test the software with > what the developers want us to test rather then shooting in the dark > only to see that the bug we reported is the same as some other bug we > reported. > > Such tools would be useful in debugging the entire framework and speed > up development. These are suggestions. I hope they help a bit. > I grudgingly have to agree that winecfg is at least partly inadequate. One of the things it is lacking is an export and and import function. I do not know how many times I have "blown away" my .wine directory. It would certainly save me some time if I could export the settings for a program and import them later. If we had the ability to import and export the settings for a program then it would also be possible for someone to upload that file somewhere (lets say the AppDB) and someone else could download it and use the same settings. The one problem that I can see with this is in the DLL overrides section. That is: if the import file contains a DLL override and the person does not have that dll installed we have a problem. Probably the best idea would be to search in the windows directories and warn the user if it could not find that file. Of course this does not address actually getting these dlls which is part of what WineTools does. Tony Lambregts

March 16, 2006

build stand alone binaries

by Benjamin Zeller

Hi there, is it possible to build real elf binaries with winelib? If i go through the tutorial on winehq.org i get only a appname.exe.so and i have to invoke wine to start the application. Is it possible to compile a binary wich can run stand alone? (Sorry for maybe posting this message twice i had some trouble with my email programm) regards benjamin z.

March 16, 2006

build stand alone binaries

by Benjamin Zeller

Hi there, is it possible to build real elf binaries with winelib? If i go through the tutorial on winehq.org i get only a appname.exe.so and i have to invoke wine to start the application. Is it possible to compile a binary wich can run stand alone? regards benjamin z.

March 16, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Leon Freitag

> I don't see any other way to speed this up the way it's being synced now, the > question is however, whether the apps really _should_ modify the bitmap on > windows too (don't know whether they would try to draw controls onto the > window and then it would be overdrawn by the opengl image; application like > Steam are trying to achieve similar, but they seemed to work well before) > Does this very rough&ready patch work any better? I'm getting undefined references to `___tls_get_addr' when trying to build with this patch. However my ld has this symbol for sure... $ nm /lib/ld-2.3.5.so | grep __tls_get_addr 0000dfc0 T ___tls_get_addr 0000d9d0 T __tls_get_addr 0000dfc0 t ___tls_get_addr_internal > If this patch improves performance I'll fix it to use Win32 TLS instead > of ELF TLS, it'll be interesting to see if that changes makes a > difference too. perhaps it will compile on my machine then... Leon

March 16, 2006

Re: May be a bad idea to have Winetools in the next SUSE release

by Joachim von Thadden

Am Fri, Mar 10, 2006 at 12:55:20AM +0100 schrieb Sven Paschukat: > Marcus Meissner schrieb: > >Hmm, I have some kind of recommendation here. > > > >What about winetools using ".winetools" as WINEPREFIX setting? > > > >This would make it possible to keep a ".wine" for the purists, and > >".winetools" for the "just get things done" people. > > > >Up to now winetools does not seem to honor a WINEPREFIX setting > >(also a bug I think). > > > >Ciao, Marcus > > Hey, you steal Joachim's ideas ;-) > > That's one point we have discussed in similar form. One directory for > the present winetools mode and another for a new builtin mode where > winetools just acts as a menu driven loader and installer. Sorry for the delay: I have been on CeBIT computer fair. To come to an end with that: Sven and I are doing the following for WineTools at the moment: - change WineTools to use WINEPREFIX - using a standard WINEPREFIX="$HOME/.winetools" if not set otherwise - change * to builtin,native - change version to WinXP - run as many apps as possible without tweaking The last one is the annoying one as it needs many testing *and* I know of no way to say "do not use the default" in winecfg or the registry. If there is a way, please mail me. I think using the AppDB for getting install and execution infos for programs is very hard to accomplish. We were already thinking about a way to send data of successful installations or executions automatically into a DB but dropped that. It would be very nice to have but it has to be - repeated for every version of wine - checked for correctness - if there are competing entries they have to be manually resolved - probably many other problems Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 16, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Joachim von Thadden

Am Thu, Mar 16, 2006 at 10:48:06AM +0900 schrieb Mike McCormack: > > Philip V. Neves wrote: > > >Something that interfaces with the AppDB would be good. It would make > >things easier. I think, given the complaints given by the developers are > >also valid but so are the complaints made by the people trying to use > >the program and even the testers. Most other projects don't need such > >tools but this one does given what its trying to accomplish and the > >complexity of whats being accomplished. Besides even windows XP has a > >roll back feature now to fix problems. Why doesn't wine considering its > >attempting a bug for bug compatibility with windows. This would be a > >wise thing to implement just for sanities sake. > > IMO, the best thing for Wine would be to have a simple front end with a > list of freely downloadable applications that work "out of the box" with > no configuration changes. > > Click -> Download application -> Install -> Run This is exactly what we try to have with the next version of WineTools. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 16, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Mike McCormack

Philip V. Neves wrote: > Something that interfaces with the AppDB would be good. It would make > things easier. I think, given the complaints given by the developers are > also valid but so are the complaints made by the people trying to use > the program and even the testers. Most other projects don't need such > tools but this one does given what its trying to accomplish and the > complexity of whats being accomplished. Besides even windows XP has a > roll back feature now to fix problems. Why doesn't wine considering its > attempting a bug for bug compatibility with windows. This would be a > wise thing to implement just for sanities sake. IMO, the best thing for Wine would be to have a simple front end with a list of freely downloadable applications that work "out of the box" with no configuration changes. Click -> Download application -> Install -> Run This would make it easy to for users to get applications working, find and report regressions, and fully test Wine, and would fully support developers in our quest to build a fully free environment for running Windows applications. Mike

March 16, 2006

Yet Another MS Windows API Emulation - SanOS, an small OS

by agaro

I don't know if somebody already found this, but may be relevant to wine-devel comunity (google don't found nothing about in this list): http://www.jbox.dk/sanos/ And the code (I haven't really looked much there): http://www.jbox.dk/sanos/source/index.html The code is released under an "BSD style" license. The win32 exception handling implementation is based on Wine code: http://www.jbox.dk/sanos/contributions.htm []s Augusto Arcoverde da Rocha

March 16, 2006

re: More dogfood tests

by Dan Kegel

> I have found very few problems, mainly just images being color-reversed, > and only on PNG of certain types. That sounds like the .gif bug here: http://bugs.winehq.org/show_bug.cgi?id=4529 Can you give the URL of one of the busted PNG's? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 16, 2006

More dogfood tests

by Segin

I have also started using Firefox in Wine for everything, namely because native lost a lib, old mozilla and opera and native firefox cause X to malloc() like mad (pkill -9 the broswer to cause X to free() ). I have found very few problems, mainly just images being color-reversed, and only on PNG of certain types. Also, Wine is MUCH faster if you have NPTL as your only threading method in glibc. (think a 15x improvement in speed here...) Wine also seems to know about the XDND X extension, cause it knows what GTK+2 widgets can be dragged and dropped onto, but otherwise the actual drag-and-drop procedure is a null effect. Ahh to hell with it, let's get to the speed tests. time wine firefox.exe, cold cache: real 0m48.895s (about 45s, really) user 0m4.116s sys 0m1.589s hot cache: real 0m9.287s (about 7.5s, really) user 0m3.966s sys 0m1.026s (Please note that the "real" time is off by about 1-2 seconds, to allow for me to quit Firefox.) Here we do the 7-Zip File Manager. Errors: err:listview:LISTVIEW_WindowProc unknown msg 2005 wp=00000001 lp=00000000 err:rebar:REBAR_AdjustBands Phase 1 failed, x=1000, maxx=-4, start=1, end=1 time wine 7zFM.exe, cold cache: real 0m34.815s (about 30s) user 0m1.044s sys 0m0.672s and with a hot cache: real 0m5.105s (about 4s, actually) user 0m0.997s sys 0m0.378s And now we do PuTTY: (no errors) Cold cache: real 0m39.382s (37s) user 0m1.023s sys 0m0.868s Hot cache: real 0m3.170s (no ajustment) user 0m0.978s sys 0m0.395s On a normal Windows system, the cache is always hot (all the core DLLs are always loaded), so the hot cache times actually rival a real Windows system, especially the one for PuTTY (which beats every test on a real Windows box I have done except those on more powerful hardware)

March 16, 2006

Re: wglMakeCurrent

by Raphael

Sorry for my late response but i haven't much time now > I'm not familiar at all with wine, so I'm not sure how we should fix this > (but it seems this would fix a lot of opengl related problems) > > When we first call X11DRV_setup_opengl_visual, I guess it's using the first > visual ID. No it's use the "best visual" who match asked capacities > But later, when we create a pixelformat descriptor, maybe we > should select a better visual (one equal or similar to the description > given in pixelformat), so when we later call wlgMakeCurrent, both visuals > will be the same No your problem don't seems to be here. can you send you glxinfo output. I presume you don't have glx1.3 support In this case wine don't be able to get a fb config compatible with wine window (one day we'll fix the wine init ...) Regards, Raphael

March 16, 2006

Re: Francois Gouget : user32: Handle WM_ENDSESSION in DefWinProc().

by James E. Lang

Francois Gouget wrote at 0:06 on 12 Mar 2006: > Rein Klazes wrote: > [...] > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > > cause termination of the complete program. [...] I see that this is still a problem in 0.9.10 so I've fallen back again to 0.9.8. -- Jim

March 16, 2006

Re: Vista compatibility page

by Stefan Dösinger

> I mean .... 5 years! FIVE YEARS! And this is what they have to show for > it? A bunch of .NET APIs that they intend to backport to XP, and which > require a runtime nobody seems to be using for desktop apps anyway. An > improved file protection hack. Some improved security, and a display > rewrite equivalent to what David Reveman was able to produce on his own > in only 2 years? Not to forget the Digital Rights Management stuff. But thats definitly something I don't want. Improved security with a lot of "backdoors" for Windows Installer to stay user-friedly. It doesn't look like Vista will enlarge Wines ToDo list noticeable ;)

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

>See if you can tell from my log: >http://www.chez.com/alors/logfile > Jesse, I can't access your log at that page (I got an error). Could you please send it to me? Thanks, W _________________________________________________________________ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 15, 2006

My two cents about winetools and the suggestions I read in Issue 308

by Philip V. Neves

What I'm seeing here with the whole debate with wine and winetools is that its a configuration management issue. The project is getting into the stage where testing needs to be accomodated and so does getting things working. I think whats currently available for managing configurations to wine is innadequate. Even winecfg provides an interface that is innadequate for making many changes in terms of dll overrides. Plus it doesn't provide a mechanism for rolling those changes back. Or even managing multiple configurations or modes so that problems can be issolated. I think whats is comming out of the winetools debate is better tools are needed for configuration management. This isn't very revolutionary. Its a natural part of the software development life cycle. As a project starts emerging from the development phase ways to provide better configuration management start showing themselves. Something that interfaces with the AppDB would be good. It would make things easier. I think, given the complaints given by the developers are also valid but so are the complaints made by the people trying to use the program and even the testers. Most other projects don't need such tools but this one does given what its trying to accomplish and the complexity of whats being accomplished. Besides even windows XP has a roll back feature now to fix problems. Why doesn't wine considering its attempting a bug for bug compatibility with windows. This would be a wise thing to implement just for sanities sake. So I'd like to provide an addition to Jason Greens brain dump * AppDB would have to be extended to be able to get and report this data, and it would make sense for each App's maintainer to be able to manage that information. * Biggest issue here is that this information could have a tendency to change very rapidly, so it might overload the app maintainers if they had to track this for each version of wine. What I think would make sense is to have regular snapshots (every 3 months?) and release a new version of "Winetools Plus" or whatever you want to call this thing a month later to give the maintainers time to update each of their apps based on the frozen version. (I think multiple versions of the AppDB would be useful. Similar to the Release and Release candidate type way of doing things.) * Data needed: AppID, AppVersionID, WineVersionID, Window Version, DLL Overrides, Window settings (fullscreen/windowed - sometimes and issue), Sound options, Video acceleration required, General notes or HOWTO's, etc. You would need separate overrides/settings for Installing vs. Running the app. * AppDB could dump this information to an xml format which "Winetools Plus" could be distributed with. Maybe have an option to download the latest xml file directly from winehq.org. * The 'Winetools Plus' front-end would just be a menu which would query all of the apps in the xml dump. The user picks they app they want to install, and it reads the necessary information, verifies the source installation media, and goes at it. * Applying patches to apps might get tricky (e.g., where wine only successfully runs version 1.5 of the app, but 1.0 is on the CD), but I'm sure it could be worked out. * A Way to roll back DLL overrides. * A Way store roll multiple registry configurations so that we establish a base reference configuration and a test configuration. Or even multiple test configurations. * An AppDB tool that allows changes to the DLL configuration in the AppDB to be made easily. * A way to detect the version of wine and provide configuration changes given that version of wine. * A way to report bugs to the appDB maintainers about configuration problems. A nice to have would be Something that allows the AppDB maintainers to distribute tweeks to the configuration changes in the AppDB to users. So that even if we aren't installing the programs on the system. The tweeks can still be made on the fly. This would eliminate having to blow away the .wine directory all the time. Blowing away the .wine directory is not a desirable. A way for wine developers to distribute a test configuration would also be a useful thing. That way we can test the software with what the developers want us to test rather then shooting in the dark only to see that the bug we reported is the same as some other bug we reported. Such tools would be useful in debugging the entire framework and speed up development. These are suggestions. I hope they help a bit.

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

so, in your system the default visual ID is 0x28, and later my app create contexts with visual ID 0x23 but everything works fine for you... ok, back to square one :-( _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 15, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/15/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Ok, so now we know what's is going on here :-) > > I'm not familiar at all with wine, so I'm not sure how we should fix this > (but it seems this would fix a lot of opengl related problems) > > When we first call X11DRV_setup_opengl_visual, I guess it's using the first > visual ID. Hold on, the log shows it picking another in your test program: trace:opengl:X11DRV_setup_opengl_visual Visual ID 28 Chosen >From glxinfo: 0x23 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None > But later, when we create a pixelformat descriptor, > maybe we > should select a better visual (one equal or similar to the description given > in pixelformat), so when we later call wlgMakeCurrent, both visuals will be > the same > > I hope this makes sense... > > Cheers, > > Wino > See if you can tell from my log: http://www.chez.com/alors/logfile Someone that knows wgl want to comment? Jesse

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

Ok, so now we know what's is going on here :-) I'm not familiar at all with wine, so I'm not sure how we should fix this (but it seems this would fix a lot of opengl related problems) When we first call X11DRV_setup_opengl_visual, I guess it's using the first visual ID. But later, when we create a pixelformat descriptor, maybe we should select a better visual (one equal or similar to the description given in pixelformat), so when we later call wlgMakeCurrent, both visuals will be the same I hope this makes sense... Cheers, Wino _________________________________________________________________ Don't just Search. Find! http://search.sympatico.msn.ca/default.aspx The new MSN Search! Check it out!

March 15, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/15/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Hi Jesse, > > That's very interesting... Yes, I'm using a nvidia card. I think I know the > reason why is working for you but not for me > > glxinfo tells me that my first visual ID is 0x21. However, on some ATI cards > glxinfo reports 0x23 as the first visual, which is the same visual ID of the > contexts I create. > > So maybe my program works fine for you because, just by coincidence, the > visual ID of my contexts are the same as the first visual ID reported by > X-Window > > Please, let me know the first visual ID reported by glxinfo is 0x23 in your > system. This will confirm my theroy :-) > > Thanks, > > Wino > Yes, you are correct that 0x23 is the first one.

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

Hi Jesse, That's very interesting... Yes, I'm using a nvidia card. I think I know the reason why is working for you but not for me glxinfo tells me that my first visual ID is 0x21. However, on some ATI cards glxinfo reports 0x23 as the first visual, which is the same visual ID of the contexts I create. So maybe my program works fine for you because, just by coincidence, the visual ID of my contexts are the same as the first visual ID reported by X-Window Please, let me know the first visual ID reported by glxinfo is 0x23 in your system. This will confirm my theroy :-) Thanks, Wino _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 15, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/15/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Hi guys > > I send a reply to the list a couple of days ago, but I attached my exe file > and it seems it was blocked but hotmail... > > First, thanks a lot for all your replies... Jesse, I've made the changes > proposed in those patches, but it didn't work :-( > > After further inspection, it seems the problem is when I call wglMakeCurrent > for a context which shares display lists with another context. I've attached > the program and the source code, so you can try it. > > > As I said, this program works just fine in Windows, so we must be doing > something differente in wine > > Any ideas/hints? > > Thanks > > Hi I tried your test program. I have the same results as with War3. Your program worked for me. I can't reproduce the same problem using DRI (Radeon 9200). So there is something specific about your configuration. I think you are using an nvidia card. Anyways, those patches didn't work either so 4604 is likely not a duplicate of 4143. Jesse

March 15, 2006

Re: ie6sp1 install failure

by James Hawkins

On 3/15/06, Samium Gromoff <_deepfire(a)mail.ru> wrote: > I tried to install IE6SP1 under wine 0.9.9, in order to allow .NET > framework to be installed, and it failed like this: > I'll look into this soon. I'm on vacation right now though. -- James Hawkins

March 15, 2006

Re: wglMakeCurrent

by Wino Rojo

Hi guys I send a reply to the list a couple of days ago, but I attached my exe file and it seems it was blocked but hotmail... First, thanks a lot for all your replies... Jesse, I've made the changes proposed in those patches, but it didn't work :-( After further inspection, it seems the problem is when I call wglMakeCurrent for a context which shares display lists with another context. I've attached the program and the source code, so you can try it. This is the output of the trace+opengl: trace:opengl:has_opengl GLX is up and running error_base = 77 trace:opengl:X11DRV_setup_opengl_visual Visual ID 21 Chosen trace:opengl:X11DRV_ChoosePixelFormat (0x403a28a8,0x406afdac) trace:opengl:dump_PIXELFORMATDESCRIPTOR - size / version : 40 / 1 trace:opengl:dump_PIXELFORMATDESCRIPTOR - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL trace:opengl:dump_PIXELFORMATDESCRIPTOR - iPixelType : PFD_TYPE_RGBA trace:opengl:dump_PIXELFORMATDESCRIPTOR - Color : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Red : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Green : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Blue : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Alpha : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Accum : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Depth : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Stencil : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Aux : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - iLayerType : PFD_MAIN_PLANE trace:opengl:X11DRV_SetPixelFormat (0x403a28a8,3,0x406afdac) trace:opengl:X11DRV_SetPixelFormat FBConfig have : trace:opengl:X11DRV_SetPixelFormat - FBCONFIG_ID 0x73 trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 trace:opengl:X11DRV_SetPixelFormat - DRAWABLE_TYPE 0x7 trace:opengl:X11DRV_GetPixelFormat (0x403a28a8): returns 3 trace:opengl:wglCreateContext (0x1cc)->(PF:3) trace:opengl:wglCreateContext creating context 0x403a2a40 (GL context creation delayed) trace:opengl:X11DRV_ChoosePixelFormat (0x403a2cc0,0x406afdac) trace:opengl:dump_PIXELFORMATDESCRIPTOR - size / version : 40 / 1 trace:opengl:dump_PIXELFORMATDESCRIPTOR - dwFlags : PFD_DOUBLEBUFFER PFD_DRAW_TO_WINDOW PFD_SUPPORT_OPENGL trace:opengl:dump_PIXELFORMATDESCRIPTOR - iPixelType : PFD_TYPE_RGBA trace:opengl:dump_PIXELFORMATDESCRIPTOR - Color : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Red : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Green : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Blue : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Alpha : 8 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Accum : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Depth : 24 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Stencil : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - Aux : 0 trace:opengl:dump_PIXELFORMATDESCRIPTOR - iLayerType : PFD_MAIN_PLANE trace:opengl:X11DRV_SetPixelFormat (0x403a2cc0,3,0x406afdac) trace:opengl:X11DRV_SetPixelFormat FBConfig have : trace:opengl:X11DRV_SetPixelFormat - FBCONFIG_ID 0x73 trace:opengl:X11DRV_SetPixelFormat - VISUAL_ID 0x23 trace:opengl:X11DRV_SetPixelFormat - DRAWABLE_TYPE 0x7 trace:opengl:X11DRV_GetPixelFormat (0x403a2cc0): returns 3 trace:opengl:wglCreateContext (0x1dc)->(PF:3) trace:opengl:wglCreateContext creating context 0x403a2e58 (GL context creation delayed) trace:opengl:wglShareLists (0x403a2a40, 0x403a2e58) trace:opengl:describeContext Context 0x403a2a40 have (vis:0x7c1782d0): trace:opengl:describeContext - FBCONFIG_ID 0x73 trace:opengl:describeContext - VISUAL_ID 0x23 trace:opengl:wglShareLists created a delayed OpenGL context (0x7c190318) for Wine context 0x403a2a40 trace:opengl:describeContext Context 0x403a2e58 have (vis:0x7c18a4d0): trace:opengl:describeContext - FBCONFIG_ID 0x73 trace:opengl:describeContext - VISUAL_ID 0x23 trace:opengl:wglShareLists created a delayed OpenGL context (0x7c1b1590) for Wine context 0x403a2e58 sharing lists with OpenGL ctx 0x7c190318 trace:opengl:wglGetCurrentDC () trace:opengl:wglGetCurrentDC no Wine context found for GLX context 0x7c096448 trace:opengl:wglGetCurrentContext () trace:opengl:wglGetCurrentContext returning (nil) (GL context 0x7c096448) trace:opengl:wglMakeCurrent (0x1dc,0x403a2e58) trace:opengl:wglMakeCurrent make current for dis 0x7c0657f0, drawable 0x3800002, ctx 0x7c1b1590 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 144 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 120 Current serial number in output stream: 120 My guess is that when we call wglMakeCurrent for the context with the shared lists, it has a VISUAL_ID of 0x23, but X11DRV_setup_opengl_visual chosed a Visual ID of 0x21, and hence the BadMatch error. As I said, this program works just fine in Windows, so we must be doing something differente in wine Any ideas/hints? Thanks _________________________________________________________________ Don't just Search. Find! http://search.sympatico.msn.ca/default.aspx The new MSN Search! Check it out!

March 15, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Alex Villacís Lasso

Robert Shearman wrote: > > The fix is to do the following in the conversion loop in > ITypeInfo::Invoke: > if (rgvt[i] == VT_VARIANT) > VariantCopy(&rgvarg[i], src_arg); > else if ((rgvt[i] & VT_BYREF) && !V_ISBYREF(src_arg)) > ... > > I don't have time to put this into patch form and test it, but > hopefully someone else will. > I tried this on the test app. It did not work. Sure, the code reaches the DispCallFunc call, but then the actual code from inside the control fails the call. It seems that the type of the variant is not adequate for the parameter. Visual Basic shows a message: "Application-defined or user defined error". It seems that I will have to wait until I code enough of a test case for a *successful* ITypeInfo::Invoke() (there are two tests of failing calls, but none of a successful one), so that I can see what native OLEAUT32.DLL is sending as the parameter. Unless somebody else beats me on this. Alex Villacís Lasso

March 15, 2006

Re: Vista compatibility page

by Mike Hearn

On Wed, 2006-03-15 at 09:24 +0100, Andreas Mohr wrote: > Not to mention that they're handing a near-fatal blow to OpenGL support, too. Maybe ... last I heard, word on the street was that vendors had found a way to write an Aero compatible ICD, so potentially nothing will change. If nothing else, it's not like video makers will just delete all their GL code the day Vista is released (whenever that is). They still have to support XP, and anyway Vista has been looking like a dead duck for a long time now. I mean .... 5 years! FIVE YEARS! And this is what they have to show for it? A bunch of .NET APIs that they intend to backport to XP, and which require a runtime nobody seems to be using for desktop apps anyway. An improved file protection hack. Some improved security, and a display rewrite equivalent to what David Reveman was able to produce on his own in only 2 years? I don't think Vista is going to be dealing near-fatal blows to anything anytime soon ...

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Mike Hearn

On Wed, 2006-03-15 at 14:01 +0000, Huw D M Davies wrote: > Sorry, maybe I should read the patch properly before commenting :-) I > assumed that you were setting need_escape to FALSE after sending the > escape, but you're not. Indeed it would be interesting to know if > this helped. Heh, you had me a bit worried for a second there! Indeed I do not know what the original patch does or why it's needed, but the slowdown just seems related to looking up the Wine_GLContext and testing it. If this patch improves performance I'll fix it to use Win32 TLS instead of ELF TLS, it'll be interesting to see if that changes makes a difference too.

March 15, 2006

Re: GDI32: Fix logical error of italic,bold determination

by Huw D M Davies

On Mon, Mar 13, 2006 at 04:10:04AM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Fix the logical error of the italic, bold determination. > > Index: dlls/gdi/freetype.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/freetype.c,v > retrieving revision 1.114 > diff -u -u -r1.114 freetype.c > --- dlls/gdi/freetype.c 9 Mar 2006 12:30:52 -0000 1.114 > +++ dlls/gdi/freetype.c 12 Mar 2006 10:01:22 -0000 > + for(i = 0; !face && i < 4; ++i) { > best = NULL; > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > face = LIST_ENTRY(face_elem_ptr, Face, entry); > - if((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0]) { > + if((!(face->Italic ^ it) ^ ((i >> 1) & 1)) && (!(face->Bold ^ bd) ^ (i & 1)) && > + ((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0])) { It doesn't seem right to compare these with 'i', the order of the faces is random. The right way to do this is to rewrite all this font matching code so that we loop through the families and faces once and score each one. At the end we pick the one with the lowest score. Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: WIDL: Add missing ignore attribute. Check for inapplicable attributes in typedef. (more better patch)

by Mike McCormack

Saveliy Tretiakov wrote: > +typedef: tTYPEDEF m_attributes type pident_list { > + attr_t *a = $2; > + int public = 0; > + while(a){ > + switch(a->type) > + { > + case ATTR_CONTEXTHANDLE: > + case ATTR_STRING: > + case ATTR_HANDLE: > + case ATTR_SWITCHTYPE: > + case ATTR_TRANSMITAS: > + case ATTR_POINTERTYPE: > + case ATTR_IGNORE: > + break; > + case ATTR_PUBLIC: > + public = 1; > + break; > + default: > + yyerror("Inapplicable attribute\n"); How about changing the grammar to define something like: attributes: td_attribs | tCONTEXTHANDLE | tSTRING | ... /* other things that can't be a typedef */ ; td_attribs: tAGGREGATABLE | ... /* other things in the existing attributes rule */ ; typedef: tTYPEDEF td_attribs type pident_list .... That way the parser can deal with the problem. Mike

March 15, 2006

Re: ie6sp1 install failure

by Mike McCormack

Samium Gromoff wrote: > I tried to install IE6SP1 under wine 0.9.9, in order to allow .NET > framework to be installed, and it failed like this: Please post this kind of thing to wine-users, not wine-devel. IE6 is known to work in Wine with the correct configuration. Mike

March 15, 2006

Re: GDI32: using the embeded bitmap in antialias mode

by Huw D M Davies

On Mon, Mar 13, 2006 at 04:10:20AM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Using the embeded bitmap in the antialias mode. > > > PS2. FT_Bitmap_Convert() is simple, but I used it. > "ftbitmap.h" is define FT_Bitmap_Embolden(), and I will use it in the > furure. Looks like FT_Bitmap_Convert is a relatively new function - I don't have it in fc4. You're going to need to provide a fallback or simply ignore it completely and code it yourself. Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: ntdll: test to get and set junctions

by Mike McCormack

I don't have alot of time to look over your code at the moment, but: tkho(a)ucla.edu wrote: > dlls/ntdll/tests/Makefile.in | 1 > dlls/ntdll/tests/file.c | 165 +++++++++++++++++++++++++++++++++++++++++++ > dlls/ntdll/tests/ntifs.h | 66 +++++++++++++++++ This is one patch, and you should roll ntifs.h into file.c > include/ntifs.h | 63 ++++++++++++++++ This should be a separate patch, and it may be better to put it in the include/ddk directory, since it doesn't seem to exist in the Windows SDK. > include/winnt.h | 4 + This is another separate patch, which should be easy enough to get accepted on its own. Mike

March 15, 2006

Re: GDI32: Using the FT_Sfnt_Name for font FamilyName

by Huw D M Davies

On Mon, Mar 13, 2006 at 04:10:36AM +0900, Byeong-Sik Jeon wrote: > ChangeLog: > Using the FT_Sfnt_Name for font FamilyName Hi, This one could be broken down too. Start off with a patch that moves FontSubst to using the struct list stuff. Then try sending a patch that uses FT_Sfnt_Name. Thanks, Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: WIDL: Add missing ignore attribute. Check for inapplicable attributes in typedef.

by Robert Shearman

Saveliy Tretiakov wrote: > Sorry, previous patch was broken. > > ChangeLog: > Saveliy Tretiakov <saveliyt(a)mail.ru> > Add missing ignore attribute. > Check for inapplicable attributes in typedef. > Register type in typelibrary only when ATTR_PUBLIC is set. Please respect the indentation style in the files you are editing. Also, the attribute lists are all sorted to make it easier to find a given attribute in it. Therefore, please add the attribute in the correct place. >+ break; >+ default: >+ yyerror("Inapplicable attribute\n"); >+ } >+ a = NEXT_LINK(a); >+ } >+ typeref_t *tref = uniq_tref($3); > You can't mix variable declarations in between statements as it won't compile on some compilers. -- Rob Shearman

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Huw D M Davies

On Wed, Mar 15, 2006 at 01:52:19PM +0000, Huw D M Davies wrote: > On Wed, Mar 15, 2006 at 12:21:56AM +0000, Mike Hearn wrote: > > Does this very rough&ready patch work any better? > > I'm sure it's much faster, problem is it doesn't work. How do we know > if the app has fiddled with the dib section bits? Sorry, maybe I should read the patch properly before commenting :-) I assumed that you were setting need_escape to FALSE after sending the escape, but you're not. Indeed it would be interesting to know if this helped. Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Huw D M Davies

On Wed, Mar 15, 2006 at 12:21:56AM +0000, Mike Hearn wrote: > On Tue, 14 Mar 2006 17:18:21 +0100, Leon Freitag wrote: > > I don't see any other way to speed this up the way it's being synced now, the > > question is however, whether the apps really _should_ modify the bitmap on > > windows too (don't know whether they would try to draw controls onto the > > window and then it would be overdrawn by the opengl image; application like > > Steam are trying to achieve similar, but they seemed to work well before) > > Does this very rough&ready patch work any better? I'm sure it's much faster, problem is it doesn't work. How do we know if the app has fiddled with the dib section bits? Huw. -- Huw Davies huw(a)codeweavers.com

March 15, 2006

Re: Vista compatibility page

by Andreas Mohr

Hi, On Tue, Mar 14, 2006 at 05:51:37PM -0800, Scott Ritchie wrote: > On Tue, 2006-03-14 at 21:56 +0000, Mike Hearn wrote: > > Potentially this is old news, but via Raymond Chen we learn of this page: > > > > So there we have it - this appears to be the first release in which they > > simply started dropping APIs. > > > And, therefore, the first time for which we can categorically state that > Wine will be more compatible with Windows applications than Windows > itself. Not to mention that they're handing a near-fatal blow to OpenGL support, too. Andreas

March 15, 2006

ie6sp1 install failure

by Samium Gromoff

I tried to install IE6SP1 under wine 0.9.9, in order to allow .NET framework to be installed, and it failed like this: deepfire(a)betelheise:/mnt/etherstorm/win32$ wine ie6setup.exe fixme:advapi:CheckTokenMembership ((nil) 0x7fd3b6b0 0x7fbefd78) stub! fixme:advapi:DecryptFileA "C:\\windows\\temp\\IXP000.TMP\\" 00000000 wine: Unhandled page fault on read access to 0x0000000e at address 0x7e69c1ba (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x0000000e in 32-bit code (0x7e69c1ba). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:7e69c1ba ESP:7fbdeff0 EBP:7fbdeff8 EFLAGS:00210212( - 00 - RIA1) EAX:00000002 EBX:7e6ad280 ECX:00000000 EDX:00000000 ESI:00000002 EDI:00000001 Stack dump: 0x7fbdeff0: 00000001 00000002 7fbdf01c 7e69d8bc 0x7fbdf000: 00000001 7fd43120 0000000b 7fbdf018 0x7fbdf010: 7e6dec3c 7fbdf788 7fd43120 7fbdf7cc 0x7fbdf020: 7e6daa8a 7fbdf788 00000001 7fbdf7ab 0x7fbdf030: 00000005 7fbdf7b0 7fbdf07c 00000000 0x7fbdf040: 7fbdf788 7fbdf7b8 7fbdf7b4 7fbdf7b0 0200: sel=1007 base=7fe4a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x7e69c1ba in setupapi (+0x1c1ba) (0x7e69c1ba) 2 0x7e69d8bc SetupGetStringFieldA+0x2c in setupapi (0x7e69d8bc) 3 0x7e6daa8a in advpack (+0xaa8a) (0x7e6daa8a) 4 0x7e6db2df TranslateInfStringA+0xff in advpack (0x7e6db2df) fixme:dbghelp:sffip_cb NIY on 'ie6wzdex.pdb' 5 0x01016f73 in ie6wzd (+0x16f73) (0x01016f73) 6 0x010199e4 in ie6wzd (+0x199e4) (0x010199e4) 7 0x00000000 (0x00000000) 0x7e69c1ba: cmpl 0xc(%eax),%edx Modules: Module Address Debug info Name (74 modules) PE 0x01000000-01034000 Export ie6wzd ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7e154000-7e15c000 Deferred librt.so.1 ELF 0x7e675000-7e6c8000 Export setupapi<elf> \-PE 0x7e680000-7e6c8000 \ setupapi ELF 0x7e6c8000-7e6e0000 Export advpack<elf> \-PE 0x7e6d0000-7e6e0000 \ advpack ELF 0x7e7f7000-7e83c000 Deferred riched20<elf> \-PE 0x7e810000-7e83c000 \ riched20 ELF 0x7e83c000-7e850000 Deferred riched32<elf> \-PE 0x7e840000-7e850000 \ riched32 ELF 0x7e934000-7e98c000 Deferred shlwapi<elf> \-PE 0x7e950000-7e98c000 \ shlwapi ELF 0x7e98c000-7ea51000 Deferred shell32<elf> \-PE 0x7e9a0000-7ea51000 \ shell32 ELF 0x7ea51000-7ea82000 Deferred uxtheme<elf> \-PE 0x7ea60000-7ea82000 \ uxtheme ELF 0x7eac6000-7eaca000 Deferred libxfixes.so.3 ELF 0x7eaca000-7ead3000 Deferred libxcursor.so.1 ELF 0x7ead3000-7eaef000 Deferred imm32<elf> \-PE 0x7eae0000-7eaef000 \ imm32 ELF 0x7eaef000-7eaf2000 Deferred libxrandr.so.2 ELF 0x7eaf2000-7eafa000 Deferred libxrender.so.1 ELF 0x7eafa000-7eb01000 Deferred libdrm.so.2 ELF 0x7eb01000-7eb67000 Deferred libgl.so.1 ELF 0x7eb67000-7ec4d000 Deferred libx11.so.6 ELF 0x7ec4d000-7ec65000 Deferred libice.so.6 ELF 0x7ec65000-7ece4000 Deferred winex11<elf> \-PE 0x7ec70000-7ece4000 \ winex11 ELF 0x7ece4000-7ed03000 Deferred libexpat.so.1 ELF 0x7ed03000-7ed31000 Deferred libfontconfig.so.1 ELF 0x7ed31000-7ed45000 Deferred libz.so.1 ELF 0x7ed45000-7edae000 Deferred libfreetype.so.6 ELF 0x7edae000-7edcc000 Deferred iphlpapi<elf> \-PE 0x7edc0000-7edcc000 \ iphlpapi ELF 0x7edcc000-7ee14000 Deferred rpcrt4<elf> \-PE 0x7ede0000-7ee14000 \ rpcrt4 ELF 0x7ee14000-7eea0000 Deferred ole32<elf> \-PE 0x7ee30000-7eea0000 \ ole32 ELF 0x7eea0000-7eeb9000 Deferred version<elf> \-PE 0x7eeb0000-7eeb9000 \ version ELF 0x7eeb9000-7ef6d000 Deferred comctl32<elf> \-PE 0x7eec0000-7ef6d000 \ comctl32 ELF 0x7ef6d000-7ef8b000 Deferred mpr<elf> \-PE 0x7ef70000-7ef8b000 \ mpr ELF 0x7ef8b000-7f0ad000 Deferred user32<elf> \-PE 0x7efb0000-7f0ad000 \ user32 ELF 0x7f0ad000-7f0b7000 Deferred libgcc_s.so.1 ELF 0x7f0b7000-7f0cb000 Deferred lz32<elf> \-PE 0x7f0c0000-7f0cb000 \ lz32 ELF 0x7f1a0000-7faa3000 Deferred gdi32<elf> \-PE 0x7f1e0000-7faa3000 \ gdi32 ELF 0x7faa3000-7fae0000 Deferred advapi32<elf> \-PE 0x7fab0000-7fae0000 \ advapi32 ELF 0x7fbe2000-7fce0000 Deferred kernel32<elf> \-PE 0x7fc00000-7fce0000 \ kernel32 ELF 0x7fce3000-7fcf0000 Deferred libxext.so.6 ELF 0x7fe02000-7fe05000 Deferred libxau.so.6 ELF 0x7fe05000-7fe0f000 Deferred libnss_files.so.2 ELF 0x7fe0f000-7fe18000 Deferred libnss_nis.so.2 ELF 0x7fe18000-7fe2d000 Deferred libnsl.so.1 ELF 0x7fe2d000-7fe36000 Deferred libnss_compat.so.2 ELF 0x7fe36000-7fe3b000 Deferred libxxf86vm.so.1 ELF 0x7fe3b000-7fe40000 Deferred libxxf86dga.so.1 ELF 0x7fe42000-7fe4a000 Deferred libsm.so.6 ELF 0x7fe4d000-7fe6f000 Deferred libm.so.6 ELF 0x7fe6f000-7ff66000 Deferred libwine_unicode.so.1 ELF 0x7ff66000-7ffe0000 Deferred ntdll<elf> \-PE 0x7ff80000-7ffe0000 \ ntdll ELF 0xb7df1000-b7df4000 Deferred libdl.so.2 ELF 0xb7df4000-b7f23000 Deferred libc.so.6 ELF 0xb7f23000-b7f35000 Deferred libpthread.so.0 ELF 0xb7f4a000-b7f64000 Deferred libwine.so.1 ELF 0xb7f67000-b7f7d000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a (D) C:\windows\temp\IXP000.TMP\ie6wzd.exe 0000000b 0 <== 00000008 00000009 0

March 15, 2006

Re: Dogfood status

by Dan Kegel

Louis wrote: >As a frequent wine-user my favourite commands are >"rm -rf ~/.wine" and "wineserver -k" Me, too. Hard to control that urge while dogfooding, it's it? >And that's where i ran into trouble... First >problem solved by consequently using > WINEPREFIX="/c" wine "c:\Program Files/Winamp/winamp.exe". >Second problem was a bit more thinking. >I compiled an extra wine package in /tmp/wine and run by >WINEPREFIX="/c" /tmp/wine/wine "c:\Program Files/Winamp/winamp.exe" >Now i can do wineserver -k without killing winamp :). Good ideas! I'll probably do something like that. >So far Mozilla runs really great; Winamp has some issues but sound plays well. Bugzilla shows four open bugs against winamp: 729 3245 4373 4825 Do you have some new ones to file? - Dan

March 15, 2006

Re: Updated DDraw over WineD3D patch

by Joseph Garvin

So I gave the latest version of Fallout1 a try with the patch, imageshack link to screenshot below :) http://img293.imageshack.us/img293/311/fallout7xc.png The game looks and works mostly correctly with only two issues: 1) The mouse lags, even though the game itself seems to be rendering pretty quickly. There was no mouse lag in the old ddraw implementation. 2) When selecting new game, load game, etc. from the main menu, the menu used to nicely fade out. This effect was really slow under the old implementation and was what motivated me to try this patch. Now the effect doesn't happen at all, it goes black and then immediately to the next screen. Nice for me but still a regression ;) 3) There's an error on exit. Output from running below. Let me know if there are any traces that would be useful to you. fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7fd49868) : stub, emulating 64Mib for now, returning 64Mib fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->(0x10024,00000011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:ddraw:IDirectDrawImpl_CreatePalette (0x7fd49188)->(44,0x7fb9f6a8,0x539 dec,(nil)) fixme:d3d:IWineD3DDeviceImpl_CreatePalette (0x7fd49868)->(44, 0x7fb9f6a8, 0x 7fd979a8, 0x7fd979a0) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->((nil),0000000 8) fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 135 Current serial number in output stream: 137 I'm running the 8.23.7 (latest version) of the proprietary fglrx drivers on a Radeon 9700 Pro (native linux opengl apps like neverball and tuxracer work great) on the dapper drake (unstable) release of ubuntu. I tried the patch against current cvs but it won't apply so I tested it with the CVS time from your site, March 9th 23:40. P.S. Ooops, sorry Stefan, didn't mean to send you with attachment :P On Fri, 2006-03-10 at 00:30 +0100, Stefan Dösinger wrote: > Hi, > I've uploaded anothe update of my DDraw->WineD3D patch to > http://stud4.tuwien.ac.at/~e0526822/. It fixes some refcounting issues and > the D3D renderer of the Half-Life 1 Steam version works. It also takes the > merged header patches into account ;) > > I am quite busy the next time, so I won't be able to do a lot ddraw > development. I'll continue to send patches, but only header changes, no added > functionality. I'll keep myself up to date and anser feedback mails, but I > don't think I've the time to do intensive development. I expect I can > continue in April. > > Have fun playing, > Stefan

March 15, 2006

Free mirror for .deb APT repository (forwarded correspondance)

by Scott Ritchie

Hey guys. For the past few days I've been corresponding with Pieter de Bruijn, who has graciously offered us a huge amount of bandwidth to host the APT repository for our .deb packages, rather than having to put it in the sourceforge webspace where it is rather slow and times out a lot. By my estimates, we get about 800 downloads of Wine from the APT repository per day, which is about 10 gigabytes. All other package downloads from sourceforge combined constitute about 4000 downloads, so roughly 20% of our package downloads are using the APT repository. As for what percentage of our user base uses current .debs, I don't know, because more or less up to date Wine packages derived from mine can be also grabbed from the Ubuntu backports server, the Ubuntu development server, and likely some other place I don't know of. It wouldn't surprise me if over half our users were on Ubuntu at this point, though. One important advantage of Peter's offer is that it allows us much more storage space, possibly including multiple APT repositories for different distributions. This would be far preferable to the ~100 megs or so we get on Sourceforge, which can barely fit one package. Anyway, I'd like to inform everyone about the hosting offer and gather some additional feedback, if you have any comments about the change. Thanks, Scott Ritchie

March 15, 2006

Re: Vista compatibility page

by Scott Ritchie

On Tue, 2006-03-14 at 21:56 +0000, Mike Hearn wrote: > Potentially this is old news, but via Raymond Chen we learn of this page: > > So there we have it - this appears to be the first release in which they > simply started dropping APIs. > And, therefore, the first time for which we can categorically state that Wine will be more compatible with Windows applications than Windows itself. Cheers, Scott Ritchie

March 15, 2006

Re: Updated DDraw over WineD3D patch

by Joseph Garvin

So I gave the latest version of Fallout1 a try with the patch, imageshack link to screenshot below :) http://img293.imageshack.us/img293/311/fallout7xc.png The game looks and works mostly correctly with only two issues: 1) The mouse lags, even though the game itself seems to be rendering pretty quickly. There was no mouse lag in the old ddraw implementation. 2) When selecting new game, load game, etc. from the main menu, the menu used to nicely fade out. This effect was really slow under the old implementation and was what motivated me to try this patch. Now the effect doesn't happen at all, it goes black and then immediately to the next screen. Nice for me but still a regression ;) 3) There's an error on exit. Output from running below. Let me know if there are any traces that would be useful to you. fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x7fd49868) : stub, emulating 64Mib for now, returning 64Mib fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->(0x10024,00000011) fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 8 fixme:ddraw:IDirectDrawImpl_CreatePalette (0x7fd49188)->(44,0x7fb9f6a8,0x539 dec,(nil)) fixme:d3d:IWineD3DDeviceImpl_CreatePalette (0x7fd49868)->(44, 0x7fb9f6a8, 0x 7fd979a8, 0x7fd979a0) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7fd49188)->((nil),0000000 8) fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 70 (X_PolyFillRectangle) Resource id in failed request: 0x0 Serial number of failed request: 135 Current serial number in output stream: 137 I'm running the 8.23.7 (latest version) of the proprietary fglrx drivers on a Radeon 9700 Pro (native linux opengl apps like neverball and tuxracer work great) on the dapper drake (unstable) release of ubuntu. I tried the patch against current cvs but it won't apply so I tested it with the CVS time from your site, March 9th 23:40. On Fri, 2006-03-10 at 00:30 +0100, Stefan Dösinger wrote: > Hi, > I've uploaded anothe update of my DDraw->WineD3D patch to > http://stud4.tuwien.ac.at/~e0526822/. It fixes some refcounting issues and > the D3D renderer of the Half-Life 1 Steam version works. It also takes the > merged header patches into account ;) > > I am quite busy the next time, so I won't be able to do a lot ddraw > development. I'll continue to send patches, but only header changes, no added > functionality. I'll keep myself up to date and anser feedback mails, but I > don't think I've the time to do intensive development. I expect I can > continue in April. > > Have fun playing, > Stefan

March 15, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime.

by Mike Hearn

On Tue, 14 Mar 2006 17:18:21 +0100, Leon Freitag wrote: > I don't see any other way to speed this up the way it's being synced now, the > question is however, whether the apps really _should_ modify the bitmap on > windows too (don't know whether they would try to draw controls onto the > window and then it would be overdrawn by the opengl image; application like > Steam are trying to achieve similar, but they seemed to work well before) Does this very rough&ready patch work any better? --- wgl.c~ 2006-02-11 01:58:59.000000000 +0000 +++ wgl.c 2006-02-16 19:11:33.000000000 +0000 @@ -77,11 +77,14 @@ XVisualInfo *vis; GLXFBConfig fb_conf; GLXContext ctx; + BOOL needs_escape; struct wine_glcontext *next; struct wine_glcontext *prev; } Wine_GLContext; static Wine_GLContext *context_list; +Wine_GLContext __thread *curctx = NULL; + static inline Wine_GLContext *get_context_from_GLXContext(GLXContext ctx) { Wine_GLContext *ret; @@ -91,18 +94,14 @@ void enter_gl(void) { - GLXContext gl_ctx; - Wine_GLContext *ctx; enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; - wine_tsx11_lock_ptr(); - gl_ctx = glXGetCurrentContext(); - if(!gl_ctx) return; - ctx = get_context_from_GLXContext(gl_ctx); - wine_tsx11_unlock_ptr(); /* unlock before calling GDI apis */ - - if(ctx && GetObjectType(ctx->hdc) == OBJ_MEMDC) - ExtEscape(ctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + if (curctx && curctx->needs_escape) + { + ERR("foo\n"); + ExtEscape(curctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + } + wine_tsx11_lock_ptr(); return; @@ -536,6 +535,7 @@ ENTER_GL(); if (hglrc == NULL) { ret = glXMakeCurrent(default_display, None, NULL); + curctx = NULL; } else { Wine_GLContext *ctx = (Wine_GLContext *) hglrc; Drawable drawable = get_drawable( hdc ); @@ -566,8 +566,12 @@ } TRACE(" make current for dis %p, drawable %p, ctx %p\n", ctx->display, (void*) drawable, ctx->ctx); ret = glXMakeCurrent(ctx->display, drawable, ctx->ctx); + curctx = ctx; if(ret && type == OBJ_MEMDC) + { + curctx->needs_escape = TRUE; glDrawBuffer(GL_FRONT_LEFT); + } } LEAVE_GL(); TRACE(" returning %s\n", (ret ? "True" : "False"));

March 15, 2006

Vista compatibility page

by Mike Hearn

Potentially this is old news, but via Raymond Chen we learn of this page: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/htm… Which talks about Vistas application compatibility. Interesting points that stand out: * They are dropping WinHelp and CHM support. You'll have to install it from their website for it to work (my first thought: wtf?) * IsBadReadPtr/IsBadWritePtr are now "banned". I wonder what that means. Presumably it just means they don't use them internally for the APIs anymore. * Windows will now silently fail to modify certain protected system files even if you're the administrator (basically the STATUS_ACCESS_DENIED error is suppressed to stop installers tripping up). * They dropped D3D RM. Not many apps use this but I think at least my fathers sailing game does. So there we have it - this appears to be the first release in which they simply started dropping APIs.

March 14, 2006

Re: Some Processor(s) specific environment variables

by Alexandre Julliard

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > Would it be acceptable to put some sane defaults in wine.inf and have > GetSystemInfo check and fill the correct keys in the registry? Or do we > need a way to fill these keys at every boot of the system (start of > wineserver)? We can either put defaults in wine.inf, or if that's not good enough compute the proper values at run-time. It doesn't really make sense to do both. -- Alexandre Julliard julliard(a)winehq.org

March 14, 2006

Re: Dogfood status

by Tom Spear

While we are on the subject of dogfooding things, to the best of anyone's knowledge, has anyone ever tried to do something as crazy as oh i dunno, defragging their hard drive (or even one of the virtual partitions) with win98's defragger? What about running win98's gui'based scandisk on either of the above? I'd do it, but my linux machine still needs a new motherboard. Anyone got a test machine they need to reformat? Tom On 3/14/06, Dan Kegel <dank(a)kegel.com> wrote: > > Oh, Picasa works pretty well, actually. (I did dogfood it earlier.) > It's just not the kind of image editor I usually reach for when > cropping screenshots etc. > > I've also tested photoshop, it's not so happy. > > I may try Irfanview, too. Thanks! > - Dan > > On 3/14/06, Tom Spear <speeddymon(a)gmail.com> wrote: > > > > Try Irfanview. It's not a full featured editor, but it can do small > jobs. > > Kinda like Picasa, but much more user friendly. Of course you could do > > Picasa, but good luck. Same for Photoshop and Paintshop. > > > > > > Tom > > > > > > > > On 3/14/06, Dan Kegel <dank(a)kegel.com> wrote: > > > Since those are the *only two gui apps I use* > > > on Linux, I'm running out of things to dogfood! > > > Oh, once in a while I need an image editor. > > > Maybe I'll dogfood windows gimp next (quadruple yuck)... > > > > > > - Dan > > > > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv >

March 14, 2006

Re: Dogfood status

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > I've been dogfooding Wine with Firefox for some time. > It's totally usable and good looking now. Hi Dan, inspired by you i decided to go this way as well. I've remeoved shortcut buttons to xmms and mozilla (linux) from my task bar and replaced them by shortcuts to little scripts that start mozilla.exe and winamp in wine. Just want to share some experiences. As a frequent wine-user my favourite commands are "rm -rf ~/.wine" and "wineserver -k" And that's where i ran into trouble... First problem solved by consequently using WINEPREFIX="/c" wine "c:\Program Files/Winamp/winamp.exe". Second problem was a bit more thinking. I compiled an extra wine package in /tmp/wine and run by WINEPREFIX="/c" /tmp/wine/wine "c:\Program Files/Winamp/winamp.exe" Now i can do wineserver -k without killing winamp :). So i've now put some aliases in /etc/bashrc for most common commands: alias _wine='WINEPREFIX="/c" /tmp/wine/wine' alias _winecfg='WINEPREFIX="/c" /tmp/wine/programs/winecfg/winecfg' alias _regedit='WINEPREFIX="/c" /tmp/wine/programs/regedit/regedit' So now i can do _wine "c:\Program Files/Winamp/winamp.exe" _and_ rm -rf ~/.wine and wineserver -k, without any trouble. Sofar Mozilla runs really great; Winamp has some issues but sound plays well.

March 14, 2006

Re: OLEAUT32: bug 4502 - request for comment before trying to fix

by Robert Shearman

Alex Villacís Lasso wrote: > Alex Villacís Lasso wrote: > >> I would like to draw attention to bug 4502. This bug can cause any VB >> application to crash when the DatePicker control is used, and an >> attempt is made to assign a date value in VB code. Even though I >> found this bug while testing an application I wrote, this might not >> be specific to this application. It is only recently that I have some >> time to dedicate to this bug, but I would like somebody to comment on >> this. >> >> When the sample application is run with WINEDEBUG=ole,variant, the >> failing invocation looks like this: >> >> trace:ole:ITypeInfo_fnInvoke >> (0x7fdd5440)(0x7fd9f61c,id=20,flags=0x00000004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c) >> >> trace:ole:dump_DispParms args=1 named args=1 >> trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) >> trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) >> trace:ole:dump_Variant ,2006/03/12 00:00:00} >> trace:ole:ITypeInfo_fnInvoke invoking: >> L"Value"(1) >> parm0: L"Value" >> memid is 00000014 >> Param 0: >> tdesc.vartype 12 (VT_VARIANT) >> u.paramdesc.wParamFlags PARAMFLAG_FIN >> u.paramdesc.lpex (nil) >> funckind: 1 (pure virtual) >> invkind: 4 (property put) >> callconv: 4 (stdcall) >> oVft: 224 >> cParamsOpt: 0 >> wFlags: 3c >> elemdescFunc (return value type): >> tdesc.vartype 25 (VT_HRESULT) >> u.paramdesc.wParamFlags PARAMFLAGS_NONE >> u.paramdesc.lpex (nil) >> helpstring: L"Returns/sets the current date." >> entry: (null) >> trace:ole:ITypeInfo_fnInvoke changing args >> trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c) >> trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36) >> trace:ole:dump_Variant ,2006/03/12 00:00:00} >> trace:variant:VariantChangeTypeEx >> (0x7fdd5520->(VT_DATE),0x7fa3eef4->(VT_DATE),0x00000400,0x0000,VT_VARIANT) >> >> trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) >> trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) >> trace:variant:VariantCopyInd >> (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) >> trace:variant:VariantCopy (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE)) >> trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY)) >> trace:variant:VARIANT_Coerce >> (0x7fa3ec40->(VT_EMPTY),0x00000400,0x0000,0x7fa3ec30->(VT_DATE),VT_VARIANT) >> >> trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY)) >> trace:variant:VariantClear (0x7fa3ec30->(VT_DATE)) >> trace:variant:VariantChangeTypeEx returning 0x80020005, >> 0x7fdd5520->(VT_DATE) >> err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT >> from VT_DATE >> trace:ole:ITypeInfo_fnInvoke -- 0x80020005 >> >> The Property Put seems to be declared as taking one VT_VARIANT >> parameter, and the VB code supplies a VT_DATE value. Therefore, an >> attempt is made to coerce VT_DATE --> VT_VARIANT. However, >> VariantChangeTypeEx() does not support conversion of *any* kind of >> variant into VT_VARIANT, so the call fails, and this brings down the >> application. I was on half a mind to add the VT_VARIANT conversion to >> VariantChangeTypeEx() myself, but then I checked the tests for this >> operation, and it seems that the absence of support for VT_VARIANT is >> actually expected (unless I am misreading the code). Therefore, one >> of the following two things is happening: >> >> 1) There is some error in the reading of the typelib, since a >> Property Put should not have a VT_VARIANT parameter in the first place. >> 2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself, >> precisely because VariantChangeTypeEx() won't do it. > The fix is to do the following in the conversion loop in ITypeInfo::Invoke: if (rgvt[i] == VT_VARIANT) VariantCopy(&rgvarg[i], src_arg); else if ((rgvt[i] & VT_BYREF) && !V_ISBYREF(src_arg)) ... I don't have time to put this into patch form and test it, but hopefully someone else will. -- Rob Shearman

March 14, 2006