April 2010 - Wine-devel - list.winehq.org

Re: [PATCH] RFC: C99: rewrote some extern inline to static inline
by Albert Lee 15 Apr '10

15 Apr '10

On Thu, 15 Apr 2010 11:56:32 +0200, Yann Droneaud <yann(a)droneaud.fr> wrote: > In order to build with CLANG with default arguments, extern inline > declaration > must be changed. > > By default CLANG uses C99's "extern inline" semantic which is like > gcc's "inline", and not the expected gcc's "extern inline" behavor. > > Additionnaly LLVM/CLANG don't support multiple function definitions with > different linkage in the same module (source file) : so it's not > possible to have a static inline definition in a header included in a > source file with a externally visible function of the same name. > C99's inline differs from GNU C's in that it will never cause a function definition to be emitted, so you should be able to replace GNU C's "extern inline" with plain inline. This has an advantage over static inline if you need to define an externally visible function, since you can avoid the copying the definition from the header to a source file by making sure the translation unit declares the function as C99 extern inline before including the inline definition. > This patch convert extern inline to static inline, so > embedded functions are not globally visible. > > This could be a problem if those symbols are needed. But currently, > I'm not able to give you any status: i was only able to run "cmd.exe", > before going further with LLVM/CLANG. I'm fighting with LLVM/CLANG bug > instead. > > If they are so symbols needed or if the binaries size grow to much, > the "extern inline" attribute will have to be converted to a macro, > expanded to "extern inline" with gcc in default behavor, and "inline" with > a C99 compatible compiler. > With C99 static inline, there should be no function definitions emitted so the size should not be much different. > See for example how this work in GMP: > http://gmplib.org:8000/gmp/file/da5903b6e386/gmp-h.in#l414 > Thanks for helping Wine get closer to C standards conformance! -Albert

1 0

Re: winex11: add support for 32-bit DDBs
by Erich Hoover 15 Apr '10

15 Apr '10

I noticed a problem with the icons in Wine when alt+tabbing today. After doing a regression test it appears that commit c29cf0591976f96c3adb30c3c3b6db59f4983251 results in pixmaps that do not always display properly when alt+tabbing (see attached screenshot). Erich Hoover ehoover(a)mines.edu

2 3

Re: [1/1] wcmd/tests: Attrib tests (resend)
by Alexandre Julliard 15 Apr '10

15 Apr '10

Eleazar Galano <eg.galano(a)gmail.com> writes: >> Dan Kegel is helping me get started with Wine development. To prepare >> for modifications to the ATTRIB function of CMD.EXE, I have added test >> cases for the current functionality of ATTRIB. It seems to me this should go in programs/attrib. Also it should test that the attributes actually changed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw: Do not restore the display mode from inside SetCooperativeLevel (resend)
by Alexandre Julliard 15 Apr '10

15 Apr '10

Johan Gill <johan.gill(a)gmail.com> writes: > dlls/ddraw/ddraw.c | 3 --- > dlls/ddraw/tests/ddrawmodes.c | 25 +++++++++++++++++++++++++ > 2 files changed, 25 insertions(+), 3 deletions(-) This causes the test to not restore the display mode properly on exit. -- Alexandre Julliard julliard(a)winehq.org

1 0

HLSL Compiler and d3dcompiler_xx.dll
by Matijn Woudt 15 Apr '10

15 Apr '10

Hi, I'm about to implement the HLSL compiler, but I want to make sure I'm taking the right direction. For the compiler: preprocessor(wpp)->hlslparser/compiler(lex/bison)->bytecode writer(same as for the shader assembler). Now the question is where to implement the compiler. It can be called from at least 3 places, d3dx9_xx, d3d10_xx and d3dcompiler_xx. It seems to me that d3dx9_xx and d3d10_xx are forwarding their calls to d3dcompiler_xx. My proposal is: 1) Create the d3dcompiler_xx.dll structure in wine. Is it legal to use a program like dll export viewer to get the exported functions for each dll? 2) Move the assembler to d3dcompiler_xx.dll and forward calls from d3dx9. This is needed because the assembler and compiler can share the same bytecode writer this way. 3) Implement the compiler in d3dcompiler_xx. Regards, Matijn

