October 2002 - Wine-Devel - list.winehq.org

Some other problems ...
by Paul Millar Oct. 31, 2002

Oct. 31, 2002

Hi everyone, Just a couple of problems I've noticed. They look like they're due to some broken build dependencies. 1. I have a copy of wine on my laptop which I do "cvs update" every few days. After updating today, I did the usual "./configure --enable-opengl && make depend && make" and left it to compile. But, when I tried the result, I got a client/server mismatch for SERVER_PROTOCOL_VERSION. One was claimed to be v88 whilst the other was v89. Doing a "make distclean" then repeating the build "fixed" the problem. Patch http://cvs.winehq.com/patch.py?id=6064 (committed last Tuesday) bumped the SERVER_PROTOCOL_VERSION up to 89. So it looks like some of the binaries weren't updated during the build. I tried altering the version (manually) and rebuilding, but wine rebuilt correctly. 2. WRT hit a problem last night where "make test" failed. The log included messages like: gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -D_REENTRANT -o registry.o registry.c LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o advapi32_test.exe.spec.c -exe advapi32_test.exe -mcui registry.o testlist.o -L../../../dlls -ladvapi32 -lkernel32 -lntdll gcc -shared -Wl,-Bsymbolic advapi32_test.exe.spec.o registry.o testlist.o -o advapi32_test.exe.so -L../../../library -lwine -lm advapi32_test.exe.spec.o: In function `__wine_exe_main': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/advapi32_test.exe.spec.c:116: undefined reference to `main' registry.o: In function `test_enum_value': /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_set_ok_location' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:69: undefined reference to `winetest_ok' /home/paulm/WINE-cvs/wine/dlls/advapi32/tests/registry.c:78: undefined reference to `winetest_set_ok_location' [... etc ...] The later build had six tests that succeded. These were the new scanf tests introduced into that build by patch http://cvs.winehq.com/patch.py?id=6107 I've just done a "make distclean" followed by a normal rebuild and test. Its currently running through the regression tests, but so far it seems to be working. These are vague reports of unrepeatable problems ... never a good thing! I'm quite busy right now (real work and everything), so I don't have time to investigate this myself. Just posting this hoping the cause its obvious to someone else :^) ---- Paul Millar

1 0

Re: dlls/msvcrt/tests: printf
by Jaco Greeff Oct. 31, 2002

Oct. 31, 2002

On Thu Oct 31 20:04:30 2002, "Jaco Greeff" <jaco(a)puxedo.org> wrote : > On Thu, 31 Oct 2002 17:57:12 +0100, Uwe Bonnes > <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote : > > Jaco> ... Tests that will fail > > Jaco> with current implementation are temporarily commented out > > > > Don't comment them out, matrk them "todo". Look at the syntax in > > documentation/testing. > > I've marked the code with a "FIXME". Sorry, I misunderstood the first time around, will something like todo("linux") { do(something() == 1, "whatever"); } do the trick? But unsure about the definition I should use, I can see "cygwin", "freebsd", etc. This one will fail on all non-Windows platforms. Greetings, Jaco

1 0

Re: dlls/msvcrt/tests: printf
by Jaco Greeff Oct. 31, 2002

Oct. 31, 2002

On Thu, 31 Oct 2002 11:04:48 -0600, Greg Turner <gmturner007(a)ameritech.net> wrote : > On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > > - Tests that will fail with current implementation are temporarily > > commented out > > Is there a middle ground for tests that are expected to fail? If not, > IMO maybe there should be: It kinda defeats the purpose of a test > framework if we just comment out tests that don't work... Agreed. It will pass shortly though :) At this point the test will help anybody wishing to verify my latest msvcrt patch. Plus, it really should pass. The part that does fail is on Unicode printing, which give me one of a few choices: 1. Don't send in a test; 2. Be stubborn and let the test fail for everybody doing a make test; 3. Send in a really crippled test case; 4. Combination of 3 + 4 so people can easily have the framework to test if progress have been made. That is the reason why I've commented it out, hopefully shortly it will be fully featured. Greetings, Jaco

1 0

Re: dlls/msvcrt/tests: printf
by Greg Turner Oct. 31, 2002

