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

Re: Develop .h for Wine by looking Microsoft Platform SDK

by Pau Garcia i Quiles

Quoting John Klehm <xixsimplicityxix(a)gmail.com>: > On 11/7/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >> Am Mittwoch, 7. November 2007 01:00:54 schrieb King InuYasha: >> > It is not legal at all. Using Microsoft Platform SDK header code is not >> > under the GNU General Public License version 2.0 or its listed compatible >> > licenses, so you have to do it manually WITHOUT looking at the PSDK. I >> > recommend removing the PSDK from your system as a way to remove >> temptation. >> Headers contain facts, and facts cannot be copyrighted. Also the sdk headers >> are the only source of information. Collecting them from the msdn is not >> going to work. >> >> The typing of the header itself is copyrighted though, so you must not >> copypaste from the MS Header. The wine header should be implemented as >> differently as possible, but still be 100% compatible. Especially watch out >> that the wine header includes the same files the other header does. > > Hrmm smells like another good FAQ item. =) Given that Wine is a client of the Software Freedom Law Center, wouldn't it be interesting to ask them for an opinion from an actual lawyer? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

Nov. 8, 2007

valgrind/urlmon & http/variable question

by Koshelev, Misha Vladislavo

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 --- diff --git a/dlls/urlmon/tests/protocol.c b/dlls/urlmon/tests/protocol.c index 00335b3..5b3579b 100644 --- a/dlls/urlmon/tests/protocol.c +++ b/dlls/urlmon/tests/protocol.c @@ -295,7 +295,9 @@ static HRESULT WINAPI ProtocolSink_Switch(IInternetProtocolSink *iface, PROTOCOL } SET_EXPECT(ReportData); + printf("!!! Continue %p -->\n", pProtocolData); hres = IInternetProtocol_Continue(http_protocol, pProtocolData); + printf("!!! Continue <--\n"); ok(hres == S_OK, "Continue failed: %08x\n", hres); CHECK_CALLED(ReportData); @@ -1255,6 +1257,7 @@ static void test_http_protocol_url(LPCWSTR url, BOOL is_first) hres = IClassFactory_CreateInstance(factory, NULL, &IID_IInternetProtocol, (void**)&http_protocol); ok(hres == S_OK, "Could not get IInternetProtocol: %08x\n", hres); + printf("!!! IInternetProtocol: %p %p\n", http_protocol, http_protocol+sizeof(IInternetProtocol)); if(SUCCEEDED(hres)) { BYTE buf[3600]; DWORD cb;

Nov. 8, 2007

Re: #winehq admin troubles

by Dan Kegel

On Nov 7, 2007 9:42 PM, Edward Savage <epssyis(a)gmail.com> wrote: > Furthermore, I'd like to add the comment that the majority of the time > Vitamin is perfectly calm and collected in his moderating, I'd like to > stress this. Though some times he acts far outside what is required > of him, no user in need should be banned, _ever_, and kicking should > be reserved for real pains. Patience is really what is needed here > and it is some thing Vitamin lacks at least some of the time. Well said. Maybe Vitaliy should simply walk away from the keyboard whenever he runs into a user who was too annoying. I once asked him to do something similar with Bugzilla replies, and it helped for a while. - Dan

Nov. 8, 2007

RE: d3dxof: return correct value for IDirectXFileDataImpl_GetType

by EA Durbin

It is still returning the wrong value, S_FALSE is not in the possible list of return values, and this causes wine to crash.> Date: Thu, 8 Nov 2007 12:40:19 +0100> From: thunderbird2k(a)gmx.net> Subject: Re: d3dxof: return correct value for IDirectXFileDataImpl_GetType> To: wine-devel(a)winehq.org> > > IDirectXFileDataImpl_GetType should return DXFILEERR_BADVALUE on failure,> > not S_FALSE> > > > This patch fixes bug 10355> > > > http://msdn2.microsoft.com/en-us/library/bb174490.aspx> > > > Sure this could fix that bug but it not a real fix. D3dxof.dll is mostly a stub and its real functionality (loading and parsing of .x files) is missing. This GetType function is also related to the parsing of the .x file. In short this file contains data and some 'templates' for describing the data. This function returns the guid of that template.> > Returning a failure is not really an option in my opion as it won't get the app working. For the time being you should a native d3dxof.dll should be used or the rest of the .x file parsing should be added.> > Roderick > > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört?> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger> > _________________________________________________________________ Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct

Nov. 8, 2007

Re: Bugs in dlls/wsock32/socket.c

by Gerald Pfeifer

On Sun, 4 Nov 2007, Juan Lang wrote: > Heh - no, that's not the intended purpose ;) I'll send a patch. Cool, thanks a bunch! :-) Gerald

