Re: Setupapi [0/6] : ReactOS setupapi patches

2006-09-09 Thread Evil Jay
EA Durbin wrote:
>> Still one week, and I got absolutly no reaction about my patches.
>> Is something wrong with them?
>>
>> Hervé
>>
>>
>>
>
>
> If I recall you got alot of reaction to your patches about
> implementing ReactOS code and they wouldn't be included as ReactOS has
> some potentially dirty code.
>

You're remembering incorrectly.  I think the messages you're writing
about were to Julien as a result of his investigation into Wine stubs
vs. ReactOS code.  I don't think Herve got any responses.

-J






RE: Setupapi [0/6] : ReactOS setupapi patches

2006-09-09 Thread EA Durbin

Still one week, and I got absolutly no reaction about my patches.
Is something wrong with them?

Hervé






If I recall you got alot of reaction to your patches about implementing 
ReactOS code and they wouldn't be included as ReactOS has some potentially 
dirty code.







RE: Setupapi [0/6] : ReactOS setupapi patches

2006-09-09 Thread Hervé Poussineau
Hi,

> As setupapi merge from ReactOS has been a recurrent demand 
> [1], I'm doing this set of patches.
>
> [...]
> 
> The goal of this set of patches is to set a solid ground to 
> implement lots of missing functions in setupapi.
> I've tried to cut them in smallest possible parts.
> Additionnaly, this patchset implements SetupDiEnumDeviceInfo 
> and (mostly) SetupDiGetClassDevsExW
> 
> [...]


Still one week, and I got absolutly no reaction about my patches.
Is something wrong with them?

Hervé





Re: shell32[1/2]: document the shell32 "mini-COM" functions

2006-09-09 Thread Mikołaj Zalewski



Maybe you've seen it already, but this blog post talks about the various
allocators: http://blogs.msdn.com/oldnewthing/archive/2004/07/05/173226.aspx

-f.r.
 

 Yes, that's where I learned about it (a link to it is included in the 
documentation of SHLoadOLE)


Mikolaj




Re: Socket resets randomly

2006-09-09 Thread Alexandre Julliard
Michael Stefaniuc <[EMAIL PROTECTED]> writes:

> find -name '*.[ch]' | xargs grep 'SetLastError( *0 *)' | wc -l
> 117
>
> Time for a new Janitorial mini task?

No, SetLastError(0) is fine.

-- 
Alexandre Julliard
[EMAIL PROTECTED]




Re: Socket resets randomly

2006-09-09 Thread Michael Stefaniuc
James Hawkins wrote:
> On 9/8/06, Ryan Miller <[EMAIL PROTECTED]> wrote:
>> +/* In Windows, if setsockopt succeeds, GetLastError() always
>> returns zero.
>> +   The native wininet.dll expects this behavior, and does not always
>> +   check the return value of setsockopt() first.*/
>> +SetLastError(0);
>> +
> 
> 
> 0 is ERROR_SUCCESS, and you need to use that define.

find -name '*.[ch]' | xargs grep 'SetLastError( *0 *)' | wc -l
117

Time for a new Janitorial mini task?

bye
michael
-- 
Michael Stefaniuc   Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart




Re: shell32[1/2]: document the shell32 "mini-COM" functions

2006-09-09 Thread Frank Richter
On 08.09.2006 21:11, Mikołaj Zalewski wrote:
> This patch adds the explanation why many shell32 functions are similar
> to ole32 ones - something I've been wondering for some time. It is not
> copied from MSDN.

Maybe you've seen it already, but this blog post talks about the various
allocators: http://blogs.msdn.com/oldnewthing/archive/2004/07/05/173226.aspx

-f.r.





Re: GetTextMetrics returns wrong First/Last char index for Symbol fonts

2006-09-09 Thread Dmitry Timoshkov

"Jie Zhu" <[EMAIL PROTECTED]> wrote:


+ptmA->tmFirstChar = ptmA->tmBreakChar - 2;
+if (ptmW->tmCharSet == SYMBOL_CHARSET)
+{
+ptmA->tmLastChar = ptmW->tmLastChar > 0x0F0FF ? 0x0FF : ptmW->tmLastChar 
& 0x0FF;
+}
+else
+{
+ptmA->tmLastChar = ptmW->tmLastChar > 255 ? 255 : ptmW->tmLastChar;
+}


Probably simple WideCharToMultiByte with CP_SYMBOL and CP_ACP would do
a proper thing for tmFirstChar, tmLastChar, tmBreakChar.

You have too many fixes for different problems in your patch, that makes
it not acceptable. Please send fixes one by one for the problems you have
encountered.

