July 2009 - Wine-devel - list.winehq.org

Fwd: [Wine] Tmax Window(a propietary OS) using Wine?
by Austin English 08 Jul '09

08 Jul '09

---------- Forwarded message ---------- From: nengad24 <wineforum-user(a)winehq.org> Date: Tue, Jul 7, 2009 at 5:54 AM Subject: [Wine] Tmax Window(a propietary OS) using Wine? To: wine-users(a)winehq.org Hi, Im posting here the next doubt: Yesterday a korean company has released a new OS which is compatible with MS Windows Apps. As they state, they are a propietary OS, and i cant see any GPL code or SVN repository.Of course my lack of Korean can help to not find the open source code,but the little im able to read seems they arent going to release any source code. I know that is quite difficult to replicate Windows APIs, so i´m asking myself if this OS is using Wine code to replicate the APIs. If they are using, they could be violating GPL rules. http://www.tmaxwindow.co.kr/ If you want to have more Info, i point you to the ReactOS Forum,where a thread about this Company can be found. http://www.reactos.org/forum/viewtopic.php?f=2&t=7134&st=0&sk=t&sd=a TMax wanted to support MS Windows drivers "using ReactOS as reference(sic)" thanks to "ReactOS is GPL code" but seems they werent able to "replicate" and that they just use a Kernel(i didnt find which one)and "their Code" to support Windows Apps. I know there is somekind of not good relation between Wine and ReactOS, but it´s my obligation to aware you about this issue since we (ReactOS+Wine) are members of the Open Source Community. Wishing that my feels are wrong,and that any GPL has been violated, One Open Source Community Guy. -- -Austin

5 6

Font problem in Notepad -- regression today
by Susan Cragin 08 Jul '09

08 Jul '09

Notepad is behaving very strangely today. It crashes every time I try to change the font. However, when I tried to trace the problem using winedbg, the font changed fine, after the following fixme showed up. Then when I closed the winedbg terminal window, notepad closed too. susan(a)ubuntu:~$ winedbg Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000008 1 00000000 'notepad.exe' 0000000e 3 0000000a 'services.exe' 00000011 4 0000000e 'winedevice.exe' 00000018 1 00000008 'explorer.exe' Wine-dbg>attach 0x8 0x680007f0 GLIBC_2+0x7f0 in ld-linux.so.2: int $0x80 Wine-dbg>set $BreakOnFirstChance=0 Wine-dbg>cont fixme:winedbg:be_i386_is_func_call Unsupported yet call insn (0xcd) at 0x680007f0

1 0

Obsolete print dialogs in comdlg32?
by Frédéric Delanoy 08 Jul '09

08 Jul '09

Hi, During update of translation of comdlg32 dialogs, I saw that some printing dialogs seem broken, namely PRINT and PRINT_SETUP, while PRINT32 and PRINT32_SETUP look OK. I checked some programs and the PRINT[_SETUP] dialogs don't seem to be used (a casual check in the code didn't find usages). Are they still needed? Or can they simply be deleted? Frédéric

2 1

Re: winhttp(2/5): Simplify netconn_resolve when using getaddrinfo
by Hans Leidekker 08 Jul '09

08 Jul '09

Hi Juan, - *sa_len = sizeof(struct sockaddr_in); - memset( sa, 0, sizeof(struct sockaddr_in) ); - memcpy( &((struct sockaddr_in *)sa)->sin_addr, &((struct sockaddr_in *)res->ai_addr)->sin_addr, sizeof(struct in_addr) ); - ((struct sockaddr_in *)sa)->sin_family = res->ai_family; - ((struct sockaddr_in *)sa)->sin_port = htons( port ); + *sa_len = res->ai_addrlen; + memcpy( sa, res->ai_addr, res->ai_addrlen ); This causes test failures, you can't ignore the port. -Hans

2 1

Re: [comctl32/tests] Fix test failures with comctl32 <= 5.80
by Nikolay Sivov 08 Jul '09

08 Jul '09

Paul Vriens wrote: > Hi, > > Most of them are with comctl32 <= 5.80 but there seem to be some > different failures for 4.70. And not all failures for <= 5.80 are on > 4.70. I didn't think changing the comment for that is a big deal. > > I don't have 4.70 on any of my boxes but I've tested with 4.72. > > Changelog > Fix test failures with comctl32 <= 5.80 > You forgot a patch.

1 0

Re: [1/3] WineD3D: An indirect address op can adjust min and max at the same time
by Henri Verbeet 08 Jul '09

08 Jul '09

