January 2015 - Wine-Devel - list.winehq.org

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 5)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=11271 Your paranoid android. === w8 (32 bit address) === The test timed out

Jan. 23, 2015

Re: Wine 64 bit

by Ken Thomases

On Jan 23, 2015, at 12:03 AM, cdavis5x(a)gmail.com wrote: > On Jan 22, 2015, at 8:58 PM, Ken Thomases <ken(a)codeweavers.com> wrote: >> >>> 0006-ntdll-Support-64-bit-Mac-OS.patch >> >> Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X? > Yep. I didn’t want to add an export of an NT API that is not exported on Windows. I’m just afraid that some program out there depends specifically on NtCurrentTeb() not being in ntdll’s export table on x64. Yes, I know it sounds paranoid, but you just never know what programs in the wild (at least, the proprietary ones) depend on. Yeah, I realized after I sent that that NtCurrentTeb() must not be exported on Windows for 64-bit. So, your approach is probably right. It shouldn't be exported in Wine, either. >> I'm not sure we care about 10.5 with the 64-bit support. That avoids the conditional definitions of the context accessor macros. > Should we then refuse to build Wine at all on Darwin 9 (= OS X 10.5)? There’s some more conditional checks we can then get rid of if we require Mac OS 10.6. I don't know if Alexandre will allow that. He wasn't willing to drop support for 10.5 back when the Mac driver was added. He was even kind of grumpy that the Mac driver itself required 10.6. At the time, he had an old Mac Mini that couldn't be upgraded past 10.5 that he continued to build and test on. Perhaps if dropping 10.5 gained us something, he could be persuaded. I just figured that support for an additional architecture could be restricted, since it doesn't remove something that used to work. On the other hand, if the only concession we need to make is this set of macros being defined two different ways, that's not much of a cost. >>> 0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch >> >> There's going to be a lot more that needs to be done for the dbghelp support. > I know. Yeah, I didn't really mean to say that was a problem with this patch. Just musing about what ultimately needs to be done. > But the nlist(3) call isn’t available on 64-bit, nor is the n_un.n_name field in struct nlist{,_64} Huh. I realized the n_name field was missing, but didn't realize that nlist() isn't available. The function declaration isn't excluded for __LP64__ in the header, but, you're right, it's not exported by libSystem or its sub-libraries. > ——even when inspecting a 32-bit binary. (I wonder if Alexandre would prefer configure checks for those…) So it wouldn’t build at all as is, and while I was in there I figured I’d fix it more or less the right way. > Thanks for the review! You're welcome. :) -Ken

Jan. 23, 2015

Re: Wine 64 bit

by cdavis5x＠gmail.com

