wine-devel October 2006

wine-devel@winehq.org

142 participants
266 discussions

advertising on winehq
by Tom Wickline 24 Oct '06

24 Oct '06

Hello, May I ask what you guys think about us starting to run some google ads on winehq ? With free software there are limited ways for a project to take in revenue and the two most common ways are by donations and running advertisements on a site. I don't in any way suggest we should become a flashing flash based site with obnoxious pop-ups and the likes. But I do believe we should however look into running small user friendly adverts from well respected companies such as google. And of course any money generated should go to the wpf to help support future wine confs. Comments? Tom

3 3

Re: comctl32: Hack for imagelist width greater than 2^16 (bug #3573)
by Robert Shearman 24 Oct '06

24 Oct '06

Mike McCormack wrote: > --- > > This hack is for bug #3573. I don't expect it to be applied to Wine, > but perhaps it will give somebody some insight into solving the bug. > > WinRAR calls ImageList create and asks for an ImageList for 256 > images, *expandable* to 2048. It doesn't actually use 2048 images: > > ImageList_Create (16 16 0x21 256 2048) > > 2048*256 is a bitmap wider than X.org wants, so it fails with a > BadAlloc error. > > The correct solution is to rewrite the imagelist code to either > > 1) Allocate the bitmap on demand > > or > > 2) Store images in separate DIB sections. or 3) Store the images in an M/N x N format instead of an M x 1 format. -- Rob Shearman

1 0

Re: riched20: Make sure to use GlobalAlloc with GlobalFree.
by Robert Shearman 24 Oct '06

24 Oct '06

Mike McCormack wrote: > ret->ref = 1; > ret->cur = 0; > ret->fmtetc_cnt = fmtetc_cnt; > - ret->fmtetc = HeapAlloc(GetProcessHeap(), 0, fmtetc_cnt*sizeof(FORMATETC)); > + ret->fmtetc = GlobalAlloc(GMEM_ZEROINIT, fmtetc_cnt*sizeof(FORMATETC)); > memcpy(ret->fmtetc, fmtetc, fmtetc_cnt*sizeof(FORMATETC)); > *lplpformatetc = (LPENUMFORMATETC)ret; > return S_OK; Why use GMEM_ZEROINIT when you initialise all of the memory straight after the GlobalAlloc call? -- Rob Shearman

1 0

Re: oleidl.idl must include windows.h and ole2.h if COM_NO_WINDOWS_H is not defined.
by Alexandre Julliard 24 Oct '06

24 Oct '06

Francois Gouget <fgouget(a)free.fr> writes: > 2) Or modify these sections so they read: > > #if !defined(COM_NO_WINDOWS_H) && !defined(__WINESRC__) > # include <windows.h> > # include <ole2.h> > #endif I think we want that, otherwise we'll end up having to add COM_NO_WINDOWS_H to pretty much every single source file. -- Alexandre Julliard julliard(a)winehq.org

3 5

WineD3D State management - going live(TM)
by Stefan Dösinger 24 Oct '06

24 Oct '06

Hi, I considererd that it would be finally time to get started with the state management rewrite :-) Just a mail with the final plan, if anyone has comments. I will move the functions applying the states into a new file, opengl_utils.c(name inspired by old ddraw). I don't want to put them into drawprim.c because that file is already quite long. For the start I will manage changed states per device, and not per context because for per context tracking I'd like to have thread safety which will take a bit longer to commit. The changed states will be managed in a standard wine list, with pointers to the dirty elements from the stateblock(the state.changed field). This will allow us to work efficiently with the list: * Add an element: Constant complexity * Remove an element: const * Check if an element exists: const(look at the stateblock) * Empty the list: const * apply the changed states from the list: linearly growing with the number of dirty states, max the number of existing states. I I will chain empty elements in a 2nd list to avoid unneccessary HeapAlloc and HeapFree calls. Many d3d games spend 10% processing time in heap management already :-/ All states(render state, sampler, texture stage, bound textures, shaders, vertex type) will share the same list. The index of the changed state will identify the type of the state, e.g. #define renderstate_entry(a) (a + 0) #define samplerstate_entry(a) (a + 1000) /* or renderstate_entry(max_render_state) #define texturestate_entry(a) (a + 2000) and so on This will allow us to group different states, e.g. D3DRS_LIGHTINGENABLE with the vertex type. As many d3d states affect the same opengl state(e.g. D3DRS_FOGVERTEXMODE, D3DRS_FOGTABLEMODE, D3DRS_FOGSTART, D3DRS_FOGEND), the states can be grouped together for efficient application. This also works accross different types. When a state is marked dirty the Set*State function checked if the state gropup representative is already marked dirty, and if yes then the state isn't put on the list again. This keeps the list size <= the number of known states, and avoids applying the same state 2 times :-) States will be applied in drawprim. BltOverride and UnlockRect change states on their own, and they can put the states the change onto the dirty list so drawprim will reset them to what the application wants. This avoids gratious setting and resetting. An extra last_was_blt field could be used to avoid that bltoverride sets its own states again and again. Any comments on that? Stefan

