December 2005 - Wine-devel - list.winehq.org

Bug 3885
by Tom Spear 21 Dec '05

21 Dec '05

Hi, I was working on bug 3885 tonight, and am stuck now.. Could someone take a look and test a couple of things? I'm running 2.6 series kernel, and it keeps dieing into the debugger before the main window opens. I think that it will sart with builtin msvcrt with 2.4 series kernel, but not 2.6, but since I'm in the middle of another project, I cant reboot to find out. It will at least start under both series for sure with native msvcrt. Louis Lenders removed a trace line from wine and recompiled and it started, even with builtin, which is kinda weird, since he didnt run it with any traces. So it may be a combination of a bug in that trace, and a bug in the 2.6 kernel.. Once running the app, with either builtin or native msvcrt, it goes thru the first benchmark and then spits out an error dialog box when it goes to start the next one, regardless of which benchmarks the app is told to test.. IOW, you can tell it to run #1 and #2, and it will spit out the error before starting #2, and take you back to the main app window. Or you can tell it to run #1 and #3, and same happens, or you can tell it to run #2 and #3, and same happens, so its not something to do with the way wine is handling the benchmark itself. Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there. If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems. If we can get it to start on 2.4 and 2.6 with builtin and get it to go all the way to mark 16 before it spits out an error, then that will be another bug closed, and I will file a separate one for mark 16.. Tom

2 1

[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

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(a)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(a)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