2009/7/7 Stefan Dösinger <stefan(a)codeweavers.com>: > if (reg->idx <= ((IWineD3DVertexShaderImpl *)This)->min_rel_offset) > + { > ((IWineD3DVertexShaderImpl *)This)->min_rel_offset = reg->idx; > - else if (reg->idx >= ((IWineD3DVertexShaderImpl *)This)->max_rel_offset) > + } > + if (reg->idx >= ((IWineD3DVertexShaderImpl *)This)->max_rel_offset) > + { > ((IWineD3DVertexShaderImpl *)This)->max_rel_offset = reg->idx; > + } If you're going to fix it, you might as well fix it properly. There's no point in assigning min_rel_offset or max_rel_offset if they're already the same as reg->idx.

2 1

AcceptEx Patch Comments
by Mike Kaplinskiy 07 Jul '09

07 Jul '09

I'm looking for some comments regarding my (winsock part by Scott) acceptex patch: http://bugs2.winehq.org/attachment.cgi?id=22193 . This is just preliminary and doesn't support receive (yet). The approach was done to fix the server-side issues AJ had with Scott's original patch, so server side code would be my main concern right now. Thanks, Mike.

1 0

Re: [PATCH 2/3] jscript: Changed to_primitive implementation
by Jacek Caban 07 Jul '09

07 Jul '09

Hi Piotr, Piotr Caban wrote: > --- > dlls/jscript/date.c | 2 +- > dlls/jscript/dispex.c | 2 +- > dlls/jscript/engine.c | 12 ++++---- > dlls/jscript/jscript.h | 9 ++++++- > dlls/jscript/jsutils.c | 57 > ++++++++++++++++++++++++++++++++++++++++---- > dlls/jscript/tests/api.js | 2 + > dlls/jscript/tests/lang.js | 7 +++++ > 7 files changed, 77 insertions(+), 14 deletions(-) > > + hres = jsdisp_get_id(jsdisp, hint == HINT_STRING ? toStringW : valueOfW, 0, &id); + if(SUCCEEDED(hres)) { + hres = jsdisp_call(jsdisp, id, ctx->lcid, DISPATCH_METHOD, &dp, ret, ei, NULL /*FIXME*/); + if(FAILED(hres)) { + FIXME("throw TypeError\n"); + return hres; You leak jsdisp here. + } + else if(V_VT(ret) != VT_DISPATCH) { + jsdisp_release(jsdisp); + return S_OK; + } + } You leak V_DISPATCH(ret) here. + hres = jsdisp_get_id(jsdisp, hint == HINT_STRING ? valueOfW : toStringW, 0, &id); + if(SUCCEEDED(hres)) { + hres = jsdisp_call(jsdisp, id, ctx->lcid, DISPATCH_METHOD, &dp, ret, ei, NULL /*FIXME*/); + if(FAILED(hres)) { + FIXME("throw TypeError\n"); + return hres; + } You leak jsdisp here. + else if(V_VT(ret) != VT_DISPATCH) { + jsdisp_release(jsdisp); + return S_OK; + } + } +date = new Date(); +function toString() { + return "toString"; +} +date.toString = toString; +ok(""+date === "toString", "\"\"+date = " + date); It would be nice to add a few more tests for different cases like returning objects from toString implementation. Also adding toString function to global scope is asking for a trouble in future tests, so I'd suggest construct like date.toString = function() {...} Thanks, Jacek

1 0

Re: user32/tests: Added test for infinite WM_PAINT loop (resend)
by Austin Lund 07 Jul '09

07 Jul '09

2009/7/5 Austin Lund <austin.lund(a)gmail.com>: > The last time I sent this, the patch was broken. I've tested it on > WinXPsp2 and wine-1.1.25. This patch relates to bug 10522. > Can I please have some feedback on this patch? The test is for what I found as the source of the problem, not for the loop itself. Should I be testing for the loop instead? Is there an easy way of doing this? For further rambling on the topic see the bug report (http://bugs.winehq.org/show_bug.cgi?id=10522)

1 0

Re: winhttp(0/5): add preliminary IPv6 support
by Austin English 07 Jul '09

07 Jul '09

On Tue, Jul 7, 2009 at 4:06 PM, Juan Lang<juan.lang(a)gmail.com> wrote: > Hi, this small patch series adds preliminary IPv6 support to winhttp. > I say it's preliminary because 1) it's not well tested, and 2) it > doesn't attempt to parse IPv6-specific address components such as the > scope ID. Mainly I wanted to get rid of the assumption that every > host address is represented by a struct sockaddr_in, because the > underlying library functions are more general than that. > > I'd appreciate feedback. For instance, it may well be that this > doesn't build on all systems, and that more configure magic will be > necessary. Builds fine for me on Ubuntu Jaunty and PC-BSD 7.1. OpenSolaris builds fine, but adds some warnings about visibility attribute (these are all over the tree though). I don't currently have Net/OpenBSD installed to test on, so if they're broken, I'll bug you when I test next ;-). -- -Austin

1 0