wine-devel December 2005

wine-devel@winehq.org

147 participants
299 discussions

[wined3d] Code questions
by Aric Cyr 21 Dec '05

21 Dec '05

I just have a couple wined3d code questions/comments that I'd like to clear up and possible submit patches if my understanding is correct. If I am misunderstanding the code please correct me. 1) basetexture.c:BindTexture() Just _before_ we call glBindTexture we call glTexParameteri and either set GL_TEXTURE_MAX_LEVEL or GL_TEXTURE_MIN_FILTER. The comment in the code is: "Always need to reset the number of mipmap levels when rebinding as it is a property of the active texture unit, and another texture may have set it to a different value" However, this doesn't make any sense to me and I believe it to be incorrect. glTexParameter affects the currently bound texture object. If the current and next texture to be bound have different mipmaps levels or parameters it should not be necessary to change these settings as all the state is encapsulated correctly in the OpenGL texture object, which should have been initialized correctly in Device::CreateTexture or BaseTexture::ApplyStateChanges. The reason the current code is bad is two-fold: 1) unneeded state changes on a performance critical path, as texture binding is very frequent and 2) changing the state of a _previous_ texture object, not the current one. The next time we go to use that texture object we will have to reapply all of it's state again, another waste of time. I spent a lot of the weekend debugging wined3d (trying to get anisotropic working in World of Warcraft) and just commenting out the block of code greatly cut down on d3d trace messages and makes the code easier to understand (and faster). 2) device.c::SetupTextureStates() Similar to my previous remark, there seems to be an incorrect state change here as well. glTexEnvf(TEXTURE_FILTER_CONTROL, LOAD_BIAS), glBlendColor() and then glTexEnvfv(TEXTURE_ENV, TEXTURE_ENV_COLOR) are called. All of these are called for each texture state update. However these are all global render states, not per-texture contrary to the comment in the code. Since these states are already being set in Device::SetRenderState() I'm pretty sure they don't need to be set here as well. Well that's all for now. Having started to really dig into wined3d, it seems that some effort in cleaning it up (coding style is way off) and stablizing it before it gets much more unwieldy is due. I'm also willing to help with such a task if there is a consensus that it should be done. Regards, Aric

2 2

Re: PATCH: wctime / wasctime
by Robert Shearman 21 Dec '05

21 Dec '05

Marcus Meissner wrote: >@@ -88,6 +88,8 @@ > MSVCRT_unexpected_function unexpected_handler; > MSVCRT__se_translator_function se_translator; > EXCEPTION_RECORD *exc_record; >+ MSVCRT_wchar_t *wctime_buffer; /* buffer for ctime */ >+ MSVCRT_wchar_t *wasctime_buffer; /* buffer for asctime */ > }; > You need to free these buffers on thread destruction. -- Rob Shearman

1 0

has the LGPL licence fell through ?
by Tom Wickline 21 Dec '05

21 Dec '05

Yes I have read the licence just re read it for that matter... So why no patches from SpecOps? should Wine move to GPL to keep from being robbed of its code? If your wondering why I'm ranting : http://news.inq7.net/infotech/index.php?index=1&story_id=60585 Tom

10 15

Re: Bill Medland : msi: Use a default dialog font if nothing is specified.
by Bill Medland 20 Dec '05

20 Dec '05

On December 20, 2005 02:56 am, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: e0d4df6bb7c009c8cbfa579c22c8d9406025f65c > URL: > http://source.winehq.org/git/?p=wine.git;a=commit;h=e0d4df6bb7 >c009c8cbfa579c22c8d9406025f65c > > Author: Bill Medland <billmedland(a)mercuryspeed.com> > Date: Tue Dec 20 11:59:23 2005 +0100 > > msi: Use a default dialog font if nothing is specified. > > --- > > dlls/msi/dialog.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/dlls/msi/dialog.c b/dlls/msi/dialog.c > index 87e14e8..c4f9d2c 100644 > --- a/dlls/msi/dialog.c > +++ b/dlls/msi/dialog.c > @@ -1618,6 +1618,8 @@ static LRESULT msi_dialog_oncreate( HWND > { > static const WCHAR df[] = { > 'D','e','f','a','u','l','t','U','I','F','o','n','t',0 > }; + static const WCHAR dfv[] = { > + 'M','S',' ','S','h','e','l','l',' ','D','l','g',0 }; > msi_dialog *dialog = (msi_dialog*) cs->lpCreateParams; > MSIRECORD *rec = NULL; > LPWSTR title = NULL; > @@ -1644,6 +1646,11 @@ static LRESULT msi_dialog_oncreate( > HWND dialog->attributes = MSI_RecordGetInteger( rec, 6 ); > > dialog->default_font = msi_dup_property( dialog->package, > df ); + if (!dialog->default_font) > + { > + dialog->default_font = strdupW(dfv); Thanks for tidying and submitting this, Alexandre. Just asking; we are confident that strdupW is symmetric with msi_free, aren't we? That was why I had the three-line "msi_strdupW" > + if (!dialog->default_font) return -1; > + } > > title = msi_get_deformatted_field( dialog->package, rec, > 7 ); SetWindowTextW( hwnd, title ); -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

Re: sound enabled but no driver checked
by Cihan Altinay 20 Dec '05

20 Dec '05

Quoting Robert Reif <reif(a)earthlink.net>: > Cihan Altinay wrote: > > >With a fresh wine prefix sound is enabled but I can't > >see which driver is used because none of them is checked > >in the new winecfg sound dialog. > >Did we forget to initialize the boxes on first run? > > > >Cheers, > >Cihan > > > Use regedit to show HKCU/Software/wine/Drivers/Audio. > Chances are it's empty (no drivers checked) so sound is > disabled. It could be set to a driver that is not available > but winecfg checks for that and should give you an error. Well... the key doesn't exist unless I run winecfg at least once and change something. In that case it's not really important because a user will probably do that anyway. The only minor issue would be that someone runs winecfg for the first time and is satisfied with the defaults (no driver checked -> sound off) so without any changes he dismisses winecfg. And in this case it seems one of the drivers is used by default (sound on). Cheers, Cihan

