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

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > All right. > > Do you want me to rip out the old Linux /proc/ide and /proc/scsi parsing > code, or do you want to move that over to mountmgr, too? It needs to be redone the proper way in mountmgr, matching the devices we get from HAL. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2011

Re: [3/3] Changing the day of month BEFORE calculating the day of week this time. (try 3)

by Vincent Povirk

And now I screwed up the title. But I'm sure git-am will fix that. On Thu, Mar 31, 2011 at 3:58 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > EVERY TIME I have to do anything different I forget to attach the patch. >

March 31, 2011

About Wine/Gecko/MSHTML

by Artem S. Tashkinov

Hi, I have no idea to what extent and how Mozilla's Gecko library is being used in Wine (all I know is that it's used in Wine's MSHTML component), but recently a Mozilla developer made a very unsettling announcement: groups dot google dot com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion I wonder if this announcement has any adverse effects on Wine's future. Best wishes, Artem

March 31, 2011

Re: [PATCH] kernel32: Populate HKLM\HARDWARE\DEVICEMAP\Scsi on Mac OS.

by Charles Davis

On 3/30/11 2:53 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: >> How do you propose to do that? The way this is done on Linux, it's >> probably fine to just build up/tear down an entry for each device that >> HAL/udev detects, but DiskArbitration only handles disks (and not other >> types of SCSI devices) on Mac. > > I don't think we care about other types of devices at this point. All right. Do you want me to rip out the old Linux /proc/ide and /proc/scsi parsing code, or do you want to move that over to mountmgr, too? Chip

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by David Adam

2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> > 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > > > > > 2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> > >> > >> 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > >> > > >> > + /* Check the width */ > >> > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > >> > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > >> > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > >> > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, > >> > received %f\n", length); > >> > >> This is not really different from the previous version: you are still > >> making assumptions about the vertex ordering (in this specific case, > >> you're assuming that vertices 18 and 19 have different X coordinate > >> but the same Y and Z coordinate values). > > > > I have an application (Geoprofs) qui use the specific ordering of the > > vertex. So if we implement randomly the vertex, it will not work. > > Really? Well, that makes my original point mostly moot. > Still, I don't think the current tests are very meaningful. Do you > know exactly what that application needs? You could test for that > specific thing, so if, for example, the application requires the left > face to be the first one, you could test just for that. > > The application colors the left face and the right face and applies geometric tranformations, so the student can see where arrives the faces in comparison with the initial box Fetching left and right faces is doing by fetching vertex . > >> > >> What I was proposing was something like this: > >> > >> for (i = 0; i < num_vertices; i++) > >> { > >> float *vertex_data = data + i * num_bytes_per_vertex; > >> if (vertex_data[0] < xmin) xmin = vertex_data[0]; > >> if (vertex_data[0] > xmax) xmax = vertex_data[0]; > >> if (vertex_data[1] < ymin) ymin = vertex_data[1]; > >> if (vertex_data[1] > ymax) ymax = vertex_data[1]; > >> if (vertex_data[2] < zmin) zmin = vertex_data[2]; > >> if (vertex_data[2] > zmax) zmax = vertex_data[2]; > >> } > >> > >> and then proceed to check whether the minimum and maximum values you > >> got match the expected ones. This code snippet can certainly be > >> improved, it is only to show you what I meant. > >> > >> Also, again, please try to fix the whitespaces... > > > > People changed the original style of the file. So, Which one must I keep > ? > > > > Arguably it is better to adopt the style used for most recent code in > wined3d or d3dcompiler_43. But, regardless of that, you should at > least be consistent in the same function. You are mixing 0 or 1 spaces > after commas, spaces or no spaces around operators and stuff like > that. > > That looks reasonnable :D Thanks again. A+ David > > Thanks for your advices ;) > > > > A+ > > > > David > > >

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by Matteo Bruni

2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > > 2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> >> >> 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: >> > >> > + /* Check the width */ >> > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); >> > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); >> > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); >> > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, >> > received %f\n", length); >> >> This is not really different from the previous version: you are still >> making assumptions about the vertex ordering (in this specific case, >> you're assuming that vertices 18 and 19 have different X coordinate >> but the same Y and Z coordinate values). > > I have an application (Geoprofs) qui use the specific ordering of the > vertex. So if we implement randomly the vertex, it will not work. Really? Well, that makes my original point mostly moot. Still, I don't think the current tests are very meaningful. Do you know exactly what that application needs? You could test for that specific thing, so if, for example, the application requires the left face to be the first one, you could test just for that. >> >> What I was proposing was something like this: >> >> for (i = 0; i < num_vertices; i++) >> { >> float *vertex_data = data + i * num_bytes_per_vertex; >> if (vertex_data[0] < xmin) xmin = vertex_data[0]; >> if (vertex_data[0] > xmax) xmax = vertex_data[0]; >> if (vertex_data[1] < ymin) ymin = vertex_data[1]; >> if (vertex_data[1] > ymax) ymax = vertex_data[1]; >> if (vertex_data[2] < zmin) zmin = vertex_data[2]; >> if (vertex_data[2] > zmax) zmax = vertex_data[2]; >> } >> >> and then proceed to check whether the minimum and maximum values you >> got match the expected ones. This code snippet can certainly be >> improved, it is only to show you what I meant. >> >> Also, again, please try to fix the whitespaces... > > People changed the original style of the file. So, Which one must I keep ? > Arguably it is better to adopt the style used for most recent code in wined3d or d3dcompiler_43. But, regardless of that, you should at least be consistent in the same function. You are mixing 0 or 1 spaces after commas, spaces or no spaces around operators and stuff like that. > Thanks for your advices ;) > > A+ > > David >

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by David Adam