> On Jan 22, 2015, at 8:58 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > > On Jan 9, 2015, at 3:56 AM, cdavis5x(a)gmail.com wrote: > >> Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight. > > Should have replied earlier, but… this is good stuff. A number of these patches should just be submitted now. They would be good to have even if they don't eventually get us to working 64-bit Wine on OS X: > >> 0001-libwine-Add-exports-file-for-Mac-OS.patch > > Not sure what this is about. I assume this is about restricting what symbols are exported. Is there a problem with excessive exports? Oh this? A while ago, I noticed that when building everywhere else, libwine restricts its exports (cf. wine.def and wine.map). I guess this is necessary for Windows (because we don’t mark the APIs with __declspec(dllexport)), but we do this on ELF platforms, too. And so I thought to myself, why aren’t we doing this on Mac, too? This happened to be in my tree when I wrote the other patches. #3 depends on it right now, and I didn’t feel like rewriting it not to need it at the time I packaged up these patches for you guys. If Alexandre won’t take it, I guess I can remove this patch. > >> 0002-configure-Don-t-build-a-64-bit-wineqtdecoder.patch > > I don't have a problem with this as is, but Alexandre may prefer an actual test of QuickTime's availability. I imagine he would, given that a) Apple is likely to remove the QuickTime headers at some point, and b) testing for availability is good autoconf practice anyway. I’ll fix that. > >> 0003-configure-Support-64-bit-compilation-on-Mac-OS.patch > > Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k. > 2) I assume it works to specify it in decimal or you'd still be getting linker errors. However, the ld man page says it is interpreted as hexadecimal with or without a leading "0x". So, probably better to specify it in hex. I must have glossed over that when I was reading the ld(1) man page. I’ll definitely fix that——even if, in the grand scheme of things, it won’t make that much more memory available. > >> 0004-winebuild-Make-emitting-mod_-_func-sections-on-Mac-O.patch > > This is clearly just better than the current code, which effectively has magic numbers. I hadn't even bothered looking closely enough at this code to learn of the existence of get_ptr_size() and get_asm_ptr_keyword(). Sure makes my hack seem… extra hack-ish. ;) I'll submit this right away. > >> 0005-server-Use-mach_vm_-functions-instead-of-the-old-vm_.patch > > Seems good. This too. > >> 0006-ntdll-Support-64-bit-Mac-OS.patch > > Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X? Yep. I didn’t want to add an export of an NT API that is not exported on Windows. I’m just afraid that some program out there depends specifically on NtCurrentTeb() not being in ntdll’s export table on x64. Yes, I know it sounds paranoid, but you just never know what programs in the wild (at least, the proprietary ones) depend on. > Is it possible to define NtCurrentTeb() such that it's inlined but also exported by ntdll on the other platforms? Given that that’s what we already do for some other API functions, probably. (GetLastError() in kernel32 comes to mind.) > This solution seems excessively convoluted. > > I'm not sure we care about 10.5 with the 64-bit support. That avoids the conditional definitions of the context accessor macros. Should we then refuse to build Wine at all on Darwin 9 (= OS X 10.5)? There’s some more conditional checks we can then get rid of if we require Mac OS 10.6. > > You seem to have some cruft. Is the #include <sys/sysctl.h> used? Nope, and I meant to get rid of that. It was used in an earlier version of my patch to set kern.thaltstack, but when I removed that (because it’s a no-op in Mac OS >= 10.5), I forgot to remove the #include. > Certainly there's an empty #ifdef __APPLE__/#endif pair. (I realize you're not done and I'm not one to talk given the hackfest I horked up. Just trying to help. ;) Hey, it’s no problem. I appreciate help. > >> 0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch > > There's going to be a lot more that needs to be done for the dbghelp support. I know. But the nlist(3) call isn’t available on 64-bit, nor is the n_un.n_name field in struct nlist{,_64}——even when inspecting a 32-bit binary. (I wonder if Alexandre would prefer configure checks for those…) So it wouldn’t build at all as is, and while I was in there I figured I’d fix it more or less the right way. > It currently uses 32-bit-specific Mach-O structures and constants (e.g. MH_MAGIC, CPU_TYPE_X86, LC_SEGMENT, and struct segment_command). I haven't checked if a 32-bit dbghelp will be expected to analyze a 64-bit process or vice versa. I should check on that. I never did actually try to use a 64-bit WinDbg/CDB/NTSD on a 32-bit binary, so I’m curious to know if that would work. > >> 0008-kernel32-Don-t-use-gs-on-64-bit-Mac-OS.patch >> 0009-kernel32-Recognize-64-bit-Mach-O-modules-too.patch >> 0010-kernel32-Also-recognize-and-handle-Mach-O-fat-binari.patch >> 0011-msvcrt-Support-64-bit-platforms-that-don-t-have-fini.patch > > These all look fine. I’ll submit all of these. > > Thanks! I'll be interested to see where this leads. Thanks for the review! Chip > > -Ken >

Jan. 23, 2015

Re: Wine 64 bit

by Ken Thomases

On Jan 9, 2015, at 3:56 AM, cdavis5x(a)gmail.com wrote: > Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight. Should have replied earlier, but… this is good stuff. A number of these patches should just be submitted now. They would be good to have even if they don't eventually get us to working 64-bit Wine on OS X: > 0001-libwine-Add-exports-file-for-Mac-OS.patch Not sure what this is about. I assume this is about restricting what symbols are exported. Is there a problem with excessive exports? > 0002-configure-Don-t-build-a-64-bit-wineqtdecoder.patch I don't have a problem with this as is, but Alexandre may prefer an actual test of QuickTime's availability. > 0003-configure-Support-64-bit-compilation-on-Mac-OS.patch Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. 2) I assume it works to specify it in decimal or you'd still be getting linker errors. However, the ld man page says it is interpreted as hexadecimal with or without a leading "0x". So, probably better to specify it in hex. > 0004-winebuild-Make-emitting-mod_-_func-sections-on-Mac-O.patch This is clearly just better than the current code, which effectively has magic numbers. I hadn't even bothered looking closely enough at this code to learn of the existence of get_ptr_size() and get_asm_ptr_keyword(). Sure makes my hack seem… extra hack-ish. ;) > 0005-server-Use-mach_vm_-functions-instead-of-the-old-vm_.patch Seems good. > 0006-ntdll-Support-64-bit-Mac-OS.patch Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X? Is it possible to define NtCurrentTeb() such that it's inlined but also exported by ntdll on the other platforms? This solution seems excessively convoluted. I'm not sure we care about 10.5 with the 64-bit support. That avoids the conditional definitions of the context accessor macros. You seem to have some cruft. Is the #include <sys/sysctl.h> used? Certainly there's an empty #ifdef __APPLE__/#endif pair. (I realize you're not done and I'm not one to talk given the hackfest I horked up. Just trying to help. ;) > 0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch There's going to be a lot more that needs to be done for the dbghelp support. It currently uses 32-bit-specific Mach-O structures and constants (e.g. MH_MAGIC, CPU_TYPE_X86, LC_SEGMENT, and struct segment_command). I haven't checked if a 32-bit dbghelp will be expected to analyze a 64-bit process or vice versa. > 0008-kernel32-Don-t-use-gs-on-64-bit-Mac-OS.patch > 0009-kernel32-Recognize-64-bit-Mach-O-modules-too.patch > 0010-kernel32-Also-recognize-and-handle-Mach-O-fat-binari.patch > 0011-msvcrt-Support-64-bit-platforms-that-don-t-have-fini.patch These all look fine. Thanks! I'll be interested to see where this leads. -Ken

