September 2010 - Wine-Devel

Re: widl: Explicitly declare default function's calling convention to avoid win64 problems.

by Jacek Caban

On 9/28/10 2:09 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: > >> @@ -369,7 +369,7 @@ static void write_type_v(FILE *h, type_t *t, int is_field, int declonly, const c >> if (type_get_type_detect_alias(pt) == TYPE_FUNCTION) { >> int i; >> const char *callconv = get_attrp(pt->attrs, ATTR_CALLCONV); >> - if (!callconv&& is_object_interface) callconv = "STDMETHODCALLTYPE"; >> + if (!callconv) callconv = is_object_interface ? "STDMETHODCALLTYPE" : "__cdecl"; > It may be useful to be able to declare functions that use the native > calling convention, I don't think we want to prevent that. Fair enough, I just wanted to make Wine safer for such cases. Jacek

Sept. 28, 2010

Re: mshtml and friends

by Jacek Caban

Hi Reece, On 9/28/10 2:59 PM, Reece Dunn wrote: > Hi, > > The current state of support for the Internet Explorer components in > Wine is good, but there are applications that don't work with it > because they are dependent on more of the functionality provided by > Internet Explorer via the WebBrowser control. > > I have had a scan through some of the mshtml code, and see various > things not handled -- such as the onload handler of the HTMLBody > element -- but I am not very familiar with this area. onload is handled properly on body element, it's just getter/setter that is a stub. It's a trivial one line patch that implements them. The fact that they are stubs means that I've never seen them used in apps I was working on. Most MSHTML APIs are trivial Gecko API wrappers. They are easy to implement, the only problem is that there are really many functions to implement. I implement only ones that are needed for real apps. The hard part of MSHTML is in the few APIs that are not just wrappers and not directly exposed parts like loading the document. > I am interested in helping out to improve this area -- my aim is to > not require the `winetricks ie6` command to get some of these > applications (specifically the Big Fish Games client) to a usable > state. > > Therefore, I am wondering if anyone knows where the best place is to > start looking (e.g. known areas of missing functionality) or how to > debug applications (and interpret WINEDEBUG output) to identify where > the issues are. There is no single answer. You want mshtml debug channel for most cases. If the problem is with embedding document in an app, then shdocvw is also useful. If you have scripts that don't work (and we use jscript for them), then jscript debug channel is the answer. If you have a problem with loading document, I'd add urlmon,wininet channel. Jacek

Sept. 28, 2010

Re: [PATCH 2/6] d3dcompiler: Implement D3DGetBlobPart().(try 2)

by Henri Verbeet

2010/9/27 Rico Schüller <kgbricola(a)web.de>: > !strcmp("unrecognized", debug_d3dcompiler_d3d_blob_part(part)) Oh, and please don't do that, I think it's very fragile.

Sept. 28, 2010

Re: [PATCH 2/6] d3dcompiler: Implement D3DGetBlobPart().(try 2)

by Henri Verbeet

2010/9/27 Rico Schüller <kgbricola(a)web.de>: > --- Wouldn't it be nicer if the "count" parameter to dxbc_init() was more of a hint? I.e., allow the sections array to grow if needed. For parse_dxbc() this works fine, because you know the number of sections in advance, but as you must have noticed, for creating the destination blob it's much more inconvenient.

Sept. 28, 2010

Re: winscard.dll

by Vitaliy Margolen

On 09/28/2010 06:46 AM, viny wrote: > Yes I started with this referenced discussion. > > Here is a first patch. With it, Winscard can identify your smartcard reader. > + g_pcscliteHandle = wine_dlopen("libpcsclite.so", RTLD_LAZY | RTLD_GLOBAL, error, sizeof(error)); You need to use configure to get the so name of the library. > +LONG WINAPI SCardListReadersA(SCARDCONTEXT hContext, LPCSTR mszGroups, LPSTR mszReaders, LPDWORD pcchReaders) > +{ > + LONG retval; > + LPSTR *pmszReaders; > + LPSTR szList = NULL; > + DWORD ListLength = 0; > + > + TRACE(" 0x%08X %p %p %p\n", (unsigned int) hContext, mszGroups, mszReaders, pcchReaders); If you want to print a pointer, print it as a pointer, don't convert it into int. It's not correct for 64-bit Wine. > +LONG WINAPI SCardListReadersA(SCARDCONTEXT hContext, LPCSTR mszGroups, LPSTR mszReaders, LPDWORD pcchReaders) > +{ > + LONG retval; > + LPSTR *pmszReaders; > + LPSTR szList = NULL; > + DWORD ListLength = 0; > + > + TRACE(" 0x%08X %p %p %p\n", (unsigned int) hContext, mszGroups, mszReaders, pcchReaders); > + > + if (!pcchReaders) > + retval = SCARD_E_INVALID_PARAMETER; > + else if (!pSCardListReaders) > + retval = SCARD_F_INTERNAL_ERROR; > + else if (mszReaders && *pcchReaders == SCARD_AUTOALLOCATE) > + { > + /* get list from pcsc-lite */ > + *pmszReaders = (LPSTR*) mszReaders; You corrupting memory here. You haven't assigned any memory to pmszReaders. Did you mean to write "pmszReaders = (LPSTR) mszReaders;" ? In fact I don't see you using the assigned value at all. Also you have some trailing spaces in your patch. Vitaliy.

Sept. 28, 2010

Re: [PATCH 2/6] msxml3: ignore whitespace nodes

by Adam Martinson

On 09/28/2010 06:27 AM, Nikolay Sivov wrote: > On 9/28/2010 05:37, Adam Martinson wrote: > >> From 1f8661342ae63290f212429e382b5776e07b9ebc Mon Sep 17 00:00:00 2001 >> From: Adam Martinson<amartinson(a)codeweavers.com> >> Date: Mon, 27 Sep 2010 19:29:04 -0500 >> Subject: [PATCH 2/6] msxml3: ignore whitespace nodes >> >> --- >> dlls/msxml3/msxml_private.h | 15 +++++++++++++++ >> dlls/msxml3/node.c | 9 +++++++++ >> dlls/msxml3/nodelist.c | 8 ++++++-- >> dlls/msxml3/tests/domdoc.c | 14 ++++++++++++++ >> 4 files changed, 44 insertions(+), 2 deletions(-) > > This should be affected by ::preserveWhiteSpace() property I guess. Yes, you are correct. I think it's fine to do that as a separate patch though, ignoring whitespace-only nodes seems to be the default behavior.

Sept. 28, 2010

mshtml and friends

by Reece Dunn

Hi, The current state of support for the Internet Explorer components in Wine is good, but there are applications that don't work with it because they are dependent on more of the functionality provided by Internet Explorer via the WebBrowser control. I have had a scan through some of the mshtml code, and see various things not handled -- such as the onload handler of the HTMLBody element -- but I am not very familiar with this area. I am interested in helping out to improve this area -- my aim is to not require the `winetricks ie6` command to get some of these applications (specifically the Big Fish Games client) to a usable state. Therefore, I am wondering if anyone knows where the best place is to start looking (e.g. known areas of missing functionality) or how to debug applications (and interpret WINEDEBUG output) to identify where the issues are. Thanks, - Reece

Sept. 28, 2010

Re: ws2_32(3/3): Implement WSAIoctl for SIO_ROUTING_INTERFACE_QUERY

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > This one may cause test failures on systems that don't have a route to > the loopback address. As far as I can tell, Windows systems always > have such a route, whereas on *ix it isn't guaranteed. I'm not sure > how to handle that, as broken() isn't allowed for Wine, and such a > networking configuration is at least strange. If it's really always present on Windows and apps depend on it, you'll have to fake a route. Otherwise just don't test it. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2010

Re: winscard.dll

by viny

Yes I started with this referenced discussion. Here is a first patch. With it, Winscard can identify your smartcard reader. Is it good enough to be sent to wine-patch ? Here (http://www.linuxunderground.be/compteco/winscard_test.zip) a Windows test program that identifies your smartcard reader. PS: don't use versions 1.6.0 and 1.6.1 of pcsc-lite (https://alioth.debian.org/tracker/?func=detail&atid=410085&aid=312555&group…) -- Vincent Le 28/09/2010 13:56, Jerome Leclanche a écrit : > The referenced discussion, in case anyone's curious: > http://www.winehq.org/pipermail/wine-devel/2008-August/068462.html > > > J. Leclanche > > > > On Tue, Sep 28, 2010 at 12:43 PM, Tom Wickline<twickline(a)gmail.com> wrote: >> Hello Vincent, >> >> I don't believe anyone is working on winscard.dll at this time. You are more >> then >> welcome to work on it or any other part of Wine. >> >> A couple years back their was a discussion about winscard.dll so you might >> want to search through the wine-dev mailing list. Maybe those old >> discussions >> can be of some help. >> >> Just some tips, >> >> Make sure you use the same coding style that's already used. >> Send as many test as you can. >> Keep your patches small and clean. >> Send patches here for review and to wine-patches for inclusion. >> >> >> Welcome to the wonderful world of Wine! >> >> Cheers, >> Tom >> >> >> >> On Tue, Sep 28, 2010 at 4:49 PM, viny<vincent.hardy.be(a)gmail.com> wrote: >>> >>> Hi all, >>> >>> Is anyone working on winscard.dll ? >>> >>> If not, may I propose patches ? >>> >>> I would like to have a working winscard.dll in wine. >>> >>> -- >>> Vincent >>> >>> >>> >> >> >> >> -- >> Wine is not a conclusion but a process... >> >> >> >> >> >>

Sept. 28, 2010

Re: ws2_32/tests: Send zero byte to any connected IrDA device (resend)

by Alexandre Julliard

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > Test for bug #19397. > Test only executed, if remote IrDA device is present. > Otherwise test is skipped. (Proposal from Mike Kaplinskiy) I'm not sure this is very useful. It's unlikely to be run on any of the test boxes, and AFAICS this is a kernel bug anyway, it should be a Unix test case not a Wine one. -- Alexandre Julliard julliard(a)winehq.org

Sept. 28, 2010