2011/3/31 Matteo Bruni <matteo.mystral(a)gmail.com> > 2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > > > + /* Check the width */ > > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, > received %f\n", length); > > This is not really different from the previous version: you are still > making assumptions about the vertex ordering (in this specific case, > you're assuming that vertices 18 and 19 have different X coordinate > but the same Y and Z coordinate values). > I have an application (Geoprofs) qui use the specific ordering of the vertex. So if we implement randomly the vertex, it will not work. > > What I was proposing was something like this: > > for (i = 0; i < num_vertices; i++) > { > float *vertex_data = data + i * num_bytes_per_vertex; > if (vertex_data[0] < xmin) xmin = vertex_data[0]; > if (vertex_data[0] > xmax) xmax = vertex_data[0]; > if (vertex_data[1] < ymin) ymin = vertex_data[1]; > if (vertex_data[1] > ymax) ymax = vertex_data[1]; > if (vertex_data[2] < zmin) zmin = vertex_data[2]; > if (vertex_data[2] > zmax) zmax = vertex_data[2]; > } > > and then proceed to check whether the minimum and maximum values you > got match the expected ones. This code snippet can certainly be > improved, it is only to show you what I meant. > > Also, again, please try to fix the whitespaces... > People changed the original style of the file. So, Which one must I keep ? Thanks for your advices ;) A+ David

March 31, 2011

Re: d3dx9_36 [patch 2/2]: Add tests for D3DXCreateBox

by Matteo Bruni

2011/3/31 David Adam <david.adam.cnrs(a)gmail.com>: > > + /* Check the width */ > + v1 = *((D3DXVECTOR3*)(data+19*num_bytes_per_vertex)); > + v2 = *((D3DXVECTOR3*)(data+18*num_bytes_per_vertex)); > + length = D3DXVec3Length(D3DXVec3Subtract(&v2,&v1,&v2)); > + ok(fabs(length-10.0f)<admitted_error, "Width expected= 10.0, received %f\n", length); This is not really different from the previous version: you are still making assumptions about the vertex ordering (in this specific case, you're assuming that vertices 18 and 19 have different X coordinate but the same Y and Z coordinate values). What I was proposing was something like this: for (i = 0; i < num_vertices; i++) { float *vertex_data = data + i * num_bytes_per_vertex; if (vertex_data[0] < xmin) xmin = vertex_data[0]; if (vertex_data[0] > xmax) xmax = vertex_data[0]; if (vertex_data[1] < ymin) ymin = vertex_data[1]; if (vertex_data[1] > ymax) ymax = vertex_data[1]; if (vertex_data[2] < zmin) zmin = vertex_data[2]; if (vertex_data[2] > zmax) zmax = vertex_data[2]; } and then proceed to check whether the minimum and maximum values you got match the expected ones. This code snippet can certainly be improved, it is only to show you what I meant. Also, again, please try to fix the whitespaces...

March 31, 2011

Re: msvcrt: Fix locale creation for multibyte encoding

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -787,13 +787,15 @@ MSVCRT__locale_t MSVCRT__create_locale(int category, const char *locale) > loc->locinfo->lc_category[MSVCRT_LC_CTYPE].locale = _strdup("C"); > } > > - for(i=0; i<256; i++) > - buf[i] = i; > - > - LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_LOWERCASE, buf, 256, > - (char*)loc->locinfo->pclmap, 256); > - LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_UPPERCASE, buf, 256, > - (char*)loc->locinfo->pcumap, 256); > + for(i=0; i<256; i++) { > + buf[0] = i; > + if(!LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_LOWERCASE, buf, 1, > + (char*)loc->locinfo->pclmap+i, 1)) > + loc->locinfo->pclmap[i] = ' '; > + if(!LCMapStringA(lcid[MSVCRT_LC_CTYPE], LCMAP_UPPERCASE, buf, 1, > + (char*)loc->locinfo->pcumap+i, 1)) > + loc->locinfo->pcumap[i] = ' '; > + } It would probably be better to replace the DBCS lead chars in the input buffer first and then still do the whole mapping in one step. -- Alexandre Julliard julliard(a)winehq.org

March 31, 2011

Why do the wintab32 tests load the dll at runtime?

by Francois Gouget

The subject says it all. Why do the wintab32 tests load the dll at runtime instead of simply linking with wintab32.dll? Is it to make it easier to compile it with Visual C++ in case the system does not have wintab32.dll? (already the SDKs don't seem to have wintab.h) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

March 31, 2011