Re: Summer of Code Project: DirectPlay

2006-04-21 Thread Adam Luchjenbroers
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'

2006-04-21 Thread Jeff Latimer

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

2006-04-21 Thread Brandon Turner

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

2006-04-21 Thread Robert Shearman

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

2006-04-21 Thread Bill Medland
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

2006-04-21 Thread Tomas Carnecky
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

2006-04-21 Thread Steven Edwards
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

2006-04-21 Thread Bill Medland
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

2006-04-21 Thread Brandon Turner
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

2006-04-21 Thread Roderick Colenbrander
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

2006-04-21 Thread Raphael
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

2006-04-21 Thread Stefan Leichter
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

2006-04-21 Thread Robert Lunnon
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

2006-04-21 Thread 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
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

2006-04-21 Thread Stefan Leichter
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

2006-04-21 Thread Alexandre Julliard
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

2006-04-21 Thread James Hawkins
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

2006-04-21 Thread Segin

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

2006-04-21 Thread Segin




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

2006-04-21 Thread Kovács András
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

2006-04-21 Thread Tom Spear (Dustin Booker, Dustin Navea)

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()

2006-04-21 Thread James Hawkins
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

2006-04-21 Thread Alistair John Strachan
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

2006-04-21 Thread Molle Bestefich
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

2006-04-21 Thread Shachar Shemesh
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