January 2003 - Wine-Devel - list.winehq.org

Re: new to wine and would like to be actively involved.

by Dan Kegel

Tom Wickline wrote: >> I am new to the wine developement community and would like to >> actively >> get involved in the activities in this community. Could anyone please >> educate me on how i can go about doing that?.. I have strong developement >> skills in C and Perl.. and have worked with converting C source code in >> informix. Awaiting more from your side.. > > Here is a starter guide :) I'm sure there is alot of other goodies to > work on as well. > See : http://www.dssd.ca/wine/Wine-Contrib-0.7.html I strongly recommend adding to the conformance test suite as a first step for people with strong C skills! By the way, http://www.dssd.ca/wine/Wine-Contrib-0.7.html#conf_tests still says "Either C or perl skills" but perhaps this should just say "C programming skills" as the Perl tests were removed. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 14, 2003

Re: Wine, Mozilla & IE ?

by Ender

> That's another possibility of course, that you might wish to look into > Ender. GTK-HTML doesn't get the same amount of press that KHTML does, > but it's written in C and is actually a fairly capable embedded html > renderer. It relies upon GTK/GDK which already has a port to Windows, > the GNOME help system uses it for rendering afaik so it should be easier > to integrate with Wine. Finally it supports editing, which might come in > useful in future. GTK-HTML is far too basic for our needs. We need at least DHTML and JS support for any IWebBrowser/IE replacement to be useful. - Ender

Jan. 14, 2003

WineMine wrc error

by John Westerman

Hi, I seem to have a bit of trouble building the winemine sample. When it gets to the wrc stage it just says: make: *** [rsrc.res] Error 1 Any ideas?

Jan. 14, 2003

Re: distcc and wine

by Martin Pool