1 0

Re: [lostwages] Remove winetools from download page
by James Hawkins 20 Dec '05

20 Dec '05

On 12/20/05, Vitaliy Margolen <wine-patch(a)kievinfo.com> wrote: > I can't say how many people have come to #winehq with different problems > that were related to winetools. From what I could see, not a single > person who I talked to had winetools installed and had Wine programs > working properly. > I agree. Winetools goes against our goal of not using native dlls, and takes away needed testing of our builtin dlls. If people decide to use it on their own, then that's cool with me, but we shouldn't promote its use. -- James Hawkins

3 2

PATCH/RFC: defer OLE apartment window creation
by Marcus Meissner 20 Dec '05

20 Dec '05

Hi, RFC ... since its likely not the clean way Robert wants. This defers the appartment window creation until it is actually need. Ciao, Marcus Changelog: Defer OLE apartment window creation until it is actually needed. Index: dlls/ole32/compobj.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.168 diff -u -r1.168 compobj.c --- dlls/ole32/compobj.c 12 Nov 2005 19:11:21 -0000 1.168 +++ dlls/ole32/compobj.c 20 Dec 2005 22:06:39 -0000 @@ -236,9 +236,6 @@ { /* FIXME: should be randomly generated by in an RPC call to rpcss */ apt->oxid = ((OXID)GetCurrentProcessId() << 32) | GetCurrentThreadId(); - apt->win = CreateWindowW(wszAptWinClass, NULL, 0, - 0, 0, 0, 0, - 0, 0, OLE32_hInstance, NULL); } else { @@ -257,6 +254,15 @@ return apt; } +void make_apartment_window(APARTMENT *apt) { + if (apt->win) return; + if (!(apt->model & COINIT_APARTMENTTHREADED)) + return; + apt->win = CreateWindowW(wszAptWinClass, NULL, 0, + 0, 0, 0, 0, + 0, 0, OLE32_hInstance, NULL); +} + /* gets and existing apartment if one exists or otherwise creates an apartment * structure which stores OLE apartment-local information and stores a pointer * to it in the thread-local storage */ Index: dlls/ole32/compobj_private.h =================================================================== RCS file: /home/wine/wine/dlls/ole32/compobj_private.h,v retrieving revision 1.60 diff -u -r1.60 compobj_private.h --- dlls/ole32/compobj_private.h 28 Nov 2005 11:04:18 -0000 1.60 +++ dlls/ole32/compobj_private.h 20 Dec 2005 22:06:39 -0000 @@ -253,6 +253,8 @@ return COM_CurrentInfo()->apt; } +void make_apartment_window(APARTMENT *apt); + #define ICOM_THIS_MULTI(impl,field,iface) impl* const This=(impl*)((char*)(iface) - offsetof(impl,field)) /* helpers for debugging */ Index: dlls/ole32/rpc.c =================================================================== RCS file: /home/wine/wine/dlls/ole32/rpc.c,v retrieving revision 1.72 diff -u -r1.72 rpc.c --- dlls/ole32/rpc.c 19 Dec 2005 20:24:25 -0000 1.72 +++ dlls/ole32/rpc.c 20 Dec 2005 22:06:39 -0000 @@ -257,6 +257,7 @@ TRACE("Calling apartment thread 0x%08lx...\n", apt->tid); + if (!apt->win) make_apartment_window(apt); PostMessageW(apt->win, DM_EXECUTERPC, 0, (LPARAM)params); } else @@ -498,6 +499,7 @@ TRACE("Calling apartment thread 0x%08lx...\n", apt->tid); + if (!apt->win) make_apartment_window(apt); PostMessageW(apt->win, DM_EXECUTERPC, 0, (LPARAM)params); WaitForSingleObject(params->handle, INFINITE); CloseHandle(params->handle);

1 0

Testing WideCharToMultiByte
by Bill Medland 20 Dec '05

20 Dec '05

Has anyone ever done a proper investigation into the edges of WideCharToMultiByte? I was quite surprised to see that given how important it is there is no test for it (or am I blind?) I am investigating a potential off-by-one in msi and want to know very exactly what is supposed to happen in the edge cases (e.g. specifying a length of 0 or a length that does not actually include a terminating null character or ...). If no-one else is involved then I am prepared to do a little investigation and write the tests but I guess we don't want to start adding tests like that at this late stage, or do we? -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

2 1

errors fixed with crossoffice
by Curro Amores 20 Dec '05

20 Dec '05

Hi i have a problem with wine and my access97 reports Letters are show separated and bigger. However using crossoffice i dont have this problem. How can i know where is the problem i have installed freetype, fontconfig last versions, copied all my ttf files... thanks

2 1

Re: WLDAP32: link to the reentrant version of libldap
by Alexandre Julliard 20 Dec '05

20 Dec '05

Hans Leidekker <hans(a)it.vu.nl> writes: > On Monday 19 December 2005 20:47, Alexandre Julliard wrote: > >> It's really not much more work to do it right the first time around, > > Thanks for calling me lazy ;-) I wasn't worried about the amount of > work, I was looking ahead thinking about how distro x version y might > need another check for some missing functions, and they would start > adding up. There was a time when the ldap_*_ext functions didn't > exist for example. This library has quite a long history. All the more reason to check for the functions we are actually using. If there are more library variants to check for, it won't be manageable to only check for a function or two and then attempt to guess which other functions may or may not be defined. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
30
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 December 2005