8 23

Re: oleaut32: be more explicit with locale dependent parsing of dates (try 2)
by Nikolay Sivov 15 Apr '10

15 Apr '10

On 4/14/2010 22:51, André Hentschel wrote: > case 0x3: /* TTT TTTDD TTTDDD */ > - if (iDate&& dp.dwCount == 3) > + if (dp.dwCount == 3&& !strncmp(ShortDate,"dd.MM.yy",8)) > > > case 0x1B: /* localized DDDTTT */ > - if (!iDate) > + if (strncmp(ShortDate,"dd.MM.yy",8)) > { > hRet = DISP_E_TYPEMISMATCH; > break; > This looks like a workaround. I don't think you should hard code it this way, what's so special with this format? And what is a initial problem with that?

2 2

Re: kernel32: Add tests for lstrcmpW (try 2)
by Dmitry Timoshkov 15 Apr '10

15 Apr '10

André Hentschel <nerv(a)dawncrow.de> wrote: > - Design similar to ntdll/tests/error.c > - Passes all Machines on WTB > - with check for existance of function > - just the known 2 instead of 4510 > - intendation for todo_wine choosen so that it can be easy removed without touching the tests You need to test CompareStringW instead, and try to avoid using any macros at all. Probably the very first thing you need to do in the test is to call GetStringType and verify that the character you want to test is supported and has the expected attributes. -- Dmitry.

1 0

Packaging Wine 64bit
by Michael Stefaniuc 14 Apr '10

14 Apr '10

Hello guys! Wine 64bit (the one able to run 64bit Windows application) is nearly feature complete. As of wine-1.1.42 Wine supports shared 32/64-bit setups; though we do not recommend it yet for general consumption. This is more of a "heads up" info as the next stable Wine release aka 1.2 is "imminent" (about one month until code freeze and then an additional month for the stabilization period). Proper Wine 64bit support poses some challenges for packaging as it requires *both* 64bit as well as 32bit libraries and binaries. This makes Wine 64bit packaging different from the normal other 64bit packages. To ease the pain we have created a wiki page with information pertinent to packagers/distributions: http://wiki.winehq.org/Wine64ForPackagers Do not hesitate to contact us either by email to wine-devel or on irc on Freenode in #winehackers if you have any questions or suggestions. The above page actually evolved from discussions on irc. If you do know about Wine packagers on other Linux distributions please forward them this info; we are pretty sure that we missed a few. We didn't forget about the non-Linux OSes but Wine 64bit is at the moment a Linux only feature; patches to change that are of course welcome ;) bye michael

1 0

Re: [PATCH 2/2] mmdevapi: Add pulseaudio on ignore for older openal-soft's
by Michael Stefaniuc 14 Apr '10

14 Apr '10

On 04/14/2010 09:24 PM, Maarten Lankhorst wrote: > --- > I cannot query the version string unless a device context is created. > Since OpenAL-1.12 added support for thread local contexts I use that to > determine whether pulseaudio should be ignored or not. OpenAL 1.10 and > older will crash on pulseaudio. Since other os's don't support > pulseaudio it is safe. > +static void boycott_pulse(const char *devstr, const char **defstr) { The function is badly named. It doesn't "boycott" PA but doesn't uses it on older OpenAL versions. > + if (!blacklist_pulse && !local_contexts) { > + WARN("Disabling pulseaudio because of old openal version\n"); > + blacklist_pulse = 1; > + } > + if (!blacklist_pulse || !devstr || strncmp(*defstr, "PulseAudio ", 11)) > + return; > + while (*devstr && !strncmp(devstr, "PulseAudio ", 11)) { > + devstr += strlen(devstr) + 1; > + } > + TRACE("New default: %s\n", devstr); > + *defstr = devstr; > +} > + bye michael

1 0

Re: usbhub.sys: add stubbed usbhub.sys
by Alexandre Julliard 14 Apr '10

14 Apr '10

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * usbhub.sys: add stubbed usbhub.sys What is this going to be useful for? -- Alexandre Julliard julliard(a)winehq.org

3 12