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

u_int32_t
by Robert Lunnon Oct. 16, 2006

Oct. 16, 2006

Seems these typedefs have found their way into some of the source files, from my recollection these definitions aren't used. What is the official typedef for these types; IE u_int32_t uint32_t or UINT32

4 3

Re: [winex11.drv] client-side DIB copy
by Alexandre Julliard Oct. 16, 2006

Oct. 16, 2006

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > + switch (dstDib.dsBm.bmBitsPixel) > + { > + case 1: > + widthBytes = (width + 7) / 8; > + srcOffsetBytes = (xSrc + 7) / 8; > + dstOffsetBytes = (xDst + 7) / 8; > + break; > + case 4: > + widthBytes = (width + 1) / 2; > + srcOffsetBytes = (xSrc + 1) / 2; > + dstOffsetBytes = (xDst + 1) / 2; > + break; You can't simply round size up, you have to handle partial bytes properly. > + case 24: > + widthBytes = width * 2; > + srcOffsetBytes = xSrc * 2; > + dstOffsetBytes = xDst * 2; > + break; I don't think you can fix 24 bits in two bytes... A bigger problem is that you also need to handle the clip region of the destination DC, and only copy the pixels that aren't clipped out. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Win64 printf format warning fixes.
by Alexandre Julliard Oct. 16, 2006

Oct. 16, 2006

Hans Leidekker <hans(a)it.vu.nl> writes: > I needed two casts to silence warnings arising from the fact > that ULONG/DWORD and SIZE_T are no longer compatible: > > dlls/ntdll/loader.c:1290 > dlls/ntdll/relay.c:651 You can't simply cast them since the types will have different sizes on Win64. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msvcrt: Make _ecvt and _fcvt work (again)
by Jesse Allen Oct. 16, 2006

Oct. 16, 2006

On 10/15/06, Stephen Moehle <smoehle(a)comcast.net> wrote: > Please ignore my previous patch for this. _ecvt and _fcvt needed a lot > more work than I first realized. The existing code had at least the > following problems: added a decimal point to the output, used scientific > notation in the output, did not remove the leading '-' for negative > numbers, and got the decimal point offset wrong for numbers like 0.0003. > This patch fixes all that and very closely matches the behavior of ecvt > an fcvt in glibc and _ecvt and _fcvt in Visual Studio 2005. I have > dropped the changes to _gcvt. I will deal with that later. > > I have another patch that I will submit shortly that simply implements > _ecvt and _fcvt in terms of ecvt_r and fcvt_r. I actually like that > patch better since it is much simpler and leverages glibc better. I am > submitting both patches because I am not sure why ecvt_r and fcvt_r were > not used in the first place. Maybe they are not portable enough or > something like that. > I'm not sure that this will be accepted. Portability is really important. I think our float implementation might be wrong from what I remember. You ought to add test cases.

1 0

Re: [PATCH 1/3] x11drv: Move cached cursor position from under x11's lock and into it's own.
by Mike McCormack Oct. 16, 2006

Oct. 16, 2006

Vitaliy Margolen wrote: > dlls/winex11.drv/mouse.c | 43 +++++++++++++++++++++++++++++++++---------- ... > POINT cursor_pos; > > +static CRITICAL_SECTION cursor_CritSection; There's a reference to cursor_pos in dlls/winex11.drv/keyboard.c too, and you're missing a critical section around it. Mike

2 1

Re: [Bug 6445] Wine Control Panel error "Cannot load any applets"
by c.saris1＠chello.nl Oct. 15, 2006

Oct. 15, 2006

Actually, "Control Panel" (control.exe) has (limited) usability (configuration of wine - ODBC, and display for example). What you have to do is copy .cpl files from an existing windows machine (probably from c:\winnt\system32 dir.) to your wine system dir (probably c:\windows\system32) and do a lot of trial and error with native/builtin configuration of control.exe. Some .cpl files make wine crash, e.g. "intl.cpl" (at least, in my case). Good luck (you'll need it!) > > van: Wine Bugs <wine-bugs(a)winehq.org> > datum: 2006/10/15 Sun AM 06:23:58 MEST > aan: wine-bugs(a)winehq.org > onderwerp: [Bug 6445] Wine Control Panel error "Cannot load any applets" > > http://bugs.winehq.org/show_bug.cgi?id=6445 > > > vitaliy(a)kievinfo.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Severity|blocker |enhancement > Component|wine-console |wine-programs > > > > > ------- Additional Comments From vitaliy(a)kievinfo.com 2006-14-10 23:23 ------- > Because there are none. Use 'winecfg' to configure Wine. > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > >

1 0

adding undocumented APIs to public headers
by James Hawkins Oct. 15, 2006

Oct. 15, 2006

Hey guys, What is our policy on adding undocumented functions to Wine's public headers? My stance is that we, as an alternative implementation of the Win32 API, provide another set of Win32 public headers, like Microsoft and cygwin/mingw provide as well. If our headers contain undocumented functions that no other headers have, then we're just that much more complete. I've always thought of the Wine code base as documentation for the Win32 API, especially in places where there is no documentation from Microsoft. There are several places where -Wmissing-declarations warns about missing declarations for exported APIs. A lot of these have no corresponding entry in Microsoft's public headers. Adding these declarations gets rid of the warnings and makes our headers more complete. What are your thoughts on this matter? -- James Hawkins

4 3

Re: ntdll: fix return values for NtQueryInformationThread ThreadDescriptorTableEntry
by Eric Pouech Oct. 15, 2006

Oct. 15, 2006

Peter Oberndorfer wrote: >this makes info segments in winedbg not spew out thousands of "fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000119" > >Changelog: >fix return values for NtQueryInformationThread ThreadDescriptorTableEntry > > the fix is wrong as STATUS_NO_LDT is the value returned on NT by NtQueryInformationThread you have either to fix the mapping to ntstatus to win32 errors (if this one is supported on NT), or fix GetThreadSelectorEntry by hand (for the ntstatus to win32 error mapping) A+

1 0

Re: [D3D9] fix for SetFVF memleak [2nd try+patch]
by Ivan Gyurdiev Oct. 15, 2006

Oct. 15, 2006

Karsten Elfenbein wrote: > * don't prevent IUnknown_Release of pDecl in the exit section and fix > for http://bugs.winehq.org/show_bug.cgi?id=5656 > This seems wrong, d3d9 does not keep an internal reference of the vdecl. Try the attached patch instead, let me know if it works... --- dlls/d3d9/d3d9_private.h | 4 ++++ dlls/d3d9/device.c | 1 + dlls/d3d9/vertexdeclaration.c | 6 +++++- 3 files changed, 10 insertions(+), 1 deletions(-) diff --git a/dlls/d3d9/d3d9_private.h b/dlls/d3d9/d3d9_private.h index 2d6397e..c5cef9f 100644 --- a/dlls/d3d9/d3d9_private.h +++ b/dlls/d3d9/d3d9_private.h @@ -176,6 +176,10 @@ typedef struct IDirect3DDevice9Impl /* IDirect3DDevice9 fields */ IWineD3DDevice *WineD3DDevice; + /* A vertex declaration was converted from setFVF. + * Keep track of it, so it can be properly freed */ + IDirect3DVertexDeclaration9 *convertedDecl; + } IDirect3DDevice9Impl; diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c index 6eeaceb..185a7ef 100644 --- a/dlls/d3d9/device.c +++ b/dlls/d3d9/device.c @@ -731,6 +731,7 @@ HRESULT WINAPI IDirect3DDevice9Impl_Se hr = IDirect3DDevice9Impl_SetVertexDeclaration(iface, pDecl); if (hr != S_OK) goto exit; + This->convertedDecl = pDecl; pDecl = NULL; exit: diff --git a/dlls/d3d9/vertexdeclaration.c b/dlls/d3d9/vertexdeclaration.c index 246b52f..88f5909 100644 --- a/dlls/d3d9/vertexdeclaration.c +++ b/dlls/d3d9/vertexdeclaration.c @@ -300,8 +300,12 @@ HRESULT WINAPI IDirect3DDevice9Impl_Se IDirect3DVertexDeclaration9Impl *pDeclImpl = (IDirect3DVertexDeclaration9Impl *)pDecl; HRESULT hr = D3D_OK; - TRACE("(%p) : Relay\n", iface); + if (This->convertedDecl && This->convertedDecl != pDecl) { + IUnknown_Release(This->convertedDecl); + This->convertedDecl = NULL; + } + TRACE("(%p) : Relay\n", iface); hr = IWineD3DDevice_SetVertexDeclaration(This->WineD3DDevice, pDeclImpl == NULL ? NULL : pDeclImpl->wineD3DVertexDeclaration); return hr; -- 1.4.2.1

3 9

Re: winetest: don't start test programs with STARTUPINFO.wShowWindow = SW_HIDE
by Francois Gouget Oct. 15, 2006

Oct. 15, 2006

On Sat, 14 Oct 2006, Mikoaj Zalewski wrote: > It no one knowns why this option is there then maybe it's safe to remove it? - si.wShowWindow = SW_HIDE; - si.dwFlags = STARTF_USESHOWWINDOW; + si.dwFlags = 0; Isn't this an attempt to make it so that running make test does not pop up windows that grab the focus and do things that prevent you from using the computer? Though some test do grab the focus and such which I guess means they're manually changing the state of the window.. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

2 1