5 34

Re: comctl32: Hack for imagelist width greater than 2^16 (bug #3573)
by Marcus Meissner 24 Oct '06

24 Oct '06

On Tue, Oct 24, 2006 at 06:11:30PM +0900, Mike McCormack wrote: > --- > > This hack is for bug #3573. I don't expect it to be applied to Wine, > but perhaps it will give somebody some insight into solving the bug. > > WinRAR calls ImageList create and asks for an ImageList for 256 images, > *expandable* to 2048. It doesn't actually use 2048 images: > > ImageList_Create (16 16 0x21 256 2048) > > 2048*256 is a bitmap wider than X.org wants, so it fails with a BadAlloc > error. Actually 2048*16 is too wide. > The correct solution is to rewrite the imagelist code to either > > 1) Allocate the bitmap on demand > > or > > 2) Store images in separate DIB sections. 3) Allocate in a 4 image deep band like Windows does. Ciao, Marcus

1 0

Re: Extra info on d3dsurface crash
by Stefan Dösinger 24 Oct '06

24 Oct '06

Am Montag 23 Oktober 2006 22:46 schrieb Robert Lunnon: > I think you are right about that, an accurate diagnostic would be helpful > and prompt someone to write the decompression code, if it's not hard I > could do that.. > > This application used to work before the d3d stuff went in (perhaps a > fall-back) If I sent you a copy of the app could you test under linux to > see if the behaviour is the same (I develop the Solaris version). It is certainly not hard, and the old ddraw code had decompression support. The issue is more a legal one. VIA holds a patent on s3tc compression. There is a s3tc compression/decompression library available(http://homepage.hispeed.ch/rscheidegger/dri_experimental/s3tc_index.html), but the legal situation of using it is difficult. The old ddraw code used that lib, if available, to work with s3tc surfaces. You can basically just copypaste the code from old ddraw(wine 0.9.15, dlls/ddraw/surface_dib.c I think) and see if that helps. A different way would be to use opengl to upload the compressed texture and read it back uncompressed, but this is tricky from a wined3d point of view because surface_gdi.c is supposed to work completely without opengl.

1 0

riched20: Add leak detection code.
by Mike McCormack 24 Oct '06

24 Oct '06

--- Hi, This code is mainly for debugging. I don't expect it to be applied, but don't object if it is. It exposes a number of memory leaks in richedit. For example, running the richedit regression test shows leaks at: line 248 file editor.c line 1120 file editor.c line 2230 file editor.c line 355 file string.c line 82 file undo.c line 2342 file reader.c line 2240 file editor.c line 32 file string.c line 35 file string.c line 145 file list.c etc. To use it, simply apply the attached patch, and run your favourite program that uses the richedit control. (Assumes you have the previous two patches I sent to wine-patches applied.) Mike dlls/riched20/editor.c | 33 +++++++++++++++++++ dlls/riched20/editor.h | 84 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 117 insertions(+), 0 deletions(-)

1 0

Run-time error 445
by David Anderson 24 Oct '06

24 Oct '06

An app (apparently Visual Basic) fails with Run-time error '445' Object doesn't support this action in a message box. I click OK (the only choice) and the app dies. A winedbg breakpoint on MessageBoxA does not trigger. On one occasion I got a breakpoint to work and a traceback and the traceback ended in MSVBVM60 . But by yesterday I don't seem to be able to get it to stop in a useful breakpoint (meaning one that had anything to do with the problem). Break)nFirstChance is 0 as if it's 1 there are sooo many stops and so little progress... Anyone with a clue about this? I'd appreciate any hints. Thanks.

4 3

Re: gdi32: Remove call to CreateCompatibleDC() from GetDIBits() implementation (try 1)
by Huw Davies 23 Oct '06

23 Oct '06

On Fri, Oct 20, 2006 at 05:49:09PM -0500, Alex Villacís Lasso wrote: > This is the first attempt at a patch that will fix the debug assertion > when icons are rendered into metafiles (triggered by Enterprise > Architect 6.5, and possibly others). This patch simply removes mentions > of memdc, created by a call to CreateCompatibleDC(), and redirects calls > to GetDIBColorTable() to use the original DC instead of memdc. Intends > to fix bug #6439. Now with patch. > This can't work, since the bitmap needs to be selected into the dc for GetDIBColorTable to succeed and you're not allow to call GetDIBits with the bitmap selected into the dc... Huw. -- Huw Davies huw(a)codeweavers.com

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2006