Re: Summer of Code Project: DirectPlay
On Thu, 20 Apr 2006 13:46, Francois Gouget wrote: It seems like this would prevent you from connecting to games hosted by commercial companies (e.g. Microsoft) as these are unlikely to install the Wine DirectPlay library. Or is DirectPlay never used in this way? Even so I think that when Wine implements network protocols (DirectPlay, DCOM) it should really be wire-compatible because requiring the other side to use our protocol is impractical it many cases. With the way DirectPlay works, we could provide our own provider and a compatible provider if we so wanted (at least, to the extent of my knowledge). True. but how does that sit with respect to reverse engineering? Any potential legal issues? Presumably not since this is essentially how Samba is being developped Good point, do they adhere to any rules / procedures to ensure legality? A few other concerns: * I recently searched MSDN for DirectPlay information - what information is still up there is perforated with dead links. Does anyone know where the good documentation (prefereably for all versions of DirectPlay are). * I took a brief look at dplay.c, at the moment it contains implementations for DirectPlay 2,3 and 4 (all in the one file) - to this we'll need to add 5,6 and 8. Is it worth re-organising this code to make the result (with the new interfaces) less cluttered? Perhaps a dplay[2-5,8].c, with common code in dplay.c? -- Dib: Now what Zim, whats your next plan? Zim: Lets run screaming!
Re: undefined reference to `GetCharABCWidthsI'
Gerald Pfeifer wrote: After the following change to dlls/gdi/font.c revision 1.32 date: 2006-04-19 18:16:36 +; author: julliard; state: Exp; lines: +49 -0 Jeff Latimer [EMAIL PROTECTED] gdi: Added implementation of GetCharABCWidthsI. I now get the following build error on FreeBSD 5.4: SUSE Linux 10.1 works fine. WOuld you mind having a look? Gerald Gerald, sorry about this. I notice that Alexandre has patched this as there is a cunning #ifdef HAVE_FREETYPE in freetype.c that I did not notice. Jeff
Re: SoC idea: finish wcmd
Dan Kegel wrote: wcmd isn't thought of as sexy, but it's important; for instance, some installers use it under the hood. Things like if %1 == %2 and the /wait commandline flag are not yet implemented. It wouldn't be all that hard to get wcmd far enough along to make those installers happy; I think it'd make a good SoC project. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv Hello, Not to take anything away from someone that wants to do a SoC project. But I'm a ROS dev and I know you guys arent taking patches from us right now but that aside, one of my shorter term goals is to try and sync wcmd(if it is what i think it is, i dont use linux / wine often so maybe im misintercepting it) with the ROS cmd. So just keep that in mind. I would also be more then willing to mentor someone for this project, assuming I am not disqualified based solely on the fact I am a ROS dev. Brandon P.S. sorry dan for not replying to the list the first time.
Re: SoC idea: finish wcmd
Brandon Turner wrote: Dan Kegel wrote: wcmd isn't thought of as sexy, but it's important; for instance, some installers use it under the hood. Things like if %1 == %2 and the /wait commandline flag are not yet implemented. It wouldn't be all that hard to get wcmd far enough along to make those installers happy; I think it'd make a good SoC project. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv Hello, Not to take anything away from someone that wants to do a SoC project. But I'm a ROS dev and I know you guys arent taking patches from us right now but that aside, one of my shorter term goals is to try and sync wcmd(if it is what i think it is, i dont use linux / wine often so maybe im misintercepting it) with the ROS cmd. So just keep that in mind. I would also be more then willing to mentor someone for this project, assuming I am not disqualified based solely on the fact I am a ROS dev. I'm pretty sure no-one is being disqualified base solely on the fact that they're from a certain project. Trust is earnt over time from submitting many good patches and people like Eric Kohl and Thomas Weidenmüller have done so and had them committed. Adding test cases helps, and if the function is undocumented then an explanation as to why it's required if it's not obvious also helps build that trust. -- Rob Shearman
What version of freetype are we requiring these days
I have just noticed that configure is telling me Warning: Freetype or Fontforge is missing Why does it think that? (freetype-devel version 2.1.9 is installed) -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: What version of freetype are we requiring these days
Bill Medland wrote: I have just noticed that configure is telling me Warning: Freetype or Fontforge is missing Why does it think that? (freetype-devel version 2.1.9 is installed) What about fontforge? Is that installed?
Re: SoC idea: finish wcmd
Hi Brandon, On 4/21/06, Brandon Turner [EMAIL PROTECTED] wrote: Not to take anything away from someone that wants to do a SoC project. But I'm a ROS dev and I know you guys arent taking patches from us right now but that aside, one of my shorter term goals is to try and sync wcmd(if it is what i think it is, i dont use linux / wine often so maybe im misintercepting it) with the ROS cmd. So just keep that in mind. I would also be more then willing to mentor someone for this project, assuming I am not disqualified based solely on the fact I am a ROS dev. The real issue is the ReactOS cmd and wcmd do not come from the same code. ReactOS cmd as you know is a 32bit port of the freedos cmd where wcmd is a totally new implementation. The reason for this is because its LGPL where FreeDOS and ROS CMD are GPL. Alexandre has stated in the past that he does not object to having GPL tools in the tree if there is no other option however most users don't need 100% cmd.exe compatiblity so getting Wine to adopt ReactOS cmd (all other issue aside) is going to be next to impossible. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: What version of freetype are we requiring these days
On April 21, 2006 10:46 am, Tomas Carnecky wrote: Bill Medland wrote: I have just noticed that configure is telling me Warning: Freetype or Fontforge is missing Why does it think that? (freetype-devel version 2.1.9 is installed) What about fontforge? Is that installed? No
Re: SoC idea: finish wcmd
Yes, Greatlord brought this to my attention today as well. I wasnt planning on moving ROS cmd into Wine really. I was more planning on moving Wcmd into ROS(Yes, I would have to talk with other ROS devs about this idea first I'm aware) and then filling in all the features that arent competele. Greatlord said that there might be problems doing that as well with the way wcmd is coded. To be honest, I havent spent much time looking into the specifics of the project yet, it is more of something that has been in the back of my head which I wanted to do during my summer break. Brandon Steven Edwards wrote: Hi Brandon, On 4/21/06, Brandon Turner [EMAIL PROTECTED] wrote: Not to take anything away from someone that wants to do a SoC project. But I'm a ROS dev and I know you guys arent taking patches from us right now but that aside, one of my shorter term goals is to try and sync wcmd(if it is what i think it is, i dont use linux / wine often so maybe im misintercepting it) with the ROS cmd. So just keep that in mind. I would also be more then willing to mentor someone for this project, assuming I am not disqualified based solely on the fact I am a ROS dev. The real issue is the ReactOS cmd and wcmd do not come from the same code. ReactOS cmd as you know is a 32bit port of the freedos cmd where wcmd is a totally new implementation. The reason for this is because its LGPL where FreeDOS and ROS CMD are GPL. Alexandre has stated in the past that he does not object to having GPL tools in the tree if there is no other option however most users don't need 100% cmd.exe compatiblity so getting Wine to adopt ReactOS cmd (all other issue aside) is going to be next to impossible. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
SoC idea: improve dsound/winmm
Hi, One of the things users complain about is wine's sound quality. Problems which you experience range from crackling sound in media players to buffer underruns and high latencies in games. For a part the problem is caused by crappy audio drivers and soundcards. None the less are there things in wine which can be improved to reduce the issues. I don't know this part of the code well but I believe the alsa driver is far from optimal and second the dsound contains some bugs too. In this SoC project a student would need to look into the causes of wine's bad sound quality and try to improve it by fixing winealsa and other parts. Regards, Roderick Colenbrander -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl
Re: SoC idea: improve dsound/winmm
On Friday 21 April 2006 20:52, Roderick Colenbrander wrote: Hi, One of the things users complain about is wine's sound quality. Problems which you experience range from crackling sound in media players to buffer underruns and high latencies in games. For a part the problem is caused by crappy audio drivers and soundcards. None the less are there things in wine which can be improved to reduce the issues. I don't know this part of the code well but I believe the alsa driver is far from optimal and second the dsound contains some bugs too. In this SoC project a student would need to look into the causes of wine's bad sound quality and try to improve it by fixing winealsa and other parts. I approve this proposal. DSound/WinMM is the main cause of games problems (after copy protections) : performances hole, deadlocks ... Regards, Roderick Colenbrander Regards, Raphael pgpbF2cKDWWXb.pgp Description: PGP signature
compile error
Hi, i am getting a compile error on current cvs. Does anyone else seeing this problem e.g. on git ? My system is SuSE Linux 9.0 Bye Stefan bison -d -t ../../../wine/tools/widl/parser.y -o parser.tab.c ../../../wine/tools/widl/parser.y:283.11: parse error, unexpected :, expecting ; or | ../../../wine/tools/widl/parser.y:283.35-38: $$ von »importlib« hat keinen deklarierten Typ ../../../wine/tools/widl/parser.y:283.35-43: $2 von »importlib« hat keinen deklarierten Typ make[2]: *** [parser.tab.c] Fehler 1 make[2]: Leaving directory `/usr/src/wine/wine-build/tools/widl' make[1]: *** [widl] Fehler 2 make[1]: Leaving directory `/usr/src/wine/wine-build/tools' make: *** [tools] Fehler 2 [EMAIL PROTECTED]:/usr/src/wine/wine-build bison --version bison (GNU Bison) 1.75 Geschrieben von Robert Corbett und Richard Stallman. Copyright © 2002 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt keine Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE ZWECKE.
Re: dosdevices
On Friday 21 April 2006 03:35, Alexandre Julliard wrote: Robert Lunnon [EMAIL PROTECTED] writes: This is the approach I took before but for some reason you didn't accept the patch in process.c related to starting unix lib type applications. The work-around was to change to the lib directory locate the pwd chdir back, then start the lib using the actual path.rather than the link. There may be another way to find the target directory of a link more elegantly but I don't know it. Anyway, I maintained this delta but it has now expired with the changes in process.c and need to be rewritten anyway. realpath() should be a lot easier. And you really want to do that in wine_dlopen, process.c is not the only place that can load files from a DOS drive. Assuming this works, you say that other places load files cia a dos drive (and I see a mkdir across this link too) is there a key place to put the resolving code to catch these accesses too ? (This is why I wanted to change the link name - all the unknown places where this link might need to be resolved)
Re: compile error
Stefan Leichter wrote:
Hi,
i am getting a compile error on current cvs. Does anyone else seeing this
problem e.g. on git ?
Does the attached patch help?
Jacek
diff --git a/tools/widl/parser.y b/tools/widl/parser.y
index 9f288bf..4f3ed57 100644
--- a/tools/widl/parser.y
+++ b/tools/widl/parser.y
@@ -279,6 +279,7 @@ import: import_start imp_statements aE
;
importlib: tIMPORTLIB '(' aSTRING ')' { if(!parse_only)
add_importlib($3); }
+ ;
libraryhdr: tLIBRARY aIDENTIFIER { $$ = $2; }
;
Re: compile error
Am Freitag, 21. April 2006 22:22 schrieb Jacek Caban: Stefan Leichter wrote: Hi, i am getting a compile error on current cvs. Does anyone else seeing this problem e.g. on git ? Does the attached patch help? Jacek Yes, it helps. Thank you Bye Stefan
Re: dosdevices
Robert Lunnon [EMAIL PROTECTED] writes: Assuming this works, you say that other places load files cia a dos drive (and I see a mkdir across this link too) is there a key place to put the resolving code to catch these accesses too ? Do functions like mkdir really fail on these too? I was under the impression that it was only dlopen(). I can understand dlopen wanting to do strange things with the path, but I'd certainly expect raw system calls to be able to handle them properly. -- Alexandre Julliard [EMAIL PROTECTED]
Re: SoC idea: improve dsound/winmm
On 4/21/06, Roderick Colenbrander [EMAIL PROTECTED] wrote: Hi, One of the things users complain about is wine's sound quality. Problems which you experience range from crackling sound in media players to buffer underruns and high latencies in games. For a part the problem is caused by crappy audio drivers and soundcards. None the less are there things in wine which can be improved to reduce the issues. I don't know this part of the code well but I believe the alsa driver is far from optimal and second the dsound contains some bugs too. In this SoC project a student would need to look into the causes of wine's bad sound quality and try to improve it by fixing winealsa and other parts. The only problem I have with this project idea is the ambiguity of 'improve dsound/winmm'. At what point is dsound and winmm considered to be improved? It would be nice to see a list of specific items that need to be fixed, and I mean more specific than crackling playback and high latencies. A specific project that would probably help with this situation is to combine all wine audio drivers into one driver, wineaudio. The common functionality of the drivers can be factored out, reducing code size while at the same time minimizing the chance for more bugs. -- James Hawkins
Re: SoC idea: finish wcmd
Brandon Turner wrote: Yes, Greatlord brought this to my attention today as well. I wasnt planning on moving ROS cmd into Wine really. I was more planning on moving Wcmd into ROS(Yes, I would have to talk with other ROS devs about this idea first I'm aware) and then filling in all the features that arent competele. Greatlord said that there might be problems doing that as well with the way wcmd is coded. To be honest, I havent spent much time looking into the specifics of the project yet, it is more of something that has been in the back of my head which I wanted to do during my summer break. Brandon Steven Edwards wrote: Hi Brandon, On 4/21/06, Brandon Turner [EMAIL PROTECTED] wrote: Not to take anything away from someone that wants to do a SoC project. But I'm a ROS dev and I know you guys arent taking patches from us right now but that aside, one of my shorter term goals is to try and sync wcmd(if it is what i think it is, i dont use linux / wine often so maybe im misintercepting it) with the ROS cmd. So just keep that in mind. I would also be more then willing to mentor someone for this project, assuming I am not disqualified based solely on the fact I am a ROS dev. The real issue is the ReactOS cmd and wcmd do not come from the same code. ReactOS cmd as you know is a 32bit port of the freedos cmd where wcmd is a totally new implementation. The reason for this is because its LGPL where FreeDOS and ROS CMD are GPL. Alexandre has stated in the past that he does not object to having GPL tools in the tree if there is no other option however most users don't need 100% cmd.exe compatiblity so getting Wine to adopt ReactOS cmd (all other issue aside) is going to be next to impossible. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo I think it is of note that Freecom (COMMAND.COM for FreeDOS) may contain code that can pretain to Wine, if used properly. This fact is often overlooked.
Re: SoC idea: improve dsound/winmm
James Hawkins wrote: On 4/21/06, Roderick Colenbrander [EMAIL PROTECTED] wrote: Hi, One of the things users complain about is wine's sound quality. Problems which you experience range from crackling sound in media players to buffer underruns and high latencies in games. For a part the problem is caused by crappy audio drivers and soundcards. None the less are there things in wine which can be improved to reduce the issues. I don't know this part of the code well but I believe the alsa driver is far from optimal and second the dsound contains some bugs too. In this SoC project a student would need to look into the causes of wine's bad sound quality and try to improve it by fixing winealsa and other parts. The only problem I have with this project idea is the ambiguity of 'improve dsound/winmm'. At what point is dsound and winmm considered to be improved? It would be nice to see a list of specific items that need to be fixed, and I mean more specific than crackling playback and high latencies. A specific project that would probably help with this situation is to combine all wine audio drivers into one driver, wineaudio. The common functionality of the drivers can be factored out, reducing code size while at the same time minimizing the chance for more bugs. -- James Hawkins I have a suggestion for a clearer definition: Get Super Collapse 2 to work in Wine without audio artifacts or a mile of dsound err code dumped to the console. Console output: [EMAIL PROTECTED] ~/.wine/c/Program Files/GameHouse/Collapse II $ wine relapse This sound card's driver does not support direct access The (slower) DirectSound HEL mode will be used instead. err:dsound:DSOUND_MixOne underrun on sound buffer 0x7fd8f6e8 [*cut for breverity, it's all repetitive*] [EMAIL PROTECTED] ~/.wine/c/Program Files/GameHouse/Collapse II $
opengl demos start problem with wine current cvs
Hi, When i try to start some opengl demos from www.humus.ca (with wine latest cvs), I get error, that my card doesn't support some opengl extensions. The applications' wine output is: err:wgl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) err:wgl:internal_glGetString GL_EXTENSIONS returns NULL fixme:wgl:wglChoosePixelFormatARB unused pfAttribFList err:wgl:X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0) err:wgl:internal_glGetString GL_EXTENSIONS returns NULL I attached the glxinfo's output. I use Xorg version 6.9.0, on Suse 10.1 beta9 with nvidia driver 2.0.2 NVIDIA 87.56, and I have a geforce 6600 256 mb pci-e vga card. Please help me. Best Regards, -- Lamarr Kovács András [EMAIL PROTECTED] http://csevego.net name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: NVIDIA Corporation server glx version string: 1.4 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.4 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: GeForce 6600/PCI/SSE2/3DNOW! OpenGL version string: 2.0.2 NVIDIA 87.56 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_pixel_buffer_object, 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_depth_stencil, 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_texture_sRGB, GL_EXT_timer_query, 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,
Re: What version of freetype are we requiring these days
Bill Medland wrote: I have just noticed that configure is telling me Warning: Freetype or Fontforge is missing Why does it think that? (freetype-devel version 2.1.9 is installed) Is fontforge installed? You need both.
Re: user: Fix and test behavior when selecting disabled menu items, and fix GetMenuItemRect()
On 4/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, This patch 1) changes the behavior of selecting disabled menu items, 2) recognizes VK_LMENU and VK_RMENU messages to the menu WndProc and 3) fixes GetMenuItemRect(). You should send one change/fix per patch. The best option is to send one patch for the tests, with todo_wine around them, and then send separate patches to fix each problem. -- James Hawkins
PROT_EXEC mmap/mprotect, i386 PAE + NX broken, x86-64 2.6.17-rc2
Hi, Just a heads up that WINE seems to suffer from breakage if executed as a 32bit binary on an x86-64 kernel as of 2.6.17-rc, because (according to Andi Kleen) i386 NX is now enabled by default, and on x86-64 i386 behaves like a PAE enabled i386 kernel when performing IA32 emulation. I've attached the entire thread for reference, as unfortunately I do not have the time to debug this problem, but thought that probably one of you would like to know. Thread is also available to read here: http://lkml.org/lkml/2006/4/21/99 Andi suspects that WINE is not making one of its mappings PROT_EXEC which causes a fault with NX enabled. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ---BeginMessage--- On Wednesday 19 April 2006 04:27, Linus Torvalds wrote: Instead of the normal one-week release schedule, there was now two weeks between 2.6.17-rc1 and -rc2, partly because I was travelling for one of those weeks, but partly because it was really quiet for a while. Likely a lot of people are concentrating on 2.6.16 and vendor releases. It picked up a bit in the last few days (it's also possible that the US people were all just stressed out over tax season ;), and I cut a 2.6.17-rc2. I expect to be back to the weekly schedule now, even if it is quiet (which I hope it will be). Not a lot of hugely interesting stuff, with a large portion of the diff being a late MIPS update (tssk tssk), and the huge diff from the long over-due removal of the Sangoma wan drivers that have been marked BROKEN for a long time. Same goes for the qlogicfc driver (which has been supplanted by the qla2xxx driver). As a result, the diff has just tons of deletions, even if most of the rest of the changes aren't all that big. But there are netfilter fixes, some more splice work, and just tons of random stuff: usb, scsi, knfsd, fuse, infiniband.. Something in here (or -rc1, I didn't test that) broke WINE. x86-64 kernel, 32bit WINE, works fine on 2.6.16.7. I'll check whether -rc1 had the same problem and work backwards, but just in case somebody has an idea.. [alistair] 11:17 [~/.wine/drive_c/Program Files/Warcraft III] wine war3.exe -opengl wine: Unhandled page fault on write access to 0x00495000 at address 0x495000 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00495000 in 32-bit code (0x00495000). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:006b GS:0063 EIP:00495000 ESP:7f9eff0c EBP:7f9effe8 EFLAGS:00010246( - 00 -RIZP1) EAX: EBX:7fcb4710 ECX:0040 EDX: ESI:7ffdf3a0 EDI:00495000 Stack dump: 0x7f9eff0c: 7fc794de 7ffdf3a0 0x7f9eff1c: 7fc35ff8 7fc4caf0 0x7f9eff2c: 7fcb4710 0040 7fcaf784 7f9effe8 0x7f9eff3c: 16d2f22f 168b9967 0001 0x7f9eff4c: 0x7f9eff5c: Backtrace: =1 0x00495000 EntryPoint in war3 (0x00495000) 2 0xf7f763ab wine_switch_to_stack+0x17 in libwine.so.1 (0xf7f763ab) 0x00495000 EntryPoint in war3: pushl%eax -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ---End Message--- ---BeginMessage--- On Fri, 21 Apr 2006, Alistair John Strachan wrote: Something in here (or -rc1, I didn't test that) broke WINE. x86-64 kernel, 32bit WINE, works fine on 2.6.16.7. I'll check whether -rc1 had the same problem and work backwards, but just in case somebody has an idea.. Nothing strikes me, but maybe Andi has a clue. [alistair] 11:17 [~/.wine/drive_c/Program Files/Warcraft III] wine war3.exe -opengl wine: Unhandled page fault on write access to 0x00495000 at address 0x495000 ... Unhandled exception: page fault on write access to 0x00495000 in 32-bit code That looks bogus. %eip is 0x00495000, and might well have taken a fault, but it sure ain't a write access. According to the built-in wine debugger it was 0x00495000 EntryPoint in war3: pushl%eax which does do a write, but to %esp (which is 7f9eff0c according to the dump, and which is unlikely to have taken a fault, since it's almost 256 bytes off the end of a page in the stack area). Alistair, if you can do a git bisect on this one, that would help. Unless Andi goes Duh!. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ---End Message--- ---BeginMessage--- On Fri, 21 Apr 2006 09:40:26 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: On Fri,
Re: SOC project
Willie Sippel wrote: Still, a DIB engine would be great, it would fix quite visual glitches in certain applications. I also tested a few applications recently (audio apps, no games) that were unusable slow with X at almost 100% CPU load on every interface redraw - I guess that's an issue the DIB engine would fix...? *cross fingers*, would it fix Shockwave Player running in Firefox? It's currently _*horribly*_ slow compared to running it under VMware..
Re: There May Be an End-run for Apple Around Windows After All
Hi Robert, I am an occasional reader of your column (truthfully, mostly when it comes up on slashdot). I usually find your comments insightful, or at least thought provocing. I'm afraid the column at the subject is a stark exception to this rule (http://www.pbs.org/cringely/pulpit/pulpit20060420.html). If you'll excuse the strong words, the claim made was nothing more then wishful thinking, with no possibility of basing it on anything real. Before I get to why, allow me to introduce myself. My name, as you can probably see from the email headers, is Shachar Shemesh. I am founder and CEO of a small Linux consulting company in Israel (http://www.lingnu.com). More to the point, however, I am (or, at least, used to be) a Wine hacker. Feel free to search for my name at http://www.winehq.com/site/who. As the task you claim Apple has undertaken is, in fact, identical to developing a second Wine, I think I have some authority in assessing how likely that is. I also took the liberty of CCing the wine-devel list, so that if anyone there wishes to claim me wrong, they can. And as for the likelihood, I can answer that question rather easilly. The answer is not very. I would even go as far as to say that the answer is extremely unlikely. Wine is a huge project. On last count it had over 1.5 million lines of code. Most of the code inside Wine is written in Win32. Yes, it's a Linux project written, mostly, in Win32. The reason is that the so called Win32 API is a convulted huge heap of layers upon layers of miscellanious implementations of anything Microsoft decided to give developers because it seemed like a good idea at the time. Some of these functions misbehave, and some programs rely on this misbehaviour in order to work. Not all of the functions, and hardly any of the misbehaviours, are documented in any way. The Wine project has been busy, for over ten years now, in duplicating said development. Despite what may appear in your column, the reason it has been taking so long is NOT Microsoft's disapproval. For all intent and purposes, MS has no technical means of slowing Wine down, and here is the main reason - Wine only cares about running actual applications. Microsoft is, of course, at liberty to change and add interfaces as much as it wants, but Wine will only care about these interface changes if and when actual applications start to use them. Over this last point MS has very little control. In that respect, I think it should be clear that Apple is in no better starting position to duplicate the Wine effort than Wine is, and there is no reason to think it will do better. Which brings us to the task at hand. Because the purpose of an API replacement is to be bug compatible with the original, we can already know how the first versions of such an effort from Apple will look. They will probably be able to run Solitare and notepad, but not much more. We know that simply because Wine used to be there itself. Getting from this 90% to 100% takes a considerable amount of time. It makes little sense, and has little return on investment, for Apple to take this herculean task upon itself, when it can get to 95% of the task by simply taking the Wine code and adapting it to Mac OS X. Don't understand this to mean that the next OS X on Intel will not be able to run Windows code without emulation. What I am saying is that it likely WILL be able to do so, but using Wine as its technology. After all, work to get Windows programs running on a Mac using Wine was underway long before Apple made the CPU switch, using thin emulation services. Dumping the emulation (and, more importantly, the endianity misalignment) is only likely to boost this effort. This, however, will happen whether Apple endorses it or not. Hoping your next column will bring us back to the level of writing you usually produce. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