Oct. 31, 2002

On Thursday 31 October 2002 10:34 am, Jaco Greeff wrote: > - Tests that will fail with current implementation are temporarily > commented out Is there a middle ground for tests that are expected to fail? If not, IMO maybe there should be: It kinda defeats the purpose of a test framework if we just comment out tests that don't work... but OTOH, its pretty unfair to the other tests to have the whole "make test" fail because of some known issue. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

1 0

Re: rpc_H_PL9
by Michael Stefaniuc Oct. 31, 2002

Oct. 31, 2002

On Thu, Oct 31, 2002 at 08:49:18AM -0600, Greg Turner wrote: > LICENSE: X11 > > CHANGELOG: > * dlls/rpcrt4: rpc_server.c; > include: rpcdcep.h: > Greg Turner <gmturner007(a)ameritech.net> > - One more fixup for winapi_check > -UINT WINAPI I_RpcWindowProc( HANDLE hWnd, UINT Message, UINT wParam, ULONG lParam) +UINT WINAPI I_RpcWindowProc( void *hWnd, UINT Message, UINT wParam, ULONG lParam ) That's totaly broken. It's a problem in winapi_check and not in your code. Well, their is a problem in your code too, i would change HANDLE to HWND. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 2

RE: winapi_check question...
by Patrik Stridvall Oct. 31, 2002

Oct. 31, 2002

> winapi_check tells me: > > ndr_stubless.c:86: rpcrt4: LONG_PTR WINAPIV > NdrClientCall2(PMIDL_STUB_DESC,PFORMAT_STRING,...): argument 1 > documentation: \ > /* CLIENT_CALL_RETURN */ This is because winapi_check misparser the line: LONG_PTR /* CLIENT_CALL_RETURN */ RPCRT4_NdrClientCall2(PMIDL_STUB_DESC pStubDesc, PFORMAT_STRING pFormat, va_list args) Ignore it. > rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI > RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): > no translation defined: PRPC_BINDING_VECTOR This is because winapi_check doesn't know the type of PRPC_BINDING_VECTOR. One day I will teach it to parse the header files properly. Until then tell it what type it is in the the file tools/winapi/win32.api: %%rpcrt4 ... %ptr ... PRPC_BINDING_VECTOR ... Since PRPC_BINDING_VECTOR is presumable a pointer it goes under the ptr section. > rpc_epmap.c:56: rpcrt4: RPC_STATUS WINAPI > RpcEpRegisterA(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR,LPSTR): > no translation defined: PUUID_VECTOR Same as above. > rpc_epmap.c:102: rpcrt4: RPC_STATUS WINAPI > RpcEpUnregister(RPC_IF_HANDLE,PRPC_BINDING_VECTOR,PUUID_VECTOR): > argument 2 type is forbidden: PRPC_BINDING_VECTOR (unknown) Same as above. > how shall I deal with these? Fix them as above or do as everybody elses do wait for me to fix it. :-)

2 1

Re: dlls/msvcrt/tests: printf
by Uwe Bonnes Oct. 31, 2002

Oct. 31, 2002

>>>>> "Jaco" == Jaco Greeff <jaco(a)puxedo.org> writes: Jaco> ... Tests that will fail Jaco> with current implementation are temporarily commented out Don't comment them out, matrk them "todo". Look at the syntax in documentation/testing. And plain inlined patches are preferred against attachments. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: Re: So lets say we do it
by chrismorgan＠rcn.com Oct. 31, 2002

Oct. 31, 2002

> > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 2002/10/31 Thu AM 11:24:28 EST > To: dpaun(a)rogers.com > CC: Wine Devel <wine-devel(a)winehq.com> > Subject: Re: So lets say we do it > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > So the 5% left, install wine, install a Win-app, and play around. > > Great, it works! > > You forgot a few things here: > > First it doesn't even start because they don't have a config file. OK, > they copy one from somewhere, it doesn't work because the drives are > wrong. Then they don't have the proper registry (winedefault.reg? > what's that?) I was going to reply yesterday on this issue. I help a fair amount of people on irc that have config problems and there are a few things we should probably do to fix this. 1. Check the wine config on startup. If the config is missing or incorrect then launch a gui config app to fix things. It would be best if this tool had two user options, one for an Automatic setup and another for an Expert setup. We do a good job with wineinstall so I don't have much doubt that we could automate the config and satisfy 80%+ of users. 2. Make it easier for users to modify their configs via a gui tool. 3. Straighten out how packages(RPM, deb, etc) setup wine's config. I'm not even sure how this is done right now and LOTS of people come asking for help saying they have installed an RPM version of wine but don't know how to configure it. This might be completely solved by #1. Chris

1 0

Re: Re: So lets say we do it
by chrismorgan＠rcn.com Oct. 31, 2002

Oct. 31, 2002

> > 2. People will look for the typical left-side menu: > > Home > > About > > Status > > Development > > Download > > Screenshots > > > > *BZZT* We don't have any. 5% will drop off here. > > Sorry to say that, but in this mail, *you* were talking *some* crap IMHO > ;-) > > We *do* have screenshots. The About page has some pretty nice screenshot. > OK, it's a minimalist approach, granted, but it does show IE etc. > I'd also like to second the opinion that we should have a dedicated "Screenshot" entry right off of the main page. I do the same stuff that Dimitrie does, go to a project, look at some text briefly and then immediately want to see what the app looks like when it is working. So maybe leave the screenshot link off of the "About" page but also put a link on the main page. Chris

1 0

RPC test code?
by Greg Turner Oct. 31, 2002

Oct. 31, 2002

OK, wine made it's first successful RPC's on my box today (yay!) Now, it's time to do a smidgen of housekeeping, and whip up a test. This is a bit tricky, I have a few open questions, which I will enumerate: 1) It feels like cheating to use the same process as client /and/ server. OTOH, it will be a bit cleaner to do it as such... any thoughts on this? specifically, 1a) Will wedging what is basically a winelib app into my test directory create a problem in the configure/make system? Is there a clean way to make sure I invoke the right winelib .exe.so file (the one in my test directory)? 1b) Are all the process-control API's I will need for this in place? (in particular I should kill off the server in case of a failure... will this be a problem? I guess probably not, or else I'd see a lot more wine's hanging around in my process table.) 1c) If the test fails in the winelib thingy, I have to propagate this back to the test; but relying on RPC for this (aside from being unimplemented ATM) is a catch-22, since error propagation might be broken (hence the need for a test)... I guess I can think of creative solutions to this like putting stupid temp files somewhere. Any better ideas? 1d) Anyone know of a problem with this I haven't thought of yet? 2) Whether I use threads or processes, I need some coordination to happen; I am very concerned about race conditions. I want my tests to run under the most absurd and grueling conditions, with NO race conditions. But I can't wrap my mind around how to avoid them ATM. For example: 2a) Should the rpc.c "real" test be the client or the server? I can imagine races either way. Let's say rpc.c is the client. This isn't so bad at a glance; I invoke the server thread/process, and poll RPC from time to time until it goes active (how I do this is another issue, but I'll think of something). Now I do my magic, and request a shutdown via RPC to the server... but, in two cases there is technically a race: first, while I'm invoking the server, I have to wait for it to start as discussed; second, after I send the Shutdown RPC to the server, I have to actually wait for the process/thread to terminate. In both cases, how long is long enough? What if the tests are running on some absurdly bogged down machine that's simultaneously compiling a matrix of 10,000 different wine's, for example? On the other hand, if I use some really liberal timeout like 30 minutes, then in a failure condition, my test would appear to hang, this isn't so great either. If rpc.c is the server, similar problems exist. 2b-?) uh, I guess I squeezed all of these questions into 2a. 3) MIDL? I still haven't figured out the legal ramifications of using midl-generated code. I'd rather not spend a month working on widl before generating a test... so do I need to code my stubs by hand? Even if I do, they're gonna come out looking more-or-less just like MIDL code... maybe I need to figure out the licensing restrictions on MIDL-generated code myself, but does anyone know offhand, I didn't see any obvious discussion of this on microsoft.com or in the platform sdk. ugh. thanks for taking the time to read this long-winded post. Any responses, assistance, flames, etc. are appreciated. -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

4 6