November 2007 - Wine-Devel - list.winehq.org

Re: wininet: make a test pass on all versions of windows

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > + > + { > + OSVERSIONINFOEX foo; > + BOOL r; > + memset(&foo, 0, sizeof(foo)); > + foo.dwOSVersionInfoSize = sizeof(foo); > + r = GetVersionEx((OSVERSIONINFO *) &foo); > + if (!r) > + { > + skip("could not get windows version\n"); > + return; > + } > + > + is_sp1 = -1; > + if (foo.dwMajorVersion > 5) > + is_sp1 = 1; > + else if (foo.dwMajorVersion == 5) > + { > + if (foo.dwMinorVersion > 1) > + is_sp1 = 1; > + else if (foo.dwMinorVersion == 1) > + { > + if (foo.wServicePackMajor > 1) > + is_sp1 = 1; > + else if (foo.wServicePackMajor == 1) > + is_sp1 = 0; > + } > + } Please don't add version checks in tests. -- Alexandre Julliard julliard(a)winehq.org

Nov. 9, 2007

Re: valgrind results updated

by Dan Kegel

On Nov 8, 2007 6:46 PM, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > I looked at the vg-user32_win.txt warnings, and most of them are > triggered by test_gettext() which intentionally passes an invalid > memory address to SendMessage(WM_GETTEXT). OK, I'll add a suppression for that. BTW tests/win.c seems pretty racy. It fails strangely with warn+heap and differently strangely under valgrind. Under Valgrind, I bet the test is just bad at running really slowly. No idea why it fails with warn+heap, which doesn't seem too slow. > There is also one memry leak reported, but I couldn't figure out > the reason of that one. I'm not so worried about those, a leak's not as bad as a wild pointer, and it's probably just a missing free or close or something in the test code. But thanks for looking. - Dan

Nov. 9, 2007

Successful Virtualization startup looking for engineers with system level Windows and Linux experience

by Richard Offer

We are a well-funded software startup in the virtualization space that is looking to hire several engineers with system level experience in Windows and Linux - ideally in combination. I can't tell you what you'd be doing but you can be re-assured that since we are long-term open source supporters any modifications to Wine or WineLib that you make will, of course, be contributed back to the community. We are particularly interested in experiences in the areas of * Registry modification, manipulation and creation * Windows internals or system level user-space. Device drivers aren't very interesting to us. * Reverse engineering skills * Installable file systems * Windows server technologies such as IIS, AD, 2003, Longhorn etc * Virtualization technologies such as VMware, AppStream, Softricity and Xen. If you or anyone you know have an interest and are eligible for working an a small but rapidly growing company in Silicon Valley on things that are novel and technically challenging, please send a current resume to engr-jobs(a)fastscale.com - including WSE in the subject line of any emails. For more information on the company, our technology and shipping products please visit us at http://www.fastscale.com/ Yours truly, Richard Offer

Nov. 9, 2007

Re: wininet: skip strcmp() in a test if the returned len is wrong

by Dmitry Timoshkov

"Lei Zhang" <thestig(a)google.com> wrote: > We'll skip doing strcmp() on a potentially uninitialized buffer if the > returned length is wrong. > - todo_wine ok(!strcmp(useragent,buffer),"Got wrong user agent string %s instead of %s\n",buffer,useragent); > - todo_wine ok(len == strlen(useragent),"Got wrong user agent length %d instead of %d\n",len,lstrlenA(useragent)); > + len_ok = (len == strlen(useragent)); > + todo_wine ok(len_ok,"Got wrong user agent length %d instead of %d\n",len,lstrlenA(useragent)); > + if (len_ok) > + todo_wine ok(!strcmp(useragent,buffer),"Got wrong user agent string %s instead of %s\n",buffer,useragent); Probably a better solution would be to actually check the return value of InternetQueryOption before touching the returned buffers. -- Dmitry.

Nov. 9, 2007

Re: valgrind results updated

by Dmitry Timoshkov

"Dan Kegel" <dank(a)kegel.com> wrote: > I've updated > http://kegel.com/wine/valgrind/ > Today's results are at > http://kegel.com/wine/valgrind/20071103/ > > The only difference from yesterday is I've added > suppressions for the most common memory leaks, > on the theory that it's easier to see the module-specific > leaks that way. I looked at the vg-user32_win.txt warnings, and most of them are triggered by test_gettext() which intentionally passes an invalid memory address to SendMessage(WM_GETTEXT). There is also one memry leak reported, but I couldn't figure out the reason of that one. -- Dmitry.

Nov. 9, 2007

valgrind/urlmon & http/variable question

by Misha Koshelev

> Hi Dan et al., > > So I just wanted to let you know that I have looked somewhat at one (the only as far as I saw) of the valgrind results related to HttpProtocol in urlmon, and basically it involves passing a pointer to a PROTOCOLDATA from a local variable inside a function to the ProtocolSink call which ends up > sending a message with this pointer. When this pointer is processed later, since it is a pointer to a local variable which (presumably) exists only on the stack, it is not really valid. > > Now this is quite easy to "fix" with a five-line patch that HeapAlloc's the proper structures. However, I was trying to figure out how native does this to copy it, and kind of ran into a dilemma. Namely, doing a simple patch like shown below (this probably won't really be a diff as I copy/pasted it > into WebMail which will probably mess it up, but it should give a general idea) and then doing a WINEDLLOVERRIDES with native urlmon and wininet and +relay WINEDEBUG I can see that the the PROTOCOLDATA pointers are pointing to stuff like 0x7d7ad790 and 0x7d7ad820. Now, much to my suprise, these > addresses, nor addresses in the proximate range (approximate) to that address don't seem to be part of any other relay calls, including any calls to any sort of allocation functions. Now this leaves me a little stumped ,as I can only see a few ways to properly implement these PROTOCOLDATA pointers > (without a memory leak): > > 1. A static PROTOCOLDATA variable (local or global). In this case, the address I see for native should never change I believe, but also this would not be correct as potentially you could have more than one HttpProtocol using the same structure. > > 2. Dynamic allocation of the PROTOCOLDATA structure. This seems like the best option to me, but native either does not seem to be using it or allocates it in some way in which the address or even partial versions of the address does not appear in any allocation functions (or really anywhere) in the > +relay log. Any ideas on what allocation functions I could be missing here? > > 3. Have one PROTOCOLDATA structure per IInternetProtocol implementation of http. This seems reasonable too, except I am also printing out the address of the IInternetProtocol structure and clearly PROTOCOLDATA is not in an address range anywhere near this structure, and it is never allocated so it > can't be a pointer within that structure. > > So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated. > > Thanks, > > Misha Hmm... so it looks like upon investigation the address ranges for PROTOCOLDATA with antive dlls are actually suspiciously similar to those I see in the current local variable implementation... which makes me think that the implementation is dissimilar (and thus leaky) in the downstream ProtocolSink implementation in binding.c, which will be a little harder to test... Misha

