January 2008 - Wine-devel - list.winehq.org

Re: d3dx implementation senseless?
by tony.wasserka＠freenet.de 07 Jan '08

07 Jan '08

> Since everybody agrees that we need a built-in d3dx9, we could begin to implement it. > In the last talk about it, no plan was found to implement it: does one create a wined3dx or implement on the top of the last d3dx9 > dll? > > So, I think that a definitive answer should be given very quickly. > > David As far as I read, we decided to create the dlls/d3dx9_** directories, use the latest one for all the code and forward all calls from older dlls to this one. However, I don't think that it is a problem if a dll contains more functions than the native dll, so we could also just use 12 (sth. around that) copies of the same dll. And about starting development: I have already began to implement the D3DXRenderToSurface interface, but I'm new to COM programming so the progress is quite slow, so I'd recommend someone other to do the base of the dll. A suggestion I'd like to do is a message that Wine should print out when a program wants to use the d3dx9 dll, sth. like: MESSAGE("The application you want to run makes use of the D3DX9 library!n"); MESSAGE("tIts implementation under Wine is very young and far away from complete.n"); MESSAGE("tYou may be better off using a native d3dx9_24.dll file.n");

3 2

[Fwd: Re: French LTEXT correction]
by Jonathan Ernst 07 Jan '08

07 Jan '08

Hello, Please use "reply-to all" so that everybody on the list can read your answer. -------- Forwarded Message -------- From: Vincent Hardy <vincent.hardy.be(a)gmail.com> Reply-To: vincent.hardy.be(a)gmail.com To: Jonathan Ernst <jonathan(a)ernstfamily.ch> Subject: Re: French LTEXT correction Date: Mon, 07 Jan 2008 08:45:19 +0100 Jonathan Ernst a écrit : > On ven, 2008-01-04 at 11:24 +0100, Vincent Hardy wrote: >> Regedit displays "Rechercher::". Now Regedit displays "Rechercher :" and >> so on... > > It doesn't here (?). Furthermore in French ":" should be preceded by an > unbreakable space (like it's the case now) and not a normal space. > > > Thank you for your explanation. Nevertheless, it is not normal "::". See capture... (sorry for my poor english, I'm french speaking)

2 3

Re: [1/2][try 3] ddraw/tests: add test for rendering vertices with zero rhw
by H. Verbeet 06 Jan '08

06 Jan '08

On 07/01/2008, Alexander Dorofeyev <alexd4(a)inbox.lv> wrote: > Hi. > > I couldn't reproduce any problems with this patch on wine or on windows, but I > moved coordinates of retrieved pixel a bit away from edges. I hope this was the > problem :-/ > It could've been a depth buffer issue as well. I'm not exactly sure what the state of the depth buffer is when the test is run, but in general it appears the GF8 rounds slightly different compared to previous nvidia cards.

1 0

Re: msxml3: IXMLDOMDocument does not support get_nextSibling
by Alistair Leslie-Hughes 06 Jan '08

06 Jan '08

Ignore this patch. Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > msxml3: IXMLDOMDocument does not support get_nextSibling > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > >

1 0

Re: msxml3: IXMLDOMAttribute does not support get_nextSibling
by Alistair Leslie-Hughes 06 Jan '08

06 Jan '08

Ignore this patch. Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > msxml3: IXMLDOMAttribute does not support get_nextSibling > > > Best Regards > Alistair Leslie-Hughes > > > ------------------------------------------------------------------------ > >

1 0

Why the dash in the new "-unknown" category?
by Dan Kegel 06 Jan '08

06 Jan '08

Is it to make it show up first in the list?

2 1

Strange bash error "shell-init: error retrieving current directory"
by Dan Kegel 06 Jan '08

06 Jan '08

I've been seeing the error shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory a lot recently when running Wine, probably when installers finish. It started a couple weeks ago. I think it's a bash error message. Anyone else seeing that, or know what causes it? (Do we run our wrapper script in a directory that goes away, say?)

1 0

What happened to the videos from WineConf?
by Maarten Lankhorst 06 Jan '08

06 Jan '08

I remember at wineconf there were some videos created, what happened with those? I tried to look on youtube for wineconf, but I didn't find anything. Are they online yet? Or will they be put online? -Maarten

5 9

Re: [PATCH] ntdll: remove bogus VALGRIND_DISCARD
by Peter Oberndorfer 06 Jan '08

06 Jan '08

On Sonntag 06 Januar 2008, Peter Oberndorfer wrote: > > VALGRIND_DISCARD is used to discard block description handles > (which are created by VALGRIND_CREATE_BLOCK) > but it was called with the return value of VALGRIND_MAKE_xxx macros > which all return 0xffffffff > dlls/ntdll/signal_i386.c uses this macros already without VALGRIND_DISCARD > --- > dlls/ntdll/heap.c | 16 ++++++++-------- > 1 files changed, 8 insertions(+), 8 deletions(-) > Please don't apply this yet, it needs further research. The valgrind manual tells us in the Client Requests section that VALGRIND_MAKE_xxx functions return such a block handle [1], But looking at the implementation of valgrind/adding traces to valgind DISCARD request show it returns 0xffffffff ? Greetings Peter [1] valgrind manual Release 3.3.0 - 4.6. Client Requests * VALGRIND_MAKE_MEM_NOACCESS, VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DE These mark address ranges as completely inaccessible, accessible but containing undeﬁned data, and accessible and containing deﬁned data, respectively. Subsequent errors may have their faulting addresses described in terms of these blocks. _Returns a "block handle"_. Returns zero when not run on Valgrind. * VALGRIND_MAKE_MEM_DEFINED_IF_ADDRESSABLE. This is just like VALGRIND_MAKE_MEM_DEFINED but only affects those bytes that are already addressable. * VALGRIND_DISCARD: At some point you may want Valgrind to stop reporting errors in terms of the blocks deﬁned by the previous three macros. To do this, the above macros return a small-integer "block handle". You can pass this block handle to VALGRIND_DISCARD. After doing so, Valgrind will no longer be able to relate addressing errors to the user-deﬁned block associated with the handle. The permissions settings associated with the handle remain in place; this just affects how errors are reported, not whether they are reported. Returns 1 for an invalid handle and 0 for a valid handle (although passing invalid handles is harmless). Always returns 0 when not run on Valgrind.

1 0

Re: comdlg32: 1/2 PageSetupDlg: Convert paint procs to Unicode
by Dmitry Timoshkov 06 Jan '08

06 Jan '08

"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > comdlg32: 1/2 PageSetupDlg: Convert paint procs to Unicod What's the purpose of this patch? It improves nothing IMO except of making the code less readable, making it not thread safe, calling CallWindowProcW where it shouldn't. -- Dmitry.

2 4