January 2007 - Wine-Devel - list.winehq.org

Using Wine headers on Mac OS X
by Mike Jan. 18, 2007

Jan. 18, 2007

Hi. I know this is unsupported but I am trying to use the Wine windows headers to port some Windows code to Mac OS X. I'm not really trying to use the Wine functionality - I use the headers more to define and map the existing Win32 defines, and datatypes to Mac OS so that I can make as few changes to the Windows code I am porting as possible. My big question is: when I add the Wine headers to my project, it seems that every datatype in the wine headers is undefined. I noticed that most wine headers don't have any #includes in them. is there some precompiled or metaheader that I should be including in all of the wine files in order to get the compiler to see the data types? Thanks, Mike

3 5

Re: [17/49] wined3d: Rewrite shader_glsl_mov() to properly take the write mask into account, in case of writing to an address register round the source
by Mirek Jan. 17, 2007

Jan. 17, 2007

Hi, this patch caused regression in TES: Oblivion, some objects like peoples are broken. Mirek Slugen H. Verbeet napsal(a): > Changelog: > - Rewrite shader_glsl_mov() to properly take the write mask into account > - in case of writing to an address register round the source, rather > than just dropping the fractional part > > > ------------------------------------------------------------------------ > > --- > > dlls/wined3d/glsl_shader.c | 33 ++++++++++++++++++++++++--------- > 1 files changed, 24 insertions(+), 9 deletions(-) > > diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c > index 60f74c0..6579e6d 100644 > --- a/dlls/wined3d/glsl_shader.c > +++ b/dlls/wined3d/glsl_shader.c > @@ -963,17 +963,32 @@ void shader_glsl_arith(SHADER_OPCODE_ARG* arg) { > > /* Process the WINED3DSIO_MOV opcode using GLSL (dst = src) */ > void shader_glsl_mov(SHADER_OPCODE_ARG* arg) { > - > + IWineD3DBaseShaderImpl* shader = (IWineD3DBaseShaderImpl*) arg->shader; > SHADER_BUFFER* buffer = arg->buffer; > - char tmpLine[256]; > - char dst_str[100], src0_str[100]; > - char dst_reg[50], src0_reg[50]; > - char dst_mask[6], src0_mask[6]; > + char src0_str[100]; > + char src0_reg[50]; > + char src0_mask[6]; > + DWORD write_mask; > > - shader_glsl_add_dst_param(arg, arg->dst, 0, dst_reg, dst_mask, dst_str); > - shader_glsl_add_src_param_old(arg, arg->src[0], arg->src_addr[0], src0_reg, src0_mask, src0_str); > - shader_glsl_add_dst_old(arg->dst, dst_reg, dst_mask, tmpLine); > - shader_addline(buffer, "%s%s)%s;\n", tmpLine, src0_str, dst_mask); > + write_mask = shader_glsl_append_dst(buffer, arg); > + shader_glsl_add_src_param(arg, arg->src[0], arg->src_addr[0], write_mask, src0_reg, src0_mask, src0_str); > + > + /* In vs_1_1 WINED3DSIO_MOV can write to the adress register. In later > + * shader versions WINED3DSIO_MOVA is used for this. */ > + if ((WINED3DSHADER_VERSION_MAJOR(shader->baseShader.hex_version) == 1 && > + !shader_is_pshader_version(shader->baseShader.hex_version) && > + shader_get_regtype(arg->dst) == WINED3DSPR_ADDR) || > + arg->opcode->opcode == WINED3DSIO_MOVA) { > + /* We need to *round* to the nearest int here. */ > + size_t mask_size = shader_glsl_get_write_mask_size(write_mask); > + if (mask_size > 1) { > + shader_addline(buffer, "ivec%d(floor(%s + vec%d(0.5))));\n", mask_size, src0_str, mask_size); > + } else { > + shader_addline(buffer, "int(floor(%s + 0.5)));\n", src0_str); > + } > + } else { > + shader_addline(buffer, "%s);\n", src0_str); > + } > } > > /* Process the dot product operators DP3 and DP4 in GLSL (dst = dot(src0, src1)) */ > > > ------------------------------------------------------------------------ > >

2 10

Re: ntdll: Declare some functions static
by Marcus Meissner Jan. 17, 2007

Jan. 17, 2007

On Wed, Jan 17, 2007 at 08:20:32PM +0000, Andrew Talbot wrote: > Changelog: > ntdll: Declare some functions static. > > diff -urN a/dlls/ntdll/exception.c b/dlls/ntdll/exception.c > --- a/dlls/ntdll/exception.c 2007-01-10 22:13:12.000000000 +0000 > +++ b/dlls/ntdll/exception.c 2007-01-17 20:11:06.000000000 +0000 > @@ -374,7 +374,7 @@ > /*********************************************************************** > * RtlRaiseException (NTDLL.@) > */ > -void WINAPI __regs_RtlRaiseException( EXCEPTION_RECORD *rec, CONTEXT *context ) > +static void WINAPI __regs_RtlRaiseException( EXCEPTION_RECORD *rec, CONTEXT *context ) > { > NTSTATUS status = raise_exception( rec, context, TRUE ); > if (status != STATUS_SUCCESS) > @@ -624,7 +624,7 @@ > * ntdll-specific implementation to avoid depending on kernel functions. > * Can be removed once ntdll.spec no longer contains stubs. > */ > -void __wine_spec_unimplemented_stub( const char *module, const char *function ) > +static void __wine_spec_unimplemented_stub( const char *module, const char *function ) > { > EXCEPTION_RECORD record; This is not a good idea, it will optimize those functions away, since gcc cannot look into the DEFINE_REGS_ENTRYPOINT() assembly. Ciao, Marcs

2 1

ntdll: Declare some functions static
by Andrew Talbot Jan. 17, 2007

Jan. 17, 2007

Sorry. This patch breaks compilation. Please do not apply. -- Andy.

1 0

Re: [kernel32][console][try3] Adds comment for function
by Robert Shearman Jan. 17, 2007

Jan. 17, 2007

Anatoly Lyutin wrote: > + * NOTES > + * Has appeared, since Windows 2000 Professional > */ > HWND WINAPI GetConsoleWindow(VOID) > { > We don't tend to add notes like this for functions as it is meaningless in the context of Wine. Also, when adding comments you must also add a disclaimer stating that you didn't copy it from MSDN. -- Rob Shearman

1 0

Anonymous structs/unions
by Joel Parker Jan. 17, 2007

Jan. 17, 2007

As seen here <http://source.winehq.org/source/include/winnt.h#L152>, we seem to be going through a lot of trouble to enable anonymous structs and unions for those compilers that support it. Why do this, especially when we need to name them anyway for those that don't? My reason for asking is that I'm doing a casual ANSI sweep of the code, and anonymous unions are causing problems (they're not allowed). I could just put in a test for __STRICT_ANSI__ and disable them if found, but that feels like gaming the system, and it's not a standard macro anyway. The best way (other than just naming all the structs/unions) is to test for __STDC__, but GCC includes that one even when not using -ansi mode. Thoughts? -- Joel Parker

3 2

[try2] user32/tests: add tests for WM_SETICON - what's wrong?
by Kirill K. Smirnov Jan. 17, 2007

Jan. 17, 2007

Hi, Traditional questions from rejected patch-sender: 1) What's wrong with the patch: http://www.winehq.org/pipermail/wine-patches/2007-January/034949.html 2) What can be done to improve it? -- Kirill

2 1

Re: [3/3] WineD3D: Implement per stream offsets
by Kovács András Jan. 17, 2007

Jan. 17, 2007

Call of duty 2 uses steam offsets. 2007. január 17. 00.06 dátummal Stefan Dösinger ezt írta: > Stumbled uppon that while reading up instancing. This is a functionality > technically required for all d3d9 drivers. The new functionality is not > really tested because I have no app that really needs this, but it should > not cause issues with games not using stream offsets. -- ------------------ andras NetClub Lamarr csevego.net andras(a)csevego.net ------------------

3 2

Re: Make.rules.in: Add variables for BISONFLAGS and LEXFLAGS.
by Alexandre Julliard Jan. 17, 2007

Jan. 17, 2007

Robert Shearman <rob(a)codeweavers.com> writes: > Make BISONFLAGS default to generating debug information so that parser > tracing works in the various tools. You should add this to the makefile of the tool you want to debug. There's no reason to force it for all parsers, and defining it in Make.rules prevents individual makefiles from having their own flags. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] WineD3D: Implement per stream offsets
by H. Verbeet Jan. 17, 2007

Jan. 17, 2007

On 17/01/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > really tested because I have no app that really needs this, but it should not > cause issues with games not using stream offsets. > I think Serious Sam 2 required stream offsets. Perhaps I should give that game another try one of these days.

2 1

Re: [3/3] WineD3D: Implement per stream offsets
by Mirek Jan. 17, 2007

Jan. 17, 2007

Hi, one or more nvidia sdk demos using instancing. Mirek Stefan Dösinger napsal(a): > Stumbled uppon that while reading up instancing. This is a functionality > technically required for all d3d9 drivers. The new functionality is not > really tested because I have no app that really needs this, but it should not > cause issues with games not using stream offsets. > > > ------------------------------------------------------------------------ > > From 6bd68813f3b05e525555ab2c28b331d838b50b92 Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Sat, 13 Jan 2007 15:09:16 +0100 > Subject: [PATCH] WineD3D: Implement per stream offsets > > --- > dlls/wined3d/directx.c | 2 +- > dlls/wined3d/drawprim.c | 47 +++++++++++++++++++++++++++++++++++++---------- > dlls/wined3d/state.c | 22 ++++++++++++---------- > 3 files changed, 50 insertions(+), 21 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index cbcbdc2..0e6f4bc 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -2244,7 +2244,7 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter, > ------------------------------------------------ */ > if (This->dxVersion > 8) { > /* d3d9.dll sets D3DDEVCAPS2_CAN_STRETCHRECT_FROM_TEXTURES here because StretchRects is implemented in d3d9 */ > - *pCaps->DevCaps2 = 0; > + *pCaps->DevCaps2 = D3DDEVCAPS2_STREAMOFFSET; > /* TODO: VS3.0 needs at least D3DDEVCAPS2_VERTEXELEMENTSCANSHARESTREAMOFFSET */ > *pCaps->MaxNpatchTessellationLevel = 0; > *pCaps->MasterAdapterOrdinal = 0; > diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c > index 400ffb5..fdc9843 100644 > --- a/dlls/wined3d/drawprim.c > +++ b/dlls/wined3d/drawprim.c > @@ -628,8 +628,12 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > DWORD diffuseColor = 0xFFFFFFFF; /* Diffuse Color */ > DWORD specularColor = 0; /* Specular Color */ > IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; > + UINT *streamOffset = This->stateBlock->streamOffset; > LONG SkipnStrides = startVertex + This->stateBlock->loadBaseVertexIndex; > > + BYTE *texCoords[WINED3DDP_MAXTEXCOORD]; > + BYTE *diffuse = NULL, *specular = NULL, *normal = NULL, *position = NULL; > + > TRACE("Using slow vertex array code\n"); > > /* Variable Initialization */ > @@ -638,6 +642,29 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > else pIdxBufL = (const long *) idxData; > } > > + /* Adding the stream offset once is cheaper than doing it every iteration. Do not modify the strided data, it is a pointer > + * to the strided Data in the device and might be needed intact on the next draw > + */ > + for (textureNo = 0, texture_idx = 0; textureNo < GL_LIMITS(texture_stages); ++textureNo) { > + if(sd->u.s.texCoords[textureNo].lpData) { > + texCoords[textureNo] = sd->u.s.texCoords[textureNo].lpData + streamOffset[sd->u.s.texCoords[textureNo].streamNo]; > + } else { > + texCoords[textureNo] = NULL; > + } > + } > + if(sd->u.s.diffuse.lpData) { > + diffuse = sd->u.s.diffuse.lpData + streamOffset[sd->u.s.diffuse.streamNo]; > + } > + if(sd->u.s.specular.lpData) { > + specular = sd->u.s.specular.lpData + streamOffset[sd->u.s.specular.streamNo]; > + } > + if(sd->u.s.normal.lpData) { > + normal = sd->u.s.normal.lpData + streamOffset[sd->u.s.normal.streamNo]; > + } > + if(sd->u.s.position.lpData) { > + position = sd->u.s.position.lpData + streamOffset[sd->u.s.position.streamNo]; > + } > + > /* Start drawing in GL */ > VTRACE(("glBegin(%x)\n", glPrimType)); > glBegin(glPrimType); > @@ -707,8 +734,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > continue; > } > > - ptrToCoords = (float *)(sd->u.s.texCoords[coordIdx].lpData + (SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride)); > - if (sd->u.s.texCoords[coordIdx].lpData == NULL) { > + ptrToCoords = (float *)(texCoords[coordIdx] + (SkipnStrides * sd->u.s.texCoords[coordIdx].dwStride)); > + if (texCoords[coordIdx] == NULL) { > TRACE("tex: %d - Skipping tex coords, as no data supplied\n", textureNo); > ++texture_idx; > continue; > @@ -796,8 +823,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } /* End of textures */ > > /* Diffuse -------------------------------- */ > - if (sd->u.s.diffuse.lpData != NULL) { > - DWORD *ptrToCoords = (DWORD *)(sd->u.s.diffuse.lpData + (SkipnStrides * sd->u.s.diffuse.dwStride)); > + if (diffuse) { > + DWORD *ptrToCoords = (DWORD *)(diffuse + (SkipnStrides * sd->u.s.diffuse.dwStride)); > diffuseColor = ptrToCoords[0]; > VTRACE(("diffuseColor=%lx\n", diffuseColor)); > > @@ -813,8 +840,8 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Specular ------------------------------- */ > - if (sd->u.s.specular.lpData != NULL) { > - DWORD *ptrToCoords = (DWORD *)(sd->u.s.specular.lpData + (SkipnStrides * sd->u.s.specular.dwStride)); > + if (specular) { > + DWORD *ptrToCoords = (DWORD *)(specular + (SkipnStrides * sd->u.s.specular.dwStride)); > specularColor = ptrToCoords[0]; > VTRACE(("specularColor=%lx\n", specularColor)); > > @@ -850,16 +877,16 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Normal -------------------------------- */ > - if (sd->u.s.normal.lpData != NULL) { > - float *ptrToCoords = (float *)(sd->u.s.normal.lpData + (SkipnStrides * sd->u.s.normal.dwStride)); > + if (normal != NULL) { > + float *ptrToCoords = (float *)(normal + (SkipnStrides * sd->u.s.normal.dwStride)); > > VTRACE(("glNormal:nx,ny,nz=%f,%f,%f\n", ptrToCoords[0], ptrToCoords[1], ptrToCoords[2])); > glNormal3f(ptrToCoords[0], ptrToCoords[1], ptrToCoords[2]); > } > > /* Position -------------------------------- */ > - if (sd->u.s.position.lpData != NULL) { > - float *ptrToCoords = (float *)(sd->u.s.position.lpData + (SkipnStrides * sd->u.s.position.dwStride)); > + if (position) { > + float *ptrToCoords = (float *)(position + (SkipnStrides * sd->u.s.position.dwStride)); > x = ptrToCoords[0]; > y = ptrToCoords[1]; > z = ptrToCoords[2]; > diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c > index bc2686f..8d74006 100644 > --- a/dlls/wined3d/state.c > +++ b/dlls/wined3d/state.c > @@ -2112,6 +2112,7 @@ static inline void unloadNumberedArrays(IWineD3DStateBlockImpl *stateblock) { > static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertexStridedData *strided) { > GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; > int i; > + UINT *offset = stateblock->streamOffset; > > for (i = 0; i < MAX_ATTRIBS; i++) { > > @@ -2130,7 +2131,7 @@ static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDi > WINED3D_ATR_GLTYPE(strided->u.input[i].dwType), > WINED3D_ATR_NORMALIZED(strided->u.input[i].dwType), > strided->u.input[i].dwStride, > - strided->u.input[i].lpData + stateblock->loadBaseVertexIndex * strided->u.input[i].dwStride)); > + strided->u.input[i].lpData + stateblock->loadBaseVertexIndex * strided->u.input[i].dwStride + offset[strided->u.input[i].streamNo]) ); > GL_EXTCALL(glEnableVertexAttribArrayARB(i)); > } > } > @@ -2139,6 +2140,7 @@ static inline void loadNumberedArrays(IWineD3DStateBlockImpl *stateblock, WineDi > static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertexStridedData *sd) { > unsigned int textureNo = 0; > unsigned int texture_idx = 0; > + UINT *offset = stateblock->streamOffset; > GLint curVBO = GL_SUPPORT(ARB_VERTEX_BUFFER_OBJECT) ? -1 : 0; > > TRACE("Using fast vertex array code\n"); > @@ -2155,7 +2157,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > #endif > > TRACE("Blend %d %p %d\n", WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType), > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride, sd->u.s.blendWeights.dwStride); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride, sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo]); > /* FIXME("TODO\n");*/ > /* Note dwType == float3 or float4 == 2 or 3 */ > > @@ -2170,7 +2172,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > VTRACE(("glWeightPointerARB(%d, GL_FLOAT, %d, %p)\n", > WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType) , > sd->u.s.blendWeights.dwStride, > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride)); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo])); > > if(curVBO != sd->u.s.blendWeights.VBO) { > GL_EXTCALL(glBindBufferARB(GL_ARRAY_BUFFER_ARB, sd->u.s.blendWeights.VBO)); > @@ -2182,7 +2184,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > WINED3D_ATR_SIZE(sd->u.s.blendWeights.dwType), > WINED3D_ATR_GLTYPE(sd->u.s.blendWeights.dwType), > sd->u.s.blendWeights.dwStride, > - sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride); > + sd->u.s.blendWeights.lpData + stateblock->loadBaseVertexIndex * sd->u.s.blendWeights.dwStride + offset[sd->u.s.blendWeights.streamNo]); > > checkGLcall("glWeightPointerARB"); > > @@ -2320,12 +2322,12 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > if(sd->u.s.position.VBO == 0) { > glVertexPointer(3 /* min(WINED3D_ATR_SIZE(sd->u.s.position.dwType),3) */, > WINED3D_ATR_GLTYPE(sd->u.s.position.dwType), > - sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride); > + sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride + offset[sd->u.s.position.streamNo]); > } else { > glVertexPointer( > WINED3D_ATR_SIZE(sd->u.s.position.dwType), > WINED3D_ATR_GLTYPE(sd->u.s.position.dwType), > - sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride); > + sd->u.s.position.dwStride, sd->u.s.position.lpData + stateblock->loadBaseVertexIndex * sd->u.s.position.dwStride + offset[sd->u.s.position.streamNo]); > } > checkGLcall("glVertexPointer(...)"); > glEnableClientState(GL_VERTEX_ARRAY); > @@ -2350,7 +2352,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > glNormalPointer( > WINED3D_ATR_GLTYPE(sd->u.s.normal.dwType), > sd->u.s.normal.dwStride, > - sd->u.s.normal.lpData + stateblock->loadBaseVertexIndex * sd->u.s.normal.dwStride); > + sd->u.s.normal.lpData + stateblock->loadBaseVertexIndex * sd->u.s.normal.dwStride + offset[sd->u.s.normal.streamNo]); > checkGLcall("glNormalPointer(...)"); > glEnableClientState(GL_NORMAL_ARRAY); > checkGLcall("glEnableClientState(GL_NORMAL_ARRAY)"); > @@ -2384,7 +2386,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > } > glColorPointer(4, GL_UNSIGNED_BYTE, > sd->u.s.diffuse.dwStride, > - sd->u.s.diffuse.lpData + stateblock->loadBaseVertexIndex * sd->u.s.diffuse.dwStride); > + sd->u.s.diffuse.lpData + stateblock->loadBaseVertexIndex * sd->u.s.diffuse.dwStride + offset[sd->u.s.diffuse.streamNo]); > checkGLcall("glColorPointer(4, GL_UNSIGNED_BYTE, ...)"); > glEnableClientState(GL_COLOR_ARRAY); > checkGLcall("glEnableClientState(GL_COLOR_ARRAY)"); > @@ -2411,7 +2413,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > } > GL_EXTCALL(glSecondaryColorPointerEXT)(4, GL_UNSIGNED_BYTE, > sd->u.s.specular.dwStride, > - sd->u.s.specular.lpData + stateblock->loadBaseVertexIndex * sd->u.s.specular.dwStride); > + sd->u.s.specular.lpData + stateblock->loadBaseVertexIndex * sd->u.s.specular.dwStride + offset[sd->u.s.specular.streamNo]); > vcheckGLcall("glSecondaryColorPointerEXT(4, GL_UNSIGNED_BYTE, ...)"); > glEnableClientState(GL_SECONDARY_COLOR_ARRAY_EXT); > vcheckGLcall("glEnableClientState(GL_SECONDARY_COLOR_ARRAY_EXT)"); > @@ -2476,7 +2478,7 @@ static void loadVertexData(IWineD3DStateBlockImpl *stateblock, WineDirect3DVerte > WINED3D_ATR_SIZE(sd->u.s.texCoords[coordIdx].dwType), > WINED3D_ATR_GLTYPE(sd->u.s.texCoords[coordIdx].dwType), > sd->u.s.texCoords[coordIdx].dwStride, > - sd->u.s.texCoords[coordIdx].lpData + stateblock->loadBaseVertexIndex * sd->u.s.texCoords[coordIdx].dwStride); > + sd->u.s.texCoords[coordIdx].lpData + stateblock->loadBaseVertexIndex * sd->u.s.texCoords[coordIdx].dwStride + offset[sd->u.s.texCoords[coordIdx].streamNo]); > glEnableClientState(GL_TEXTURE_COORD_ARRAY); > } > } else if (!GL_SUPPORT(NV_REGISTER_COMBINERS)) { > > > ------------------------------------------------------------------------ > >

1 0

Re: comctl32: center calendar in monthcal
by Lei Zhang Jan. 17, 2007

Jan. 17, 2007

Hi, Can we get this patch committed? It's a trivial fix to the calendar positioning, as seen here: http://linux.ucla.edu/~leiz/software/wine/screenshots/monthcal.png - Lei On 12/29/06, Lei Zhang <thestig(a)google.com> wrote: > The month calendar currently puts the calendar in the top-right corner > of the control window, it should be centered. > > --- > monthcal.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > >

1 0

The real DLL-Hell ("sfc.dll"), created by MS
by Detlef Riekenberg Jan. 16, 2007

Jan. 16, 2007

I verify my work on winspool.drv and localspl.dll with the native versions of "localspl.dll" in wine. To my surprise, localspl.dll/XP needs a native "sfc_os.dll", while localspl.dll/W2K is happy with our buildin "sfc.dll" Please remember: - "sfc.dll" was not present before w2k. - The "System File Checker" API was introduced in win98 (with a different API in "sfcdll.dll") MS produced the ugliest case of the DLL-Hell on ther own! Two total different DLL's with a different API, but the same name: http://support.microsoft.com/dllhelp/?dlltype=file&l=55&alpha=sfc.dll&S=1&x… --- cut -- SFC.DLL (13.Nov.1998) in MS Office 2000 Prof (Starfighter Foundation Classes v1.0 DLL) http://support.microsoft.com/dllhelp/default.aspx?l=55&fid=115535 sfc.dll (07.Dec.1999) in Windows 2000 Prof (Windows File Protection) http://support.microsoft.com/dllhelp/?fid=72785&l=55&det=1 -- cut --- And to make the things even worse, the "sfc.dll" from office has the Version "1998.*" Congratulations -- By by ... Detlef

1 0

WineD3D: ProcessVertices
by Christoph Bumiller Jan. 16, 2007

Jan. 16, 2007

Henri Verbeet wrote: > Well, you can't set a VBO as rendertarget directly, but you can copy > the FBO data into a PBO, which you can bind as a VBO. That's pretty > legitimate in OpenGL. But I was wondering how hard it would be to use > something like that for ProcessVertices. Well, you would get the rendered pixels' data written to the VBO then, right? To use this for ProcessVertices one would have to have a bijective relation between pixel's and processed vertices; p.e. pass the transformed vertex coordinates in varying variables and use'em as the color components and have the pixels stored in the order the vertices are so we can tell afterwards from what vertex they originate, in passing the vertex index as an attribute and so generate appropriate vertex coords ... theoretically. I don't think its easy or even possible to have exactly one pixel per vertex at sequential positions in the pixel buffer, or is it (using points and knowing the resolution etc.) ?

2 1

Time for wine-mono or wine-dotnet11 component in Bugzilla?
by Dan Kegel Jan. 16, 2007

Jan. 16, 2007

While filing http://bugs.winehq.org/show_bug.cgi?id=7098 I realized that I'm starting to see lots of apps that require dot net, and there are two ways we could go to support them: 1) get msft's dotnetfx.exe to install (see http://bugs.winehq.org/show_bug.cgi?id=5358) and work 2) whip our mono integration into shape (see http://kegel.com/wine/fakedotnet.sh ) The question is, how should we tag bugs in bugzilla that fail because neither of these approaches really work yet? Should we make them depend on bug 5358, or should we create a new bug component, wine-dotnet11 or wine-mono, and put them in there? Filing these bugs as wine-misc seems wrong, so I'm leaning towards a new bugzilla component. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 8

Getting GTK/W32 applications to run
by Peter Gerwinski Jan. 16, 2007

Jan. 16, 2007

Hello, WINE developers! While working on a cross-platform project, I tried to run some self-compiled GTK/W32 applications on a Debian GNU/Linux Sarge system using WINE 0.9.29, compiled from source. They crashed immediately. After some long, but unsuccessful Google sessions and some long, but successful RTFS/debugging sessions, I am now able to run and test my cross-compiled GTK/W32 applications in WINE. :-) Furthermore, I can start the W32 version of The GIMP up to the moment where it tries to load its plug-ins. (Without the plug-ins, the remaining parts of The GIMP even seem to work flawlessly.) Since Google told me that running GTK/W32 applications in WiNE - in particular: The GIMP - was an unsolved problem, I am hereby telling you what I observed and what I did. * Out of the box, pango (GTK's font renderer) does not find any suitable font. OTOH a non-GTK program, opening a MessageBox, works flawlessly, so the fonts are there. * When I tell pango to use a TrueType font *and* place the .ttf file in c:/windows/fonts/, I can start GTK's "Hello, world!" program, but the text is >300 pixels high, and thus unusable. (Real-world programs used to crash with a message similar to "memory exhausted", but trying to reproduce the exact message now results in *running* programs with a giant font. Sorry.) I conclude that (at least in my installation) pango does not find WINE's pixel fonts (even if I place them in c:/windows/fonts/), and sees the TTFs only with a wrong scaling factor. * When I tell pango to use the font "Sans 0.1", I get satisfying results. (In concrete, I got it working with the following gtkrc: style "wine-default-style" { font_name = "Sans 0.1" } widget "*" style "wine-default-style" ) I cannot fine-tune the font size. Using "Sans 0.2" or "Sans 0.01" yields exactly the same as "Sans 0.1". There seems to be one more intermediate size at "Sans 0.5"; after that the "normal" font sizes start with "Sans 1". Since both WINE and pango/GTK are free software, I am confident that these problems will be solved in the long run. I hope that you can use my observations. BTW, let me thank you for over 10 years of WINE by hacking Tom Payne's famous quote on Unix: Ten years ago mainstream users were choosing WABI over WINE. Now they are choosing $PROPRIETARY_FORK_OF_WINE over WINE. What part of that message aren't they getting? Keep on your excellent work! Cheers, Peter -- Dr. rer. nat. Peter Gerwinski - http://www.peter.gerwinski.de German pages for GNU & free software - http://www.gnu.de G-N-U GmbH - EDV-Dienstleistungen - http://www.g-n-u.de Essener Linux User Group - http://www.elug.de

3 4

Re: Alexandre Julliard : ntdll: Implemented NtLockVirtualMemory and NtUnlockVirtualMemory.
by Robert Shearman Jan. 16, 2007

Jan. 16, 2007

Alexandre Julliard wrote: > dlls/ntdll/virtual.c | 56 ++++++++++++++++++++++++++++++++++----- > include/wine/server_protocol.h | 32 +++++++++++++++++++++- > server/protocol.def | 30 ++++++++++++++++++++- > server/thread.c | 2 + > server/trace.c | 18 +++++++++++++ > 5 files changed, 127 insertions(+), 11 deletions(-) > It looks like the part of the commit to handle APC_VIRTUAL_LOCK/UNLOCK in call_apcs in dlls/ntdll/sync.c has been omitted. -- Rob Shearman

1 0

Re: iphlpapi - MacOS / BSD support
by Stefan Dösinger Jan. 16, 2007

Jan. 16, 2007

Am Dienstag 16 Januar 2007 03:17 schrieb Gavriel State: > Author: Mark Adams <mark(a)transgaming.com> > > ChangeLog: > - Clarify interface counting > - Filter out no-ip addresses when building ip address table > - Add error messages when unimplemented functions are called on > non-linux platforms (ie: platforms without routing info in /proc) > - Implement retrieving the interface list on MacOS X (and other > platforms that use NET_RT_DUMP) I don't know the iphlpapi code, but the changelog suggests to me that the changes should be split up into seperate patches.

1 0

Re: iphlpapi - MacOS / BSD support
by Francois Gouget Jan. 16, 2007

Jan. 16, 2007

--- iphlpapi/ifenum.c 21 Dec 2006 16:37:51 -0000 1.25 +++ iphlpapi/ifenum.c 15 Jan 2007 23:16:54 -0000 @@ -22,7 +22,7 @@ [...] - * - using the sysctl interface (FreeBSD and Mac OS X) + * - using the sysctl interface (FreeBSD and MacOS X) Just a small note; based on the Apple website I think the original spelling was correct. But don't worry about it, my 'typos' script should pick it up once your patch is committed and I will send a fix for it then. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

1 0

Re: [dinput 4/5] Add a config for the axes
by Vitaliy Margolen Jan. 16, 2007

Jan. 16, 2007

Christoph Frick wrote: > Add a config for the axes like we do for the buttons > > This adds a mapping from the linux input id of the axis to the instance id > we assigned the axis. > --- > df->rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(axis++) | DIDFT_ABSAXIS; > } > - for (i = 0; i < 4; i++) > + > + idx = WINE_JOYSTICK_MAX_AXES; Why are you creating a gap? This is exactly the point here to skip all the objects that we do not have. And they all need to be sequential in godf - no gaps. Otherwise you braking EnumObjects. Vitaliy.

2 2

re: iphlpapi - MacOS / BSD support
by Dan Kegel Jan. 16, 2007

Jan. 16, 2007

Hi Gav! You wrote: >Author: Mark Adams <mark at transgaming.com> >... Cool... nice to see you on wine-patches again! For completeness, can you specify the license your patches are under? I assume MIT/X11...? - Dan

2 1

Re: user32/tests: add tests for WM_SETICON
by Dmitry Timoshkov Jan. 16, 2007

Jan. 16, 2007

"Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > + /* Message sequences for WM_SETICON */ > + hwnd = CreateWindowExA(0, "TestWindowClass", NULL, > + WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, > + NULL, NULL, 0); > + flush_sequence(); > + SendMessage(hwnd, WM_SETICON, ICON_SMALL, (LPARAM)LoadIcon(0, IDI_APPLICATION)); > + ok_sequence(WmSetIcon, "WM_SETICON for window with caption", FALSE); This code doesn't show behaviour of a more interesting case - a visible window. -- Dmitry.

1 0

Re: appdb rating inflation
by Jesse Allen Jan. 15, 2007

Jan. 15, 2007

Whoever it is that is wanting to update the HOWTO for the Diablo 2 appdb please email me. I don't have my email address on there for nothing. For whatever reason, I can't see who changes things nor does the appdb email me on changes anymore. Quote from new HOWTO note. "THIS IS A DUPLICATE ENTRY. I am making this simply because lots of the information in the original howto is either wrong, invalid or unnecessary. This is the new HOWTO. I'm leaving the old one in place so that the ones that wrote it can see the changes and voice anything before I remove the old one entirely. " I read it and you really did not change anything. But I will say that that YES the HOWTO is mostly unnessecary. However, when I tried going to a skeletal HOWTO, I got a bunch of odd complaints (especially on the CD-ROM info you removed). Also note, that the HOWTO duplicates the War3 one just because it's the same in almost every way. Jesse

1 0

Re: oleaut32: Remove unused items
by Michael Stefaniuc Jan. 15, 2007

Jan. 15, 2007

Andrew Talbot wrote: > Changelog: > oleaut32: Remove unused items. > > diff -urN a/dlls/oleaut32/vartype.c b/dlls/oleaut32/vartype.c > --- a/dlls/oleaut32/vartype.c 2006-12-22 14:43:36.000000000 +0000 > +++ b/dlls/oleaut32/vartype.c 2007-01-13 20:13:23.000000000 +0000 > @@ -228,7 +228,6 @@ > SIMPLE(LONG64, SHORT, VarI8FromI2); > SIMPLE(LONG64, signed char, VarI8FromI1); > SIMPLE(LONG64, USHORT, VarI8FromUI2); > -SIMPLE(LONG64, LONG, VarI8FromI4); Are you removing a test here? > SIMPLE(LONG64, ULONG, VarI8FromUI4); > POSTST(LONG64, ULONG64, VarI8FromUI8, I8_MAX); bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

Some stats (Was: Re: Alexandre Julliard : oleaut32/tests: Replace some macros by functions to reduce code size and compile time.)
by Michael Stefaniuc Jan. 15, 2007

Jan. 15, 2007

Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 25571d878960cd802aa31f291d473888dc01e035 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=25571d878960cd802aa31f291… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Jan 15 13:01:42 2007 +0100 > > oleaut32/tests: Replace some macros by functions to reduce code size and compile time. Some compile stats for vartest.c on my P4 3GHz HT, 2 GB RAM, FC6, gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) -O0 -O1 -O2 -O3 -Os size vartest.o with -O2 before 9s 38s 60s 870s 750s 1352256 after 3s 23s 35s 41s 42s 474300 I would say impressive, especially the -O3 and -Os changes. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0