September 2006 - Wine-Devel

todo_wine problems

by Jeff L

I am having trouble with getting todo_wine working. It seems to be ignored and the test is being executed on wine and failing as expected. Is there a trick to setting todo up? According to all the examples and the text this should work: todo_wine { ok(hr == S_OK, "ScriptStringOut Stub should return S_OK not %08lx\n", hr); } Jeff

Sept. 30, 2006

Re: dlls/user/tests/win.c fix

by Dmitry Timoshkov

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > The attached patch (sorry, crappy mailer) fixes the win.c failure I was > seeing. Is it correct? No it's not correct. Does the attached patch fix the failure? -- Dmitry.

Sept. 30, 2006

Re: Yesterday's (6/28) Git (gdi32) updates break 64-bit compilation.

by Dmitry Timoshkov

"Evil Jay" <evil(a)eternaldusk.com> wrote: > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.n0hnjc.o) is not > supported > winebuild: ld -m elf_i386 -r failed with status 256 That's quite strange since apparently nothing has changed in the bidi support in GDI. Do you have HAVE_ICU or HAVE_UNICODE_UBIDI_H defined in your config.h? What happens if you #undef'ine them? Also try to exec 'make clean' as a general rule. -- Dmitry.

Sept. 30, 2006

Re: [D3D9] Remove const qualifier on state_test data.

by Ivan Gyurdiev

Michael Stefaniuc wrote: > Ivan Gyurdiev wrote: > >> Type: Cleanup >> >> Why: >> The const qualifier is unnecessarily restrictive. >> I intend to allocate and free such data on the heap in a future patch. >> Instead, const should be primarily used on function parameters. >> > Question: do you realy have to use void pointers? Yes. > Void pointers are > compatible with every pointer type and thus will disable the type > checking of the compiler. This is intentional - it's a form of polymorphism. The data stored can be of many different types. Each test knows what type of data it is using. > Also you do not need to to cast a rvalue to > void * if the type of the lvalue is void *. > Yes, you do...the type of the lvalue is void*, while the type of the rvalue is const void*. Not casting produces a warning (correctly). Casting replaces the compile-time guarantee that the value will be kept constant by runtime contract [ because both const and non-const rvalue will be used in the future ].

Sept. 30, 2006

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.

by Jesse Allen

On 9/29/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Also your patch is not correct. It's been discussed on wine-devel that > we should not restrict any one particular version of FontForge. Many > distros come with old but good versions and this will add extra noise > for no good reason. And it will not catch any new versions that are > broken either... > > Vitaliy. > Could someone tell me which version works the best? It seems to be a mystery. I've been using a snapshot of fontforge from 2006-08-22. Jesse

Sept. 30, 2006

Vista applications that work & those that don't

by Nick Law

I thought this may be of interest... applications that work and those that don't in Vista RC1 It would be interesting on how this same list compares with wine 0.9.22 http://www.iexbeta.com/wiki/index.php/Windows_Vista_Software_Compatibility_… and the hardware compatibility list .. http://www.iexbeta.com/wiki/index.php/Windows_Vista_RC_1_Hardware_Compatibi… I don't believe Microsoft's official list has been made public yet, although they said they would sometime! Nick

Sept. 30, 2006

Re: [Bug 4995] Check for fontforge >= 20060406 as earlier versions fail to build our fonts with catastrophic results.

by Vitaliy Margolen

Sam Dennis wrote: > aclocal.m4 | 16 ++++++++++++++++ > configure.ac | 6 +++++- > 2 files changed, 21 insertions(+), 1 deletions(-) > You missing change log. Please don't forget to include it in the email body not just subject. Also your patch is not correct. It's been discussed on wine-devel that we should not restrict any one particular version of FontForge. Many distros come with old but good versions and this will add extra noise for no good reason. And it will not catch any new versions that are broken either... Vitaliy.

Sept. 30, 2006

Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2

by Michael Stefaniuc

Juan Lang wrote: >>Ignoring VT_ERROR just masks a previous error. > > > Hm.. are you sure? These are input arguments, not results. This isn't You can never be sure with this OLE stuff. My only experience with VT_ERROR stems from variant arithmetics and those functions didn't like VT_ERROR as input. Well except VarCmp when both input variants where VT_ERROR it would return "equal". > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. Definitely. 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

Sept. 29, 2006

Re: shdocvw(2/2): ignore VT_ERROR arguments to WebBrowser_Navigate2

by Jacek Caban

Hi, Juan Lang wrote: >> Ignoring VT_ERROR just masks a previous error. >> > > Hm.. are you sure? These are input arguments, not results. This isn't > the only app that gets further with this patch. See also bug 6166. > > I guess a test case is the only answer. > I've tested it and we really shouldn't return E_INVALIDARG in this case so your patch is good. Thanks, Jacek

Sept. 29, 2006

Re: [PATCH 0/4] Janitorial: Win64 printf format warning fixes

by Michael Stefaniuc

Michael Stefaniuc wrote: > For all the people wanting to help out with this janitorial task please > wait until Alexandre commits this patch series. After that i'll create a > page for this task on the Wine wiki and link it from > http://wiki.winehq.org/JanitorialProjects Ok, this janitorial task has now a Wiki page: http://wiki.winehq.org/Win64PrintfFormatWarnings This is a good opportunity for anybody that wants to start submitting patches for Wine and get accustomed to this process. > I will put in a download link for my perl script that can automaticly > fix around 20000 out of the remaining 25000 warnings. You realy do not > want to go manualy over 25k warnings. 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

Sept. 29, 2006