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

Re: mlang: Make mlang tests pass under windows
by Dmitry Timoshkov 08 May '08

08 May '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > + /* Not all codepages can be converted to UTF-8 */ > + if (cpinfo[i].uiCodePage == 20127 || cpinfo[i].uiCodePage == 28591 || cpinfo[i].uiCodePage == 28605) > + expected = S_FALSE; The statement above is not true. The reason for mlang test failures is that apparently mlang in Windows has its own idea of supported locales not connected to real kernel32 implementation. I'd leave the tests as they are, there is nothing wrong in them, we can't fix Windows bugs. -- Dmitry.

2 2

Bison 2.1 / Solaris
by Austin English 08 May '08

08 May '08

Howdy, Tried compiling wine on Nexenta (Opensolaris kernel with GNU userland). Trying to test out the conformance test, but can't get it to compile: make[2]: Entering directory `/export/home/austin/wine/libs/wpp' gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o preproc.o preproc.c gcc -c -I. -I. -I../../include -I../../include -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o wpp.o wpp.c bison -p ppy_ -o ppy.tab.c -d ppy.y make[2]: *** [ppy.tab.h] Broken Pipe make[2]: Leaving directory `/export/home/austin/wine/libs/wpp' make[1]: *** [wpp] Error 2 make[1]: Leaving directory `/export/home/austin/wine/libs' make: *** [libs] Error 2 austin(a)nexenta:~/wine$ bison --version bison (GNU Bison) 2.1 Looking at my feisty box, looks like it's using 2.3. Anyone had similar troubles getting wine to compile in 2.1? Google's not turning up much, aside from saying get it precompiled... -Austin

3 2

Re: wininet: Deal with bogus accept types array passed into HttpOpenRequestA.
by Maarten Lankhorst 07 May '08

07 May '08

Hoi Hans 2008/5/7 Hans Leidekker <hans(a)it.vu.nl>: > > The bug reporting agent in Google Sketchup passes an accept types > array that includes a wild pointer and a pointer to an empty string, > both of which are ignored by Windows. Although the wild pointer changed > between a number of tries its high word remained unset, so we may get > away with a check on the high word instead of an exception handler. > > Fixes http://bugs.winehq.org/show_bug.cgi?id=11954 > > -Hans This test fails on xp for me, can you fix it? http.c:1767: Test failed: got ', */*, %p, , */*' expected '*/*, %p, */*' Cheers, Maarten.

1 0

Re: SOC 2008 Projects Announced
by Dylan Smith 07 May '08

07 May '08

Hello everyone, My name is Dylan Smith, and I will be working on implementing tables in rich edit controls as a Google Summer of Code project. Any remaining time I have will also be focused on rich edit controls for this summer. Forgive me for taking so long to introduce myself on the developers mailing list. I ended up going straight for the code as soon as my exams finished. I just finished my last year of Software Engineering at Carleton University which is located in Ottawa, Canada. I will be returning to Carleton University for my Masters after the summer. I am thrilled that I am getting this opportunity to work on Wine for the summer. Happy coding to you all, Dylan

1 0

2nd draft: 1.0 call for testing
by Dan Kegel 07 May '08

07 May '08

How's this look? It's on the wiki now: http://wiki.winehq.org/PlatinumRegressionHunt

1 0

winetricks missing MFC42
by Cesar Izurieta 07 May '08

07 May '08

I see that MFC42 is missing on wine tricks. There's a cab available from: http://activex.microsoft.com/controls/vc/mfc42.cab that contains an installer. It would be nice to add this to winetricks I guess.

1 0

Re: [PATCH] check for iface->ref to avoid crash
by Robert Shearman 07 May '08

07 May '08

Marcus Meissner wrote: > @@ -742,6 +742,9 @@ static void write_c_method_def(FILE *header, const type_t *iface) > > static void write_c_disp_method_def(FILE *header, const type_t *iface) > { > + if (!iface->ref) { > + error_loc("write_c_disp_method_def: no reference on interface(%p)\n", iface); > + } > do_write_c_method_def(header, iface->ref, iface->name); > } > This can't ever happen. dispinterfaces always derive from IDispatch: > dispinterfacehdr: attributes dispinterface { attr_t *attrs; > is_in_interface = TRUE; > is_object_interface > = TRUE; > $$ = $2; > if ($$->defined) > error_loc("multiple definition error\n"); > attrs = > make_attr(ATTR_DISPINTERFACE); > $$->attrs = > append_attr( check_dispiface_attrs($2->name, $1), attrs ); > $$->ref = > find_type("IDispatch", 0); > if (!$$->ref) > error_loc("IDispatch is undefined\n"); > $$->defined = TRUE; > if (!parse_only && > do_header) write_forward($$); > } -- Rob Shearman

2 1

Re: rpcrt4: Fix ndr_marshall test failures, try 2
by Robert Shearman 07 May '08

07 May '08

Maarten Lankhorst wrote: > - ok(RPC_S_OK == RpcServerUseProtseqEp(ncalrpc, 20, endpoint, NULL), "RpcServerUseProtseqEp\n"); > - ok(RPC_S_OK == RpcServerRegisterIf(IFoo_v0_0_s_ifspec, NULL, NULL), "RpcServerRegisterIf\n"); > - ok(RPC_S_OK == RpcServerListen(1, 20, TRUE), "RpcServerListen\n"); > + status = RpcServerUseProtseqEp(ncalrpc, 20, endpoint, NULL); > + ok(RPC_S_OK == status, "RpcServerUseProtseqEp failed with status %08lx\n", status); > + status = RpcServerRegisterIf(IFoo_v0_0_s_ifspec, NULL, NULL); > + ok(RPC_S_OK == status, "RpcServerRegisterIf failed with status %08lx\n", status); > + status = RpcServerListen(1, 20, TRUE); > + ok(RPC_S_OK == status, "RpcServerListen failed with status %08lx\n", status); > Since the RPC status values are in decimal in winerror.h, it is more user-friendly to output them in decimal in the failure messages. -- Rob Shearman

1 0

What happened to the ntdll rtlstr tests?
by Maarten Lankhorst 07 May '08

07 May '08

Hello Alexandre, Why were the fixes for the ntdll rtlstr test failures on windows not accepted? Cheers, Maarten.

2 1

Serial port support in wine-1.0: What to do to make it working ?
by Pavel Troller 07 May '08

07 May '08

Hi! I have really BIG problems running any application, which needs to comm over a serial port: - My ham TCVR - My GPS - My multimeter - A lot of my mobiles - A lot of devices used in my work (special telco equipment, comms varying from simple AT-style commands up to complex proprietary binary protocols). In all the cases there are very similar problems - either the program doesn't detect the device properly, or the device doesn't respond, or in some cases the device does, what the program wants, but it then can't read it back. It looks that some archaic wine versions are better, for example I have to use wine-0.9.40 to communicate with a device in my work (simple text-based command-reply communication), any wine newer than say 0.9.50 doesn't work, the communication times out. Because I'm a telco engineer and serial comm is my daily work, and there are only windows versions of many tools I have to use, proper and mature serial port support is essential for me. So, what can I do to help fixing these problems ? Should I open a bug for every such a program ? Or just open one bug and state all the programs there ? I think that bugzilla contains a lot of bugs related to serial port; is it good to add a new ones ? I'm afraid I can't bisect a problem between 0.9.40 and current wine, but I can make a serial trace for both of them and look at the difference. Would it help to find at least this one particular problem ? Or what more can I do to make the serial port working ? I can code in C in the Linux environment, but I know NOTHING about windows... With regards, Pavel Troller

3 3