On 14 Jan 2003, Paul Millar <paulm(a)astro.gla.ac.uk> wrote: > I've just tried distcc and its wonderful! Thanks. :-) > I haven't benchmarked it yet, > but subjectively (from watching the nodes' load-avr) distcc seems to give > *much* more even loading that just running OpenMOSIX. If anyone has more > than one machine at their disposal, I'd strongly recommend investigating > distcc. > > On Thu, 9 Jan 2003, Martin Pool wrote: > > I haven't tried it myself but I would have expected the short, intense > > jobs generated by compilation to be a problem [for OpenMOSIX] > > Yes, I agree. But, I think OM still has a role to play. Running OM > underneath distcc should help improve the mean performance (in a > heterogeneous cluster). Whenever a faster node is unloaded whilst a > slower node is busy compiling (and this situation lasts for any length of > time) OM should migrate that process to the faster node, speeding up > compilation. That might occur just before linking, for example. The argument against it is this: compiler processes have a large working set (>20MB, say, though it varies), do a lot of IO, and only run for a few seconds. On a 100Mbps network migration of a running process will take a few seconds, after which time many other processes may have started and stopped, so the load pattern may be very different. I think it may be difficult for OpenMOSIX to react fast enough to handle the condition you describe. I have not personally benchmarked OpenMOSIX for this, so you should take the above with a pinch of salt. I'd very much like to work with somebody with a >8 machine cluster to run distcc benchmarks and comparisons to SSI clusters. The "grainy" nature of the workload makes it difficult for distcc to schedule optimally, although it should improve somewhat in the next few months. This paper describes good results using MOSIX for software building: http://www.mosix.cs.huji.ac.il/ftps/usenix.ps.gz Thought they did spend USD $390,000, which is more than I can manage. :-) > I guess the improvement will depend strongly on the composition of the > cluster and the code you're compiling. The improvement (from running OM) > might be marginal in certain cases, but I don't think it would make things > worse. Well, it may use network bandwidth and CPU cycles for migration or overhead that might be better spent on either cc or distcc. It's great that there is good free single-image clustering software. The point of distcc is just that you can distribute the particular task of compilation with a much simpler and less intrusive program. -- Martin

Jan. 14, 2003

Re: prevent dereferencing null

by Bill Medland

On January 13, 2003 06:36 pm, you wrote: > On January 9, 2003 10:44 pm, Marcus Meissner wrote: > > On Thu, Jan 09, 2003 at 05:45:00PM -0800, Bill Medland wrote: > > > On January 9, 2003 03:12 pm, Dimitrie O. Paun wrote: > > > > On January 9, 2003 07:08 pm, Bill Medland wrote: > > > > > + if (!tpinfo->chanbuf) { > > > > > + ERR("tpinfo has no Rpc Channel Buffer\n"); > > > > > + return 0; > > > > > + } > > > > > > > > Is this expected behaviour? If so, there's no need for the ERR msg. > > > > If not, there's no need for the test, we need to fix the root > > > > cause... > > > > > > You are, of course, quite correct. > > > I don't know what the expected behaviour is; all I know is that > > > dereferncing the null pointer isn't. > > > If someone actually understands all that proxy stuff then maybe they > > > can do something about it. > > > If not then I guess it is destined to languish unfixed. > > > > I vaguely remember this happening for inter-thread COM, I did not come > > around to debug it yet. > > > > "return E_FAIL;" might be more appropriate too. > > > > Ciao, Marcus > > Does anyone have any test harness/Petzold-style code for investigating > IProxyBuffer so that we can tighten up the loose edges? Woops. I mean IRpcProxyBuffer -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

Jan. 14, 2003

Re: prevent dereferencing null

by Bill Medland

On January 9, 2003 10:44 pm, Marcus Meissner wrote: > On Thu, Jan 09, 2003 at 05:45:00PM -0800, Bill Medland wrote: > > On January 9, 2003 03:12 pm, Dimitrie O. Paun wrote: > > > On January 9, 2003 07:08 pm, Bill Medland wrote: > > > > + if (!tpinfo->chanbuf) { > > > > + ERR("tpinfo has no Rpc Channel Buffer\n"); > > > > + return 0; > > > > + } > > > > > > Is this expected behaviour? If so, there's no need for the ERR msg. > > > If not, there's no need for the test, we need to fix the root cause... > > > > You are, of course, quite correct. > > I don't know what the expected behaviour is; all I know is that > > dereferncing the null pointer isn't. > > If someone actually understands all that proxy stuff then maybe they can > > do something about it. > > If not then I guess it is destined to languish unfixed. > > I vaguely remember this happening for inter-thread COM, I did not come > around to debug it yet. > > "return E_FAIL;" might be more appropriate too. > > Ciao, Marcus Does anyone have any test harness/Petzold-style code for investigating IProxyBuffer so that we can tighten up the loose edges? -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

Jan. 14, 2003

Re: distcc and wine

by Paul Millar

I've just tried distcc and its wonderful! I haven't benchmarked it yet, but subjectively (from watching the nodes' load-avr) distcc seems to give *much* more even loading that just running OpenMOSIX. If anyone has more than one machine at their disposal, I'd strongly recommend investigating distcc. On Thu, 9 Jan 2003, Martin Pool wrote: > I haven't tried it myself but I would have expected the short, intense > jobs generated by compilation to be a problem [for OpenMOSIX] Yes, I agree. But, I think OM still has a role to play. Running OM underneath distcc should help improve the mean performance (in a heterogeneous cluster). Whenever a faster node is unloaded whilst a slower node is busy compiling (and this situation lasts for any length of time) OM should migrate that process to the faster node, speeding up compilation. That might occur just before linking, for example. I guess the improvement will depend strongly on the composition of the cluster and the code you're compiling. The improvement (from running OM) might be marginal in certain cases, but I don't think it would make things worse. Hmmm, time for some more experiments. ---- Paul Millar

Jan. 14, 2003

Re: problem building tests with msvc6

by Paul Millar

On Thu, 9 Jan 2003, Dan Kegel wrote: > Paul Millar wrote: > > [1] - http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php > > Wow. Does it really make sense to test against windows 2.0 > or 3.0 anymore? I recall Windows itself was pretty much a joke > and terribly unstable until windows 3.1... Probably not, but I thought: what the hell :^) > Are the WRT sources in CVS? Well, they're in _a_ cvs (here in Glasgow) but not _the_ winehq cvs. They're currently an embarrassing hackage of bash scripts with some customised code to do the bits sed/awk/... couldn't easily do. Oh, and some PHP to act as a front end. But, if anyone wants to have a look and/or help out, I'll try and figure out how to get the code out on the web, or something. ---- Paul Millar

Jan. 14, 2003

patch for "GetFileTitleW: illegal call to GetFileTitleA" 2ed

by liu spider

Thanks to Dmitry Timoshkov. This patch is the second edition, adopted his suggestions. ChangeLog: -dlls/commdlg/filetitle.c implemented GetFileTitleW GetFileTitleA now is a call to GetFileTitleW (The patch seems to be ignored without any comments. Could anyone give some clues on how to improve this patch? thanks.) liuspider __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Index: dlls/commdlg/filetitle.c =================================================================== RCS file: /home/wine/wine/dlls/commdlg/filetitle.c,v retrieving revision 1.12 diff -u -r1.12 filetitle.c --- dlls/commdlg/filetitle.c 31 May 2002 23:25:45 -0000 1.12 +++ dlls/commdlg/filetitle.c 12 Jan 2003 07:09:56 -0000 @@ -3,6 +3,7 @@ * * Copyright 1994 Martin Ayotte * Copyright 1996 Albrecht Kleine + * Copyright 2003 liuspider * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -24,10 +25,10 @@ #include "winbase.h" #include "winnls.h" #include "commdlg.h" +#include "wine/unicode.h" +#include "winternl.h" #include "wine/debug.h" -#include "heap.h" /* Has to go */ - WINE_DEFAULT_DEBUG_CHANNEL(commdlg); #include "cdlg.h" @@ -38,19 +39,39 @@ */ short WINAPI GetFileTitleA(LPCSTR lpFile, LPSTR lpTitle, UINT cbBuf) { - int i, len; + int ret; + UNICODE_STRING strWFile, strWTitle; + RtlCreateUnicodeStringFromAsciiz(&strWFile, lpFile); + RtlCreateUnicodeStringFromAsciiz(&strWTitle,lpTitle); + ret = GetFileTitleW(strWFile.Buffer, strWTitle.Buffer, cbBuf * sizeof(WCHAR)); + if (!ret){ + WideCharToMultiByte( CP_ACP, 0, strWTitle.Buffer, -1, lpTitle, cbBuf, NULL, NULL ); + } + RtlFreeUnicodeString( &strWFile ); + RtlFreeUnicodeString( &strWTitle ); + return ret; +} + +/*********************************************************************** + * GetFileTitleW (COMDLG32.@) + * + */ +short WINAPI GetFileTitleW(LPCWSTR lpFile, LPWSTR lpTitle, UINT cbBuf) +{ + int i, len; + WCHAR brkpoint[] = {'*','[',']'}; TRACE("(%p %p %d); \n", lpFile, lpTitle, cbBuf); if(lpFile == NULL || lpTitle == NULL) return -1; - len = strlen(lpFile); + len = strlenW(lpFile); if (len == 0) return -1; - if(strpbrk(lpFile, "*[]")) + if(strpbrkW(lpFile, brkpoint)) return -1; len--; @@ -70,34 +91,14 @@ if(i == -1) i++; - TRACE("---> '%s' \n", &lpFile[i]); + TRACE("---> '%s' \n", debugstr_w(&lpFile[i])); - len = strlen(lpFile+i)+1; + len = strlenW(lpFile+i)+1; if(cbBuf < len) return len; - strncpy(lpTitle, &lpFile[i], len); + strncpyW(lpTitle, &lpFile[i], len); return 0; -} - - -/*********************************************************************** - * GetFileTitleW (COMDLG32.@) - * - */ -short WINAPI GetFileTitleW(LPCWSTR lpFile, LPWSTR lpTitle, UINT cbBuf) -{ - LPSTR file = HEAP_strdupWtoA(GetProcessHeap(), 0, lpFile); /* Has to go */ - LPSTR title = HeapAlloc(GetProcessHeap(), 0, cbBuf); - short ret; - - ret = GetFileTitleA(file, title, cbBuf); - - if (cbBuf > 0 && !MultiByteToWideChar( CP_ACP, 0, title, -1, lpTitle, cbBuf )) - lpTitle[cbBuf-1] = 0; - HeapFree(GetProcessHeap(), 0, file); - HeapFree(GetProcessHeap(), 0, title); - return ret; }

Jan. 14, 2003

Re: patch for "GetFileTitleW: illegal call to GetFileTitleA" 2ed

by Dimitrie O. Paun

On January 13, 2003 09:02 pm, liu spider wrote: > (The patch seems to be ignored without any comments. > Could anyone give some clues on how to improve this > patch? thanks.) If no one complained, it's probably OK until Alexandre gets around to it. He can't reply in real time, wait for a few days. If you see commits going in (subscribe to, or check the mail archives for wine-cvs(a)winehq.org to monitor the checkins) and yours is not applied, email and ask him what's up. -- Dimi.

Jan. 14, 2003