Re: iphlpapi: _res is per-thread in glibc with pthreads
On Mon, Feb 8, 2010 at 12:01 AM, Dan Kegel wrote: > With test. Without the fix, the test case crashes on my machine. > Fixes crash in bug http://bugs.winehq.org/show_bug.cgi?id=21624 > > Same fix probably needed in dnsapi, or maybe iphlpapi should > use dnsapi rather than unix dns api. > > Thanks to AF for the analysis. > testWin98OnlyFunctions(); testWinNT4Functions(); -testWin98Functions(); +thread = CreateThread(NULL, 0, testWin98Functions, NULL, 0, &threadId); +testWin98Functions(NULL); +WaitForSingleObject( thread, INFINITE ); Is that extra non threaded testWin98Functions(NULL) supposed to be in there? Regards, --John Klehm
Re: idea: display drivers
On Sun, Feb 7, 2010 at 22:47, David Gerard wrote: > No idea, sorry. Xsun is on extended (life-)support with Sun moving to > Xorg (and Alan Coopersmith from Sun being one of the main Xorg > developers). Xming is Xorg compiled for mingw Xming: An ancient version of Xorg (at least for the free version) (6.9) I have seen Solaris 10 default to Xsun in some cases... (Although Xorg is available...) What I meant is that requiring OpenGL might lose some portability... (Needing an X server for console apps is irritation, but solvable using something like Xvnc. This becomes a lot harder to solve if you need an X server with OpenGL) Gert
Re: Getting start with IXMLHTTPRequest
On 2/8/10 3:36 AM, Nikolay Sivov wrote: Even if that's true, it's not a reason to choose wrong architecture. Let's say we have a WinHttpRequest object that works, it provides similar interface as IXMLHTTP. Why should I use urlmon for that? WinHttpRequest should stay in winhttp, and won't use urlmon. We don't have, it's impossible. Pluggable protocol is one of the reasons and you can't handle them unless you use urlmon. Btw, what was a reason for using it? Everything IE-related should use it for binding. It's because of plugable protocols, shared wininet session and more. urlmon is not just a wrapper around wininet. Why IXMLHTTPRequest is IE related? Or you mean that anything that uses internet should go through urlmon? It is designed to be used by JScript scripts on web pages (although it's not the only use of it). Jacek
Re: Getting start with IXMLHTTPRequest
On 2/8/2010 05:24, Jacek Caban wrote:
On 2/7/10 3:08 PM, Nikolay Sivov wrote:
On 2/7/2010 16:45, Hans Leidekker wrote:
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough
but since it's first time i'm using winhttp,
there could be some problems, especially cause IXMLHTTPRequest
supports
asynchronous requests.
Could someone with winhttp knowledge review this patch before it
goes to
far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of
winhttp,
which may already handle asynchronous requests.
-Hans
Such things:
---
static HRESULT WINAPI HttpInfo_QueryInfo(IWinInetHttpInfo *iface,
DWORD dwOption,
void *pBuffer, DWORD *pcbBuffer, DWORD *pdwFlags, DWORD
*pdwReserved)
{
HttpProtocol *This = INETINFO_THIS(iface);
FIXME("(%p)->(%x %p %p %p %p)\n", This, dwOption, pBuffer,
pcbBuffer, pdwFlags, pdwReserved);
return E_NOTIMPL;
}
---
static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface,
HRESULT hrReason,
DWORD dwOptions)
{
HttpProtocol *This = PROTOCOL_THIS(iface);
FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions);
return E_NOTIMPL;
}
---
make me think it's not ready.
Even if that's true, it's not a reason to choose wrong architecture.
Let's say we have a WinHttpRequest object that works, it provides
similar interface as IXMLHTTP.
Why should I use urlmon for that? WinHttpRequest should stay in winhttp,
and won't use urlmon.
Also IXMLHTTPRequest methods look to directly map tp Winhttp calls.
For example how can I implement IXMLHTTPRequest::setRequestHeader()
with urlmon?
By implementing IHttpNegotiate on bind status callback.
Thanks, will take a look.
Btw, what was a reason for using it?
Everything IE-related should use it for binding. It's because of
plugable protocols, shared wininet session and more. urlmon is not
just a wrapper around wininet.
Why IXMLHTTPRequest is IE related? Or you mean that anything that uses
internet should go through urlmon?
Jacek
Re: Getting start with IXMLHTTPRequest
On 2/7/10 3:08 PM, Nikolay Sivov wrote:
On 2/7/2010 16:45, Hans Leidekker wrote:
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough
but since it's first time i'm using winhttp,
there could be some problems, especially cause IXMLHTTPRequest supports
asynchronous requests.
Could someone with winhttp knowledge review this patch before it
goes to
far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of winhttp,
which may already handle asynchronous requests.
-Hans
Such things:
---
static HRESULT WINAPI HttpInfo_QueryInfo(IWinInetHttpInfo *iface,
DWORD dwOption,
void *pBuffer, DWORD *pcbBuffer, DWORD *pdwFlags, DWORD
*pdwReserved)
{
HttpProtocol *This = INETINFO_THIS(iface);
FIXME("(%p)->(%x %p %p %p %p)\n", This, dwOption, pBuffer,
pcbBuffer, pdwFlags, pdwReserved);
return E_NOTIMPL;
}
---
static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface,
HRESULT hrReason,
DWORD dwOptions)
{
HttpProtocol *This = PROTOCOL_THIS(iface);
FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions);
return E_NOTIMPL;
}
---
make me think it's not ready.
Even if that's true, it's not a reason to choose wrong architecture.
Also IXMLHTTPRequest methods look to directly map tp Winhttp calls.
For example how can I implement IXMLHTTPRequest::setRequestHeader()
with urlmon?
By implementing IHttpNegotiate on bind status callback.
Btw, what was a reason for using it?
Everything IE-related should use it for binding. It's because of
plugable protocols, shared wininet session and more. urlmon is not just
a wrapper around wininet.
Jacek
Re: grrrrr
Dan Kegel wrote: > http://www.pro-linux.de/NB3/news/1/15259/starmoney-stellt-linux-variante-ein.html > Looks like Star Money is blaming Wine for its troubles... > IIRC, they switched to .net or something without asking whether it > would work on Wine. > .NET the evil geniuses in Redmond strike again. Maybe it will work with Mono James McKenzie
grrrrr
http://www.pro-linux.de/NB3/news/1/15259/starmoney-stellt-linux-variante-ein.html Looks like Star Money is blaming Wine for its troubles... IIRC, they switched to .net or something without asking whether it would work on Wine. Grr.
Wine FIXME Report January 2010
Wine FIXME Report January 2010
==
The data for this report comprise the emails from January 2010 archives
of the mailing lists wine-{bugs,devel,users} as well as the bugzilla
attachments referenced by the wine-bugs emails. Although WARN messages
were collected too they aren't handled in this report.
File parsed: 6364 (emails: 5850, bugzilla attachments: 514)
Files with FIXME/ERR/WARN: 436
Type | Total | Unique
--+-+---
fixme | 1354429 | 8122
err | 24115 | 993
warn |3491 | 404
The Most Popular Messages
-
This are the most prevalent ERR and FIXME messages aka the number of
files where they show up.
FIXME:
Files | Lines | Channel:Function Text
--+---+--
59 | 119 | d3d:WineD3D_ChoosePixelFormat Add OpenGL context
recreation support to SetDepthStencilSurface
42 |45 | system:SetProcessDPIAware stub!
36 |46 | iphlpapi:GetAdaptersAddresses no support for IPv6
addresses
33 |61 | mixer:ALSA_MixerInit No master control found on HDA
ATI HDMI, disabling mixer
29 |57 | urlmon:URLMoniker_BindToObject use running object table
22 |41 | shdocvw:BindStatusCallback_OnProgress status code 11
19 |21 | system:SystemParametersInfoW Unimplemented action: 59
(SPI_SETSTICKYKEYS)
18 |21 | resource:GetGuiResources (0x,0): stub
18 |37 | shdocvw:PropertyNotifySink_OnChanged unimplemented
dispid 1005
17 |71 | storage:StgCreateDocfile Storage share mode not
implemented.
ERR:
Files | Lines | Channel:Function Text
--+---+--
22 |41 | alsa:ALSA_CheckSetVolume Could not find 'PCM Playback
Volume' element
18 |25 | ole:CoGetClassObject class
{9a5ea990-3034-4d6f-9128-01f3c61022bc} not registered
18 |26 | ole:CoGetClassObject no class object
{9a5ea990-3034-4d6f-9128-01f3c61022bc} could be created for context 0x1
15 | 1646 | ddraw:PixelFormat_WineD3DtoDD Can't translate this
Pixelformat 58
14 | 1645 | ddraw:PixelFormat_WineD3DtoDD Can't translate this
Pixelformat 64
12 |44 | ole:CoGetClassObject class
{6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered
12 |44 | ole:CoGetClassObject no class object
{6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1
12 | 114 | ole:apartment_getclassobject DllGetClassObject
returned error 0x80040111
10 |18 | rpc:I_RpcGetBuffer no binding
9 |12 | ole:CoGetClassObject class
{77f10cf0-3db5-4966-b520-b7c54fd35ed6} not registered
Noisy Popular Messages
--
The noisiest messages that show up at least in 1% of the collected reports.
FIXME:
Lines | Files | Channel:Function Text
--+---+--
223 | 7 | mshtml:nsChannel_GetSecurityInfo default action not
implemented
155 |11 | ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported
144 |12 | wininet:InternetLockRequestFile STUB
119 |59 | d3d:WineD3D_ChoosePixelFormat Add OpenGL context
recreation support to SetDepthStencilSurface
110 | 9 | advapi:LsaClose (0xcafe) stub
99 | 8 | font:WineEngAddFontResourceEx Ignoring flags 10
92 | 5 | wininet:GetUrlCacheEntryInfoExW Undocumented flag(s): 100
75 | 7 | file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH
unimplemented
71 |17 | storage:StgCreateDocfile Storage share mode not
implemented.
61 |33 | mixer:ALSA_MixerInit No master control found on HDA
ATI HDMI, disabling mixer
ERR:
Lines | Files | Channel:Function Text
--+---+--
1646 |15 | ddraw:PixelFormat_WineD3DtoDD Can't translate this
Pixelformat 58
1645 |14 | ddraw:PixelFormat_WineD3DtoDD Can't translate this
Pixelformat 64
114 |12 | ole:apartment_getclassobject DllGetClassObject
returned error 0x80040111
113 | 6 | ole:ClientIdentity_QueryMultipleInterfaces
IRemUnknown_RemQueryInterface failed with error 0x80004002
66 | 7 | ole:ITypeInfo_fnInvoke did not find member id -504,
flags 0x2!
66 | 7 | ole:ITypeInfo_fnInvoke did not find member id -514,
flags 0x2!
62 | 6 | shell:SHGetFileInfoW pidl is null!
44 |12 | ole:CoGetClassObject class
{6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered
44 |12 | ole:CoGetClassObject no class object
{6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1
41 |22 | alsa:ALSA_CheckSetVolume Could not find 'PCM Playback
Volume' element
Noisy Popular Functions
---
The noisiest functions that show up at least in 1% of the collected reports.
FIXME:
Lines | Files | Channel:Function
--+---+-
434041 | 716 | ole:NdrCorrelationInitialize
434009 | 716 | ole:NdrCorrelationFree
7620 | 6 | d3d:context_check_fbo_status
2716 | 100 | d3d_
Re: idea: display drivers
On 7 February 2010 20:23, Gert van den Berg wrote: > On Sun, Feb 7, 2010 at 21:40, David Gerard wrote: >> As I understand it, current Xorg does OpenGL in software on any video >> chipset it supports ... eeerrryyy ssslllooowwwlllyyy, but it does >> it. > But what about other X servers, such as Xsun, Xvnc, remote Xming sessions, > etc? No idea, sorry. Xsun is on extended (life-)support with Sun moving to Xorg (and Alan Coopersmith from Sun being one of the main Xorg developers). Xming is Xorg compiled for mingw. Xvnc, no idea. - d.
Re: idea: display drivers
On Sun, Feb 7, 2010 at 21:40, David Gerard wrote: > On 7 February 2010 15:40, Reece Dunn wrote: > >> 1/ Does this mean that OpenGL is required for all GDI calls, not >> just D3D? If so, it will exclude people who don't have OpenGL support >> (e.g. are using the vesa, nv, or nouveau drivers). > > > As I understand it, current Xorg does OpenGL in software on any video > chipset it supports ... eeerrryyy ssslllooowwwlllyyy, but it does > it. > But what about other X servers, such as Xsun, Xvnc, remote Xming sessions, etc?
Re: idea: display drivers
On 7 February 2010 15:40, Reece Dunn wrote: > 1/ Does this mean that OpenGL is required for all GDI calls, not > just D3D? If so, it will exclude people who don't have OpenGL support > (e.g. are using the vesa, nv, or nouveau drivers). As I understand it, current Xorg does OpenGL in software on any video chipset it supports ... eeerrryyy ssslllooowwwlllyyy, but it does it. - d.
Re: idea: display drivers
Roderick Colenbrander wrote: > On Sun, Feb 7, 2010 at 6:41 PM, James McKenzie > wrote: > >> Correct. But why keep the old stuff around? It might be confusing to >> the Wine beginner. >> >> > > The new style driver would only work on modern hardware like windows7 does. > > That makes sense. However, how long are we going to support 'older' hardware? Most manufacturers give up after two years. James McKenzie
Re: idea: display drivers
Roderick Colenbrander wrote: >> Emmanuel's code is available from Sourceforge. It is a good starting >> point for this. If you want, send me what you have so far for testing >> purposes. It would be great to have a native MacOSX windowing system. >> >> James McKenzie >> >> > > The design of the old quartz driver is not correct. I remember that > Alexandre commented that a lot of code which was in it doesn't make > sense for a quartz driver but only for X11. Before a quartz driver can > be written we really need a dib engine. It will make writing another > driver much easier and much more code would be shared. > I agree with the fact that the quartz.dll is not functionally accurate. However, the conversation started (I think) on building a native driver for MacOSX, which should not use an X11 code. This is why I pointed out the fact that it took YEARS (and I really mean this 2003-2009) to get a native version of OpenOffice.org to function properly. Your assessment may be proper in that the X11 version of quartz.dll may need to be completely redone to make this easier and to facilitate movement to other windowing systems. > Thinking a few steps further I also think that at some point the > current X11 driver needs to be redesigned for modern windows version > (we would get a classic winex11 and a modern one). The modern one > would in my opinion only be responsible for creating windows, font > rendering but the rest would all be done using OpenGL. This way the > rendering code could also work on OSX and only window management stuff > would be needed. > Correct. But why keep the old stuff around? It might be confusing to the Wine beginner. James McKenzie
Re: idea: display drivers
On Sun, Feb 7, 2010 at 4:40 PM, Reece Dunn wrote:
> On 7 February 2010 15:02, Roderick Colenbrander
> wrote:
>>> Emmanuel's code is available from Sourceforge. It is a good starting
>>> point for this. If you want, send me what you have so far for testing
>>> purposes. It would be great to have a native MacOSX windowing system.
>>>
>>> James McKenzie
>>>
>>
>> The design of the old quartz driver is not correct. I remember that
>> Alexandre commented that a lot of code which was in it doesn't make
>> sense for a quartz driver but only for X11. Before a quartz driver can
>> be written we really need a dib engine. It will make writing another
>> driver much easier and much more code would be shared.
>>
>> Thinking a few steps further I also think that at some point the
>> current X11 driver needs to be redesigned for modern windows version
>> (we would get a classic winex11 and a modern one). The modern one
>> would in my opinion only be responsible for creating windows, font
>> rendering but the rest would all be done using OpenGL. This way the
>> rendering code could also work on OSX and only window management stuff
>> would be needed.
>
> In general, this seems to be the best approach. I do have a few
> questions, though:
>
> 1/ Does this mean that OpenGL is required for all GDI calls, not
> just D3D? If so, it will exclude people who don't have OpenGL support
> (e.g. are using the vesa, nv, or nouveau drivers).
I think that in the end we would need 2 drivers. One classic x11 in
the current design (adjusted a bit were possible) and one which
follows the Win7-design using OpenGL. The idea would be to let Wine
perform the majority of GDI calls in software (both the DIB stuff and
a big part of the DDB calls). Like Win7 we would accelerate common GDI
functions like AlphaBlend, BitBlt/StretchBlt (only the common ROPs
like SRCBLT and a few others) and ColorFill on the gpu using opengl.
See http://msdn.microsoft.com/en-us/library/dd434692.aspx for what
Win7 accelerates.
When using OpenGL we would emulate DIBSections using PBOs and perhaps
GLX_texture_from_bitmap is of any use as well in case of X11.
> 2/ What will the performance of GDI32 calls be like? There are
> various comments that the Vista architecture does not optimise GDI32
> calls, so applications that use these are slower.
>
Vista performed all of GDI in software but Win7 accelerates a couple
of common calls which I mentioned above using the GPU. Performance
could be quite good.
So to summarize a win7-style wine rendering architecture would perform
all DIB rendering in software ('the dib engine') and also the
non-common DDB calls. Other calls are accelerated using OpenGL. A
x11/quartz/some_other_os driver would be used for window creation,
window management, input and likely font rendering.
Roderick
Re: [4/6] wininet: Clean up locks after closing libssl and libcrypto.
On 02/07/2010 04:56 PM, Paul Vriens wrote:
On 02/07/2010 04:46 PM, Hans Leidekker wrote:
On Sunday 07 February 2010 16:24:11 Paul Vriens wrote:
if (OpenSSL_ssl_handle)
@@ -305,6 +297,12 @@ void NETCON_unload(void)
pSSL_CTX_free(ctx);
wine_dlclose(OpenSSL_ssl_handle, NULL, 0);
}
+ if (ssl_locks)
+ {
+ int i;
+ for (i = 0; i< pCRYPTO_num_locks(); i++)
DeleteCriticalSection(&ssl_locks[i]);
+ HeapFree(GetProcessHeap(), 0, ssl_locks);
+ }
#endif
}
Hi Hans,
I was checking a crash in an installer (the AkamaiDownloadManager to
download CS4 for example) and it looks like we are accessing a ssl
function CRYPTO_num_locks() after we've closed the library?
Can you confirm this?
Yes, looks like I fixed this in winhttp but forgot to send the same
patch for
wininet. Try this patch.
-Hans
Yup, crash is gone, thanks.
Forgot to include wine-devel.
--
Cheers,
Paul.
Re: [4/6] wininet: Clean up locks after closing libssl and libcrypto.
On Sunday 07 February 2010 16:24:11 Paul Vriens wrote:
> > if (OpenSSL_ssl_handle)
> > @@ -305,6 +297,12 @@ void NETCON_unload(void)
> > pSSL_CTX_free(ctx);
> > wine_dlclose(OpenSSL_ssl_handle, NULL, 0);
> > }
> > +if (ssl_locks)
> > +{
> > +int i;
> > +for (i = 0; i< pCRYPTO_num_locks(); i++)
> > DeleteCriticalSection(&ssl_locks[i]);
> > +HeapFree(GetProcessHeap(), 0, ssl_locks);
> > +}
> > #endif
> > }
> >
> Hi Hans,
>
> I was checking a crash in an installer (the AkamaiDownloadManager to
> download CS4 for example) and it looks like we are accessing a ssl
> function CRYPTO_num_locks() after we've closed the library?
>
> Can you confirm this?
Yes, looks like I fixed this in winhttp but forgot to send the same patch for
wininet. Try this patch.
-Hans
diff --git a/dlls/wininet/netconnection.c b/dlls/wininet/netconnection.c
index 0e7b62a..c2560b5 100644
--- a/dlls/wininet/netconnection.c
+++ b/dlls/wininet/netconnection.c
@@ -160,6 +160,7 @@ MAKE_FUNCPTR(sk_value);
#undef MAKE_FUNCPTR
static CRITICAL_SECTION *ssl_locks;
+static unsigned int num_ssl_locks;
static unsigned long ssl_thread_id(void)
{
@@ -458,14 +459,14 @@ DWORD NETCON_init(WININET_NETCONNECTION *connection, BOOL useSSL)
pSSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, netconn_secure_verify);
pCRYPTO_set_id_callback(ssl_thread_id);
-ssl_locks = HeapAlloc(GetProcessHeap(), 0,
-pCRYPTO_num_locks() * sizeof(CRITICAL_SECTION));
+num_ssl_locks = pCRYPTO_num_locks();
+ssl_locks = HeapAlloc(GetProcessHeap(), 0, num_ssl_locks * sizeof(CRITICAL_SECTION));
if (!ssl_locks)
{
LeaveCriticalSection(&init_ssl_cs);
return ERROR_OUTOFMEMORY;
}
-for (i = 0; i < pCRYPTO_num_locks(); i++)
+for (i = 0; i < num_ssl_locks; i++)
InitializeCriticalSection(&ssl_locks[i]);
pCRYPTO_set_locking_callback(ssl_lock_callback);
LeaveCriticalSection(&init_ssl_cs);
@@ -494,7 +495,7 @@ void NETCON_unload(void)
if (ssl_locks)
{
int i;
-for (i = 0; i < pCRYPTO_num_locks(); i++) DeleteCriticalSection(&ssl_locks[i]);
+for (i = 0; i < num_ssl_locks; i++) DeleteCriticalSection(&ssl_locks[i]);
HeapFree(GetProcessHeap(), 0, ssl_locks);
}
#endif
Re: idea: display drivers
On 7 February 2010 15:02, Roderick Colenbrander wrote: >> Emmanuel's code is available from Sourceforge. It is a good starting >> point for this. If you want, send me what you have so far for testing >> purposes. It would be great to have a native MacOSX windowing system. >> >> James McKenzie >> > > The design of the old quartz driver is not correct. I remember that > Alexandre commented that a lot of code which was in it doesn't make > sense for a quartz driver but only for X11. Before a quartz driver can > be written we really need a dib engine. It will make writing another > driver much easier and much more code would be shared. > > Thinking a few steps further I also think that at some point the > current X11 driver needs to be redesigned for modern windows version > (we would get a classic winex11 and a modern one). The modern one > would in my opinion only be responsible for creating windows, font > rendering but the rest would all be done using OpenGL. This way the > rendering code could also work on OSX and only window management stuff > would be needed. In general, this seems to be the best approach. I do have a few questions, though: 1/ Does this mean that OpenGL is required for all GDI calls, not just D3D? If so, it will exclude people who don't have OpenGL support (e.g. are using the vesa, nv, or nouveau drivers). 2/ What will the performance of GDI32 calls be like? There are various comments that the Vista architecture does not optimise GDI32 calls, so applications that use these are slower. References: * http://www.theregister.co.uk/2007/12/04/vista_vs_xp_tests/ * http://blogs.msdn.com/nickkramer/archive/2006/04/07/571162.aspx (primitives now rendered in software) * http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx NOTE: Windows 7 appears to have reversed part of the Vista trend by hardware accelerating as many of the GDI calls as they could References: * http://blogs.msdn.com/e7/archive/2009/04/25/engineering-windows-7-for-graphics-performance.aspx * http://www.pcpro.co.uk/blogs/2009/05/07/windows-7-gdi-performance-the-big-trade-off/ - Reece
Re: [4/6] wininet: Clean up locks after closing libssl and libcrypto.
On 10/27/2009 10:04 AM, Hans Leidekker wrote:
Found by valgrind.
---
dlls/wininet/netconnection.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/dlls/wininet/netconnection.c b/dlls/wininet/netconnection.c
index 97c764f..16cce40 100644
--- a/dlls/wininet/netconnection.c
+++ b/dlls/wininet/netconnection.c
@@ -289,14 +289,6 @@ void NETCON_unload(void)
#if defined(SONAME_LIBSSL)&& defined(SONAME_LIBCRYPTO)
if (OpenSSL_crypto_handle)
{
-if (ssl_locks)
-{
-int i;
-
-for (i = 0; i< pCRYPTO_num_locks(); i++)
-DeleteCriticalSection(&ssl_locks[i]);
-HeapFree(GetProcessHeap(), 0, ssl_locks);
-}
wine_dlclose(OpenSSL_crypto_handle, NULL, 0);
}
if (OpenSSL_ssl_handle)
@@ -305,6 +297,12 @@ void NETCON_unload(void)
pSSL_CTX_free(ctx);
wine_dlclose(OpenSSL_ssl_handle, NULL, 0);
}
+if (ssl_locks)
+{
+int i;
+for (i = 0; i< pCRYPTO_num_locks(); i++)
DeleteCriticalSection(&ssl_locks[i]);
+HeapFree(GetProcessHeap(), 0, ssl_locks);
+}
#endif
}
Hi Hans,
I was checking a crash in an installer (the AkamaiDownloadManager to
download CS4 for example) and it looks like we are accessing a ssl
function CRYPTO_num_locks() after we've closed the library?
Can you confirm this?
--
Cheers,
Paul.
Re: idea: display drivers
> Emmanuel's code is available from Sourceforge. It is a good starting > point for this. If you want, send me what you have so far for testing > purposes. It would be great to have a native MacOSX windowing system. > > James McKenzie > The design of the old quartz driver is not correct. I remember that Alexandre commented that a lot of code which was in it doesn't make sense for a quartz driver but only for X11. Before a quartz driver can be written we really need a dib engine. It will make writing another driver much easier and much more code would be shared. Thinking a few steps further I also think that at some point the current X11 driver needs to be redesigned for modern windows version (we would get a classic winex11 and a modern one). The modern one would in my opinion only be responsible for creating windows, font rendering but the rest would all be done using OpenGL. This way the rendering code could also work on OSX and only window management stuff would be needed. Roderick
Re: Getting start with IXMLHTTPRequest
On Sunday 07 February 2010 15:08:33 Nikolay Sivov wrote:
> Such things:
> ---
> static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface,
> HRESULT hrReason,
> DWORD dwOptions)
> {
> HttpProtocol *This = PROTOCOL_THIS(iface);
> FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions);
> return E_NOTIMPL;
> }
> ---
> make me think it's not ready. Also IXMLHTTPRequest methods look to
> directly map tp Winhttp calls.
Sure there are stubs, but implementing those should not be much different
from what you've written now. The question is, does urlmon map better to
IXMLHTTPRequest than winhttp?
> For example how can I implement IXMLHTTPRequest::setRequestHeader() with
> urlmon?
Now this might be a good reason to go with winhttp instead of urlmon.
In that case the (unimplemented) WinHttpRequest object is probably a
better fit than the C interface.
> Btw, what was a reason for using it?
I think it's just a matter of trying to avoid code duplication.
-Hans
Re: idea: display drivers
Stefan Dösinger wrote: >> The problem is that there can't be any Objective-C code in Wine. At all. >> Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any >> language other than pure, procedural C. >> > Alexandre has said that you can put objective C code into wine, but only if > this code is properly abstracted from the other parts of the quartz driver. > E.g. by a simple binding wrapper that does nothing but wrap Objective C to C > bindings. The requirement is that somebody can read and understand the Quartz > driver without knowing Objective C. > > The biggest obstacle to merging a Quartz driver is cleaning up the user32 > driver interface. Objective C is a minor issue with a pretty straightforward > solution. Currently nobody knows what a proper user32 driver interface would > look like. > It might be a good idea to look at the code used in other projects to get a good starting point. OpenOffice.org did an implementation of an Aqua driver based from X11 code. Took SEVERAL years to do. James McKenzie
Re: idea: display drivers
Charles Davis wrote:
> C.W. Betts wrote:
>
>> Is is just because of the Objective-C code? Would it be safe to make C
>> functions that would call Objective-C? Such as:
>> cheader.h:
>> typedef struct struct1 struct1;
>> cfuncCreate(struct1 *s);
>> cfunc1();
>> cfunc2();
>> cfuncDestroy (struct1 *s);
>>
>> cfile.m:
>> @interface WHQFunc
>> {
>>
>> }
>> -(id)init;
>> -(void)dealloc;
>> @end
>> struct
>> {
>> WHQFunc *ObjC;
>> int ids;
>> }struct1;
>> @implementation WHQFunc
>>
>> -(id)init
>> {
>> return [super init];
>> }
>> -(void)dealloc
>> {
>> [super dealloc];
>> }
>> @end
>>
>> cfunc1()
>> {
>>
>> }
>> cfunc2()
>> {
>>
>> }
>> cfuncCreate(struct1 *s)
>> {
>> s = malloc(sizeof(struct1));
>> [[s->ObjC alloc] init];
>> }
>> cfuncDestroy (struct1 *s)
>> {
>> [s->ObjC release];
>> free(s);
>> }
>>
>>
> Working on it.
>
> The problem is that there can't be any Objective-C code in Wine. At all.
> Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any
> language other than pure, procedural C.
>
> I wanted to wait until it was finished, but I may as well announce it
> now. I'm working on a new tool to create pure C bindings to Objective-C
> frameworks. That way, you can use an Objective-C framework (like the
> Cocoa Foundation and AppKit frameworks) from C. There is a even a
> companion framework that lets you define your own classes and create
> instances of them--without writing a single line of Objective-C.
>
> If you'll be patient, I'll be finishing it soon, and I'll post the
> source and binaries somewhere so you can use it. My intent is precisely,
> among other things, to use this to create a Quartz driver that will work
> in 64-bit (because the Carbon UI stuff doesn't work in 64-bit).
>
>
Chip:
Emmanuel's code is available from Sourceforge. It is a good starting
point for this. If you want, send me what you have so far for testing
purposes. It would be great to have a native MacOSX windowing system.
James McKenzie
Re: idea: display drivers
C.W. Betts wrote:
> Is is just because of the Objective-C code? Would it be safe to make C
> functions that would call Objective-C? Such as:
> cheader.h:
> typedef struct struct1 struct1;
> cfuncCreate(struct1 *s);
> cfunc1();
> cfunc2();
> cfuncDestroy (struct1 *s);
>
> cfile.m:
> @interface WHQFunc
> {
>
> }
> -(id)init;
> -(void)dealloc;
> @end
> struct
> {
> WHQFunc *ObjC;
> int ids;
> }struct1;
> @implementation WHQFunc
>
> -(id)init
> {
> return [super init];
> }
> -(void)dealloc
> {
> [super dealloc];
> }
> @end
>
> cfunc1()
> {
>
> }
> cfunc2()
> {
>
> }
> cfuncCreate(struct1 *s)
> {
> s = malloc(sizeof(struct1));
> [[s->ObjC alloc] init];
> }
> cfuncDestroy (struct1 *s)
> {
> [s->ObjC release];
> free(s);
> }
>
No .m filesThere can be no code that cannot compile or be ignored on
other *NIX platforms.
James McKenzie
Re: idea: display drivers
> The problem is that there can't be any Objective-C code in Wine. At all. > Or C++. Or Fortran. Or Pascal. Or Ada. Or Java. Or C# or VB. Or any > language other than pure, procedural C. Alexandre has said that you can put objective C code into wine, but only if this code is properly abstracted from the other parts of the quartz driver. E.g. by a simple binding wrapper that does nothing but wrap Objective C to C bindings. The requirement is that somebody can read and understand the Quartz driver without knowing Objective C. The biggest obstacle to merging a Quartz driver is cleaning up the user32 driver interface. Objective C is a minor issue with a pretty straightforward solution. Currently nobody knows what a proper user32 driver interface would look like.
Re: [PATCH 2/5] qedit: Add pins, IMemInputPin implementation and grabbing to SampleGrabber (try 4)
On 2/5/2010 17:54, Paul Chitescu wrote:
Changelog:
qedit: Add pins, IMemInputPin implementation and grabbing to
SampleGrabber
This time I checked it applies. Sorry.
---
+/* Sample Grabber pin implementation */
+typedef struct _SG_Pin {
+IPin pin;
This should be const IPinVtbl.
+PIN_DIRECTION dir;
+WCHAR const *name;
+struct _SG_Impl *sg;
+IPin *pair;
If it's a list why not SG_Pin* here?
+} SG_Pin;
---
Also I don't see why such helpers are needed:
---
static ULONG SampleGrabber_addref(SG_Impl *This)
---
Why not use common I_AddRef() on grabber anywhere you need it?
Re: Getting start with IXMLHTTPRequest
On 2/7/2010 16:45, Hans Leidekker wrote:
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote:
Recently I tried to start with this interface. It looks trivial enough
but since it's first time i'm using winhttp,
there could be some problems, especially cause IXMLHTTPRequest supports
asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to
far from reality?
P.S. any comments are welcome actually.
Last time this came up Jacek suggested to use urlmon instead of winhttp,
which may already handle asynchronous requests.
-Hans
Such things:
---
static HRESULT WINAPI HttpInfo_QueryInfo(IWinInetHttpInfo *iface, DWORD
dwOption,
void *pBuffer, DWORD *pcbBuffer, DWORD *pdwFlags, DWORD
*pdwReserved)
{
HttpProtocol *This = INETINFO_THIS(iface);
FIXME("(%p)->(%x %p %p %p %p)\n", This, dwOption, pBuffer,
pcbBuffer, pdwFlags, pdwReserved);
return E_NOTIMPL;
}
---
static HRESULT WINAPI HttpProtocol_Abort(IInternetProtocol *iface,
HRESULT hrReason,
DWORD dwOptions)
{
HttpProtocol *This = PROTOCOL_THIS(iface);
FIXME("(%p)->(%08x %08x)\n", This, hrReason, dwOptions);
return E_NOTIMPL;
}
---
make me think it's not ready. Also IXMLHTTPRequest methods look to
directly map tp Winhttp calls.
For example how can I implement IXMLHTTPRequest::setRequestHeader() with
urlmon?
Btw, what was a reason for using it?
re: Forward SHLocalAlloc to kernel32 LocalAlloc
What app needs this? It's been discussed before a bit; Win 98 explorer used it, http://www.winehq.org/pipermail/wine-devel/2005-August/039487.html but http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/api/index.htm says that ordinal 200 was later taken over by SHCreateDesktop. Unless we have a real good reason, we probably want to go with the later scheme. - Dan
Re: Getting start with IXMLHTTPRequest
On Sunday 07 February 2010 14:28:37 Nikolay Sivov wrote: > Recently I tried to start with this interface. It looks trivial enough > but since it's first time i'm using winhttp, > there could be some problems, especially cause IXMLHTTPRequest supports > asynchronous requests. > > Could someone with winhttp knowledge review this patch before it goes to > far from reality? > > P.S. any comments are welcome actually. Last time this came up Jacek suggested to use urlmon instead of winhttp, which may already handle asynchronous requests. -Hans
Re: Participate to GSoC
On 7 February 2010 10:35, Warren Dumortier wrote: > Hello everybody! Hello, and welcome to the Wine project. > First i'll present myself. > So my name's Warren Dumortier and i live in Belgium, i've been using > Wine for 4 years and i've always been interrested on how it works > Also i'm quite active on AppDB for submitting apps. I actively program > in C on Linux since 3 years as Gfire (our program) developer. > > As i actively program in C and would like to develop for WINE, i had a > look at the GSoC wiki page. > This year i could finally participate as i'm legally allowed now. > > Are there any specific things to know in order to be accepted as a > GSoC student for WINE? The requirements for participation are listed on the Wine wiki page (http://wiki.winehq.org/SummerOfCode). > These are the two ideas i'd like to implement: > > Theming - Implement Wine GTK/QT theming support http://wiki.winehq.org/XPThemes is a good starting point (I am updating this to link to the ColorSchemes page (which I am updating), and the other page about theme integration). > Vista Game Explorer API - Implement the core functionality of this dll That is covered in http://bugs.winehq.org/show_bug.cgi?id=21261, as noted on the wiki page. > I don't know which one i would choose yet, but how are ideas assigned > to students, are there requirements needed for each idea? Students send emails like you have done saying what they are interested in. Also, participate in the #winehackers IRC channel -- that is where a lot of discussion about Wine development takes place. As for requirements for each idea, it depends on the idea. It would also help to have experience in the different areas. For the theming work, it would help to have an understanding of GDI programming, the uxtheme (XP theming support) API and writing custom controls on the Wine/Windows API side for any improvement work to the theming logic. The main part here though, is how GTK (and Qt) theming works and how that can be captured to create an XP theme from it. It might be easier to start with the colour scheme (http://wiki.winehq.org/ColorScheme) integration, picking that up from the GTK/Qt theme (probably limiting to GTK initially, as this is a C API and limits what you need to understand) first and use that as your goal for the GSoC project, as doing a full-blown XP-based theme is a lot of work, and you end up hitting a lot of Wine bugs in that area. Once you have this in place, you can then consider extending it to Qt, or building it up to be an XP theme (tackling it a control at a time, with the first control adding the necessary infrastructure on top of the colour scheme work, will be best I think, although I am not sure how the theming logic responds to a partial theme -- that is, a theme that just specifies how buttons look). NOTE: I am > Then i could for example get familiar with the idea before the GSoC starts... > When can i ask to be GSoC student? According to the top of the Wine wiki page, you need to apply at http://code.google.com/soc/. > Thanks in advance, kind regards. - Reece
Getting start with IXMLHTTPRequest
Hi.
Recently I tried to start with this interface. It looks trivial enough
but since it's first time i'm using winhttp,
there could be some problems, especially cause IXMLHTTPRequest supports
asynchronous requests.
Could someone with winhttp knowledge review this patch before it goes to
far from reality?
P.S. any comments are welcome actually.
>From 04174c73f76309be5499ed3d5da3f98849adb842 Mon Sep 17 00:00:00 2001
From: Nikolay Sivov
Date: Sun, 7 Feb 2010 04:25:32 +0300
Subject: Initial implementation of IXMLHTTPRequest
---
dlls/msxml3/Makefile.in|2 +-
dlls/msxml3/httprequest.c | 219
dlls/msxml3/tests/domdoc.c | 62 -
3 files changed, 261 insertions(+), 22 deletions(-)
diff --git a/dlls/msxml3/Makefile.in b/dlls/msxml3/Makefile.in
index 8997f1b..f0e2739 100644
--- a/dlls/msxml3/Makefile.in
+++ b/dlls/msxml3/Makefile.in
@@ -4,7 +4,7 @@ TOPOBJDIR = ../..
SRCDIR= @srcdir@
VPATH = @srcdir@
MODULE= msxml3.dll
-IMPORTS = uuid urlmon shlwapi oleaut32 ole32 user32 advapi32 kernel32
+IMPORTS = uuid urlmon shlwapi oleaut32 ole32 user32 advapi32 kernel32 winhttp
EXTRALIBS = @XML2LIBS@
EXTRAINCL = @XML2INCL@ @XSLTINCL@
diff --git a/dlls/msxml3/httprequest.c b/dlls/msxml3/httprequest.c
index a477753..a9cfdca 100644
--- a/dlls/msxml3/httprequest.c
+++ b/dlls/msxml3/httprequest.c
@@ -25,6 +25,8 @@
#include "windef.h"
#include "winbase.h"
#include "winuser.h"
+#include "winhttp.h"
+
#include "ole2.h"
#include "msxml2.h"
@@ -40,6 +42,13 @@ typedef struct _httprequest
{
const struct IXMLHTTPRequestVtbl *lpVtbl;
LONG ref;
+
+HINTERNET session;
+HINTERNET connection;
+HINTERNET request;
+
+DWORD status; /* HTTP status code */
+DWORD content_length;
} httprequest;
static inline httprequest *impl_from_IXMLHTTPRequest( IXMLHTTPRequest *iface )
@@ -47,6 +56,54 @@ static inline httprequest *impl_from_IXMLHTTPRequest(
IXMLHTTPRequest *iface )
return (httprequest *)((char*)iface - FIELD_OFFSET(httprequest, lpVtbl));
}
+static inline void httprequest_cleanup( httprequest *This )
+{
+if ( This->request )WinHttpCloseHandle( This->request );
+if ( This->connection ) WinHttpCloseHandle( This->connection );
+if ( This->session )WinHttpCloseHandle( This->session );
+This->request = This->connection = This->session = NULL;
+This->status = 0;
+This->content_length = 0;
+}
+
+static void CALLBACK httprequest_callback(HINTERNET handle,
+ DWORD_PTR context,
+ DWORD status,
+ LPVOIDstatus_info,
+ DWORD info_len)
+{
+TRACE("status=0x%08x\n", status);
+
+switch (status)
+{
+case WINHTTP_CALLBACK_STATUS_SENDREQUEST_COMPLETE:
+case WINHTTP_CALLBACK_STATUS_REQUEST_SENT:
+WinHttpReceiveResponse(handle, NULL);
+break;
+
+case WINHTTP_CALLBACK_STATUS_RESPONSE_RECEIVED:
+{
+httprequest *This = (httprequest*)context;
+static DWORD size = sizeof(DWORD);
+
+/* update HTTP status code */
+WinHttpQueryHeaders(handle,
+WINHTTP_QUERY_STATUS_CODE |
WINHTTP_QUERY_FLAG_NUMBER,
+WINHTTP_HEADER_NAME_BY_INDEX,
+&This->status,
+&size,
+WINHTTP_NO_HEADER_INDEX);
+/* update content length */
+WinHttpQueryHeaders(handle,
+WINHTTP_QUERY_CONTENT_LENGTH |
WINHTTP_QUERY_FLAG_NUMBER,
+WINHTTP_HEADER_NAME_BY_INDEX,
+&This->content_length,
+&size,
+WINHTTP_NO_HEADER_INDEX);
+ }
+}
+}
+
static HRESULT WINAPI httprequest_QueryInterface(IXMLHTTPRequest *iface,
REFIID riid, void **ppvObject)
{
httprequest *This = impl_from_IXMLHTTPRequest( iface );
@@ -83,6 +140,7 @@ static ULONG WINAPI httprequest_Release(IXMLHTTPRequest
*iface)
ref = InterlockedDecrement( &This->ref );
if ( ref == 0 )
{
+httprequest_cleanup( This );
heap_free( This );
}
@@ -158,14 +216,96 @@ static HRESULT WINAPI httprequest_Invoke(IXMLHTTPRequest
*iface, DISPID dispIdMe
return hr;
}
-static HRESULT WINAPI httprequest_open(IXMLHTTPRequest *iface, BSTR
bstrMethod, BSTR bstrUrl,
-VARIANT varAsync, VARIANT bstrUser, VARIANT bstrPassword)
+static HRESULT WINAPI httprequest_open(IXMLHTTPRequest *iface, BSTR method,
BSTR url,
+VARIANT v_async, VARIANT user, VARIANT password)
{
httprequest *This = impl_from_IXMLHTTPRequest( iface );
+URL_COMPONENTS uc;
+BSTR name, verb;
+VARIANT b_async;
+DWORD
Re: winedbg: output of the bt command misses sometimes a frame
--- On Sat, 6/2/10, Bernhard Übelacker wrote: > Hello, > as I was debugging in wine I wondered if following > behaviour is intended or > could be considered a bug (and should be filed in > bugtracker?). > > When the debugger's current position is on the opening > curly bracket of a > function a "bt" command writes a different stack as if the > current position > is on the next instruction in this function. I think you mis-understand how compiler and debugger works. Curly brackets delimit blocks of code but do not correspond to any machine instructions themselves, and is hence removed during compilation and execution. So debuggers are supposed to skip over them and behaves as if they don't exist during code inspection. > What me makes wonder is the frame 0 is always correct but > the calling > function is not in the stack at all in the first bt: > > > Wine-dbg>bt > Backtrace: > =>0 0x7ebe3622 IsWindow(hwnd=0x20060) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2503] > in user32 (0x0033b500) > 1 0x7e25429d create_window16+0x5c(cs=0x33b53c, > className="QWidget", instance=0x40, unicode=1) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670] > in user.exe16 (0x0033b520) > 2 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024, > className="QWidget", windowName="pica", style=114032640, > x=-2147483648, y=-2147483648, width=-2147483648, > height=-2147483648, parent=(nil), menu=(nil), > instance=0x40, data=0x0(nil)) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500] > in user32 (0x0033b570) > 3 0x650778f3 in qtgui4 (+0x778f3) (0x8000) > > > Wine-dbg>next > 2507if (!(ptr = WIN_GetPtr( > hwnd ))) return FALSE; > > > Wine-dbg>bt > Backtrace: > =>0 0x7ebe3637 IsWindow+0x15(hwnd=0x20060) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:2507] > in user32 (0x0033b2b0) > 1 0x7ebe0bda WIN_CreateWindowEx+0x1201(cs=0x33b53c, > className="QWidget", module=0x40, unicode=1) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1406] > in user32 (0x0033b500) > 2 0x7e25429d create_window16+0x5c(cs=0x33b53c, > className="QWidget", instance=0x40, unicode=1) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user.exe16/message.c:2670] > in user.exe16 (0x0033b520) > 3 0x7ebe0f91 CreateWindowExW+0x7e(exStyle=1024, > className="QWidget", windowName="pica", style=114032640, > x=-2147483648, y=-2147483648, width=-2147483648, > height=-2147483648, parent=(nil), menu=(nil), > instance=0x40, data=0x0(nil)) > [/home/bernhard/data/entwicklung/2010/wine/wine-git/dlls/user32/win.c:1500] > in user32 (0x0033b570) > 4 0x650778f3 in qtgui4 (+0x778f3) (0x8000) > > > Wine-dbg> > > > Kind regards > Bernhard > > >
Participate to GSoC
Hello everybody! First i'll present myself. So my name's Warren Dumortier and i live in Belgium, i've been using Wine for 4 years and i've always been interrested on how it works Also i'm quite active on AppDB for submitting apps. I actively program in C on Linux since 3 years as Gfire (our program) developer. As i actively program in C and would like to develop for WINE, i had a look at the GSoC wiki page. This year i could finally participate as i'm legally allowed now. Are there any specific things to know in order to be accepted as a GSoC student for WINE? These are the two ideas i'd like to implement: Theming - Implement Wine GTK/QT theming support Vista Game Explorer API - Implement the core functionality of this dll I don't know which one i would choose yet, but how are ideas assigned to students, are there requirements needed for each idea? Then i could for example get familiar with the idea before the GSoC starts... When can i ask to be GSoC student? Thanks in advance, kind regards.