Also, if you could make your tests use FreeType APIs (like Wine GDI does) 
instead
of home-made ones that would simplify them a lot. It would be nice to see a real
Wine test suite for the above conversions.

--
Dmitry.




Re: Symbol demangling and the games crashing

2006-09-09 Thread Stefan Dösinger
Am Freitag 08 September 2006 19:38 schrieb Vijay Kiran Kamuju:
> Hi,
>
> In the bug reports I have seen that we are facing problems with symbol
> demangling of '_R' operators and 'Y' datatypes.
>
> err:msvcrt:symbol_demangle Unknown operator: _R
> and
> err:msvcrt:demangle_datatype Unknown type Y
>
> Escpecially for games StarTrek Armada and Gothic.
Are you speaking about Gothic 1 or Gothic 2? Gothic 2 needs native dmusic and 
friends to work(dmime, dmloader, dmsynth, dmusic). I don't know about 
Startrek Armada, can you send me a +ddraw,+d3d7 trace, or file a bug report 
if there isn't already one?


pgpNqfUtegJm2.pgp
Description: PGP signature



Re: Socket resets randomly

2006-09-09 Thread James Hawkins

On 9/8/06, Ryan Miller <[EMAIL PROTECTED]> wrote:

Index: ChangeLog
===
RCS file: /home/wine/wine/ChangeLog,v
retrieving revision 1.120
diff -u -r1.120 ChangeLog
--- ChangeLog   24 Aug 2006 14:43:25 -  1.120
+++ ChangeLog   8 Sep 2006 22:49:55 -
@@ -1,3 +1,8 @@
+2006-09-08  Ryan Miller <[EMAIL PROTECTED]> & Zach Gorman <[EMAIL PROTECTED]>
+
+   * dlls/ws2_32/socket.c, dlls/ws2_32/sock.c
+   ws2_32: Fixed bug with sockets randomly reseting and tests.
+
 2006-08-24  Alexandre Julliard <[EMAIL PROTECTED]>

* configure, configure.ac:

Index: dlls/ws2_32/socket.c



As someone already said, no changes to Changelog.

===

RCS file: /home/wine/wine/dlls/ws2_32/socket.c,v
retrieving revision 1.4
diff -u -r1.4 socket.c
--- dlls/ws2_32/socket.c8 Sep 2006 10:16:19 -   1.4
+++ dlls/ws2_32/socket.c8 Sep 2006 22:48:11 -
@@ -2660,6 +2660,11 @@
 TRACE("socket: %04x, level %d, name %d, ptr %p, len %d\n",
   s, level, optname, optval, optlen);

+/* In Windows, if setsockopt succeeds, GetLastError() always returns zero.
+   The native wininet.dll expects this behavior, and does not always
+   check the return value of setsockopt() first.*/
+SetLastError(0);
+


0 is ERROR_SUCCESS, and you need to use that define.


 /* SO_OPENTYPE does not require a valid socket handle. */
 if (level == WS_SOL_SOCKET && optname == WS_SO_OPENTYPE)
 {


Index: dlls/ws2_32/tests/sock.c
===
RCS file: /home/wine/wine/dlls/ws2_32/tests/sock.c,v
retrieving revision 1.2
diff -u -r1.2 sock.c
--- dlls/ws2_32/tests/sock.c23 May 2006 12:49:01 -  1.2
+++ dlls/ws2_32/tests/sock.c8 Sep 2006 22:48:12 -
@@ -1410,6 +1410,27 @@

 }

+static void test_setsockopt_last_error() {
+SOCKET s;
+BOOL bKeepAlive=0;
+struct sockaddr_in addr;
+struct timeval select_timeout;
+
+select_timeout.tv_sec=5;
+select_timeout.tv_usec=0;
+addr.sin_family = AF_INET;
+addr.sin_addr.s_addr = inet_addr(SERVERIP);
+addr.sin_port = htons(SERVERPORT);
+
+s = socket(AF_INET, SOCK_STREAM, 0);
+do_bind(s, (struct sockaddr *)&addr, sizeof(addr));
+
+SetLastError(1);
+setsockopt(s,SOL_SOCKET, SO_KEEPALIVE, (char *)&bKeepAlive, 
sizeof(bKeepAlive));
+ok( GetLastError()==0, "GetLastError() was not cleared by setsockopt\n");
+closesocket(s);
+}
+


You need to SetLastError to some value that you know will never be set
by windows, something like 0xdeadbeef.  The reasoning is that
theoretically it could alter the results of the test.


 / Main program  ***/

 START_TEST( sock )
@@ -1438,6 +1459,8 @@
 test_WSAStringToAddressW();

 test_select();
-
+
+test_setsockopt_last_error();
+
 Exit();
 }








--
James Hawkins