Nov. 9, 2007

Valgrind results for Oct 8: lots of hangs?!

by Dan Kegel

Data online at http://kegel.com/wine/valgrind/20071108/ For some reason, today I had to do 'wineserver -k' about five times (yesterday and the day before only once). And one of those times was during a d3d9 test which took over / hung the screen; not even ctl-alt-backspace helped, I actually had to reboot (I didn't try ssh'ing in). Running the tests was like pulling teeth. That said, here are the changes in the list of bad tests; - means test didn't show any valgrind errors today but did yesterday, + means it did show valgrind errors today but not yesterday. -vg-d3d9_visual.txt (might be one I had to reboot for) -vg-iphlpapi_iphlpapi.txt -vg-mlang_mlang.txt +vg-mshtml_dom.txt +vg-mshtml_htmldoc.txt +vg-shdocvw_webbrowser.txt -vg-wininet_ftp.txt -- Wine for Windows ISVs: http://kegel.com/wine/isv

Nov. 9, 2007

None

by Colin M Inglis

Hi! I'm trying to install Wine for a client, a Mac house, who run some software only supported under Windows or Classic. With the recent introduction of Intel Macs (that no longer support Classic) into the business, the Windows version is, unfortunately, their only upgrade path. I have C development experience and am familiar with compiling C applications under unix, although that was some years ago and processes seem to have changed somewhat. In particular, I am unfamiliar with the 'configure' executable described in your installation manual, which is raising an error. Could you please look briefly at the attached config.log? I would be interested to know if this is an issue to which I can attend, or whether it is a deficiency in the configuration process itself. I would also appreciate a workaround, if possible. Thanks in anticipation of your assistance. Regards, ////////// // // / / Colin M Inglis BInfoTech&Comm //////////// // // / / Software Application Development /// //\//\\ infinite 15 Jasmine St, Strathpine, Q, Australia // // // // Snailmail PO Box 2188 Strathpine Q 4500 /// \\//\// interface email manager(a)infinitei.com.au ///////// // // / / web http://www.infinitei.com.au ////// // // / / Ph/Fax +61 7 3881 3494 ABN: 40 030 880 342 Mobile +61 414 388 134 "infinite interface programmes programmes users use"

Nov. 9, 2007

Re: Problem with client manually starting services

by Robert Shearman

Roy Shea wrote: > Specifying test_service.exe in the registry causes > the service to fail since CreateProcessW is unable to locate the file. > Finally, setting the registry value to svchost.exe.so works without > any errors. Unfortunately, this last version is not compatible with > Windows registry configurations. > > CreateProcessW already preforms a search for the binary it is > starting. Perhaps we could have it also look for a binary ending in > ".so". Or just create a fake executable for it by listing it in tools/wine.inf. -- Rob Shearman

Nov. 8, 2007

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes

by Mirek Slugeň

Nov. 8, 2007