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

Re: fonts:(followup)

by Louis Lenders

Steven Edwards <winehacker <at> gmail.com> writes: > Talk to the ReactOS guys and ask them if they still have it. > I don't > remeber if I ever committed it to ReactOS svn but if its there it > would have been in reactos/media/fonts. Email them or ask on IRC if > they can get you in touch with the author. I think his irc handle was > WiredW but I don't recall his real name. The author had offered to > license it LGPL or X11/BSD and was going to try to import the source > or whatever in to fontforge but was frustrated because it lost his > hinting or something. > Hi Steven, i asked in reactos' irc, but this guy (wierd_w) hasn't been seen around for a while. So i've sent him a e-mail twice( 2 weeks ago, and a week ago, wierd-w(a)yahoo.com) but got no response. Looks like he disappeared mysteriously....:( (at least from this e-mail address) Looks like this way ends here for now.

Dec. 24, 2006

Re: Building a full win32 winetest.exe

by Louis Lenders

Paul Millar <paulm <at> astro.gla.ac.uk> writes: > Try posting the problems with the crypt32 and hlink tests: it could be you > need to patch you MinGW compiler to support extra functions. > > HTH, > > Paul. I too had problems trying to do make crosstest in crypt32 a time ago, this is what i get (link errors): cert.cross.o: In function `testSignAndEncodeCert': /sda6/wine-git/dlls/crypt32/tests/cert.c:1094: undefined reference to `_CryptSignAndEncodeCertificate(a)36' /sda6/wine-git/dlls/crypt32/tests/cert.c:1098: undefined reference to `_CryptSignAndEncodeCertificate(a)36' /sda6/wine-git/dlls/crypt32/tests/cert.c:1102: undefined reference to `_CryptSignAndEncodeCertificate(a)36' /sda6/wine-git/dlls/crypt32/tests/cert.c:1106: undefined reference to `_CryptSignAndEncodeCertificate(a)36' /sda6/wine-git/dlls/crypt32/tests/cert.c:1114: undefined reference to `_CryptSignAndEncodeCertificate(a)36' cert.cross.o:/sda6/wine-git/dlls/crypt32/tests/cert.c:1119: more undefined references to `_CryptSignAndEncodeCertificate(a)36' follow cert.cross.o: In function `testAcquireCertPrivateKey': /sda6/wine-git/dlls/crypt32/tests/cert.c:1939: undefined reference to `_CryptImportPublicKeyInfo(a)16' cert.cross.o: In function `testGetPublicKeyLength': /sda6/wine-git/dlls/crypt32/tests/cert.c:2013: undefined reference to `_CertGetPublicKeyLength(a)8' /sda6/wine-git/dlls/crypt32/tests/cert.c:2018: undefined reference to `_CertGetPublicKeyLength(a)8' /sda6/wine-git/dlls/crypt32/tests/cert.c:2025: undefined reference to `_CertGetPublicKeyLength(a)8' /sda6/wine-git/dlls/crypt32/tests/cert.c:2030: undefined reference to `_CertGetPublicKeyLength(a)8' /sda6/wine-git/dlls/crypt32/tests/cert.c:2038: undefined reference to `_CertGetPublicKeyLength(a)8' cert.cross.o:/sda6/wine-git/dlls/crypt32/tests/cert.c:2043: more undefined references to `_CertGetPublicKeyLength(a)8' follow collect2: ld returned 1 exit status make: *** [crypt32_crosstest.exe] Error 1

Dec. 24, 2006

Re: ntdll: Added stubs for the Rtl*GenericTable* functions

by Vitaliy Margolen

Is there are any reason why do you need this functions at all? According to ddk they are part of "Installable File System Drivers". This is a kernel level thing only and no user app should use these routines. Especially stabbing them won't do you any good if something actually using them. But that something has no place to run in Wine yet. Vitaliy.

Dec. 24, 2006

Re: comctl monthcalendar help

by Vijay Kiran Kamuju

Hi, I am trying to figure why its not highlighting the current date (It should be greyed), but its not. Well I am trying to figure out. I think somehow it indirectly sends the MCN_SELECT for the current date. We need to incorporate that in the ode calling default case. I need some help, which function would be called if we send MCN_SELECT and MCN_RELEASED messages Thanks, VJ On 12/23/06, Duane Clark <dclark(a)akamail.com> wrote: > Vijay Kiran Kamuju wrote: > > Hi, > > > > I am trying to fix visual bug in comctl monthcalendar control. > > When I am using the control spy v2.0 for comctl5.0, I can see that > > current date is highled with grey background on windows xp. (similar > > to when we click a day in the calendar) > > But on wine its not happening. > > I am trying to find out, how we draw that highlighting. > > And also how we draw the default calendar. > > In general, drawing is done by the function "Paint"; in the case of the > monthcal, by MONTHCAL_Paint. The default date is set in MONTHCAL_Create, > with the call > GetLocalTime(&infoPtr->todaysDate); > The decoration of the day, including highlighting, is done in > MONTHCAL_DrawDay. The highlighting would be the calls > hbr = GetSysColorBrush(COLOR_GRAYTEXT); > hrgn = CreateEllipticRgn(r.left, r.top, r.right, r.bottom); > FillRgn(hdc, hrgn, hbr); > > > > > >

Dec. 24, 2006

Re: Building a full win32 winetest.exe

by Paul Millar

Hi Paul, On Friday 22 December 2006 15:38, Paul Vriens wrote: > any pointers how to build a winetest.exe I can run on Windows? Try make inside programs/winetest/ directory. However, winetest.exe has dependencies on all the DLL tests: to build the single winetest.exe executable, all the <dll>_test.exe executables must build correctly. You say you're having difficulty with crypt32 and hlink DLL tests. To build winetest.exe, you must either fix building of these tests (the preferred option) or remove the winetest.exe dependency on these executables (not so good). Try posting the problems with the crypt32 and hlink tests: it could be you need to patch you MinGW compiler to support extra functions. HTH, Paul. PS. I'll have sporadic access to email for the next couple of weeks, but if you post the problems I'll try and catch up.

Dec. 24, 2006

kernel32 (profile.c): current section and key implementation

by Claudio Fontana

Hello all, I posted previously a patch to wine-patches here: http://www.winehq.org/pipermail/wine-patches/2006-December/034022.html However, I now understand that although it solves the issue I had with the specific program, the change is incomplete, since in several other places, sections and keys are only considered meaningful when not equal to the empty string. In the Microsoft implementation, the unnamed section is valid, as are zero length keys. Thus, I think a broader scope change is required. Before I start working on a new patch, do you acknowledge that the current implementation is incorrect, and a patch fixing it by not requiring name[0] to be != '\0' is likely to be accepted? (btw, I've noticed you switched to git, so I will be using that instead now). Thanks, Claudio Fontana

Dec. 23, 2006

Re: comctl monthcalendar help

by Duane Clark

Vijay Kiran Kamuju wrote: > Hi, > > I am trying to fix visual bug in comctl monthcalendar control. > When I am using the control spy v2.0 for comctl5.0, I can see that > current date is highled with grey background on windows xp. (similar > to when we click a day in the calendar) > But on wine its not happening. > I am trying to find out, how we draw that highlighting. > And also how we draw the default calendar. In general, drawing is done by the function "Paint"; in the case of the monthcal, by MONTHCAL_Paint. The default date is set in MONTHCAL_Create, with the call GetLocalTime(&infoPtr->todaysDate); The decoration of the day, including highlighting, is done in MONTHCAL_DrawDay. The highlighting would be the calls hbr = GetSysColorBrush(COLOR_GRAYTEXT); hrgn = CreateEllipticRgn(r.left, r.top, r.right, r.bottom); FillRgn(hdc, hrgn, hbr);

Dec. 23, 2006

Re: d3d8: Don't report Shader Model 2.0 or higher

by Stefan Dösinger

Am 23.12.2006 um 18:02 schrieb H. Verbeet: > On 23/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: >> D3D8 never reports anything above SM 1.x. > Does this fix something? > It fixes Morrowind with glsl. This game seems to check for an exact number, not >=

Dec. 23, 2006

Re: d3d8: Don't report Shader Model 2.0 or higher

by H. Verbeet

On 23/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: > D3D8 never reports anything above SM 1.x. Does this fix something?

Dec. 23, 2006

comctl monthcalendar help

by Vijay Kiran Kamuju

Hi, I am trying to fix visual bug in comctl monthcalendar control. When I am using the control spy v2.0 for comctl5.0, I can see that current date is highled with grey background on windows xp. (similar to when we click a day in the calendar) But on wine its not happening. I am trying to find out, how we draw that highlighting. And also how we draw the default calendar. Thanks, VJ

Dec. 23, 2006

Re: WineLib porting project for small Windows application

by Andreas Mohr

Hi, On Fri, Dec 22, 2006 at 03:34:26PM -0500, Eric Rhodes wrote: > Hi Wine developers, > > My name is Eric Rhodes and I work for Schmap, Inc. (www.schmap.com) > > I'm posting this message to find out if any of you would be > interested in working with us on a Mac "porting" project for a small > Windows application (using Wine). A full project description is set > forth below. Since you mention that it is a "small" application it may be suitable to simply do a direct cross-platform port (Mac, Linux, Windows, handheld, others) via wxWidgets (just in case you haven't considered that yet). However this would be quite easy only in case of the app being written in MFC, since wxWidgets is *very* similar to MFC (it's very similar to the point of merely requiring a scripted API name string replacement in several code areas!) and thus other Win32 programming methods (raw Win32, Borland, ...) would face more issues during porting. Having said that I'm quite sure that a WineLib port is less of a pain than having to touch the whole source code in a wx port, and development work should be at least as comfortable, and due to source code availability you should be able to directly interface with Mac OS functionality on WineLib, too. Thank you very much for your offer/query, it's very much appreciated to have these kinds of queries on this list! Yours sincerely, Andreas Mohr

Dec. 22, 2006

WineLib porting project for small Windows application

by Eric Rhodes

Hi Wine developers, My name is Eric Rhodes and I work for Schmap, Inc. (www.schmap.com) I'm posting this message to find out if any of you would be interested in working with us on a Mac "porting" project for a small Windows application (using Wine). A full project description is set forth below. Please feel free to contact me directly at 919-246-0186 (or via email at <mailto:eric.rhodes(a)schmap.com>eric.rhodes(a)schmap.com) if you are interested in this project, or if you would like to refer someone else that might be. Thanks and happy holidays, Eric Rhodes ++++++++++++++++++++++++++++++++ Our Company Schmap is a media and technology company with a focus on developing client and server based consumer mapping solutions with a geospatial twist - see www.schmap.com. The Project We are seeking a senior engineer with strong C++ (preferably MS C++) to assist us with a self-contained WineLib porting project, working alongside two engineers who helped develop the Windows application to be ported. Mac programming experience is desired but not absolutely necessary. Specific Responsibilities Initial consultation and project setup; project planning (liasing with the CTO to develop a plan for the port); general code porting (outside of the consultancy role, you'll also be expected to get your hands dirty with some coding once the port gets underway); reporting on progress to the CTO. Duration Initial 4 to 8 week contract, with potential for extension depending on how the work progresses. Location One week onsite in Beijing, China required (beginning mid January 2007); remainder offsite. Must be eligible for Chinese visa. In addition to the fees for this project, we will fly you to Beijing and put you up in comfortable accommodations at our expense.

Dec. 22, 2006

State of demoscene productions under wine.

by Wojciech 'arab' Arabczyk

Hello So, i've been holding back with writing this mail for the last three releases of wine. Im pleased to infrom the whole wine team that almost every demoscene prod i keep a warm place for in my hearth is now (since 0.9.27) working with wine. The list with corresponding links below (all downloads are freeware or public domain): - Kewlers with "Variform" (working perfectly since i remember) http://www.pouet.net/prod.php?which=7138 - Kewlers and Mfx with "1995" (working since last [0.9.27] version, some strange slowdowns occur) http://www.pouet.net/prod.php?which=25783 - Kewlers with Protozoa (working since 0.9.23 i think, some strange slowdowns occur) - Farbrausch with fr-08 (working since 0.9.18 tho minor graphic glitches occur, between 0.9.21 and 0.9.22 occured a regression that does not allow the demo to finish. I'll do some regression test as soon as i'll have some time for it) http://www.pouet.net/prod.php?which=1221 - Farbrausch with fr-025 (working since last release [0.9.27] yet still some strange bugs [on-screen buffers that should not be displayed?] occur) http://www.pouet.net/prod.php?which=9450 - Kasparov from Elitegroup (some effects missing) http://www.pouet.net/prod.php?which=374 - Iconoclast by ASD (working since last [0.9.27] release, some strange slowdowns occur just as in 1995 by Kewlers and MFX and Protozoa by Kewlers [maybe a race condition?]) I hope the list is interesting? I could do some screenshot comparisions with effects/graphics problems or differences between the demos runing natively under windows and under wine. Also please note that the list is incomplete. I could add at least a donzen of demos still not working (i just thot i'll focus this time on those i like most). -- Best regards Wojciech Arabczyk

Dec. 22, 2006

Building a full win32 winetest.exe

by Paul Vriens

Hi, any pointers how to build a winetest.exe I can run on Windows? All tests (but crypt32 and hlink) can be cross compiled (MinGW) but only give me the single test executable for that dll. Cheers, Paul.

Dec. 22, 2006

Re: dinput: AddRef and Release parent DirectInput class.

by Alexandre Julliard

Vitaliy Margolen <wine-patches(a)kievinfo.com> writes: > This fixes bug 6918. > --- > dlls/dinput/joystick_linuxinput.c | 5 +++++ > dlls/dinput/keyboard.c | 8 ++++++++ > dlls/dinput/mouse.c | 5 +++++ > 3 files changed, 18 insertions(+), 0 deletions(-) It fails make test: ../../../tools/runtest -q -P wine -M dinput.dll -T ../../.. -p dinput_test.exe.so keyboard.c && touch keyboard.ok keyboard.c:159: Test failed: IDirectInput_Release() reference count = 1 -- Alexandre Julliard julliard(a)winehq.org

Dec. 22, 2006

WineAlsa mmap patch

by Maarten Lankhorst

This changes the winealsa dsound driver to stop using asynchronous callbacks and use snd_pcm_wait instead, I'm welcoming testing. For me this fixes the mmap_crst deadlock. I don't know what caused the deadlock in the first place, but this seems to have fixed it somehow. My test was basically running max payne 2 on my old pc, for some reason it's prone to this bug. With this patch I didn't have this problem. Detlef Riekenberg helped me testing first (buggy version) and now I hopefully fixed all issues that were found in it. It's not entirely ready yet I think, I'm not satisfied with latency for non-direct hw access. Basically it is the same loop as for direct hardware access at the moment. That means increased latency, which I think is noticable. Welcoming all comments on it and experiences with it. Maarten

Dec. 21, 2006

Re: kernel32 console bug?

by Eric Pouech

Robert Reif a écrit : > Eric Pouech wrote: > >> if you move the test() call a couple of lines below, when the console >> is actually created, it should work. >> for the actual program to run, you should use wineconsole. >> A+ >> >> >> 2006/12/20, Robert Reif <reif(a)earthlink.net >> <mailto:reif(a)earthlink.net>>: >> >> I get an error when running a windows console program on wine. It >> appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't >> return a >> handle to a console so GetConsoleMode() on that handle fails. The >> actual programs that fail are at: http://simh.trailing-edge.com/ >> > I just launched these .exes on xp in explorer and they created a > console window. > > Doing the same thing in wine using winefile produces the same failure > as in wine. The program quits when GetConsoleMode fails. The > programs do work using wineconsole. > > Somehow windows knows to run these .exes in a console window but wine > doesn't. perhaps ShellExecute is supposed to create a console when calling CreateProcess for CUI subprocesses (this should be tested) A+

Dec. 21, 2006

Re: kernel32 console bug?

by Eric Pouech

Robert Reif a écrit : > Eric Pouech wrote: > >> if you move the test() call a couple of lines below, when the console >> is actually created, it should work. >> for the actual program to run, you should use wineconsole. >> A+ >> >> >> 2006/12/20, Robert Reif <reif(a)earthlink.net >> <mailto:reif(a)earthlink.net>>: >> >> I get an error when running a windows console program on wine. It >> appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't >> return a >> handle to a console so GetConsoleMode() on that handle fails. The >> actual programs that fail are at: http://simh.trailing-edge.com/ >> >> -- >> Eric Pouech > > Would it be possible for wine to output a warning that this type of > program must be run using wineconsole? that may not be straightforward as lots of console APIs would require this kind of fix A+

Dec. 21, 2006

Re: libwine: Fix some typos

by Andrew Talbot

Alexandre Julliard wrote: > On any decent Unix the S_ISCHR etc. macros are defined by sys/stat.h, > so our defines are never used. > Right. I now see that Splint represents S_ISCHR() and the like as functions (despite containing a comment saying that "they're macros virtually everywhere"), so the #ifndef's in "wine/port.h" were not seeing prior preprocessor definitions. Thanks, -- Andy.

Dec. 21, 2006

Re: libwine: Fix some typos

by Alexandre Julliard

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > I am getting "unrecognized identifier" messages when looking at > ntdll/directory.c where it calls the S_ISCHR() and S_ISDIR() macros, these > are caused by the identifiers like _S_IFMT in "wine/port.h" seemingly not > being defined. The only place, on my system, where I could find definitions > of these identifiers was in "include/msvcrt/sys/stat.h". Are files such as > ntdll/directory.c and ntdll/file.c getting to know about these identifiers > via a route that a static checker cannot follow? On any decent Unix the S_ISCHR etc. macros are defined by sys/stat.h, so our defines are never used. -- Alexandre Julliard julliard(a)winehq.org

Dec. 21, 2006

Re: STLPort 5.1 and winegcc / winelib

by Gendo Ikari

Boaz, I followed you example in the files from SourceForge but I keep bumping into an error below. I figure I am not defining something properly and I have seen it when I was messing with StlPort 4 as well, so I was wondering if you might know where the issue lay. ../../stlport/stl/_threads.h:331: error: ‘pthread_spinlock_t’ does not name a type ../../stlport/stl/_threads.h: In member function ‘void stlp_std::_STLP_mutex_base::_M_initialize()’: ../../stlport/stl/_threads.h:332: error: ‘_M_lock’ was not declared in this scope ../../stlport/stl/_threads.h:332: error: ‘pthread_spin_init’ was not declared in this scope ../../stlport/stl/_threads.h: In member function ‘void stlp_std::_STLP_mutex_base::_M_destroy()’: ../../stlport/stl/_threads.h:333: error: ‘_M_lock’ was not declared in this scope ../../stlport/stl/_threads.h:333: error: ‘pthread_spin_destroy’ was not declared in this scope ../../stlport/stl/_threads.h: In member function ‘void stlp_std::_STLP_mutex_base::_M_acquire_lock()’: ../../stlport/stl/_threads.h:345: error: ‘_M_lock’ was not declared in this scope ../../stlport/stl/_threads.h:345: error: ‘pthread_spin_lock’ was not declared in this scope ../../stlport/stl/_threads.h: In member function ‘void stlp_std::_STLP_mutex_base::_M_release_lock()’: ../../stlport/stl/_threads.h:346: error: ‘_M_lock’ was not declared in this scope ../../stlport/stl/_threads.h:346: error: ‘pthread_spin_unlock’ was not declared in this scope winegcc: g++ failed. make: *** [obj/winegcc/so/dll_main.o] Error 2 On Tue, 2006-12-19 at 14:38 +0200, Boaz Harrosh wrote: > gendo(a)cox.net wrote: > > I was wondering if anyone had tried STLPort 5 with winelib. From searching the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and pass the -mno-cygwin option. Doing that gives me these errors. > > > > make -f gcc.mak all > > > > wineg++ -pthread -mno-cygwin -fexceptions -fident -fPIC -O2 -fuse-cxa-atexit -D_REENTRANT -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp > > /usr/include/../include/stdlib.h:469: error: expected â€˜;â€™ before â€˜*â€™ token > > /usr/include/../include/stdlib.h:470: error: expected â€˜;â€™ before â€˜*â€™ token > > /usr/include/../include/stdlib.h:471: error: expected â€˜;â€™ before â€˜*â€™ token > > /usr/include/../include/stdlib.h:475: error: expected â€˜;â€™ before â€˜*â€™ token > > /usr/include/../include/stdlib.h:479: error: â€˜int32_tâ€™ has not been declared > > winegcc: g++ failed. > > make: *** [obj/gcc/so/dll_main.o] Error 2 > > > > Anyway these are probably from grabbing the system headers which I have read you should not have happen, but if I try to use a -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and -nostdinc++ you then get tons of errors about the stl headers missing exception, cstring, etc. I was wondering if anyone had any thoughts or ideas on how to get this compiled so it is usable is porting applications. > > > > Thanks > > > > > > > > > look at, and download from: http://sourceforge.net/projects/onesource/ > (If you use KDE it has a phantom folder inside watch out) > > You will see an STLport folder and a wine\include\msvcrt folder and also > the Makefiles. > This is all very old, pre-winegcc. STLPort 4.6.x, but the principle is > there. A wine.mac for STL to compile over msvcrt from wine, a config.h > or what ever it is I can't remember. And the most important is > "typeinfo" and "new" header files in wine/include/msvcrt. > > I can hardly remember all the details but in principle. Configure > STLport to use all it's internal implementations (see wine > stlport-config files inside). And like you tried, don't let GCC use any > of it's headers. Than the only missing headers will be "typeinfo" and > "new". Also I think I had to play with include path a bit, or put some > headers in stlport/include that include other headers of same name from > wine. It did work at the end, let the compiler guide you. Also look back > in 2004/2005 archives I remember I had a much more detailed description > of what to do exactly. Search for "stlport". (You are not the first one > that asks) > > Please note: > - wine headers are very old, use new wine headers with what ever is > missing from my zip file. > - the "typeinfo" and "new" files are basically the GPLed files from GCC > a bit modifies so they compile. See if you need to do it again to newer > GCC files, what ever the GCC version you have. > - Some more headers can be found at msvc/include folder that had a bit > of magic to glue every thing together, but that was more for MFC and ATL > stuff, I'm not sure STLport needed any of that. I think you need MBCS > defined for msvcrt to have all that STLPort needs. > > Free Life > Boaz > >

Dec. 21, 2006

Re: libwine: Fix some typos

by Andrew Talbot

Alexandre Julliard wrote: > Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > >> I believe these identifiers are POSIX ones (from <sys/stat.h>), so they >> should not possess one leading underscore (unlike the similar ones in >> "msvcrt"). > > These defines are meant for Windows, where they do have underscores. > I am getting "unrecognized identifier" messages when looking at ntdll/directory.c where it calls the S_ISCHR() and S_ISDIR() macros, these are caused by the identifiers like _S_IFMT in "wine/port.h" seemingly not being defined. The only place, on my system, where I could find definitions of these identifiers was in "include/msvcrt/sys/stat.h". Are files such as ntdll/directory.c and ntdll/file.c getting to know about these identifiers via a route that a static checker cannot follow? -- Andy.

Dec. 21, 2006

Re: msxml.dll: nextNode and reset functions

by Colin Pitrat

OK, I finally managed to cross-compile and run this test under windows and under wine. The patch (test and functions) works well. Colin Pitrat (Bull Services Telco) Bull, Architect of an Open World (TM) Tél : +33 (0) 1 30 80 72 93 www.bull.com Colin Pitrat wrote: > New version of this patch, including corrections suggested by Huw > Davies, a correction and the addition of a test case. > However, I didn't run the test case under Windows because I have a > problem when I run make crosstest : > Undefined reference to _IID_IXMLDOMDocument > and other similar messages with _IID_IXMLDOMNode, _IID_IXMLDOMElement... > > Maybe this error is related to a previous one when running make > crosstest in top directory, occuring for advpack : > Can't find -lcabinet > > Change Log: > Add an iterator to _xmlnodemap struct > Implement nextNode function that give nodes one by one > Implement resetNode that reset the iterator > Add a test case for these functions > > Colin Pitrat (Bull Services Telco) > Bull, Architect of an Open World (TM) > Tél : +33 (0) 1 30 80 72 93 > www.bull.com > > > Colin Pitrat wrote: >> Change Log: >> Add an iterator to _xmlnodemap struct >> Implement nextNode function that give nodes one by one >> Implement resetNode that reset the iterator >> >> It's my first patch, so please tell me if something is wrong. I saw on >> http://www.winehq.com/site/sending_patches that I should write a test >> case, but I don't know how to do this (do I need windows ? because I >> don't have it). >> >> >> ------------------------------------------------------------------------ >> >> diff --git a/dlls/msxml3/nodemap.c b/dlls/msxml3/nodemap.c >> index 0797436..ead0138 100644 >> --- a/dlls/msxml3/nodemap.c >> +++ b/dlls/msxml3/nodemap.c >> @@ -44,6 +44,7 @@ typedef struct _xmlnodemap >> const struct ISupportErrorInfoVtbl *lpSEIVtbl; >> LONG ref; >> IXMLDOMNode *node; >> + long iterator; >> } xmlnodemap; >> >> static inline xmlnodemap *impl_from_IXMLDOMNamedNodeMap( >> IXMLDOMNamedNodeMap *iface ) >> @@ -297,15 +298,47 @@ static HRESULT WINAPI xmlnodemap_nextNod >> IXMLDOMNamedNodeMap *iface, >> IXMLDOMNode** nextItem) >> { >> - FIXME("\n"); >> - return E_NOTIMPL; >> + xmlnodemap *This = impl_from_IXMLDOMNamedNodeMap( iface ); >> + xmlNodePtr node; >> + xmlAttrPtr curr; >> + long attrIndex; >> + >> + TRACE("%p %ld\n", This, This->iterator); >> + >> + *nextItem = NULL; >> + >> + node = xmlNodePtr_from_domnode( This->node, 0 ); >> + curr = node->properties; >> + >> + for (attrIndex = 0; attrIndex < This->iterator; attrIndex++) { >> + if (curr->next == NULL) >> + return S_FALSE; >> + else >> + curr = curr->next; >> + } >> + >> + if (curr->next == NULL) >> + return S_FALSE; >> + else >> + curr = curr->next; >> + >> + This->iterator++; >> + + *nextItem = create_node( (xmlNodePtr) curr ); >> + >> + return S_OK; >> } >> >> static HRESULT WINAPI xmlnodemap_reset( >> IXMLDOMNamedNodeMap *iface ) >> { >> - FIXME("\n"); >> - return E_NOTIMPL; >> + xmlnodemap *This = impl_from_IXMLDOMNamedNodeMap( iface ); >> + >> + TRACE("%p %ld\n", This, This->iterator); >> + >> + This->iterator = 0; >> + >> + return S_OK; >> } >> >> static HRESULT WINAPI xmlnodemap__newEnum( >> > > ------------------------------------------------------------------------ > > diff --git a/dlls/msxml3/nodemap.c b/dlls/msxml3/nodemap.c > index 0797436..5458542 100644 > --- a/dlls/msxml3/nodemap.c > +++ b/dlls/msxml3/nodemap.c > @@ -44,6 +44,7 @@ typedef struct _xmlnodemap > const struct ISupportErrorInfoVtbl *lpSEIVtbl; > LONG ref; > IXMLDOMNode *node; > + long iterator; > } xmlnodemap; > > static inline xmlnodemap *impl_from_IXMLDOMNamedNodeMap( IXMLDOMNamedNodeMap *iface ) > @@ -258,8 +259,8 @@ static HRESULT WINAPI xmlnodemap_get_len > > first = node->properties; > if (first == NULL) { > - *listLength = 0; > - return S_OK; > + *listLength = 0; > + return S_OK; > } > > curr = first; > @@ -297,15 +298,42 @@ static HRESULT WINAPI xmlnodemap_nextNod > IXMLDOMNamedNodeMap *iface, > IXMLDOMNode** nextItem) > { > - FIXME("\n"); > - return E_NOTIMPL; > + xmlnodemap *This = impl_from_IXMLDOMNamedNodeMap( iface ); > + xmlNodePtr node; > + xmlAttrPtr curr; > + long attrIndex; > + > + TRACE("%p %ld\n", This, This->iterator); > + > + *nextItem = NULL; > + > + node = xmlNodePtr_from_domnode( This->node, 0 ); > + curr = node->properties; > + > + for (attrIndex = 0; attrIndex < This->iterator; attrIndex++) { > + if (curr->next == NULL) > + return S_FALSE; > + else > + curr = curr->next; > + } > + > + This->iterator++; > + > + *nextItem = create_node( (xmlNodePtr) curr ); > + > + return S_OK; > } > > static HRESULT WINAPI xmlnodemap_reset( > IXMLDOMNamedNodeMap *iface ) > { > - FIXME("\n"); > - return E_NOTIMPL; > + xmlnodemap *This = impl_from_IXMLDOMNamedNodeMap( iface ); > + > + TRACE("%p %ld\n", This, This->iterator); > + > + This->iterator = 0; > + > + return S_OK; > } > > static HRESULT WINAPI xmlnodemap__newEnum( > @@ -389,6 +417,7 @@ IXMLDOMNamedNodeMap *create_nodemap( IXM > nodemap->lpSEIVtbl = &support_error_vtbl; > nodemap->node = node; > nodemap->ref = 1; > + nodemap->iterator = 0; > > IXMLDOMNode_AddRef( node ); > /* Since we AddRef a node here, we don't need to call xmldoc_add_ref() */ > diff --git a/dlls/msxml3/tests/domdoc.c b/dlls/msxml3/tests/domdoc.c > index a2824fd..d8f08ac 100644 > --- a/dlls/msxml3/tests/domdoc.c > +++ b/dlls/msxml3/tests/domdoc.c > @@ -114,7 +114,10 @@ static void test_domdoc( void ) > r = CoCreateInstance( &CLSID_DOMDocument, NULL, > CLSCTX_INPROC_SERVER, &IID_IXMLDOMDocument, (LPVOID*)&doc ); > if( r != S_OK ) > + { > + printf("CoCreateInstance failed : %d\n",r); > return; > + } > > /* try some stupid things */ > r = IXMLDOMDocument_loadXML( doc, NULL, NULL ); > @@ -411,7 +414,7 @@ todo_wine > ok( node == NULL, "getNamedItem should have returned NULL\n"); > SysFreeString( str ); > > - /* test indexed access of attributes */ > + /* test indexed access of attributes */ > r = IXMLDOMNamedNodeMap_get_length( map, &count ); > ok ( r == S_OK, "get_length wrong code\n"); > ok ( count == 1, "get_length != 1\n"); > @@ -434,6 +437,23 @@ todo_wine > r = IXMLDOMNode_get_nodeName( node, NULL ); > ok ( r == E_INVALIDARG, "get_nodeName (NULL) wrong code\n"); > > + /* test sequential access of attributes */ > + node = NULL; > + r = IXMLDOMNamedNodeMap_nextNode( map, &node ); > + ok ( r == S_OK, "nextNode (first time) wrong code\n"); > + ok ( node != NULL, "nextNode, should be attribute\n"); > + > + r = IXMLDOMNamedNodeMap_nextNode( map, &node ); > + ok ( r != S_OK, "nextNode (second time) wrong code\n"); > + ok ( node == NULL, "nextNode, there is no attribute\n"); > + > + r = IXMLDOMNamedNodeMap_reset( map ); > + ok ( r == S_OK, "reset should return S_OK\n"); > + > + r = IXMLDOMNamedNodeMap_nextNode( map, &node ); > + ok ( r == S_OK, "nextNode (third time) wrong code\n"); > + ok ( node != NULL, "nextNode, should be attribute\n"); > + > /* content doesn't matter here */ > str = SysAllocString( szNonExistentFile ); > r = IXMLDOMNode_get_nodeName( node, &str ); >

Dec. 21, 2006

Re: [dinput] regression: No need to copy default constant format. Use already defined static instead

by Vitaliy Margolen

Christoph Frick wrote: > On Wed, Dec 20, 2006 at 10:27:52AM -0700, Vitaliy Margolen wrote: > >> The biggest problem is we don't properly "initialize" device. We >> should create our own data format structure that has only found >> objects. So we don't need to do it over and over again in EnumObjects >> or GetObjectInfo. > > In the joystick_linuxinput i have added such "search what we have" > already some month ago so support more than one device. so if i catch > your drift here we would again set up on a per-device-base a DataFormat > - which then could also be used for EnumObjects and GetObjectInfo, > right? Exactly. Then we use it instead if default data format to assign to wine_df. > > i can help on that end at least on the input edge of code - under your > supervision. Sweet. Vitaliy.

Dec. 21, 2006

Re: [dinput] regression c17e06d5c0e456d3052a1b6de688956f87c59d3e: No need to copy default constant format. Use already defined static instead

by Christoph Frick

On Wed, Dec 20, 2006 at 10:27:52AM -0700, Vitaliy Margolen wrote: > The biggest problem is we don't properly "initialize" device. We > should create our own data format structure that has only found > objects. So we don't need to do it over and over again in EnumObjects > or GetObjectInfo. In the joystick_linuxinput i have added such "search what we have" already some month ago so support more than one device. so if i catch your drift here we would again set up on a per-device-base a DataFormat - which then could also be used for EnumObjects and GetObjectInfo, right? i can help on that end at least on the input edge of code - under your supervision. -- cu

Dec. 21, 2006

Re: gdi32: Extract the constituent TrueType files from Mac suitcase fonts into the user's caches directory and use these instead of the original suitcase.

by Pierre d'Herbemont

> +#ifdef WORDS_BIGENDIAN > +#define GET_BE_WORD(x) (x) > +#else > +#define GET_BE_WORD(x) ((((x) & 0xff) << 8) | (((x) & 0xff00) >> 8)) > +#endif This could be replaced by CoreFoundation's CFSwapInt16BigToHost, which might be a bit more efficient... Pierre.

Dec. 21, 2006

Re: gdi32: Extract the constituent TrueType files from Mac suitcase fonts into the user's caches directory and use these instead of the original suitcase.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > + ret = malloc(sizeof(*ret)); > + if(!ret) > + { > + CloseResFile(res_ref); > + return NULL; > + } > + list_init(ret); It's better to avoid using malloc() in Wine. Also it seems to me it would be cleaner to return an array of char*, instead of a struct list that forces the caller to make assumptions about the type of the list elements. -- Alexandre Julliard julliard(a)winehq.org

Dec. 21, 2006

Re: libwine: Fix some typos

by Alexandre Julliard

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > I believe these identifiers are POSIX ones (from <sys/stat.h>), so they should > not possess one leading underscore (unlike the similar ones in "msvcrt"). These defines are meant for Windows, where they do have underscores. -- Alexandre Julliard julliard(a)winehq.org

Dec. 21, 2006

Re: d3d9: Add a render target test

by Ivan Gyurdiev

H. Verbeet wrote: > On 20/12/06, H. Verbeet <hverbeet(a)gmail.com> wrote: >> This time as part of the device.c test. >> >> Changelog: >> - Add a render target test >> > Use the attached patch instead, the previous version doesn't apply. This test really belongs in stateblock.c, along with every other set <--> get test if you ask me, that's what the framework there was written for. It might be kind of a pain to get this particular one to work though, since changing the rendertarget is currently considered an "event", across which all other set/get tests are ran, but I'm sure it's possible. The question of whether stateblocks track render targets should be answered eventually...

Dec. 21, 2006

Re: kernel32 console bug?

by Robert Reif

Eric Pouech wrote: > if you move the test() call a couple of lines below, when the console > is actually created, it should work. > for the actual program to run, you should use wineconsole. > A+ > > > 2006/12/20, Robert Reif <reif(a)earthlink.net <mailto:reif(a)earthlink.net>>: > > I get an error when running a windows console program on wine. It > appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't return a > handle to a console so GetConsoleMode() on that handle fails. The > actual programs that fail are at: http://simh.trailing-edge.com/ > I just launched these .exes on xp in explorer and they created a console window. Doing the same thing in wine using winefile produces the same failure as in wine. The program quits when GetConsoleMode fails. The programs do work using wineconsole. Somehow windows knows to run these .exes in a console window but wine doesn't.

Dec. 20, 2006

Re: setupapi: Use GetSystemDirectory() rather than hardcoding 'system32'.

by Alexandre Julliard

Francois Gouget <fgouget(a)codeweavers.com> writes: > @@ -87,13 +87,13 @@ static HINF search_for_inf(LPCVOID InfSpec, DWORD SearchControl) > HINF hInf = INVALID_HANDLE_VALUE; > WCHAR inf_path[MAX_PATH]; > > + static const WCHAR bslashW[] = {'\\',0}; > static const WCHAR infW[] = {'\\','i','n','f','\\',0}; > - static const WCHAR system32W[] = {'\\','s','y','s','t','e','m','3','2','\\',0}; > > if (SearchControl == INFINFO_REVERSE_DEFAULT_SEARCH) > { > - GetWindowsDirectoryW(inf_path, MAX_PATH); > - lstrcatW(inf_path, system32W); > + GetSystemDirectoryW(inf_path, MAX_PATH); > + lstrcatW(inf_path, bslashW); It's really supposed to hardcode system32, at least according to MSDN. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2006

Re: usp10: impelment ScriptStringGetLogicalWidths

by Alexandre Julliard

Clinton Stimpson <cjstimpson(a)afinternet.net> writes: > The test passed on my machine. > I double checked with the native usp10.dll, and it gives the same failure. > Perhaps it is my machine? I guess I'll change the test to expect the value the > native usp10.dll gives, and it'll pass on yours, and live with that failure on > my machine? No, you should figure out why it fails, otherwise it will most likely fail for others too. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2006

Re: gdi32: Improve the fontconfig filtering hack so that Mac suitcase fonts get through.

by Paul Vriens

On Wed, 2006-12-20 at 17:59 +0000, Huw Davies wrote: > On Wed, Dec 20, 2006 at 06:37:22PM +0100, Paul Vriens wrote: > > On Tue, 2006-12-19 at 21:21 +0000, Huw Davies wrote: > > > + if(strcasecmp(ext, "pfa") && strcasecmp(ext, "pfb")) > > > AddFontFileToList(file, NULL, ADDFONT_EXTERNAL_FONT); > > Hi, > > > > this patch was committed but I don't think this 'if' statement is > > correct as it will never be entered. > > Sure it will, if ext doesn't match "pfa" && ext doesn't match "pfb". > Note that strcasecmp probably doesn't return what you think it does. > > Huw. My bad. Sorry for the noise. Paul.

Dec. 20, 2006

Re: gdi32: Improve the fontconfig filtering hack so that Mac suitcase fonts get through.

by Huw Davies

On Wed, Dec 20, 2006 at 06:37:22PM +0100, Paul Vriens wrote: > On Tue, 2006-12-19 at 21:21 +0000, Huw Davies wrote: > > + if(strcasecmp(ext, "pfa") && strcasecmp(ext, "pfb")) > > AddFontFileToList(file, NULL, ADDFONT_EXTERNAL_FONT); > Hi, > > this patch was committed but I don't think this 'if' statement is > correct as it will never be entered. Sure it will, if ext doesn't match "pfa" && ext doesn't match "pfb". Note that strcasecmp probably doesn't return what you think it does. Huw. -- Huw Davies huw(a)codeweavers.com

Dec. 20, 2006

Re: gdi32: Improve the fontconfig filtering hack so that Mac suitcase fonts get through.

by Paul Vriens

On Tue, 2006-12-19 at 21:21 +0000, Huw Davies wrote: > + if(strcasecmp(ext, "pfa") && strcasecmp(ext, "pfb")) > AddFontFileToList(file, NULL, ADDFONT_EXTERNAL_FONT); Hi, this patch was committed but I don't think this 'if' statement is correct as it will never be entered. No clue if it's just changing '&&' into '||'. Cheers, Paul.

Dec. 20, 2006

Re: [dinput] regression c17e06d5c0e456d3052a1b6de688956f87c59d3e: No need to copy default constant format. Use already defined static instead

by Vitaliy Margolen

Christoph Frick wrote: > The old code copied the default constant format and applied > caclulate_ids on it. So the dwTypes where set with proper > MAKEINSTANCE(...) calls. So an app, that requested later its own data > format with SetDataFormat using the data from EnumObjects. After the > change now the default const has ANY_INSTANCE all over the place but the > app request a certain instance - so on SetDataFormat there are no > matches. > > So the big question is: is our SetDataFormat wrong or is this patch > wrong? Please advice. > I know about this problem. The test I added actually has that sort of custom data format. The thing is, I'm not sure yet how to fix this properly. I don't want to just copy default data format, modify it and use it as internal format. This is only one place that needs to be fixed. But there are several other areas that need this data format with some additional requirements. The biggest problem is we don't properly "initialize" device. We should create our own data format structure that has only found objects. So we don't need to do it over and over again in EnumObjects or GetObjectInfo. Also, because we create user format during device creation, we can not check if user actually set data format. Vitaliy Margolen.

Dec. 20, 2006

Re: usp10: impelment ScriptStringGetLogicalWidths

by Clinton Stimpson

Quoting Alexandre Julliard <julliard(a)winehq.org>: > Clinton Stimpson <cjstimpson(a)utwire.net> writes: > > > This patch implements ScriptStringGetLogicalWidths. > > Update usp10.spec so it isn't a stub anymore. > > Also added a test for this function. > > The test fails for me: > > ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p > usp10_test.exe.so usp10.c && touch usp10.ok > usp10.c:1297: Test failed: ScriptStringGetLogicalWidths should return index 4 > = 10, not 5 The test passed on my machine. I double checked with the native usp10.dll, and it gives the same failure. Perhaps it is my machine? I guess I'll change the test to expect the value the native usp10.dll gives, and it'll pass on yours, and live with that failure on my machine? Thanks, Clinton

Dec. 20, 2006

Re: usp10: impelment ScriptStringGetLogicalWidths

by Alexandre Julliard

Clinton Stimpson <cjstimpson(a)utwire.net> writes: > This patch implements ScriptStringGetLogicalWidths. > Update usp10.spec so it isn't a stub anymore. > Also added a test for this function. The test fails for me: ../../../tools/runtest -q -P wine -M usp10.dll -T ../../.. -p usp10_test.exe.so usp10.c && touch usp10.ok usp10.c:1297: Test failed: ScriptStringGetLogicalWidths should return index 4 = 10, not 5 -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2006

Re: kernel32: suppress an unneeded warning (try 3)

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> writes: > This time I added a test. It wouldn't have failed before, it would merely > produce a useless fixme. This suppresses that fixme by removing comments > before checking whether the read string overflows the buffer. > > ChangeLog: remove comments from string read in GetPrivateProfileIntW There is nothing special about ';' in values, other characters will terminate the number conversion too. It's probably safe to simply remove the FIXME, or maybe make it a WARN. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2006

Re: ws2_32: ws_sockaddr_u2ws should zero the WS_sockaddr before using it.

by Kai Blin

On Wednesday 20 December 2006 13:37, Francois Gouget wrote: > On Wed, 20 Dec 2006, Kai Blin wrote: > > @@ -946,6 +946,9 @@ static int ws_sockaddr_u2ws(const struct > { > int res; > > + /* Zero the ws_sockaddr structure before using */ > + memset(wsaddr, 0, *wsaddrlen); > > Are you sure this is needed in ws_sockaddr_u2ws() or should it rather be > done by getsockname() (as your test indicates). Well, this seemed the best place to do this, as it basically contains the getsockname() logic. > Also, do we know of a > real-world application that needs this? I don't know of any real world applications that need this, but it sure is making my life easier when trying to figure out directplay traces. Native dplay seems to use getsockname() to construct the dplay headers. > Finally, this memset() makes the one in the AF_UNSPEC case redundant, > and may itself be redundant with some of the memcpy()s... True. I'll adapt the patch to do the memset only in the AF_INET case, and only set the sin_zero member to 0. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 20, 2006

Re: kernel32 console bug?

by Robert Reif

Eric Pouech wrote: > if you move the test() call a couple of lines below, when the console > is actually created, it should work. > for the actual program to run, you should use wineconsole. > A+ > > > 2006/12/20, Robert Reif <reif(a)earthlink.net <mailto:reif(a)earthlink.net>>: > > I get an error when running a windows console program on wine. It > appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't return a > handle to a console so GetConsoleMode() on that handle fails. The > actual programs that fail are at: http://simh.trailing-edge.com/ > > -- > Eric Pouech Would it be possible for wine to output a warning that this type of program must be run using wineconsole?

Dec. 20, 2006

Re: ws2_32: ws_sockaddr_u2ws should zero the WS_sockaddr before using it.

by Francois Gouget

On Wed, 20 Dec 2006, Kai Blin wrote: @@ -946,6 +946,9 @@ static int ws_sockaddr_u2ws(const struct { int res; + /* Zero the ws_sockaddr structure before using */ + memset(wsaddr, 0, *wsaddrlen); Are you sure this is needed in ws_sockaddr_u2ws() or should it rather be done by getsockname() (as your test indicates). Also, do we know of a real-world application that needs this? Finally, this memset() makes the one in the AF_UNSPEC case redundant, and may itself be redundant with some of the memcpy()s... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Dec. 20, 2006

Re: [5/5] d3d9: Add a render target test

by Alexandre Julliard

"H. Verbeet" <hverbeet(a)gmail.com> writes: > Test if the stuff I just sent works. > > Changelog: > - Add a render target test > --- > > dlls/d3d9/tests/Makefile.in | 1 > dlls/d3d9/tests/rendertarget.c | 156 ++++++++++++++++++++++++++++++++++++++++ Could you please merge the test into one of the existing files, like device.c? We don't want to create new files for every test. -- Alexandre Julliard julliard(a)winehq.org

Dec. 20, 2006

[dinput] regression c17e06d5c0e456d3052a1b6de688956f87c59d3e: No need to copy default constant format. Use already defined static instead

by Christoph Frick

hiho with that patch: commit c17e06d5c0e456d3052a1b6de688956f87c59d3e Author: Vitaliy Margolen <wine-patches(a)kievinfo.com> Date: Sun Dec 10 14:15:08 2006 -0700 dinput: No need to copy default constant format. Use already defined static instead. :100644 100644 c5a35a1... 369c26d... M dlls/dinput/joystick_linuxinput.c The game Richard Burns Rally does no longer get any events. The game worked after some patches some month ago from me. As i had no intention on that pages to make things right but to make the game work i might have not picked the optimal solution. But this patches fixed all the apps, that worked with their own DataFormat. So the problem is like that: The old code copied the default constant format and applied caclulate_ids on it. So the dwTypes where set with proper MAKEINSTANCE(...) calls. So an app, that requested later its own data format with SetDataFormat using the data from EnumObjects. After the change now the default const has ANY_INSTANCE all over the place but the app request a certain instance - so on SetDataFormat there are no matches. So the big question is: is our SetDataFormat wrong or is this patch wrong? Please advice. -- cu

Dec. 20, 2006

Re: kernel32 console bug?

by Eric Pouech

if you move the test() call a couple of lines below, when the console is actually created, it should work. for the actual program to run, you should use wineconsole. A+ 2006/12/20, Robert Reif <reif(a)earthlink.net>: > > I get an error when running a windows console program on wine. It > appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't return a > handle to a console so GetConsoleMode() on that handle fails. The > actual programs that fail are at: http://simh.trailing-edge.com/ > > Here is a simple patch to kernel32/tests/console.c to demonstrate the > problem: > > > > > diff -p -u -r1.2 console.c > --- dlls/kernel32/tests/console.c 10 Oct 2006 18:19:57 -0000 > 1.2 > +++ dlls/kernel32/tests/console.c 20 Dec 2006 07:20:06 -0000 > @@ -552,12 +552,31 @@ static void testCtrlHandler(void) > ok(GetLastError() == ERROR_INVALID_PARAMETER, "Bad error %u\n", > GetLastError()); > } > > +static void test(void) > +{ > + HANDLE std_input; > + DWORD saved_mode; > + > + std_input = GetStdHandle(STD_INPUT_HANDLE); > + ok(std_input != INVALID_HANDLE_VALUE, > + "GetStdHandle(STD_INPUT_HANDLE) returned INVALID_HANDLE_VALUE\n"); > + > + if (std_input != INVALID_HANDLE_VALUE) > + { > + BOOL status; > + status = GetConsoleMode(std_input, &saved_mode); > + ok(status != FALSE, "GetConsoleMode() failed: %08x\n", > GetLastError()); > + } > +} > + > START_TEST(console) > { > HANDLE hConIn, hConOut; > BOOL ret; > CONSOLE_SCREEN_BUFFER_INFO sbi; > > + test(); > + > /* be sure we have a clean console (and that's our own) > * FIXME: this will make the test fail (currently) if we don't run > * under X11 > > > > > > -- Eric Pouech

Dec. 20, 2006

kernel32 console bug?

by Robert Reif

I get an error when running a windows console program on wine. It appears that in wine, GetStdHandle(STD_INPUT_HANDLE) doesn't return a handle to a console so GetConsoleMode() on that handle fails. The actual programs that fail are at: http://simh.trailing-edge.com/ Here is a simple patch to kernel32/tests/console.c to demonstrate the problem: diff -p -u -r1.2 console.c --- dlls/kernel32/tests/console.c 10 Oct 2006 18:19:57 -0000 1.2 +++ dlls/kernel32/tests/console.c 20 Dec 2006 07:20:06 -0000 @@ -552,12 +552,31 @@ static void testCtrlHandler(void) ok(GetLastError() == ERROR_INVALID_PARAMETER, "Bad error %u\n", GetLastError()); } +static void test(void) +{ + HANDLE std_input; + DWORD saved_mode; + + std_input = GetStdHandle(STD_INPUT_HANDLE); + ok(std_input != INVALID_HANDLE_VALUE, + "GetStdHandle(STD_INPUT_HANDLE) returned INVALID_HANDLE_VALUE\n"); + + if (std_input != INVALID_HANDLE_VALUE) + { + BOOL status; + status = GetConsoleMode(std_input, &saved_mode); + ok(status != FALSE, "GetConsoleMode() failed: %08x\n", GetLastError()); + } +} + START_TEST(console) { HANDLE hConIn, hConOut; BOOL ret; CONSOLE_SCREEN_BUFFER_INFO sbi; + test(); + /* be sure we have a clean console (and that's our own) * FIXME: this will make the test fail (currently) if we don't run * under X11

Dec. 20, 2006

Re: winemenubuilder: Write truecolor icons as PNGs

by Frank Richter

On 06.12.2006 20:01, Francois Gouget wrote: > The thing that blocked this patch from being applied last time is that, > if I remember correctly, Alexandre would like the PNG functionality to > be added to the IPicture implementation in dlls/oleaut32/olepicture.c. > Then winemenubuilder would use this interface to save the icon into the > proper format. > > It's easy to see where the code should go to extend this interface to > support loading PNG files as it already supports loading Gif and Jpeg > files. However I'm fuzzy on how one would use this interface to specify > the format to use for saving. Maybe by defining Wine-specific > PICTYPE_XXX values? But that would not work on Windows... Looking at IPicture, it just doesn't seem to be made for conversions. You can save an image in the "original format", but that's about it for image format support. Using IPicture to write a PNG seems like trying to fit a square peg into a round hole. Ideas like abusing PICTTYPE don't help to relieve that feeling. -f.r.

Dec. 20, 2006

Re: [18/19] WineD3D: Do not change the states if render target locking is disabled

by Stefan Dösinger

Am Dienstag 19 Dezember 2006 23:27 schrieb Stefan Dösinger: > There is no point in messing with the states if we aren't going to draw > anything anyway. This patch will conflict slightly with Henri's multiple render target patch. (device->renderTarget vs device->renderTarget[0]). If it does not apply then its not a crucial problem for the other patches, they should still work fine.

Dec. 19, 2006

Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)

by Alex Villacís Lasso

Alexandre Julliard escribió: > Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > > >> +#define HANDLE_DISPATCH(left, right) \ >> + if ((V_VT(param_left) & VT_TYPEMASK) == VT_DISPATCH && \ >> + (V_VT(param_right) & VT_TYPEMASK) != VT_NULL) \ >> + {\ >> + HRESULT hres;\ >> + left = &tempLeft;\ >> + hres = VARIANT_FetchDispatchValue(param_left, left);\ >> + if (!SUCCEEDED(hres)) return hres;\ >> + }\ >> + if ((V_VT(param_right) & VT_TYPEMASK) == VT_DISPATCH &&\ >> + (V_VT(param_left) & VT_TYPEMASK) != VT_NULL)\ >> + {\ >> + HRESULT hres;\ >> + right = &tempRight;\ >> + hres = VARIANT_FetchDispatchValue(param_right, right);\ >> + if (!SUCCEEDED(hres)) return hres;\ >> + } >> > > This macro is quite ugly. Also I don't see why you check the other > variant against VT_NULL first, aren't there cases where you still need > the other value? > > If I remove the check for VT_NULL on the other variant, I get this test failure: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so vartest.c && touch vartest.ok fixme:variant:VarMod Could not convert left type 4096 to 20? rc == 0x80020008 fixme:variant:VarMod Could not convert left type 8192 to 20? rc == 0x80020008 fixme:variant:VarMod Could not convert left type 16384 to 20? rc == 0x80020008 vartest.c:4910: Test failed: VarAdd: 1|0x0, 9|0x0: expected S_OK, vt 1, got 0x80020005 vt 0 vartest.c:4910: Test failed: VarAdd: 9|0x0, 1|0x0: expected S_OK, vt 1, got 0x80020005 vt 0 make: *** [vartest.ok] Error 2 This happens because for VarAdd, VT_NULL + VT_DISPATCH should succeed and give VT_NULL as a result, but the patch fetches the result value of the VT_DISPATCH before doing anything else. For null VT_DISPATCHs like the ones the test feeds the function, this causes the fetch to fail before the code for handling VT_NULLs is reached. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.

Dec. 19, 2006

Re: Add a test for IDirectDrawSurface_SetColorKey

by Stefan Dösinger

Am Montag 18 Dezember 2006 22:10 schrieb Günther Brammer: > Only tested with wine, unfortunately. Tests for the issue causing Bug 5730. I will run your test on windows, but I'd expect it to work. Can you also test which color key GetSurfaceDesc returns? > > diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c > index 3d70f82..74e4f28 100644 > --- a/dlls/ddraw/tests/dsurface.c > +++ b/dlls/ddraw/tests/dsurface.c > @@ -167,6 +167,7 @@ static void SrcColorKey32BlitTest(void) > LPDIRECTDRAWSURFACE lpDst; > DDSURFACEDESC ddsd; > DDSURFACEDESC ddsd2; > + DDCOLORKEY DDColorKey; > LPDWORD lpData; > HRESULT rc; > > @@ -222,6 +223,21 @@ static void SrcColorKey32BlitTest(void) > "Destination data after blitting is not correct\n"); > rc = IDirectDrawSurface_Unlock(lpDst, NULL); > ok(rc==DD_OK,"Unlock returned: %x\n",rc); > + > + /* Also test SetColorKey */ > + IDirectDrawSurface_GetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + ok(DDColorKey.dwColorSpaceLowValue == 0xFF00FF && > DDColorKey.dwColorSpaceHighValue == 0xFF00FF, + "GetColorKey does not > return the colorkey used at surface creation\n"); + > + DDColorKey.dwColorSpaceLowValue = 0x00FF00; > + DDColorKey.dwColorSpaceHighValue = 0x00FF00; > + IDirectDrawSurface_SetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + > + DDColorKey.dwColorSpaceLowValue = 0; > + DDColorKey.dwColorSpaceHighValue = 0; > + IDirectDrawSurface_GetColorKey(lpSrc, DDCKEY_SRCBLT, &DDColorKey); > + ok(DDColorKey.dwColorSpaceLowValue == 0x00FF00 && > DDColorKey.dwColorSpaceHighValue == 0x00FF00, + "GetColorKey does not > return the colorkey set with SetColorKey\n"); > > IDirectDrawSurface_Release(lpSrc); > IDirectDrawSurface_Release(lpDst);

Dec. 19, 2006

Re: Status of wine development

by Mark Hatsell

"Stefan Dösinger" <stefan(a)codeweavers.com> wrote in message news:200612191308.05608.stefan(a)codeweavers.com... > > DirectX10 will be after Wine 1.0 I am afraid. Development outside the tree > may > start earlier, but last I knew AJ plans a feature freeze soon(aka when d3d > is > stable), adding d3d10 would delay that way to much. Right now I am > rewriting > the state management in wined3d, which is the last big thing I really want > to > get in before the freeze. Just wondered if D3D in a child window is likely to be implemented before the freeze?? See bug: http://bugs.winehq.org/show_bug.cgi?id=3568 Mark

Dec. 19, 2006

Re: Status of wine development

by Pierre d'Herbemont

On 19 déc. 06, at 00:51, Kai Blin wrote: > On Tuesday 19 December 2006 00:27, Remco wrote: >> So, what's the status/news of DX10? DX in general? the Mac-port? >> Wine 1.0? >> What's the status of anything else that has been a major thing >> last year? > > As I don't own an Intel Mac, I can't tell you much about the Mac > port. It > should work ok in X, the quartz driver is still pretty stubbed out > for all I > know (correct me if I'm wrong). Kay, you're right, the quartz driver is stubbed out, and will probably stay as is until the graphics drivers' factorization in user32 is completed, or sufficiently advanced :( The winex11 -> user move tends to be really tricky as we could break many things for x11 platforms with those modifications. We also need to do that in a way that is acceptable for Alexandre. Which means, I think, not to reproduce the past errors (like extensive inter-calls between user32 and x11drv) in the x11drv architecture, that Alexandre had been fixing during last x11drv rewrite. Pierre.

Dec. 19, 2006

Re: oleaut32: preliminary support for VT_DISPATCH as parameters to VarAdd (and other 2-operand operations) (try 2) (RESEND)

by Alexandre Julliard

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > +#define HANDLE_DISPATCH(left, right) \ > + if ((V_VT(param_left) & VT_TYPEMASK) == VT_DISPATCH && \ > + (V_VT(param_right) & VT_TYPEMASK) != VT_NULL) \ > + {\ > + HRESULT hres;\ > + left = &tempLeft;\ > + hres = VARIANT_FetchDispatchValue(param_left, left);\ > + if (!SUCCEEDED(hres)) return hres;\ > + }\ > + if ((V_VT(param_right) & VT_TYPEMASK) == VT_DISPATCH &&\ > + (V_VT(param_left) & VT_TYPEMASK) != VT_NULL)\ > + {\ > + HRESULT hres;\ > + right = &tempRight;\ > + hres = VARIANT_FetchDispatchValue(param_right, right);\ > + if (!SUCCEEDED(hres)) return hres;\ > + } This macro is quite ugly. Also I don't see why you check the other variant against VT_NULL first, aren't there cases where you still need the other value? -- Alexandre Julliard julliard(a)winehq.org

Dec. 19, 2006

Re: Conformance tests

by Paul Vriens

On Tue, 2006-12-19 at 13:09 +0100, Michal Okresa wrote: > Hello, > > wine developers guide says that conformance tests must pass successfully on > all Windows platforms. > > I tried couple of tests in past weeks to catch wine's style of unit testing, > but now I am confused. For example I run crosscompiled olefont test > (oleaut32) on the windows machines (XP, 98). The test ended with 15 > failures. The same test executed on my linux machine ended with 13 failures > (reasons for failures are almost identical with previous runs on windows). > > Is this expected behaviour of conformance tests on windows platforms? > > thanks > As you can see on tests.winehq.org, there are several tests that fail on several flavors of Windows. The goal is of course to have all these tests succeed. So bottom-line, the expected/wanted behavior is to have all tests succeed on all versions of Windows and Wine. If a test is known to have different output on different versions, the tests have to cope with that. Cheers, Paul.

Dec. 19, 2006

Re: Bug 50

by Pedro Araújo Chaves Jr.

On 12/19/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > Passing the DC is not an option, that's a private gdi32 structure that > the driver doesn't know about. You shouldn't need to change the > function signature in any case, it already takes an lpDx array, all > you have to do is put better spacing values in there. Well, I had dropped that idea altogether as soon as I started working early in the morning, before reading your e-mail... besides, my next move was to play around with the spacing array, of course. Anyway, for a number of reasons, the idea of changing the function signature didn't sound well from the start to me neither. Yet I wanted to give it a shot, since it once fixed the issue. I'll keep you informed. Regards, Pedro.

Dec. 19, 2006

Re: STLPort 5.1 and winegcc / winelib

by Boaz Harrosh

gendo(a)cox.net wrote: > I was wondering if anyone had tried STLPort 5 with winelib. From searching the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and pass the -mno-cygwin option. Doing that gives me these errors. > > make -f gcc.mak all > > wineg++ -pthread -mno-cygwin -fexceptions -fident -fPIC -O2 -fuse-cxa-atexit -D_REENTRANT -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp > /usr/include/../include/stdlib.h:469: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:470: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:471: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:475: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:479: error: â€˜int32_tâ€™ has not been declared > winegcc: g++ failed. > make: *** [obj/gcc/so/dll_main.o] Error 2 > > Anyway these are probably from grabbing the system headers which I have read you should not have happen, but if I try to use a -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and -nostdinc++ you then get tons of errors about the stl headers missing exception, cstring, etc. I was wondering if anyone had any thoughts or ideas on how to get this compiled so it is usable is porting applications. > > Thanks > > > > look at, and download from: http://sourceforge.net/projects/onesource/ (If you use KDE it has a phantom folder inside watch out) You will see an STLport folder and a wine\include\msvcrt folder and also the Makefiles. This is all very old, pre-winegcc. STLPort 4.6.x, but the principle is there. A wine.mac for STL to compile over msvcrt from wine, a config.h or what ever it is I can't remember. And the most important is "typeinfo" and "new" header files in wine/include/msvcrt. I can hardly remember all the details but in principle. Configure STLport to use all it's internal implementations (see wine stlport-config files inside). And like you tried, don't let GCC use any of it's headers. Than the only missing headers will be "typeinfo" and "new". Also I think I had to play with include path a bit, or put some headers in stlport/include that include other headers of same name from wine. It did work at the end, let the compiler guide you. Also look back in 2004/2005 archives I remember I had a much more detailed description of what to do exactly. Search for "stlport". (You are not the first one that asks) Please note: - wine headers are very old, use new wine headers with what ever is missing from my zip file. - the "typeinfo" and "new" files are basically the GPLed files from GCC a bit modifies so they compile. See if you need to do it again to newer GCC files, what ever the GCC version you have. - Some more headers can be found at msvc/include folder that had a bit of magic to glue every thing together, but that was more for MFC and ATL stuff, I'm not sure STLport needed any of that. I think you need MBCS defined for msvcrt to have all that STLPort needs. Free Life Boaz

Dec. 19, 2006

Re: STLPort 5.1 and winegcc / winelib

by Boaz Harrosh

gendo(a)cox.net wrote: > I was wondering if anyone had tried STLPort 5 with winelib. From searching the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and pass the -mno-cygwin option. Doing that gives me these errors. > > make -f gcc.mak all > > wineg++ -pthread -mno-cygwin -fexceptions -fident -fPIC -O2 -fuse-cxa-atexit -D_REENTRANT -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp > /usr/include/../include/stdlib.h:469: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:470: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:471: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:475: error: expected â€˜;â€™ before â€˜*â€™ token > /usr/include/../include/stdlib.h:479: error: â€˜int32_tâ€™ has not been declared > winegcc: g++ failed. > make: *** [obj/gcc/so/dll_main.o] Error 2 > > Anyway these are probably from grabbing the system headers which I have read you should not have happen, but if I try to use a -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and -nostdinc++ you then get tons of errors about the stl headers missing exception, cstring, etc. I was wondering if anyone had any thoughts or ideas on how to get this compiled so it is usable is porting applications. > > Thanks > > > > look at, and download from: http://sourceforge.net/projects/onesource/ (If you use KDE it has a phantom folder inside watch out) You will see an STLport folder and a wine\include\msvcrt folder and also the Makefiles. This is all very old, pre-winegcc. STLPort 4.6.x, but the principle is there. A wine.mac for STL to compile over msvcrt from wine, a config.h or what ever it is I can't remember. And the most important is "typeinfo" and "new" header files in wine/include/msvcrt. I can hardly remember all the details but in principle. Configure STLport to use all it's internal implementations (see wine stlport-config files inside). And like you tried, don't let GCC use any of it's headers. Than the only missing headers will be "typeinfo" and "new". Also I think I had to play with include path a bit, or put some headers in stlport/include that include other headers of same name from wine. It did work at the end, let the compiler guide you. Also look back in 2004/2005 archives I remember I had a much more detailed description of what to do exactly. Search for "stlport". (You are not the first one that asks) Please note: - wine headers are very old, use new wine headers with what ever is missing from my zip file. - the "typeinfo" and "new" files are basically the GPLed files from GCC a bit modifies so they compile. See if you need to do it again to newer GCC files, what ever the GCC version you have. - Some more headers can be found at msvc/include folder that had a bit of magic to glue every thing together, but that was more for MFC and ATL stuff, I'm not sure STLport needed any of that. I think you need MBCS defined for msvcrt to have all that STLPort needs. Free Life Boaz

Dec. 19, 2006

Conformance tests

by Michal Okresa

Hello, wine developers guide says that conformance tests must pass successfully on all Windows platforms. I tried couple of tests in past weeks to catch wine's style of unit testing, but now I am confused. For example I run crosscompiled olefont test (oleaut32) on the windows machines (XP, 98). The test ended with 15 failures. The same test executed on my linux machine ended with 13 failures (reasons for failures are almost identical with previous runs on windows). Is this expected behaviour of conformance tests on windows platforms? thanks -- Michal Okresa

Dec. 19, 2006

Re: Status of wine development

by Stefan Dösinger

Am Dienstag 19 Dezember 2006 07:53 schrieb Tom Wickline: > On 12/18/06, Remco <remco47(a)yahoo.com> wrote: > > So, what's the status/news of DX10? DX in general? > > See : http://wiki.winehq.org/DirectX-ToDo > > That ToDo is up to date as far as I know, DX10 = 0% completeness. > > If anyone is aware of something in need of change on the DX-ToDo > please fix it or let me know and ill update the page. DirectX10 will be after Wine 1.0 I am afraid. Development outside the tree may start earlier, but last I knew AJ plans a feature freeze soon(aka when d3d is stable), adding d3d10 would delay that way to much. Right now I am rewriting the state management in wined3d, which is the last big thing I really want to get in before the freeze. That said, we're doing some preparative work for d3d10, like namespace cleanups. We also know the d3d10 changes a bit, and when we're making a design decision we decide with d3d10 in mind. That said, if anyone wants to jump in, he can start working on Direct3D10 support today. The first things will be easy, like adding the headers and writing stub versions of the interfaces.

Dec. 19, 2006

Re: Bug 50

by Alexandre Julliard

"Pedro Araújo Chaves Jr." <inckie(a)gmail.com> writes: > Right now I can't think of another way around that bug except a patch that > big, but I think we could break it into two smaller ones: the first one > would change what must be changed for the second one ― the actual correction > ― to work. Well, that first one involves changing the signatures of the > ExtTextOut functions in winex11.drv, in a similar fashion to what Keith had > proposed; but, instead of adding 'INT *breakTotalExtra, INT *breakCount' to > their argument lists, I suggest that we pass them the whole DC instead of > just its physDev ― that way we'd have access to the relevant attributes > while still being able to get its physDev (assigning it to a variable right > at the beginning of the functions, in order to keep their current > functionality in this first step). Passing the DC is not an option, that's a private gdi32 structure that the driver doesn't know about. You shouldn't need to change the function signature in any case, it already takes an lpDx array, all you have to do is put better spacing values in there. -- Alexandre Julliard julliard(a)winehq.org

Dec. 19, 2006

Re: Status of wine development

by Kai Blin

On Tuesday 19 December 2006 08:11, Edward Savage wrote: > The next issue of WWN is around half done and will most likely be submitted > for the end of this week. Great, thanks for picking this up. I remember WWN being incredibly helpful when I got started with Wine. > Also more worrying is that I can't think of a good quip to put at the start > of the news letter! I guess this is a matter of practice. I'd suggest bugging Brian to let you in on the secret of witty remarks for Wine Weekly News (WRWWN). Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 19, 2006

Re: Status of wine development

by Edward Savage

The next issue of WWN is around half done and will most likely be submitted for the end of this week. It will focus on the major changes since the last issue and the work being done in d3dx. The problem has mainly been the size of wine and how many people there are working on it. Catching up on threads of discussion and the like takes a lot of caching of the wine-devel list and tracking people down to ask questions to get a grasp of that area of development is tricky. Expect the rate at which I am able to send in an edition to increase drastically once the first one is out. Also more worrying is that I can't think of a good quip to put at the start of the news letter! Edward On 12/19/06, Kai Blin <kai.blin(a)gmail.com> wrote: > > > Well, there was somebody offering to pick up on Wine Weekly News, wonder > what > happened to that. Also, I'd disagree that minor releases aren't front-page > news. There's usually a significant change in features (and bugs) in every > release. :) > > > Cheers, > Kai > >

Dec. 19, 2006

Re: Status of wine development

by Tom Wickline

On 12/18/06, Remco <remco47(a)yahoo.com> wrote: > > So, what's the status/news of DX10? DX in general? See : http://wiki.winehq.org/DirectX-ToDo That ToDo is up to date as far as I know, DX10 = 0% completeness. If anyone is aware of something in need of change on the DX-ToDo please fix it or let me know and ill update the page. Happy Holidays Tom

Dec. 19, 2006

Re: Running winetest on Vista

by Frank Richter

On 18.12.2006 16:50, Dmitry Timoshkov wrote: > Well, a manifest is just an text (.xml) file with the resource type set > to RT_MANIFEST. Adding it into the resources is easy, the problem is that > wrc doesn't support that kind of a resource, so that support should be > added to wrc first. RT_MANIFEST is 24. Adding a resource of type 24, ID 1, should suffice; no special handling in wrc should be needed. E.g.: 1 24 "myapplication.manifest" or: 1 24 { "<assembly ..." "</assembly>" } f-r-

Dec. 19, 2006

Re: Status of wine development

by Kai Blin

On Tuesday 19 December 2006 00:27, Remco wrote: > I ask it consisely, but maybe the answers could be posted as a news item > on WineHQ. It would be great for Wine to get some exposure on tech sites > from time to time. That requires some actual news (new minor releases > aren't front-page news after all). Well, there was somebody offering to pick up on Wine Weekly News, wonder what happened to that. Also, I'd disagree that minor releases aren't front-page news. There's usually a significant change in features (and bugs) in every release. :) > So, what's the status/news of DX10? DX in general? the Mac-port? Wine 1.0? > What's the status of anything else that has been a major thing last year? I think the DX work is focusing on DX9 so far, and probably will stay like that for a while. Maybe some of the D3D people can fill in on the details. We're also working on getting DInput to be less broken, and someone in IRC seemed interested in DMusic, which could really need some love. We've ironed out almost all the bugs for running native DPlay, and I'm still working on figuring out that protocol. I expect this to take a while, though. As I don't own an Intel Mac, I can't tell you much about the Mac port. It should work ok in X, the quartz driver is still pretty stubbed out for all I know (correct me if I'm wrong). Wine 1.0 is due to be out in 6-18 months, as it's been the last 14 years. Actually, all kidding aside, we might see something in that direction once the D3D development stabilizes. How long that'll take, well... That's been my impression from reading the mailing list, people working on the single areas might know more specific things, so please correct me if this is all wrong. :) Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

Dec. 18, 2006

Status of wine development

by Remco

I ask it consisely, but maybe the answers could be posted as a news item on WineHQ. It would be great for Wine to get some exposure on tech sites from time to time. That requires some actual news (new minor releases aren't front-page news after all). So, what's the status/news of DX10? DX in general? the Mac-port? Wine 1.0? What's the status of anything else that has been a major thing last year? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Dec. 18, 2006

STLPort 5.1 and winegcc / winelib

by gendo＠cox.net

I was wondering if anyone had tried STLPort 5 with winelib. From searching the archives it seems you need to swap out gcc/c++ for winegcc/wineg++ and pass the -mno-cygwin option. Doing that gives me these errors. make -f gcc.mak all wineg++ -pthread -mno-cygwin -fexceptions -fident -fPIC -O2 -fuse-cxa-atexit -D_REENTRANT -D_GNU_SOURCE -I../../stlport -c -o obj/gcc/so/dll_main.o ../../src/dll_main.cpp /usr/include/../include/stdlib.h:469: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:470: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:471: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:475: error: expected ‘;’ before ‘*’ token /usr/include/../include/stdlib.h:479: error: ‘int32_t’ has not been declared winegcc: g++ failed. make: *** [obj/gcc/so/dll_main.o] Error 2 Anyway these are probably from grabbing the system headers which I have read you should not have happen, but if I try to use a -isystem/usr/include/wine/msvcrt or -Isystem/usr/include/wine/msvcrt and -nostdinc++ you then get tons of errors about the stl headers missing exception, cstring, etc. I was wondering if anyone had any thoughts or ideas on how to get this compiled so it is usable is porting applications. Thanks

Dec. 18, 2006

Re: [1] WineD3D: Add the state dirtification infrastructure

by Stefan Dösinger

Am Montag 18 Dezember 2006 19:25 schrieb Stefan Dösinger: Another issue I stumbled uppon: This patch moves the + 1 for the array declaration to the right place. > Am Montag 18 Dezember 2006 14:06 schrieb Stefan Dösinger: > Another update, it fixes an spotted by Henri issue where the state was used > instead of the representative and uses shifting and bitmasks to calculate > the index and shift for the bitmap. > > > This is another updated version, it uses bitmaps for the isStateDirty > > member. > > > > Am Sonntag 17 Dezember 2006 14:45 schrieb Stefan Dösinger: > > > Am Freitag 15 Dezember 2006 18:31 schrieb Stefan Dösinger: > > > > This patch adds the dirty list infrastructure. A dirty marker > > > > consists of a DWORD containing the state it marks dirty, and the list > > > > structure to build the list. > > > > > > > > The wined3ddevice has 3 new members: > > > > dirtyStateList: The list of dirty states. This will be moved to a > > > > per-context stucture once we add multithreading support > > > > freeListElems: A list containing unused dirty markers to avoid > > > > unnecessary HeapAlloc/HeapFree calls. I have seen D3D games spending > > > > 15% cpu time in the Heap code, we don't want to increase that. > > > > dirtyStates: An array that tells if a state is dirty. It is used to > > > > avoid double dirtification. I do not use the > > > > stateblock->changed.XXXX[] array because this is used for different > > > > purposes in the stateblock code. Ivan, do we still need it? > > > > > > Attached is an updated patch that uses an array for dirtification > > > instead of a list. Actually there are 2 arrays, one to quickly find out > > > if a specific state is dirty, and one to quickly find all dirty states. > > > > > > Checking if a state is dirty is done very often, so we need the > > > isStateDirty. A linear search on the dirtyArray would take way too much > > > time. On the other hand, my experiance so far shows that usually not > > > more than 10-20 states are dirty at the beginning of a drawprim call, > > > so iterating over all states would be a waste of time too. That's why > > > the dirtyArray is there. > > > > > > In the end there will be around 1000 states, so the size of those > > > arrays will be 8-10 kilobytes. Even oldest games load textures in the > > > area of megabytes, with recent games it's about gigabytes, so I don't > > > think those 10 kb's are an issue :-) . I could easilly change the > > > DWORDs to shorts, but all d3d states are defined as DWORDs, so I > > > decided to use DWORDS. > > > > > > If I used a bitmap I could squeeze the same information in about 128 > > > bytes + extra size for the code dealing with the bitmap + extra runtime > > > needs for bit shifting and checking all DWORDs in the bitmap. D3D games > > > are usually cpu limited, so I prefer the more memory intensive version. > > > > > > The other patches should apply cleanly over this patch, so I do not > > > resend them.

Dec. 18, 2006

Re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.

by Dan Kegel

Thanks for all the info, Hans. I stole some time this morning and, starting with your script, came up with one that lets Life Balance install; this would probably be appropriate for any .net 1.1 application: #!/bin/sh wineserver -k cat >> $HOME/.wine/system.reg <<"_EOF_" [Software\\Microsoft\\NET Framework Setup\\NDP\\v1.1.4322] "Install"=dword:00000001 "SP"=dword:00000001 [Software\\Microsoft\\.NETFramework\\policy\\v1.1] "4322"="3706-4322" _EOF_ The installer hangs at the end after you answer the "want to reboot?" prompt, but the app seems to be installed ok offhand. Running it fails with $ ~/wine-git/wine Life\ Balance.exe ** (Life Balance.exe:10): WARNING **: field __ImageBase in <Module> should have RVA data, but hasn't Stacktrace: at Life_Balance.LBForm..cctor () <0xffffffff> at Life_Balance.LBForm..cctor () <0x00084> at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> (This is with the latest Mono for Windows installed.) But hey, that's progress! - Dan

Dec. 18, 2006

Re: Running winetest on Vista

by Dmitry Timoshkov

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: >> Does it help if you rename it to test_setupapi.exe? >> > No :-( As soon as setup is contained in the name it doesn't run. The > link that Kevin showed makes sense now. > > Any idea how we can approach this? Do we indeed need to start adding > manifests to some of our tests? I'm afraid this is not the only thing > we're going to run into. IE7 and Vista already show some major changes > in things like advpack/crypt32/wintrust. Well, a manifest is just an text (.xml) file with the resource type set to RT_MANIFEST. Adding it into the resources is easy, the problem is that wrc doesn't support that kind of a resource, so that support should be added to wrc first. -- Dmitry.

Dec. 18, 2006

Re: ws2_32: Implement the SIO_ADDRESS_LIST_QUERY ioctl.

by Dmitry Timoshkov

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > case WS_SIO_ADDRESS_LIST_QUERY: > - FIXME("-> SIO_ADDRESS_LIST_QUERY request: stub\n"); > - break; > + { > + int fd; > + DWORD size; > + > + TRACE("-> SIO_ADDRESS_LIST_QUERY request\n"); > + > + if (!lpcbBytesReturned || (fd = get_sock_fd(s, 0, NULL)) == -1) It appears that fd is not used later at all. -- Dmitry.

Dec. 18, 2006

Re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.

by Hans Leidekker

Here's a very simple .NET app that runs: http://www.heise.de/software/default.shtml?prg=20130&T=dingler&osg=1 $ file hit_windows.exe hit_windows.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit Mono/.Net assembly And the obligatory screenshot: -Hans

Dec. 18, 2006

re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.

by Paul Chitescu

Hi, Dan I don't think it's a good idea to make a check for .NET 2.0 succeed. Currently Mono implements only .NET 1.1 Paul Chitescu On Sun, 17 Dec 2006, Dan Kegel wrote: > [...] > > And bingo, > http://msdn2.microsoft.com/en-us/library/aa480243.aspx documents > this as part of the check to see if .net is installed. Has somebody > figured out a canned .reg file to use to fake out this install check? > - Dan

Dec. 18, 2006

Bug 50

by Pedro Araújo Chaves Jr.

First, sorry for the blank mail I accidentally sent earlier... my bad. Ok, so I have been assigned bug 50 [1] here at my job, and I'm trying to apply the patch [2] Keith Dunwoody proposed in June 2005, which fixed the issue but was rejected for technical reasons. Right now I can't think of another way around that bug except a patch that big, but I think we could break it into two smaller ones: the first one would change what must be changed for the second one ― the actual correction ― to work. Well, that first one involves changing the signatures of the ExtTextOut functions in winex11.drv, in a similar fashion to what Keith had proposed; but, instead of adding 'INT *breakTotalExtra, INT *breakCount' to their argument lists, I suggest that we pass them the whole DC instead of just its physDev ― that way we'd have access to the relevant attributes while still being able to get its physDev (assigning it to a variable right at the beginning of the functions, in order to keep their current functionality in this first step). I'm only afraid that may bring a little overhead, so I'd really like to see some opinions, or some better ideas... [1] http://bugs.winehq.org/show_bug.cgi?id=50 [2] http://bugs.winehq.org/attachment.cgi?id=912&action=view I'll be testing that here, anyway. Cheers, Pedro. -- "People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster." (Adam Osborne)

Dec. 18, 2006

Bug 50

by Pedro Araújo Chaves Jr.

-- "People think computers will keep them from making mistakes. They're wrong. With computers you make mistakes faster." (Adam Osborne)

Dec. 18, 2006

Re: DDraw: Implement depth filling through blit. (re-resubmit) try3

by Stefan Dösinger

Am Sonntag 17 Dezember 2006 23:24 schrieb greg87(a)online.de: > Original Author: > Elie Morisse > lachienne(a)wanadoo.fr > > Updated by: > Gregor Münch > greg87(a)online.de > > This is modified version of this patch: > http://www.winehq.org/pipermail/wine-patches/2006-September/030815.html > > With the help from Stefan Dösinger I altered 2 lines. Full credit > belongs to Elie Morisse > > fixes: http://bugs.winehq.org/show_bug.cgi?id=4306 A small issue: The indentions in IWineD3DSurfaceImpl_BltZ look a bit strange. --- a/dlls/ddraw/ddraw.c +++ b/dlls/ddraw/ddraw.c @@ -1787,7 +1787,7 @@ IDirectDrawImpl_CreateNewSurface(IDirect { Usage |= WINED3DUSAGE_OVERLAY; } - if(This->depthstencil) + if(This->depthstencil || (pDDSD->ddsCaps.dwCaps & DDSCAPS_ZBUFFER)) { Perhaps you can get rid of This->depthstencil by setting the DDSCAPS_ZBUFFER flag instead on the requested surface desc in the auto depth stencil creation callback. Mind you, this auto depth stencil creation isn't used nowadays any more, it was needed earlier to prevent wined3d from crashing. You can remove the function body and replace it by an ERR entirely I think, it shouldn't be called if everything works correctly in wined3d.

Dec. 18, 2006

Re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.

by Hans Leidekker

On Monday 18 December 2006 04:06, Dan Kegel wrote: > Which apps? > Now that your patches seem to have been committed, I've started > trying to find and install apps that require .net, but for some > reason I'm having trouble finding many. For some years now I've been doing an unscientific benchmark of Wine by trying every installer on the CD that comes bundled with the excellent German magazine CT, every two months or so (I can confirm that we're doing much, much better than two years ago). For some time now it includes the dotnet runtime distributable along with a handful of applications that require it. CT's publisher, Heise Verlag maintains a vast online software database that is another shining example of Deutsche Gruendlichkeit: http://www.heise.de/software/default.shtml?osg=1 Try '.net' as keyword. > http://msdn2.microsoft.com/en-us/library/aa480243.aspx documents > this as part of the check to see if .net is installed. Has somebody > figured out a canned .reg file to use to fake out this install check? Good point. Here's a script that does that, modeled after your fakeie.sh. -Hans #!/bin/sh wineserver -k cat >> $HOME/.wine/system.reg <<"_EOF_" [Software\\Microsoft\\NET Framework Setup\\NDP\\v2.0.50727] "Install"=dword:00000001 _EOF_

Dec. 18, 2006

Re: A wine success story

by Martin Owens

It might be an idea to look into it, start ie or what ever your using with debug flags and see whats happening. there might be an error which doesn't kill wine but slows it down in an important way. On 12/18/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote: > Dan Kegel wrote: > > Today I saw one that says > > "I have discovered a way to get Shockwave working under Linux. > > Funny, I did the same thing at one point. > Worked well but was slow. > > I ended up using Shockwave in a VMware session because it was just > infinitely faster than using Shockwave by means of Wine. > > I think I was playing the game at www.isketch.net. It was unplayable > with Wine, but worked fine (= fast) in VMware. Wonder why. > > >

Dec. 18, 2006

Re: A wine success story

by Molle Bestefich

Dan Kegel wrote: > Today I saw one that says > "I have discovered a way to get Shockwave working under Linux. Funny, I did the same thing at one point. Worked well but was slow. I ended up using Shockwave in a VMware session because it was just infinitely faster than using Shockwave by means of Wine. I think I was playing the game at www.isketch.net. It was unplayable with Wine, but worked fine (= fast) in VMware. Wonder why.

Dec. 18, 2006

re: mscoree: Add a stub implementation for CorExitProcess and GetRequestedRuntimeInfo.

by Dan Kegel

Hans wrote: > These stubs make the installer happy that is common to many of the .NET apps I tried. Which apps? Now that your patches seem to have been committed, I've started trying to find and install apps that require .net, but for some reason I'm having trouble finding many. The first one I tried is Life Balance (http://appdb.winehq.org/appview.php?iAppId=2928) but even if Mono-1.2 is installed, Life Balance seems to still try to download and install the MS c# runtime. +relay shows this before the download starts: 0009:Call advapi32.RegOpenKeyExA(80000002,0042f148 "SOFTWARE\\Microsoft\\NET Framework Setup\\NDP",00000000,00020019,0033bb90) ret=0040fa26 0009:Ret advapi32.RegOpenKeyExA() retval=00000002 ret=0040fa26 And bingo, http://msdn2.microsoft.com/en-us/library/aa480243.aspx documents this as part of the check to see if .net is installed. Has somebody figured out a canned .reg file to use to fake out this install check? - Dan

Dec. 18, 2006

Re: Running winetest on Vista

by Paul Vriens

On Mon, 2006-12-18 at 00:12 +0800, Dmitry Timoshkov wrote: > "Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > > > While investigating that (several hours up to now) I found (not 100% > > sure though) that if an executable (like our setupapi_test.exe) has the > > word setup in it and is not properly signed, Vista starts > > complaining !!! > > > > Just copying our setupapi_test.exe to paul.exe makes it possible to run > > 'paul.exe --list'. > > > > Any ideas about the latter? > > Does it help if you rename it to test_setupapi.exe? > No :-( As soon as setup is contained in the name it doesn't run. The link that Kevin showed makes sense now. Any idea how we can approach this? Do we indeed need to start adding manifests to some of our tests? I'm afraid this is not the only thing we're going to run into. IE7 and Vista already show some major changes in things like advpack/crypt32/wintrust. Cheers, Paul.

Dec. 17, 2006

Re: WineD3D: paletted texture emulation using fragment shaders

by Frank Richter

On 16.12.2006 22:24, Roderick Colenbrander wrote: > + "MUL index.x, index.x, constants.x;\n" /* Scale the index by 255/256 */ > + "ADD index.x, index.x, constants.y;\n" /* Add a bias of '0.5' in order to sample in the middle */ FWIW, this can be conflated to "MAD index.x, index.x, constants.x, constants.y;". -f.r.

Dec. 17, 2006

Re: Running winetest on Vista

by Kevin Koltzau

On Sunday 17 December 2006 10:46 am, Paul Vriens wrote: > While investigating that (several hours up to now) I found (not 100% > sure though) that if an executable (like our setupapi_test.exe) has the > word setup in it and is not properly signed, Vista starts > complaining !!! > > Just copying our setupapi_test.exe to paul.exe makes it possible to run > 'paul.exe --list'. > > Any ideas about the latter? http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-b7… Search for "Installer Detection Technology" one of the criteria is 'Filename includes keywords like "install," "setup," "update," etc.' The solution appears to involve adding a manifest to the setupapi_test.exe containing <requestedExecutionLevel level="asInvoker" uiAccess="false"/> which will prevent vistas installer detection heuristics from kicking in

Dec. 17, 2006

Re: Running winetest on Vista

by Dmitry Timoshkov

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > While investigating that (several hours up to now) I found (not 100% > sure though) that if an executable (like our setupapi_test.exe) has the > word setup in it and is not properly signed, Vista starts > complaining !!! > > Just copying our setupapi_test.exe to paul.exe makes it possible to run > 'paul.exe --list'. > > Any ideas about the latter? Does it help if you rename it to test_setupapi.exe? -- Dmitry.

Dec. 17, 2006

Running winetest on Vista

by Paul Vriens

Hi, I've started to run our winetest executable on Vista. The current output is 7.8 MB or so, so we will never be able to sent it out just yet (1.5MB limit). I will start reducing the number of test failures on Vista (if I can of course). One thing that struck me and most likely it's due to Vista security is that when I run winetest.exe it tells me that it couldn't retrieve the list for the setupapi tests. While investigating that (several hours up to now) I found (not 100% sure though) that if an executable (like our setupapi_test.exe) has the word setup in it and is not properly signed, Vista starts complaining !!! Just copying our setupapi_test.exe to paul.exe makes it possible to run 'paul.exe --list'. Any ideas about the latter? Cheers, Paul.

Dec. 17, 2006

Re: usp10/tests: Testing of EnumLanguageGroupLocalesA

by Dmitry Timoshkov

"Paul Vriens" <paul.vriens.wine(a)gmail.com> wrote: > usp10/tests/usp10.c contains a test for EnumLanguageGroupLocalesA. The > test that uses this function is not using any other functions. > > EnumLanguageGroupLocalesA is a kernel32 function and Win98 and NT4 don't > have this function. > > The question now is should I change the usp10.c tests to check for the > availability of EnumLanguageGroupLocalesA or just move the complete test > to the kernel32 ones (where the availability is already tested). The test in usp10 uses EnumLanguageGroupLocalesA just as a loop driver to test usp10 APIs inside of enum_proc(), that's impossible to move the test to kernel32 without losing its functionality. So, I'd propose just add a check for EnumLanguageGroupLocalesA presence before executing the test. -- Dmitry.

Dec. 17, 2006

usp10/tests: Testing of EnumLanguageGroupLocalesA

by Paul Vriens

Hi, usp10/tests/usp10.c contains a test for EnumLanguageGroupLocalesA. The test that uses this function is not using any other functions. EnumLanguageGroupLocalesA is a kernel32 function and Win98 and NT4 don't have this function. The question now is should I change the usp10.c tests to check for the availability of EnumLanguageGroupLocalesA or just move the complete test to the kernel32 ones (where the availability is already tested). Cheers, Paul.

Dec. 17, 2006

Re: WineD3D: paletted texture emulation using fragment shaders

by Stefan Dösinger

Am Sonntag 17 Dezember 2006 04:03 schrieb Chris Robinson: > On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote: > > Hi, > > > > This patch adds 8-bit paletted texture emulation support using a fragment > > shader. > > Won't this break for programs that attempt to use paletted textures and > fragment shaders itself? If you need to emulate paletted textures, IMHO, a > better option would be to hold the palette and 8-bit image in RAM, and just > convert it to RGB(A) when either's changed. > > Though hardware has dropped native support for paletted textures, so, also > IMHO, that should be done on the ddraw side, instead of making all d3d apps > think paletted textures are available. If you look at dlls/wined3d/surface.c, d3dfmt_get_conv() and d3dfmt_convert_surface() then you'll see that we do exactly that :-) The problem is that unpacking a 8 bit palettized texture to a 32 bit ARGB texture eats a lot of video memory and cpu time. The idea behind the blitting shader is to have unpacking done in the gpu and avoid eating video memory. But as you've correctly seen, this won't work for 3D rendering, only for 2D blitting.

Dec. 17, 2006

Re: WineD3D: paletted texture emulation using fragment shaders

by Stefan Dösinger

Am Sonntag 17 Dezember 2006 05:06 schrieb H. Verbeet: > On 17/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: > > Won't this break for programs that attempt to use paletted textures and > > fragment shaders itself? > > For ddraw that won't be an issue, but in case of d3d I think it will, > even if the game isn't using fragment shaders itself. Calls to > DrawPrimitive will (re)bind the proper vertex / fragment shaders, > which would effectively disable the surface conversion. > > AFAIK this patch is aimed at ddraw blits with 8-bit paletted surfaces, > where this would of course work just fine, but code that gets called Yeah, this will only work for 2D Blits, not for 3D drawing. Even if the app doesn't use pixel shaders we would need a full fragment pipeline replacement I think. Games that use fragment shaders and 8 bit textures at the same time should be pretty rare, as directx drivers dropped 8 bit support long ago. I think we should remove the advertisement for WINED3DFMT_P8 if the texture palette extension isn't available for directx8 and directx9, even though we support those formats. Even though the emulation via manual unpacking works, it needs 4 times the video memory, and CPU time for unpacking. Games will fall back to a 16 bit texture usually. They have to deal with a lack of that format on windows too. We should keep advertising it for DirectX7 and below games. Afaik all cards that were out when these games were written had support for P8 (well, the ddraw format that represents D3DFMT_P8). And if a dx8/9 game tries to use P8, then this should succeed, with just beeing inefficient in terms of vidmem usage.

Dec. 17, 2006

Re: [1] WineD3D: Add the state dirtification infrastructure

by Stefan Dösinger

Am Samstag 16 Dezember 2006 16:51 schrieben Sie: > Stefan Dösinger <stefan(a)codeweavers.com> writes: > > The main arguments for a list were: > > > > * The shader constant code uses it too. It keeps the code somewhat > > simmilar * memory usage. An array has a fixed sizeof(DWORD) * > > STATE_HIGHEST mem usage, while a list has sizeof(DWORD) + 2*sizeof(void > > *) * number of dirty states memory usage. well, that was the idea > > That list thing still looks very inefficient. If you don't want a full > array (though I note you have one anyway in your code) you can use a > growing DWORD array of dirty states id; then adding a state become > simply something like dirtyStates[count++] = state. That was my original idea, I think I'll go back to that :-)

Dec. 17, 2006

Re: WineD3D: paletted texture emulation using fragment shaders

by H. Verbeet

On 17/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: > Won't this break for programs that attempt to use paletted textures and > fragment shaders itself? For ddraw that won't be an issue, but in case of d3d I think it will, even if the game isn't using fragment shaders itself. Calls to DrawPrimitive will (re)bind the proper vertex / fragment shaders, which would effectively disable the surface conversion. AFAIK this patch is aimed at ddraw blits with 8-bit paletted surfaces, where this would of course work just fine, but code that gets called from LoadTexture probably isn't the right place. A few other points: On 16/12/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: >+static int use_fragment_program; >+static unsigned int shader_id; ... >+ "END"; >+ These are only used inside d3dfmt_p8_upload_palette(), so they probably shouldn't be global. Also, use_fragment_program is assigned, but never read. >- extensions like ARB_fragment_program and ATI_fragment_shaders will be added as well. >+ extensions like ARB_fragment_program and ATI_fragment_shaders will be added aswell. "as well" is actually the proper spelling :-) >+ if(!have_fragment_program) >+ { >+ glEnable(GL_FRAGMENT_PROGRAM_ARB); >+ GL_EXTCALL(glGenProgramsARB(1, &shader_id)); >+ GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, shader_id)); >+ GL_EXTCALL(glProgramStringARB(GL_FRAGMENT_PROGRAM_ARB, GL_PROGRAM_FORMAT_ASCII_ARB, strlen(fragment_palette_conversion), (const GLbyte *)fragment_palette_conversion)); >+ glDisable(GL_FRAGMENT_PROGRAM_ARB); >+ have_fragment_program=1; >+ } I don't think the glEnable()/glDisable() is required there. If it is though, you can kill the glDisable(), and move the glEnable() above the if-block, to save a few redundant state changes. Also, it probably makes sense to just check if shader_id is non-zero, rather than introducing another variable to check if the program is already created. >+ glActiveTexture(GL_TEXTURE1); You should probably call that through GL_EXTCALL, even though I doubt there are much pre-1.3 GL setups left.

Dec. 17, 2006

Re: WineD3D: paletted texture emulation using fragment shaders

by Chris Robinson

On Saturday 16 December 2006 13:24, Roderick Colenbrander wrote: > Hi, > > This patch adds 8-bit paletted texture emulation support using a fragment > shader. Won't this break for programs that attempt to use paletted textures and fragment shaders itself? If you need to emulate paletted textures, IMHO, a better option would be to hold the palette and 8-bit image in RAM, and just convert it to RGB(A) when either's changed. Though hardware has dropped native support for paletted textures, so, also IMHO, that should be done on the ddraw side, instead of making all d3d apps think paletted textures are available.

Dec. 17, 2006

Re: winsock.h undefined symbols ___wine_ulong_swap ___wine_ushort_swap

by Pierre d'Herbemont

> Pierre's fix regarding use of hton and ntoh functions on Big Endian > when including from winsock2.h did not > completely resolve compilation errors. Sanjay, it did fix the compilation error, but it seems, looking at your diff, that you're wine sources are mangled : you have mixed the first patch and the second one that were sent to wine-patches. > diff -urN /Darwine/winesrc/wine-0.9.27/include/winsock.h /Darwine/ > winesrc/wine-0.9.27_compiled/include/winsock.h > --- /Darwine/winesrc/wine-0.9.27/include/winsock.h 2006-12-08 > 16:34:42.000000000 -0500 > +++ /Darwine/winesrc/wine-0.9.27_compiled/include/winsock.h > 2006-12-15 16:14:59.000000000 -0500 > @@ -516,12 +516,14 @@ Looking at the way you diff, I think you shouldn't send your patch against version release, git [1] would be more appropriate, and won't have let you send a patch that cannot be applied. [1] http://www.winehq.org/site/git http://www.winehq.org/site/sending_patches Pierre.

Dec. 16, 2006

Re: setupapi: add SPFILENOTIFY_TARGETNEWER support to SetupDefaultQueueCallback

by Alexandre Julliard

Robert Reif <reif(a)earthlink.net> writes: > Index: dlls/setupapi/queue.c > =================================================================== > RCS file: /home/wine/wine/dlls/setupapi/queue.c,v > retrieving revision 1.24 > diff -p -u -r1.24 queue.c > --- dlls/setupapi/queue.c 14 Nov 2006 11:15:45 -0000 1.24 > +++ dlls/setupapi/queue.c 15 Dec 2006 16:38:56 -0000 > @@ -1379,6 +1379,28 @@ UINT WINAPI SetupDefaultQueueCallbackA( > case SPFILENOTIFY_NEEDMEDIA: > TRACE( "need media\n" ); > return FILEOP_SKIP; > + case SPFILENOTIFY_TARGETNEWER: > + TRACE( "target newer? Source: %s Target: %s\n", > + debugstr_a(paths->Source), debugstr_a(paths->Target) ); > + { > + WIN32_FILE_ATTRIBUTE_DATA Source, Target; > + > + if (GetFileAttributesExA(paths->Source, GetFileExInfoStandard, &Source)) > + { > + if (GetFileAttributesExA(paths->Target, GetFileExInfoStandard, &Target)) > + { > + TRACE( "Target = 0x%08x%08x, Source = 0x%08x%08x\n", > + Target.ftCreationTime.dwHighDateTime, Target.ftCreationTime.dwLowDateTime, > + Source.ftCreationTime.dwHighDateTime, Source.ftCreationTime.dwLowDateTime ); > + > + if (CompareFileTime(&Target.ftCreationTime, &Source.ftCreationTime) == 1) > + return TRUE; > + > + return FALSE; > + } > + } > + } That doesn't make sense to me. At this point the file is known to be newer from the version info, why would you want to check creation time and overwrite a newer file? -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2006

Re: [1] WineD3D: Add the state dirtification infrastructure

by Alexandre Julliard

Stefan Dösinger <stefan(a)codeweavers.com> writes: > The main arguments for a list were: > > * The shader constant code uses it too. It keeps the code somewhat simmilar > * memory usage. An array has a fixed sizeof(DWORD) * STATE_HIGHEST mem usage, > while a list has sizeof(DWORD) + 2*sizeof(void *) * number of dirty states > memory usage. well, that was the idea That list thing still looks very inefficient. If you don't want a full array (though I note you have one anyway in your code) you can use a growing DWORD array of dirty states id; then adding a state become simply something like dirtyStates[count++] = state. -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2006

Re: winelauncher

by Vitaliy Margolen

Anssi Hannula wrote: > Vitaliy Margolen wrote about Debian packaging: >> It seems there is no end to how far will packagers go to brake Wine by >> trying to make it better > [...] >> Also as default it's using "winelauncher" >> instead of standard "wine" binary. That makes it that much more >> complicated to troubleshoot any problems that users might have. > > Could you (or someone else) explain why is it bad to use "winelauncher"? There are number of reasons: 1. It outputs different information from normal "wine" command. This is confusing to user as well as person who trying to debug the problem. 2. It's hard-coded to the default WINEPREFIX. More and more users starting to use other prefixes for testing purposes or just to separate applications. 3. It's not well maintained. 4. It does not work with wine from source directory or custom "wine" scripts. I don't have Wine installed but I have custom ~/bin/wine script. The winelauncher was unable to find nor start wine properly in this configuration. And possibly number of other problems that I don't know about. > We don't currently use it in the Mandriva packaging of wine, but a > request just got opened asking us to use "winelauncher" instead of "wine": > http://bugzilla.mandriva.com/show_bug.cgi?id=27638 What bug reporter seems to ask is to add "wine" and possibly "winecfg" entries to the WM's menu. That is something you can do with provided xpm icon and pre-made wine.desktop link. That link should also take care of associating Wine with at least *.exe files. Also it might be because until few versions back, Wine was able to create menu entries for KDE users only. Oh and also looking at winelauncher, it doesn't create the links bug reporter asks for. Vitaliy.

Dec. 16, 2006

Cast-qual warnings: current status

by Andrew Talbot

Hi, Apart from any oversights, I have completed my run of cast-qual fixes for the "dlls" and "dlls/tests" directories. The one file that most distorts the picture when -Wcast-qual is applied is "unicode.h", since its wide-string functions are inlined and it is included quite widely. I have posted a patch (dated 16 Dec 2006, entitled "include: Cast-qual warnings fix using const_cast macro") that, if not accepted, you can apply locally, if you want to build with "-Wcast-qual" to see the extent of the remaining problem. For the places where we still must use casts, I propose the introduction of a macro that takes on the role of the "const_cast" in C++. My attempt at that is as follows. #ifdef __cplusplus #define const_cast(t, e) const_cast<t>(e) #else #define const_cast(t, e) (t)(ULONG_PTR)(e) #endif This will make its purpose stand out from those of other casts. So, for example, the definition of strchrW() would become: extern inline WCHAR *strchrW( const WCHAR *str, WCHAR ch ) { do { if (*str == ch) return const_cast(WCHAR *, str); } while (*str++); return NULL; } The positive point of aiming to add -Wcast-qual universally - I would argue - is that it lets the compiler watch out for inadvertent introductions of fresh violations, so I become redundant, and you proper programmers can concentrate on more interesting things. :) I invite you, please, to debate the above issues, so we can determine the way forward concerning this issue. Meanwhile, I shall move on to the few "programs" and "server" files that generate cast-qual warnings. Thanks, -- Andy.

Dec. 16, 2006

Re: [5/5] usp10: remote todo_wine

by Matt Finnicum

I think that what James Hawkins had meant something like this: Apply patch one, run the tests. If patch one fixed any of them, remove the todo_wine's for those tests as a part of patch one. Otherwise, leave them todo_wine. Apply patch two, run the tests. If patch two fixed any of them, remove the todo_wine's for those tests as a part of patch two. Etc. This way, if someone builds wine at any step of applying the five patches then the todo_wine's will reflect the current status of if the functions work or not. I think this is important for regression testing. Of course, this will cause troubles if the patches are applied out-of-order or the later patches are applied without the first ones - but I think that's acceptable if you note that they should be committed in order. --Matt Finicum On 12/15/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > I can change the tests a bit, and change the currently empty functions > to return E_NOTIMPL instead of S_OK. > Then I can do it piecemeal. > Is that how y'all want it? > > Clint > > Clinton Stimpson wrote: > > Ok. There are 4 functions that have to be implemented at the same > > time in order to not break any tests, because of how the tests were > > written. > > A few days ago, I sent a single patch that implemented those 4 > > functions, including an update of the tests. > > It wasn't accepted, and it was suggested to break the patch up. But, > > I can't break it up without breaking the tests. > > I do have more patches coming after this batch, and those will be > > smaller and atomic. > > > > So I guess I'm back to asking why my original patch wasn't accepted. ?? > > Should I resend it? > > > > Thanks, > > Clinton > > > > James Hawkins wrote: > >> On 12/14/06, Clinton Stimpson <cjstimpson(a)utwire.net> wrote: > >>> Hi, > >>> > >>> Part 5 of 5. > >>> Remove many todo_wine's from the tests, now that the functions are > >>> implemented. > >>> > >> > >> You have to remove the todo_wine's in the same patch that fixes the > >> tests, or the tests will fail for at least one commit. Patches have > >> to be atomic and error free, and a failing test is an error. > >> > > > > > > > >

Dec. 16, 2006

Re: [AppDB] Add generic sound help (resend)

by Chris Morgan

Is it ok if we link to this entry in the Wine documentation instead: http://winehq.org/site/docs/wineusr-guide/config-wine-main#AEN282 Chris On Friday 15 December 2006 12:27 pm, Alexander Nicolaysen Sørnes wrote: > (I assume this was overlooked.) > > Add a paragraph about sound problems on the bottom of the generic help page > (as most sound problem reports are due to incorrect configurations). > > Also update the outdated usage of --debugmsg. > > > Regards, > > Alexander N. Sørnes

Dec. 16, 2006

winelauncher (was: Call to all packagers (especially Debian))

by Anssi Hannula

Vitaliy Margolen wrote about Debian packaging: > It seems there is no end to how far will packagers go to brake Wine by > trying to make it better [...] > Also as default it's using "winelauncher" > instead of standard "wine" binary. That makes it that much more > complicated to troubleshoot any problems that users might have. Could you (or someone else) explain why is it bad to use "winelauncher"? We don't currently use it in the Mandriva packaging of wine, but a request just got opened asking us to use "winelauncher" instead of "wine": http://bugzilla.mandriva.com/show_bug.cgi?id=27638 Thanks, -- Anssi Hannula

Dec. 16, 2006