wine-devel November 2007

wine-devel@winehq.org

117 participants
275 discussions

Successful Virtualization startup looking for engineers with system level Windows and Linux experience
by Richard Offer 09 Nov '07

09 Nov '07

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

1 0

Re: wininet: skip strcmp() in a test if the returned len is wrong
by Dmitry Timoshkov 09 Nov '07

09 Nov '07

"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.

1 0

valgrind/urlmon & http/variable question
by Misha Koshelev 09 Nov '07

09 Nov '07

> 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

1 0

Problem with client manually starting services
by Roy Shea 08 Nov '07

08 Nov '07

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. This is blocking me from developing an svchost wrapped DLL. I guess its not surprising that the work around of first manually starting a service fails for a DLL with no main function :-) Dan Kegel mentioned a recollection of a known bug in Wine along these lines where, as a work around, clients are manually starting servers. Anyone know more details on this problem? Any pointers to old emails or knowledge of this problem would be a big help I start digging through WINEDEBUG logs. Thanks! -Roy

2 4

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes
by Mirek Slugeň 08 Nov '07

08 Nov '07

2 6

Re: WineD3D: flush gl buffers are blt to drawable [attempt2]
by Stefan Dösinger 08 Nov '07

08 Nov '07

Am Donnerstag, 8. November 2007 23:40:18 schrieb Roderick Colenbrander: > Hi, > > This patch makes sure the gl buffer is flushed after blitting to the > screen. This fixes bug 9826 where traces of old frames appeared due to > this. You really shouldn't do this unconditionally, it is only needed if two contexts are drawing to the same drawable. A suggestion would be to mark the first use of a 2nd thread in a device in FindContext, and call the glFlush only if happened. The same glFlush is needed in all other places that draw something to the drawable: drawprim, clear and BltOverride come to my mind.

1 0

Typing Chinese Online On FireFox
by Jiang,Yi 08 Nov '07

08 Nov '07

I developped a site for Typing Chinese Online: http://www.typingChinese.com. It works on FireFox, IE, Mac. On test, I found FireFox is the fastest and used much less memory! Regards to all, Jiang,Yi

1 0

Develop .h for Wine by looking Microsoft Platform SDK
by Pau Garcia i Quiles 08 Nov '07

08 Nov '07

Hello, How legal (if at all) would be to develop a header file by looking reading the corresponding header file from the Microsoft Platform SDK and adapting it to gcc (removing MSVC stuff, etc)? I'm interested in supporting annotations[*] and before I start deducting everything from MSDN documentation, I'd like to know if there is a fast track. [*] More information: http://msdn2.microsoft.com/en-us/library/aa383701.aspx http://msdn2.microsoft.com/en-us/library/ms235402(VS.80).aspx Thank you. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

4 4

valgrind/urlmon & http/variable question
by Koshelev, Misha Vladislavo 08 Nov '07

08 Nov '07

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;

1 0

Re: d3dxof: return correct value for IDirectXFileDataImpl_GetType
by Roderick Colenbrander 08 Nov '07

08 Nov '07

> 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

2 1

← Newer
1
...
19
20
21
22
23
24
25
...
28
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2007