Nov. 8, 2007

Re: #winehq admin troubles

by feba thatl

Tom, you can try to guilt me, but I don't care. There are two sides to this. Either you think that #winehq is a support channel for end users, and should if not cater to them, at least treat them with some respect until they've proved that they deserve none, or you think that #winehq is a channel where people can go for help if some one with an @ isn't in a mood to ban them. If you can honestly say that you fully agree with the latter, and would have no problem getting banned from a random channel when you were seeking help, I don't know what to tell you. If, however, you think the first thing, we're on the same side. I don't think anyone here doesn't want to see #winehq, and the entire project really, become a better place. There might be one or two people exploiting this for personal reasons, but I cannot control that. I posted this in the hopes that #winehq would be made a better place, not for me, but for everyone. Including vitamin and the rest of the ops. I have a question for you, what offends you so much about my comments that you are not only refusing to help me, but also trying to pin me with the blame for your refusal to help others? Is it because you feel that your experience with wine gives you to the right to mistreat users, or because you are offended by what a few other people said in a thread that I started? Do you not want #winehq to be a better place? Or do you not realize the actual point of what I'm saying?

Nov. 8, 2007

Re: svchost: Implementation of svchost

by Robert Shearman

Roy Shea wrote: > Changelog: > * Implementation of svchost > You've got a lot of global functions in this patch that should be static. -- Rob Shearman

Nov. 8, 2007

Re: Problem with client manually starting services

by Robert Shearman

Roy Shea wrote: > Howdy All, > > I'm developing missing services in Wine and am running into problems > with how Wine starts services. In Windows a service can be started > using "net start <service name>", assuming that the service is > properly added to the registry. In Wine it appears that the user must > manually start the service before calling "net start <service name>", > or the service fails to start. What makes you think that? There are quite a few programs, including InstallShield, that start their own services without the process being started beforehand. You could start with pulling +advapi,+relay log of "net start" executing to try to figure out what is going wrong. My guess would be that either svchost or the DLL isn't notifying the SCM of its started status. -- Rob Shearman

Nov. 8, 2007

Re: d3dxof: return correct value for IDirectXFileDataImpl_GetType

by Roderick Colenbrander

> IDirectXFileDataImpl_GetType should return DXFILEERR_BADVALUE on failure, > not S_FALSE > > This patch fixes bug 10355 > > http://msdn2.microsoft.com/en-us/library/bb174490.aspx > Sure this could fix that bug but it not a real fix. D3dxof.dll is mostly a stub and its real functionality (loading and parsing of .x files) is missing. This GetType function is also related to the parsing of the .x file. In short this file contains data and some 'templates' for describing the data. This function returns the guid of that template. Returning a failure is not really an option in my opion as it won't get the app working. For the time being you should a native d3dxof.dll should be used or the rest of the .x file parsing should be added. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

Nov. 8, 2007

Re: wininet: Fully initialize a variable

by Alexandre Julliard

"Juan Lang" <juan.lang(a)gmail.com> writes: > static void COOKIE_crackUrlSimple(LPCWSTR lpszUrl, LPWSTR hostName, int hostNameLen, LPWSTR path, int pathLen) > { > - URL_COMPONENTSW UrlComponents; > + URL_COMPONENTSW UrlComponents = { 0 }; > > - UrlComponents.lpszExtraInfo = NULL; > - UrlComponents.lpszPassword = NULL; > - UrlComponents.lpszScheme = NULL; > UrlComponents.lpszUrlPath = path; > - UrlComponents.lpszUserName = NULL; > UrlComponents.lpszHostName = hostName; > UrlComponents.dwHostNameLength = hostNameLen; > UrlComponents.dwUrlPathLength = pathLen; Please avoid that unportable array initialization syntax, and since the code is already explicitly setting the fields you should simply add the ones that are needed and missing. -- Alexandre Julliard julliard(a)winehq.org

Nov. 8, 2007