Re: [2/2] ntdll: Store full line status register in the internal structure, not just the TIOCSER_TEMT bit.
Dmitry Timoshkov wrote: > Printing complete lsr value in the log may help with diagnosing > test failures on Alexandre's machine. This patch is marked as 'Build failure' in the tracker, but I've checked it once again and compiles just fine here. What kind of build failure is that? -- Dmitry.
Re: Help to create a server request
On Aug 29, 2013, at 6:43 PM, Bruno Jesus wrote:
> Hi all, I need some help to continue my current wine work.
>
> In order to implement SO_PROTOCOL_INFO for getsockopt I need to
> retrieve some information from the socket like its family and
> protocol.
>
> I have searched for a few days and ended up with a solution I dislike
> so I had a better idea (at least I hope I did).
>
> Instead of using non-portable SO_DOMAIN and SO_PROTOCOL/SO_PROTOTYPE
> to retrieve the socket family and protocol or using non-reliable
> guessing using only the socket type I thought it would be better to
> ask the server for this information. Using a request just like is used
> for several other information in ws2_32 (operation which will work on
> every OS).
>
> So, all I need is a server request that based on the socket fd will
> return the socket family, type and protocol. I tried to understand how
> requests work but I failed completely.
>
> Maybe this request can be later improved to return the connection time
> so we can finally fix SO_CONNECT_TIME option.
>
> The current solution is attached, since I sent the tests separated and
> they were commited the patch will not apply, it's only for reference.
> The idea is to remove the functions get_sock_[family|protocol|type] to
> a single server request.
>
> So, is this a good idea?
There's no way I know of to get this information directly on at least Mac OS,
so I'd say go for it. (But I can't speak for anyone else on this list, so...)
> If yes, how can I create and use the request?
To add a new request to the server, you first add a definition to
server/protocol.def . This file is processed by the make_requests tool, which
generates a bunch of other files from it. The syntax of the server protocol
definition file is somewhat like Objective-C (if you've ever used or seen
that). A typical server request definition looks like this:
@REQ(request_name)
/* input parameters go here */
int input;
obj_handle_t handle; /* don't use Windows types */
@REPLY
/* output values go here */
int output;
@END
As with all generated files, the files generated by make_requests shouldn't be
included in your patch.
After defining a new server call, you define the handler in the server like so:
DECL_HANDLER(request_name)
{
/* implicit parameters: req, reply */
/* use the 'current' global to refer to the process and thread that made
the request */
if (req->handle != ((obj_handle_t)-1))
{
reply->output = do_something(req->input, req->handle);
}
else
{
set_error(STATUS_UNSUCCESSFUL); /* NTSTATUS is returned to client */
}
/* no return value */
}
Then, in the client DLLs, you make server calls like this:
SERVER_START_REQ( request_name )
{
/* implicit variables: req, reply */
req->input = 1;
req->handle = wine_server_obj_handle( handle ); /* converts Windows HANDLE
to a server obj_handle_t */
if (wine_server_call( req ) != STATUS_SUCCESS)
{
/* SetLastError(), return error code, etc. */
}
do_something(reply->output);
}
SERVER_END_REQ;
There's lots of examples throughout Wine of this in action, especially in
lower-level DLLs like ntdll and kernel32; I encourage you to look at them.
(That's how I figured all this out, after all.) If you have any more questions
(and not just because you were too lazy to even look ;), feel free to ask.
Chip
Help to create a server request
Hi all, I need some help to continue my current wine work.
In order to implement SO_PROTOCOL_INFO for getsockopt I need to
retrieve some information from the socket like its family and
protocol.
I have searched for a few days and ended up with a solution I dislike
so I had a better idea (at least I hope I did).
Instead of using non-portable SO_DOMAIN and SO_PROTOCOL/SO_PROTOTYPE
to retrieve the socket family and protocol or using non-reliable
guessing using only the socket type I thought it would be better to
ask the server for this information. Using a request just like is used
for several other information in ws2_32 (operation which will work on
every OS).
So, all I need is a server request that based on the socket fd will
return the socket family, type and protocol. I tried to understand how
requests work but I failed completely.
Maybe this request can be later improved to return the connection time
so we can finally fix SO_CONNECT_TIME option.
The current solution is attached, since I sent the tests separated and
they were commited the patch will not apply, it's only for reference.
The idea is to remove the functions get_sock_[family|protocol|type] to
a single server request.
So, is this a good idea? If yes, how can I create and use the request?
If not I'm all ears.
Best wishes and thanks in advance,
Bruno
diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c
index 462f153..5218b5c 100644
--- a/dlls/ws2_32/socket.c
+++ b/dlls/ws2_32/socket.c
@@ -1018,6 +1018,57 @@ static inline int get_rcvsnd_timeo( int fd, int optname)
return ret;
}
+static inline int get_sock_family(int fd)
+{
+int optval = AF_UNSPEC;
+#ifdef SO_DOMAIN
+socklen_t optlen = sizeof(optval);
+if (getsockopt(fd, SOL_SOCKET, SO_DOMAIN, (char *) &optval, &optlen))
+ERR("getsockopt(SO_DOMAIN) failed\n");
+#else
+union generic_unix_sockaddr uaddr;
+socklen_t uaddrlen = sizeof(uaddr);
+
+if (!getsockname(fd, &uaddr.addr, &uaddrlen))
+optval = uaddr.addr.sa_family;
+
+if (optval == AF_UNSPEC)
+{
+optval = AF_INET;
+ERR("could not detect socket family - defaulting to AF_INET\n");
+}
+#endif
+return optval;
+}
+
+static inline int get_sock_type(int fd)
+{
+ int optval = 0;
+ socklen_t optlen = sizeof(optval);
+ if (getsockopt(fd, SOL_SOCKET, SO_TYPE, (char *) &optval, &optlen))
+ ERR("getsockopt(SO_TYPE) failed\n");
+ return optval;
+}
+
+static inline int get_sock_protocol(int fd)
+{
+int optval = IPPROTO_IP;
+#ifdef SO_PROTOCOL
+socklen_t optlen = sizeof(optval);
+if (getsockopt(fd, SOL_SOCKET, SO_PROTOCOL, (char *) &optval, &optlen))
+ERR("getsockopt(SO_PROTOCOL) failed\n");
+#elif defined(SO_PROTOTYPE)
+socklen_t optlen = sizeof(optval);
+if (getsockopt(fd, SOL_SOCKET, SO_PROTOTYPE, (char *) &optval, &optlen))
+ERR("getsockopt(SO_PROTOTYPE) failed\n");
+#else
+int socktype = get_sock_type(fd);
+if (socktype == SOCK_STREAM) optval = IPPROTO_TCP;
+else if (socktype == SOCK_DGRAM) optval = IPPROTO_UDP;
+#endif
+return optval;
+}
+
/* macro wrappers for portability */
#ifdef SO_RCVTIMEO
#define GET_RCVTIMEO(fd) get_rcvsnd_timeo( (fd), SO_RCVTIMEO)
@@ -1116,6 +1167,60 @@ convert_socktype_u2w(int unixsocktype) {
return -1;
}
+static int fill_protocol_info(int fd, int unicode, char *optval)
+{
+int sockfamily, socktype, sockproto, items, sz, i;
+DWORD listsize = 0;
+WSAPROTOCOL_INFOW *buffer = NULL;
+
+union _infow
+{
+ WSAPROTOCOL_INFOA *a;
+ WSAPROTOCOL_INFOA *w;
+} info;
+info.a = (WSAPROTOCOL_INFOA *) optval;
+
+sz = unicode ? sizeof(WSAPROTOCOL_INFOW) : sizeof(WSAPROTOCOL_INFOA);
+memset(optval, 0, sz);
+
+sockfamily = convert_af_u2w(get_sock_family(fd));
+socktype = convert_socktype_u2w(get_sock_type(fd));
+sockproto = convert_proto_u2w(get_sock_protocol(fd));
+
+/* Start by filling basic information in case our search below fails */
+info.a->iAddressFamily = sockfamily;
+info.a->iSocketType = socktype;
+info.a->iProtocol = sockproto;
+
+items = WSAEnumProtocolsW(NULL, NULL, &listsize);
+if (items == SOCKET_ERROR && WSAGetLastError() == WSAENOBUFS &&
+ (buffer = HeapAlloc(GetProcessHeap(), 0, listsize)))
+{
+items = WSAEnumProtocolsW(NULL, buffer, &listsize);
+for (i = 0; i < items; i++)
+{
+if (buffer[i].iAddressFamily == sockfamily &&
+buffer[i].iSocketType == socktype &&
+buffer[i].iProtocol == sockproto)
+{
+if (unicode)
+memcpy(info.w, &buffer[i], sz);
+else
+{
+/* convert the structure from W to A */
+memcpy(info.a, &buffer[i], FIELD_OFFSET(WSAPROTOCOL_INFOA,
szProtocol));
+WideCharToMultiByte(CP_ACP, 0, buffer[i].szProtocol, -1,
+info.a->szPr
Re: RFC: Mark dylib/mach-o on Mac OS X
André Hentschel writes: > Am 29.08.2013 23:15, schrieb Alexandre Julliard: >> André Hentschel writes: >> >>> Am 29.08.2013 19:52, schrieb André Hentschel: Hi, thank you both for the comments, i'll see what i can do. >>> >>> How about that? >> >> I don't see the point at all. There's no reason to add all that >> complexity for a purely cosmetic detail. >> > > OK, one use case is when we want to automatically parse the BTs, > e.g. when sending them over to a server at winehq. > (wasn't that one idea when the crash dialog was discussed?) We have system information in the crash logs already. -- Alexandre Julliard julli...@winehq.org
Re: RFC: Mark dylib/mach-o on Mac OS X
Am 29.08.2013 23:15, schrieb Alexandre Julliard: > André Hentschel writes: > >> Am 29.08.2013 19:52, schrieb André Hentschel: >>> Hi, >>> thank you both for the comments, i'll see what i can do. >> >> How about that? > > I don't see the point at all. There's no reason to add all that > complexity for a purely cosmetic detail. > OK, one use case is when we want to automatically parse the BTs, e.g. when sending them over to a server at winehq. (wasn't that one idea when the crash dialog was discussed?)
Re: RFC: Mark dylib/mach-o on Mac OS X
André Hentschel writes: > Am 29.08.2013 19:52, schrieb André Hentschel: >> Hi, >> thank you both for the comments, i'll see what i can do. > > How about that? I don't see the point at all. There's no reason to add all that complexity for a purely cosmetic detail. -- Alexandre Julliard julli...@winehq.org
Re: Embedding a HWND window into an X11 window
> This solutions implies to modify wine, so do you think that this patch > or an improved version could be merged into wine? > Because I don't want to require a custom version of wine. Even if it were merged, that would not give you the ability to use it from within a Windows or winelib program. For that you would need either some extra Wine-specific API's to allow this or an approach that does not rely on Wine (which may be possible using X11 to reparent Wine's windows, but would be a hacky approach).
Re: RFC: Mark dylib/mach-o on Mac OS X
Am 29.08.2013 22:46, schrieb Charles Davis:
>
> On Aug 29, 2013, at 2:35 PM, André Hentschel wrote:
>
>> Am 29.08.2013 19:52, schrieb André Hentschel:
>>> Hi,
>>> thank you both for the comments, i'll see what i can do.
>>
>> How about that?
> Much better, but...
>>
>> diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
>> index c0b86ba..0667ad7 100644
>> --- a/programs/winedbg/info.c
>> +++ b/programs/winedbg/info.c
>> @@ -244,6 +244,11 @@ void info_win32_module(DWORD64 base)
>> }
>> }
>> }
>> +else if (strstr(im.mi[i].ModuleName, ""))
>> +{
>> +dbg_printf("Mach-O\t");
>> +module_print_info(&im.mi[i], FALSE);
> If there are any modules embedded in a Mach-O file (i.e. the PE DLLs embedded
> in a Wine built-in DLL), this will no longer print them.
Oops, true.
changes since last one:
> dbg_printf("Mach-O\t");
> module_print_info(&im.mi[i], FALSE);
> +/* print all modules embedded in this one */
> +for (j = 0; j < im.num_used; j++)
> +{
> +if (!strstr(im.mi[j].ModuleName, "") &&
> module_is_container(&im.mi[i], &im.mi[j]))
> +{
> +dbg_printf(" \\-PE\t");
> +module_print_info(&im.mi[j], TRUE);
> +}
> +}
> }
> else
> {
> /* check module is not embedded in another module */
> for (j = 0; j < im.num_used; j++)
> {
> -if (strstr(im.mi[j].ModuleName, "") &&
> module_is_container(&im.mi[j], &im.mi[i]))
> +if ((strstr(im.mi[j].ModuleName, "") ||
> strstr(im.mi[j].ModuleName, "")) &&
> +module_is_container(&im.mi[j], &im.mi[i]))
> break;
Could you test that please? Maybe some ideas regarding code duplication?
diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c
index 6bea436..ed1d9c0 100644
--- a/dlls/dbghelp/module.c
+++ b/dlls/dbghelp/module.c
@@ -33,6 +33,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
const WCHARS_ElfW[] = {'<','e','l','f','>','\0'};
+const WCHARS_MachoW[] = {'<','m','a','c','h','-','o','>','\0'};
const WCHARS_WineLoaderW[] =
{'<','w','i','n','e','-','l','o','a','d','e','r','>','\0'};
static const WCHAR S_DotSoW[] = {'.','s','o','\0'};
static const WCHAR S_DotDylibW[]= {'.','d','y','l','i','b','\0'};
@@ -89,12 +90,19 @@ static void module_fill_module(const WCHAR* in, WCHAR* out,
size_t size)
out[len - l] = '\0';
else if (len > strlenW(loader) && !strcmpiW(out + len - strlenW(loader),
loader))
lstrcpynW(out, S_WineLoaderW, size);
-else
-{
-if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) &&
-(l = match_ext(out, len - 3)))
-strcpyW(&out[len - l - 3], S_ElfW);
-}
+else if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) && (l =
match_ext(out, len - 3)))
+switch (module_get_type_by_name(out))
+{
+case DMT_ELF:
+strcpyW(&out[len - l - 3], S_ElfW);
+break;
+case DMT_MACHO:
+strcpyW(&out[len - l - 3], S_MachoW);
+break;
+default:
+break;
+}
+
while ((*out = tolowerW(*out))) out++;
}
diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
index c0b86ba..79cadc0 100644
--- a/programs/winedbg/info.c
+++ b/programs/winedbg/info.c
@@ -244,16 +244,39 @@ void info_win32_module(DWORD64 base)
}
}
}
+else if (strstr(im.mi[i].ModuleName, ""))
+{
+dbg_printf("Mach-O\t");
+module_print_info(&im.mi[i], FALSE);
+/* print all modules embedded in this one */
+for (j = 0; j < im.num_used; j++)
+{
+if (!strstr(im.mi[j].ModuleName, "") &&
module_is_container(&im.mi[i], &im.mi[j]))
+{
+dbg_printf(" \\-PE\t");
+module_print_info(&im.mi[j], TRUE);
+}
+}
+}
else
{
/* check module is not embedded in another module */
for (j = 0; j < im.num_used; j++)
{
-if (strstr(im.mi[j].ModuleName, "") &&
module_is_container(&im.mi[j], &im.mi[i]))
+if ((strstr(im.mi[j].ModuleName, "") ||
strstr(im.mi[j].ModuleName, "")) &&
+module_is_container(&im.mi[j], &im.mi[i]))
break;
}
if (j < im.num_used) continue;
-if (strstr(im.mi[i].ModuleName, ".so") ||
strchr(im.mi[i].ModuleName, '<'))
+if (strstr(im.mi[i].ModuleName, ""))
+#ifdef __APPLE__
+dbg_printf("Mach-O\t");
+#else
+dbg_printf("ELF\t");
+#endif
+else if (strstr(im.mi[i].Mod
Re: Embedding a HWND window into an X11 window
On Thu, Aug 29, 2013 at 2:43 PM, André Hentschel wrote: > Am 29.08.2013 21:58, schrieb Erich E. Hoover: >> The "pipelight" guys put together a patch to support XEmbed: >> http://www.compholio.com/wine-compholio/download.php?file=0008-winex11-Add-minimal-XEmbed-client-support.patch >> >> That might do what he wants. > > might be interesting to clean/fix it up and try to get it upstream, no? I'm encouraging them to submit it for review, they're concerned that since it requires external applications to be conscious of Wine's behavior that Alexandre won't accept it. Best, Erich
Re: RFC: Mark dylib/mach-o on Mac OS X
On Aug 29, 2013, at 2:35 PM, André Hentschel wrote:
> Am 29.08.2013 19:52, schrieb André Hentschel:
>> Hi,
>> thank you both for the comments, i'll see what i can do.
>
> How about that?
Much better, but...
>
> diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
> index c0b86ba..0667ad7 100644
> --- a/programs/winedbg/info.c
> +++ b/programs/winedbg/info.c
> @@ -244,6 +244,11 @@ void info_win32_module(DWORD64 base)
> }
> }
> }
> +else if (strstr(im.mi[i].ModuleName, ""))
> +{
> +dbg_printf("Mach-O\t");
> +module_print_info(&im.mi[i], FALSE);
If there are any modules embedded in a Mach-O file (i.e. the PE DLLs embedded
in a Wine built-in DLL), this will no longer print them.
> +}
> else
> {
> /* check module is not embedded in another module */
Chip
Re: Embedding a HWND window into an X11 window
Am 29.08.2013 21:58, schrieb Erich E. Hoover: > The "pipelight" guys put together a patch to support XEmbed: > http://www.compholio.com/wine-compholio/download.php?file=0008-winex11-Add-minimal-XEmbed-client-support.patch > > That might do what he wants. might be interesting to clean/fix it up and try to get it upstream, no?
Re: RFC: Mark dylib/mach-o on Mac OS X
Am 29.08.2013 19:52, schrieb André Hentschel:
> Hi,
> thank you both for the comments, i'll see what i can do.
How about that?
diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c
index 6bea436..ed1d9c0 100644
--- a/dlls/dbghelp/module.c
+++ b/dlls/dbghelp/module.c
@@ -33,6 +33,7 @@
WINE_DEFAULT_DEBUG_CHANNEL(dbghelp);
const WCHARS_ElfW[] = {'<','e','l','f','>','\0'};
+const WCHARS_MachoW[] = {'<','m','a','c','h','-','o','>','\0'};
const WCHARS_WineLoaderW[] =
{'<','w','i','n','e','-','l','o','a','d','e','r','>','\0'};
static const WCHAR S_DotSoW[] = {'.','s','o','\0'};
static const WCHAR S_DotDylibW[]= {'.','d','y','l','i','b','\0'};
@@ -89,12 +90,19 @@ static void module_fill_module(const WCHAR* in, WCHAR* out,
size_t size)
out[len - l] = '\0';
else if (len > strlenW(loader) && !strcmpiW(out + len - strlenW(loader),
loader))
lstrcpynW(out, S_WineLoaderW, size);
-else
-{
-if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) &&
-(l = match_ext(out, len - 3)))
-strcpyW(&out[len - l - 3], S_ElfW);
-}
+else if (len > 3 && !strcmpiW(&out[len - 3], S_DotSoW) && (l =
match_ext(out, len - 3)))
+switch (module_get_type_by_name(out))
+{
+case DMT_ELF:
+strcpyW(&out[len - l - 3], S_ElfW);
+break;
+case DMT_MACHO:
+strcpyW(&out[len - l - 3], S_MachoW);
+break;
+default:
+break;
+}
+
while ((*out = tolowerW(*out))) out++;
}
diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
index c0b86ba..0667ad7 100644
--- a/programs/winedbg/info.c
+++ b/programs/winedbg/info.c
@@ -244,6 +244,11 @@ void info_win32_module(DWORD64 base)
}
}
}
+else if (strstr(im.mi[i].ModuleName, ""))
+{
+dbg_printf("Mach-O\t");
+module_print_info(&im.mi[i], FALSE);
+}
else
{
/* check module is not embedded in another module */
@@ -253,7 +258,15 @@ void info_win32_module(DWORD64 base)
break;
}
if (j < im.num_used) continue;
-if (strstr(im.mi[i].ModuleName, ".so") ||
strchr(im.mi[i].ModuleName, '<'))
+if (strstr(im.mi[i].ModuleName, ""))
+#ifdef __APPLE__
+dbg_printf("Mach-O\t");
+#else
+dbg_printf("ELF\t");
+#endif
+else if (strstr(im.mi[i].ModuleName, ".dylib") ||
strstr(im.mi[i].ModuleName, ""))
+dbg_printf("Mach-O\t");
+else if (strstr(im.mi[i].ModuleName, ".so") ||
strstr(im.mi[i].ModuleName, ""))
dbg_printf("ELF\t");
else
dbg_printf("PE\t");
diff --git a/programs/winedbg/symbol.c b/programs/winedbg/symbol.c
index 99b382d..b8092ae 100644
--- a/programs/winedbg/symbol.c
+++ b/programs/winedbg/symbol.c
@@ -779,6 +779,8 @@ static BOOL CALLBACK symbols_info_cb(PSYMBOL_INFO sym,
ULONG size, PVOID ctx)
size_t len = strlen(mi.ModuleName);
if (len > 5 && !strcmp(mi.ModuleName + len - 5, ""))
mi.ModuleName[len - 5] = '\0';
+else if (len > 8 && !strcmp(mi.ModuleName + len - 8, ""))
+mi.ModuleName[len - 8] = '\0';
}
dbg_printf("%08lx: %s!%s", (ULONG_PTR)sym->Address, mi.ModuleName,
sym->Name);
Re: Embedding a HWND window into an X11 window
The "pipelight" guys put together a patch to support XEmbed: http://www.compholio.com/wine-compholio/download.php?file=0008-winex11-Add-minimal-XEmbed-client-support.patch That might do what he wants. Best, Erich On Thu, Aug 29, 2013 at 1:33 PM, Vincent Povirk wrote: > The systray/notification area code has to do that: > http://source.winehq.org/source/dlls/winex11.drv/systray.c#L620 > > I don't think it can be done without modifying winex11.drv. > >
Re: Embedding a HWND window into an X11 window
The systray/notification area code has to do that: http://source.winehq.org/source/dlls/winex11.drv/systray.c#L620 I don't think it can be done without modifying winex11.drv.
Re: patch:kernel32
On Aug 29, 2013, at 8:15 AM, matyapiro31 wrote: > > <0001-kernel32-change-for-loop-to-optimize.patch><0002-kernel32-change-for-loop-to-optimize.patch> One patch per email, please. Also, the subject should be more descriptive. The first one doesn't look much better than the second one (which was already rejected). sizeof(array)/sizeof(array[0]) is a constant expression; any optimizing compiler worth its salt will optimize that for you. (And I would know, because I work on LLVM and Clang.) The first part of that patch (against dlls/kernel32/console.c) might be a bit more promising, though, since it hoists a computation that isn't constant at compile time but is constant for the duration of the loop; but again, any good optimizing compiler would be smart enough to do that, too. Oh, and you forgot to actually declare the variables that hold the hoisted values. Those assignments don't count, because: a) You never gave them a type. That's an error in any C compiler (C89, C99, etc.) I'm not even sure a K&R compiler would take that. b) Wine is written in C89 (with some GNU extensions scattered throughout, but generally we try to write portable code around here); that means (among other things) all variable declarations must come before other statements. Did you even try to compile Wine with these patches? Chip
Re: gdi32: Fixed Rectangle() rotation problem with GM_ADVANCED graphics mode.
Ralf Habacker writes: > see http://bugs.winehq.org/show_bug.cgi?id=34381 > --- > dlls/gdi32/painting.c | 18 -- > 1 Datei geändert, 16 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-) This would have to be done in the drivers. -- Alexandre Julliard julli...@winehq.org
Re: RFC: Mark dylib/mach-o on Mac OS X
Hi, thank you both for the comments, i'll see what i can do.
Re: [PATCH 2/2] ddraw/tests: Test WM_ACTIVATEAPP messages generated by SetCooperativeLevel
On 29 August 2013 11:14, Stefan Dösinger wrote: > +BOOL activateapp_received; > +IDirectDraw *activateapp_ddraw; > +HWND activateapp_window; > +DWORD activateapp_coop_level; > + I think those should be static, and you'll probably want to put them in a structure.
Re: my patch was wrong at dlls/kernel32/computernames.c
On Thu, Aug 29, 2013 at 11:31:06PM +0900, matyapiro31 wrote: > From > if ( isalnumW ( wc ) ) return wc; > for ( i = 0; i < 17; i++ ) > To > if ( isalnumW ( wc ) ) return wc; > for ( i = 0; i < 16; i++ ) > and the original version was wrong,too. > It counts the NULL of the end. Thats why you should use sizeof() or strlen() ... and not hardcoded magic values. CIao, Marcus
my patch was wrong at dlls/kernel32/computernames.c
From if ( isalnumW ( wc ) ) return wc; for ( i = 0; i < 17; i++ ) To if ( isalnumW ( wc ) ) return wc; for ( i = 0; i < 16; i++ ) and the original version was wrong,too. It counts the NULL of the end.
Re: patch:kernel32
On Thu, Aug 29, 2013 at 11:15 AM, matyapiro31 wrote: The patch could have a better subject =) > +unix_len=sizeof(unix_vars)/sizeof(unix_vars[0]; Missing the closing ) ? Will this compile? > -for ( i = 0; i < sizeof (special) / sizeof (WCHAR); i++ ) > +for ( i = 0; i < 17; i++ ) I guess the compiler does this for you. And for the other cases too. Also you should send only one patch per email. Regards, Bruno
Re: patch:try 2 of adding wine ja mannual
On Wed, 28 Aug 2013 20:29:43 +0900, �� wrote: > diff --git a/loader/Makefile.in b/loader/Makefile.in > index a7ab893..bc11378 100644 > --- a/loader/Makefile.in > +++ b/loader/Makefile.in > @@ -20,14 +20,16 @@ MANPAGE = wine.man > EXTRA_MANPAGES = \ > wine.de.man \ > wine.fr.man \ > - wine.pl.man > + wine.pl.man \ > +wine.ja.man The line was indented spaces, use tabs instead here, please. The list should be in alphabetical order, i.e. de, fr, ja, pl. > INSTALLDIRS = \ > $(DESTDIR)$(bindir) \ > $(DESTDIR)$(mandir)/man$(prog_manext) \ > $(DESTDIR)$(mandir)/de.UTF-8/man$(prog_manext) \ > $(DESTDIR)$(mandir)/fr.UTF-8/man$(prog_manext) \ > - $(DESTDIR)$(mandir)/pl.UTF-8/man$(prog_manext) > + $(DESTDIR)$(mandir)/pl.UTF-8/man$(prog_manext) \ > +$(DESTDIR)$(mandir)/ja/man$(prog_manext) Use tabs and insert the line between fr and pl, please. Why don't you use ja.UTF-8? > diff --git a/loader/wine.ja.man.in b/loader/wine.ja.man.in > new file mode 100644 > index 000..e2e1cba > --- /dev/null > +++ b/loader/wine.ja.man.in The document still looks like wine 1.4 age text. Some sentences deleted before 1.6 release, e.g. git url, still remain. Updated texts, e.g. DESCRIPTION section, aren't reflected in the translated one. Please refer the diff page [1] to figure out what was changed between wine-1.4 and wine-1.6. [1] http://source.winehq.org/git/wine.git/blobdiff/wine-1.4..wine-1.6:/loader/wine.man.in I noticed that you added Japanese specific section -- 文字化けについて -- to the man page. I'm not sure about this because other translators didn't do like this and it is difficult to keep up-to-date language specific information. Regards, Akihiro Sagawa
Re: wininet: Replacing a header with an empty value deletes it.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://newtestbot.winehq.org/JobDetails.pl?Key=1918 Your paranoid android. === w7pro64 (32 bit http) === http.c:4279: Test failed: HttpSendRequest failed: 12057 http.c:4284: Test failed: expected secure flag to be set === w7pro64 (64 bit http) === http.c:3445: Test failed: HttpQueryInfo failed 0
Re: [PATCH] iphlpapi: Add AllocateAndGetTcpExTableFromStack().
On 28.08.2013 12:54, Hans Leidekker wrote: On Wed, 2013-08-28 at 12:21 +0200, Ralf Habacker wrote: diff --git a/dlls/iphlpapi/iphlpapi.spec b/dlls/iphlpapi/iphlpapi.spec index 36ba13f..1eed5ae 100644 --- a/dlls/iphlpapi/iphlpapi.spec +++ b/dlls/iphlpapi/iphlpapi.spec @@ -6,6 +6,7 @@ @ stdcall AllocateAndGetIpForwardTableFromStack( ptr long long long ) @ stdcall AllocateAndGetIpNetTableFromStack( ptr long long long ) @ stdcall AllocateAndGetTcpTableFromStack( ptr long long long ) +@ stdcall AllocateAndGetTcpExTableFromStack( ptr long long long long ) AllocateAndGetTcpExTableFromStack sorts before AllocateAndGetTcpTableFromStack. sorted the entry below - sorry, updated patch diff --git a/dlls/iphlpapi/ipstats.h b/dlls/iphlpapi/ipstats.h index bf5bb92..efdb1cc 100644 --- a/dlls/iphlpapi/ipstats.h +++ b/dlls/iphlpapi/ipstats.h @@ -33,6 +33,7 @@ DWORD getInterfaceStatsByName(const char *name, PMIB_IFROW entry) DECLSPEC_HIDDEN; DWORD WINAPI AllocateAndGetUdpTableFromStack(PMIB_UDPTABLE *ppUdpTable, BOOL bOrder, HANDLE heap, DWORD flags) DECLSPEC_HIDDEN; +DWORD WINAPI AllocateAndGetTcpExTableFromStack(PVOID *ppTcpTable, BOOL bOrder, HANDLE heap, DWORD flags, DWORD family) DECLSPEC_HIDDEN; Again, you don't need this part. This is because it is used nowhere else yet ? Ralf
Embedding a HWND window into an X11 window
Hi, How could I embed a HWND window created with CreateWindow() into an X11 window? Thanks! :-) -- Alexandre Bique
Re: [4/4] ntdll: Properly set flag which indicates buffer empty state.
Am Donnerstag, 29. August 2013, 10:47:46 schrieb Dmitry Timoshkov: > Wolfgang Walter wrote: > > I think that happens: > > > > * application writes data to com port. > > * all is written, serial buffer is empty > > * application calls WaitCommEvent() > > * wait_on() is called > > * wait_on() calls get_irq_info() > > * get_irq_info() sets commio->irq_info->temt = 1 > > * wait_on() calls check_events() and uses sets commio->irq_info for old an > > new * so old->temt == new->temt and EV_TXEMPTY is not set > > * if there are no other events (in real world basically EV_RXCHAR): > > * wait_for_event() is startet with commio->irq_info->temt set to one > > * wait_for_event() calls get_irq_info() with new_irq_info() > > * get_irq_info() sets new_irq_info->temt = 1 because the buffer is still > > empty * wait_for_event() calls check_events() with new_irq_info and > > commio->irq_info * again check_events() will not set EV_TXEMPTY as both > > have temt == 1 > > > > It seems that we do not recover from that hang. > > > > Please correct me if I misread the code and I'm wrong. > > > > > > I think it's better if WaitCommEvent() returns with EV_TXEMPTY even if > > there > > has no new data been sent in between: > That means that WaitCommEvent(EV_TXEMPTY) without any prior WriteFile > would always return success and signal the EV_TXEMPTY event. My tests > show that WaitCommEvent(EV_TXEMPTY) fails with a timeout in this case. > Since the serial device is very slow it should be unlikely that after > successful WriteFile() with some data WaitCommEvent() sees an already > empty transmitter's output queue. Maybe for tests. But the application which fails here (with vanilla wine) hangs because it waits for EV_TXEMPTY. Basically it writes data to several serial ports, then write to files and then waits for the EV_TXEMPTYs. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts Abteilungsleiter IT Leopoldstraße 15 80802 München
Re: [1/2] server: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port. Take 2.
Dmitry Timoshkov wrote: > Based on a patch of Wolfgang Walter. Is there anything wrong with this patch? -- Dmitry.
