Re: opengl32: fix a compiler warning on Mac OS X
Actually I need to fix opengl32 properly. For some reason opengl32 is opengl 1.2 while it should be 1.1. Then GL_GLEXT_PROTOTYPES is not needed at all for compiling opengl32. Roderick On Wed, Jun 10, 2009 at 12:18 AM, Austin English wrote: > GL_GLEXT_PROTOTYPES is defined in GL/gl.h on Mac. Other #ifdef methods > end up breaking compilations elsewhere. > > -- > -Austin > > > >
Re: user32/tests: Add more intensive tests for SetCursor.
On Tue, Jun 9, 2009 at 5:13 PM, Daniel Santos wrote: > > Hello! This is a prelude to other cursor patches to follow (both Griswold's > & my work). As requested, I have replaced the __FILE_SPOT with the standard > ok_(file,line) mechanism (looks much better to me). I've removed the windows > version checking from tests and last error checking on success, although I > have reservations about it (mostly the later). Forgot patch. -- -Austin
Re: wldap32: fix a compiler warning on Mac OS X
On Tue, Jun 9, 2009 at 4:51 PM, Stefan
Leichter wrote:
> Am Tuesday 09 June 2009 23:46:51 schrieb Austin English:
>> Cast was removed by d576c2d9342e769c01fb99c0cc200a0bc4b9cded, but
>> causes a compiler warning on OS X. The same cast is used ~20 lines
>> later.
>
> You forgot the patch
>
> --
> Stefan
>
>
>
Whoops, thanks! Here it is.
--
-Austin
diff --git a/dlls/wldap32/parse.c b/dlls/wldap32/parse.c
index f7e93dd..6439ba6 100644
--- a/dlls/wldap32/parse.c
+++ b/dlls/wldap32/parse.c
@@ -444,7 +444,7 @@ INT CDECL ldap_parse_vlv_controlW( WLDAP32_LDAP *ld,
PLDAPControlW *control,
#ifdef HAVE_LDAP_PARSE_VLV_CONTROL
if (!(ret = ldap_parse_vlv_control( ld, controlU, &pos, &count,
-context, errcode )))
+(struct berval **)context, errcode )))
{
*targetpos = pos;
*listcount = count;
Re: wldap32: fix a compiler warning on Mac OS X
Am Tuesday 09 June 2009 23:46:51 schrieb Austin English: > Cast was removed by d576c2d9342e769c01fb99c0cc200a0bc4b9cded, but > causes a compiler warning on OS X. The same cast is used ~20 lines > later. You forgot the patch -- Stefan
Re: gdiplus: Add stubs for GdipGetVisibleClipBoundsI, GdipDrawDriverString & GdipMeasureDriverString
Ken Sharp wrote:
These stubs stop three crashes in Photoshop CS4.
>From 4e5dd892a7a577001072fd7701467c262c483b1f Mon Sep 17 00:00:00 2001
From: Ken Sharp
Date: Tue, 9 Jun 2009 21:48:05 +0100
Subject: [PATCH] gdiplus: Add stubs for GdipGetVisibleClipBoundsI,
GdipDrawDriverString & GdipMeasureDriverString
This fixes three crashes in Photoshop CS4.
---
dlls/gdiplus/gdiplus.spec |6 +++---
dlls/gdiplus/graphics.c | 35 ++-
2 files changed, 37 insertions(+), 4 deletions(-)
+GpStatus WINGDIPAPI GdipMeasureDriverString(GpGraphics *graphics, GDIPCONST
UINT16 *text, INT length,
+GDIPCONST GpFont *font, GDIPCONST
PointF *positions,
+INT flags, GDIPCONST GpMatrix
*matrix, RectF *boundingBox)
+{
+FIXME("(%p %p %d %p %p %d %p %p): stub\n", graphics, text, length, font,
positions, flags, matrix, boundingBox);
+return FALSE;
+}
+
You should return NotImplemented.
Re: Wine translation statistics sources
Michael Stefaniuc schrieb: André Hentschel wrote: Paul Vriens schrieb: Alexandre Julliard wrote: Mikołaj Zalewski writes: It's online again. Having it on WineHQ would probably give a better uptime (and a much better latency, but this should also improve on my side, when I won't need a temporary SSH tunnel anymore and will move the HTTP server from my good old Pentium 100MHz to a new Atom machine). I've been in contact with Jeremy Newman about it some time ago, but, after a few exchanges, my e-mails got unanswered, so I assumed he is too busy to help with it (and, alone, I don't know how to do it). If you send me the necessary information I can probably take care of it. And we of course need something to cope with the change to the clock resource files as mentioned by Michael Stefaniuc. Or we should change our clock resources to fit in the rest of wine? You mean reverting Alexandre's patch? Doubt it. For now i dont't understand the sense of the patch...
Re: How do I actually write a testcase for a 16-bit API ?
Dmitry Timoshkov escribió:
"Alex Villacís Lasso" wrote:
I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in
which I showed that DlgDirList is behaving incorrectly for 16-bit
apps. I also included a test program compiled with the Watcom C
compiler, as well as a patch. Then a comment appeared saying that it
should be possible to create a testcase for this API.
By creating a test I meant to have a test for 32-bit behaviour first,
then compare it with 16-bit one.
The 32-bit test is already in place in current git, and shows that the
behavior is compliant for 32-bit apps. It is at
dlls/user32/tests/listbox.c. Lines 1189 through 1219 show that
DDL_DRIVES alone implies DDL_EXCLUSIVE. Lines 1231 through 1263 show
that DDL_DRIVES|DDL_DIRECTORY does *not* imply DDL_EXCLUSIVE.
I am taking issue with lines 617 through 619 of dlls/user32/dialog16.c:
/**
* DlgDirList (USER.100)
*/
INT16 WINAPI DlgDirList16( HWND16 hDlg, LPSTR spec, INT16 idLBox,
INT16 idStatic, UINT16 attrib )
{
/* according to Win16 docs, DDL_DRIVES should make DDL_EXCLUSIVE
* be set automatically (this is different in Win32, and
* DIALOG_DlgDirList sends Win32 messages to the control,
* so do it here) */
if (attrib & DDL_DRIVES) attrib |= DDL_EXCLUSIVE;
return DlgDirListA( WIN_Handle32(hDlg), spec, idLBox, idStatic,
attrib );
}
If a 16-bit test were placed in the testsuite, it would show that the
current implementation (attrib & DDL_DRIVES) is incorrect, as
demonstrated by my test program. It should be attrib == DDL_DRIVES
instead. The program so far shows that the flag behavior is identical
for 16-bit and 32-bit calls.
--
perl -e '$x=2.3;printf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'
Re: How is 0.0.0.0 handled in Wine?
On Tuesday 09 June 2009 17:33:32 Austin English wrote: > FWIW, a user sent me this e-mail: That looks like a bug in iphlpapi, not related to how wine deals with INADDR_ANY as target ip address. Feel free to open a bug about that, but I fail to see how this is related to the current thread, Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: How is 0.0.0.0 handled in Wine?
FWIW, a user sent me this e-mail: I was reading your post about wine and 0.0.0.0 and wanted to share a bug a developer recently came across connected with networking, though I was unsure if you would be interested and I am not confident enough to post to bugzilla (I fear the vitamin). The developer involved is steve gibson - I think you can download his test software that showed a repeatable crash but with info from the discussion in the mailing list with numerous testters apparently using the latest wine, I am hoping a test from him might not be necessary: http://12078.net/grcnews/article.php?id=3293&group=grc.dns#3293 quote: Calling "GetNetworkParams" with a null buffer size causes it to fill in the size of the buffer it requires. This size should never change from one call to another --- at least with nothing else changing in the system -- since the requested data is relatively fixed at that point. http://msdn.microsoft.com/en-us/library/aa365968(VS.85).aspx But both Robin and Mark's logs reveal that the SECOND call to the same function is -- inexplicably -- returning a smaller value. That's not right. ..., what's more, in Robin's posted case, the call back to the function using the smaller allocation that was all if said it needed ... crashes the app! end quote I suspect they are talking about this http://source.winehq.org/source/dlls/iphlpapi/iphlpapi_main.c#L1263 example of log of cause of suspected cause of crash http://12078.net/grcnews/article.php?id=3286&group=grc.dns#3286 commentary by another programmer http://12078.net/grcnews/article.php?id=&group=grc.dns# Steve is quite amenable to getting his software working well in wine, but is limited in his time. Apparently he does not test for wine, but he has used a workaround to get it working. HTH regards JHB -- -Austin
Re: Latest git fails compiling
2009/6/10 Austin English :
> On Tue, Jun 9, 2009 at 7:14 AM, Ben Klein wrote:
>> I've occasionally got compilation errors while doing a git bisect. As
>> there is no way to fix this (assuming there's nothing wrong with libs
>> on my system, since every other revision I try gets built fine)
>> without manually hacking at the git repository (which is a very bad
>> idea for all sorts of reasons), I just mark that revision as bad and
>> continue.
>
> That's a very poor practice, leading to wrong regression test results.
> The proper thing to do is either:
> A) fix the compile manually, then revert your change before the next
> git bisect {good,bad}
> B) use 'git bisect skip'.
Now that you mention it, B sounds very familiar. I believe that is
what I used. Regardless, my test did find the correct patch at the
time and the author was able to provide a fix for me :)
My apologies, I've been hideously tired and stressed recently.
Re: Latest git fails compiling
On Tue, Jun 9, 2009 at 7:14 AM, Ben Klein wrote:
> 2009/6/9 Uwe Bonnes :
>>> "Ben" == Ben Klein writes:
>>
>> Ben> 2009/6/9 Uwe Bonnes :
>> >> Hello,
>> >>
>> >> on a fresh tree check out and compiled successfully yesterday
>> >> (090608) and updated today(090609), compile fails with:
>> >>
>> >> make[1]: Entering directory
>> >> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl
>> >> -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl
>> >> ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H
>> >> activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include
>> >> -I../include \ -h -H activscp.h activscp.idl oaidl.idl:121: error:
>> >> parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void
>> >> * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory
>> >> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include'
>> >>
>> >> This is on Suse 11.1, x86-64. I have not seens this reported
>> >> before. Any hints for fixing (perhaps my setup)?
>>
>> Ben> Please provide the git revision number, not just the date.
>>
>> Trying to run "git bisect" and going back to
>> de945384a4c1f593820e91811c1c04ff0263ca48 (the number gitk reports in the
>> topmost entry) now everything compiled fine. Strange...
>
> I've occasionally got compilation errors while doing a git bisect. As
> there is no way to fix this (assuming there's nothing wrong with libs
> on my system, since every other revision I try gets built fine)
> without manually hacking at the git repository (which is a very bad
> idea for all sorts of reasons), I just mark that revision as bad and
> continue.
That's a very poor practice, leading to wrong regression test results.
The proper thing to do is either:
A) fix the compile manually, then revert your change before the next
git bisect {good,bad}
B) use 'git bisect skip'.
--
-Austin
Add-stub-for-IoOpenDeviceRegistryKey-needed-for-l.patch
Appended stup is needed for libusb-win32-0.1x
--
Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
>From 7216b1e26b9cbd3d4bb7eaa096757ad11d0b77b5 Mon Sep 17 00:00:00 2001
From: Uwe Bonnes
Date: Tue, 9 Jun 2009 16:41:09 +0200
Subject: Add stub for IoOpenDeviceRegistryKey(), needed for libusb-win32-0.1.2
---
dlls/ntoskrnl.exe/ntoskrnl.c| 11 +++
dlls/ntoskrnl.exe/ntoskrnl.exe.spec |2 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c
index 5a043e5..99c2847 100644
--- a/dlls/ntoskrnl.exe/ntoskrnl.c
+++ b/dlls/ntoskrnl.exe/ntoskrnl.c
@@ -2493,6 +2493,17 @@ NTSTATUS WINAPI PsSetCreateThreadNotifyRoutine(
PCREATE_THREAD_NOTIFY_ROUTINE No
/***
+ * IoOpenDeviceRegistryKey (NTOSKRNL.EXE.@)
+ */
+NTSTATUS WINAPI IoOpenDeviceRegistryKey( PDEVICE_OBJECT DeviceObject,
+ULONG DevInstKeyType, ACCESS_MASK DesiredAccess, PHANDLE DevInstRegKey)
+{
+FIXME( "stub:\n");
+return STATUS_SUCCESS;
+}
+
+
+/***
* MmGetSystemRoutineAddress (NTOSKRNL.EXE.@)
*/
PVOID WINAPI MmGetSystemRoutineAddress(PUNICODE_STRING SystemRoutineName)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
index 52efd92..cda9230 100644
--- a/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
+++ b/dlls/ntoskrnl.exe/ntoskrnl.exe.spec
@@ -409,7 +409,7 @@
@ stdcall IoIsWdmVersionAvailable(long long)
@ stub IoMakeAssociatedIrp
@ stub IoOpenDeviceInterfaceRegistryKey
-@ stub IoOpenDeviceRegistryKey
+@ stdcall IoOpenDeviceRegistryKey (long long long long)
@ stub IoPageRead
@ stub IoPnPDeliverServicePowerNotification
@ stub IoQueryDeviceDescription
--
1.6.0.2
Re: Latest git fails compiling
2009/6/9 Uwe Bonnes : >> "Ben" == Ben Klein writes: > > Ben> 2009/6/9 Uwe Bonnes : > >> Hello, > >> > >> on a fresh tree check out and compiled successfully yesterday > >> (090608) and updated today(090609), compile fails with: > >> > >> make[1]: Entering directory > >> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl > >> -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl > >> ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H > >> activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include > >> -I../include \ -h -H activscp.h activscp.idl oaidl.idl:121: error: > >> parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void > >> * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory > >> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' > >> > >> This is on Suse 11.1, x86-64. I have not seens this reported > >> before. Any hints for fixing (perhaps my setup)? > > Ben> Please provide the git revision number, not just the date. > > Trying to run "git bisect" and going back to > de945384a4c1f593820e91811c1c04ff0263ca48 (the number gitk reports in the > topmost entry) now everything compiled fine. Strange... I've occasionally got compilation errors while doing a git bisect. As there is no way to fix this (assuming there's nothing wrong with libs on my system, since every other revision I try gets built fine) without manually hacking at the git repository (which is a very bad idea for all sorts of reasons), I just mark that revision as bad and continue.
Re: Latest git fails compiling
> "Ben" == Ben Klein writes: Ben> 2009/6/9 Uwe Bonnes : >> Hello, >> >> on a fresh tree check out and compiled successfully yesterday >> (090608) and updated today(090609), compile fails with: >> >> make[1]: Entering directory >> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl >> -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl >> ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H >> activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include >> -I../include \ -h -H activscp.h activscp.idl oaidl.idl:121: error: >> parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void >> * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory >> `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' >> >> This is on Suse 11.1, x86-64. I have not seens this reported >> before. Any hints for fixing (perhaps my setup)? Ben> Please provide the git revision number, not just the date. Trying to run "git bisect" and going back to de945384a4c1f593820e91811c1c04ff0263ca48 (the number gitk reports in the topmost entry) now everything compiled fine. Strange... -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: wine-patches Digest, Vol 47, Issue 40
Piotr Caban writes: > Whats wrong with this patch? > > All the date expressions (e.g. day_from_year) are copied from ECMA-262 > standard specification. Because of the date range it can be keep in > double without error. Look a bit closer at your constant definitions... -- Alexandre Julliard julli...@winehq.org
Re: wine-patches Digest, Vol 47, Issue 40
> Message: 2 > Date: Thu, 04 Jun 2009 22:37:48 +0200 > From: Piotr Caban > Subject: jscript: Added Date_getFullYear and Date_getUTCFullYear > implementation (3/7) > To: wine-patc...@winehq.org > Message-ID: <4a28309c.9000...@gmail.com> > Content-Type: text/plain; charset="utf-8" > > --- > dlls/jscript/date.c | 73 > ++-- > dlls/jscript/tests/api.js |9 + > 2 files changed, 78 insertions(+), 4 deletions(-) Whats wrong with this patch? All the date expressions (e.g. day_from_year) are copied from ECMA-262 standard specification. Because of the date range it can be keep in double without error. Piotr Caban
Re: Latest git fails compiling
2009/6/9 Uwe Bonnes : > Hello, > > on a fresh tree check out and compiled successfully yesterday (090608) and > updated today(090609), compile fails with: > > make[1]: Entering directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' > ../tools/widl/widl -I. -I. -I../include -I../include \ > -h -H activaut.h activaut.idl > ../tools/widl/widl -I. -I. -I../include -I../include \ > -h -H activdbg.h activdbg.idl > ../tools/widl/widl -I. -I. -I../include -I../include \ > -h -H activscp.h activscp.idl > oaidl.idl:121: error: parameter 'pvData' of (null) 'tagSAFEARRAY' \ > cannot derive from void * > make[1]: *** [activscp.h] Fehler 1 > make[1]: Leaving directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' > > This is on Suse 11.1, x86-64. I have not seens this reported before. Any > hints for fixing (perhaps my setup)? Please provide the git revision number, not just the date.
Re: mlang/tests: [Patch 2] Skip some tests on systems, that do not support CP_UTF8
Detlef Riekenberg writes:
> @@ -1164,6 +1165,14 @@ static void test_GetRfc1766Info(IMultiLanguage2 *iML2)
> ok(!lstrcmpA(rfc1766A, info_table[i].rfc1766),
> "#%02d: got '%s' (expected '%s')\n", i, rfc1766A,
> info_table[i].rfc1766);
>
> +if (!localenameA[0]) {
> +/* old win95 systems do not support CP_UTF8 */
> +if (!i)
> +win_skip("CP_UTF8 not supported on this system\n");
> +
> +continue;
> +}
You should store the table in Unicode instead.
--
Alexandre Julliard
julli...@winehq.org
Re: How is 0.0.0.0 handled in Wine?
On Tuesday 09 June 2009 07:17:58 Austin English wrote: > > 0.0.0.0 and broadcast packets cause some problems with the newer Command > > and Conquer games, but the ticket was closed some time ago. I believe it > > was decided that since the kernel devs wouldn't change how Linux handles > > these cases that it would be too much trouble to work around it. > > http://bugs.winehq.org/show_bug.cgi?id=7929 Rereading this bug tells me that it's a) not related to 0.0.0.0 being pingable in unix b) due to programmers abusing the api to get their broadcasts to work c) not fixable by us without kernel support d) not going to happen Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: How is 0.0.0.0 handled in Wine?
On Tuesday 09 June 2009 11:00:25 David Gerard wrote: > > On Windows, this would likely cause a catchable error. On Linux (at > > least), the socket connection may succeed. I think someone said C&C3 > > is affected by this inconsistency between Linux and Windows INADDR_ANY > > handling; this is probably why :P > > Until someone demonstrates a real need for this (with appropriate test > > cases) ... > > Apart from the test cases, didn't you just name a real app that needs this? I'm pretty sure C&C had other issues. I don't have C&C (3 iirc) myself, so I can't test that. I know that StarCraft is affected by broadcasts on unix being different than broadcasts on win. However, the StarCraft way of doing networking is _very_ braindead (you can tell IP based network gaming was a quick slap-on patch) and is easy to break on windows machines with more than one network interface as well. I figure C&C has similar issues. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: How is 0.0.0.0 handled in Wine?
2009/6/9 David Gerard : > 2009/6/9 Ben Klein : >> Only case that I can think of where 0.0.0.0 handling will break apps >> is in lazy network programming. > > I am shocked, shocked to hear that there might be apps with lazy > network programming! ;-p I was going to say "extreme laziness" ... >> On Windows, this would likely cause a catchable error. On Linux (at >> least), the socket connection may succeed. I think someone said C&C3 >> is affected by this inconsistency between Linux and Windows INADDR_ANY >> handling; this is probably why :P >> Until someone demonstrates a real need for this (with appropriate test >> cases) ... > > Apart from the test cases, didn't you just name a real app that needs this? Well, I don't have C&C3, and I'm not going to get it just to prove it expects a broken connection on 0.0.0.0 ;) Test cases are virtually required for this.
Re: How is 0.0.0.0 handled in Wine?
2009/6/9 Ben Klein : > Only case that I can think of where 0.0.0.0 handling will break apps > is in lazy network programming. I am shocked, shocked to hear that there might be apps with lazy network programming! ;-p > On Windows, this would likely cause a catchable error. On Linux (at > least), the socket connection may succeed. I think someone said C&C3 > is affected by this inconsistency between Linux and Windows INADDR_ANY > handling; this is probably why :P > Until someone demonstrates a real need for this (with appropriate test > cases) ... Apart from the test cases, didn't you just name a real app that needs this? - d.
Re: How is 0.0.0.0 handled in Wine?
2009/6/9 Kai Blin : > It was > annoying enough having to handle that modern linux distros always resolve the > hostname to a loopback address and many windows apps think that > gethostbyname(gethostname()) was a good idea to figure out what IP address to > bind to when they actually want to bind to INADDR_ANY. (That's 0.0.0.0 btw, > and will find you my "gethostname() should not resolve to localhost" hack.) Ah, I thought 0.0.0.0 was invalid. This explains a bit. Only case that I can think of where 0.0.0.0 handling will break apps is in lazy network programming. Consider the psuedo-code: ip_addr = "0.0.0.0" for (each_ip in valid_addresses) if (some_test(each_ip)) ip_addr=each_ip socket=connect_to(ip_addr) On Windows, this would likely cause a catchable error. On Linux (at least), the socket connection may succeed. I think someone said C&C3 is affected by this inconsistency between Linux and Windows INADDR_ANY handling; this is probably why :P Until someone demonstrates a real need for this (with appropriate test cases) ...
Latest git fails compiling
Hello, on a fresh tree check out and compiled successfully yesterday (090608) and updated today(090609), compile fails with: make[1]: Entering directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' ../tools/widl/widl -I. -I. -I../include -I../include \ -h -H activaut.h activaut.idl ../tools/widl/widl -I. -I. -I../include -I../include\ -h -H activdbg.h activdbg.idl ../tools/widl/widl -I. -I. -I../include -I../include\ -h -H activscp.h activscp.idl oaidl.idl:121: error: parameter 'pvData' of (null) 'tagSAFEARRAY' \ cannot derive from void * make[1]: *** [activscp.h] Fehler 1 make[1]: Leaving directory `/media/sda8/sdb8/spare/bon/Wine/wine-git/include' This is on Suse 11.1, x86-64. I have not seens this reported before. Any hints for fixing (perhaps my setup)? -- Uwe Bonnesb...@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: kernel32: Prevent second loading of a library with specified path.
> I think we already create our own dll's for testing purposes, see > kernel32/tests/loader.c (test_Loader()). > > Will that suffice? Thanks. This is what is need.
Re: kernel32: Prevent second loading of a library with specified path.
Alexander Morozov wrote: This should most likely be done in ntdll. Also please add tests for these different cases. For tests should create dll which can be loaded. But I do not know how to implement this in tests on WINE. I tried to copy and rename .exe.so module but it seems like the problem is existing only for PE modules. I think we already create our own dll's for testing purposes, see kernel32/tests/loader.c (test_Loader()). Will that suffice? -- Cheers, Paul.
Re: kernel32: Prevent second loading of a library with specified path.
> This should most likely be done in ntdll. Also please add tests for > these different cases. For tests should create dll which can be loaded. But I do not know how to implement this in tests on WINE. I tried to copy and rename .exe.so module but it seems like the problem is existing only for PE modules.