Jan. 23, 2015

Re: WineHQ zh_CN Translation Patch Up

by Bruno Jesus

On Thu, Jan 22, 2015 at 2:10 PM, Jeff Bai <jeffbaichina(a)gmail.com> wrote: > Hello fellow developers > > Here is a copy of the patch of changed zh_CN localization from AOSC (Anthon > Open Source Community) L10n project. We've fixed the msgid width problem > which was addressed last time. The patch is large so we put this on our > public PasteBin site, as follows > > https://pastebin.anthonos.org/view/a0c1c1a3 > > Please mail back with any issue over this patch. Hi, please send the email again with the patch as an attachment and I think a more proper subject would be: po: Update Simplified Chinese translation > Keep up the good work! > > Jeff Bai > AOSC Best regards, Bruno

Jan. 22, 2015

Re: WineHQ zh_CN Translation Patch Up

by Alex Henrie

Jeff, The best way to submit patches is with `git format-patch` and `git send-email`. It looks like Alexandre won't accept patches submitted via pastebin. -Alex

Jan. 22, 2015

Re: [PATCH 5/5] wined3d: Use the core version of the shader object functions.

by Chris Robinson

On 01/22/2015 04:22 AM, Henri Verbeet wrote: > I'm not sure that's really much better than just adding a (void *) cast. C doesn't technically allow casting function pointers to/from void*, <https://stackoverflow.com/questions/5579835/c-function-pointer-casting-to-v…>.

Jan. 22, 2015

Re: [PATCH 5/5] wined3d: Use the core version of the shader object functions.

by Henri Verbeet

On 22 January 2015 at 15:34, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Do you prefer I just unconditionally add the (void *) cast to > MAP_GL_FUNCTION or still add the separate define and only cast there? I don't have a strong opinion, but there's probably some value in explicitly marking the functions that do that kind of cast, so I guess it makes sense to have a separate macro.

Jan. 22, 2015

Re: [PATCH 5/5] wined3d: Use the core version of the shader object functions.

by Matteo Bruni

2015-01-22 13:22 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 21 January 2015 at 18:32, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> + typedef void (WINE_GLAPI *gl_shader_source_type)(GLuint, GLsizei, const GLchar * const *, const GLint*); >> + > ... >> + #define MAP_GL_FUNCTION_CAST(core_func, cast, ext_func) \ >> + do \ >> + { \ >> + if (!gl_info->gl_ops.ext.p_##core_func) \ >> + gl_info->gl_ops.ext.p_##core_func = (cast)gl_info->gl_ops.ext.p_##ext_func; \ >> + } while (0) > ... >> + MAP_GL_FUNCTION_CAST(glShaderSource, gl_shader_source_type, glShaderSourceARB); > I'm not sure that's really much better than just adding a (void *) cast. Do you prefer I just unconditionally add the (void *) cast to MAP_GL_FUNCTION or still add the separate define and only cast there? For the records, the only other used function requiring a cast is glTexImageEXT, because of the GLenum <-> GLint internalformat mismatch.

Jan. 22, 2015

Re: ws2_32: Better trace setsockopt/getsockopt

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > On Tue, Jan 6, 2015 at 12:49 AM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> The intention of this patch is to make it easier to read winsock logs, >> for setsockopt it even displays the value if its size is less than 5 >> bytes. > > Hi, any complains about this patch? It's pending for 2 weeks now and I > think this is a good waiting time to ask. You should be using wine_dbg_sprintf and the like. -- Alexandre Julliard julliard(a)winehq.org

Jan. 22, 2015