Re: ntdll: Store all 'comClass' attributes
On 8/26/2013 19:04, Alexandre Julliard wrote:
Nikolay Sivov writes:
+while (min <= max)
+{
+int n, c;
+
+n = (min+max)/2;
+
+c = strncmpW(olemisc_values[n].name, str, len);
strncmp isn't enough.
Right, thanks.
RE: Does auto-apt work to get wine dependencies in source code?
On Monday, 26 August 2013 5:20 AM, Maarten Lankhorst wrote: >Op 25-08-13 14:09, Susan Cragin schreef: >> Was thinking of running some tests but the list of dependencies on the >> website seems outdated, apt-get build-dep does not work. >Is that with the ubuntu-wine ppa enabled? The Wine PPA isn't required on Ubuntu or similar distros (e.g. Linux Mint). You just need to make sure that the source repositories (i.e. deb-src) are enabled in /etc/apt/sources.list or /etc/apt/sources.list.d/sources.list. (Ubuntu seems to do this automatically.) Once this is done, you can just enter 'sudo apt-get build-dep wine' in a terminal. Confusion may come from the Recommended Packages wiki page (http://wiki.winehq.org/Recommended_Packages). The command should be 'wine' not 'wine1.3' or 'wine1.4'. I'll get a patch for this later today.
Re: [PATCH 1/3] ws2_32: Implement SIO_ADDRESS_LIST_CHANGE with NotifyAddrChange (try 2).
On Mon, Aug 5, 2013 at 1:24 AM, Erich E. Hoover wrote: > The attached patch is the next step in the series of fixes for > Silverlight/PlayReady under Wine. This particular patch does not > impact Netflix, but it does impact a number of other PlayReady > streaming services (and a variety of non-streaming sites as well). > Sorry it's taken so long to get back to this, life has been busy > lately. > > With this patch the SIO_ADDRESS_LIST_CHANGE call gets passed on to > NotifyAddrChange, which effectively fixes a problem where Silverlight > apps can loop forever calling SIO_ADDRESS_LIST_CHANGE (Bug #32328). > Part 2 actually implements the NotifyAddrChange call on Linux, though > this patch is sufficient on its own to resolve the bug since the > overlapped IO event no longer gets triggered. > > This version of the patch has bee updated to include tests that show > that the notification is not tied to the socket. For example, > changing an interface that the socket is not bound to still results in > an overlapped notification. It's worth noting that these tests > require interactive mode and a PC with two network cards, so for my > testing I used an actual (non-VM) Windows 7 box with a wired and a > wireless card. Was this patch already reviewed? Is there anything else take can be done to get it commited? I tested it in 2 different environments (win7 eth+wifi and winxp eth+eht) and the tests work as expected. Regards, Bruno
Re: Does auto-apt work to get wine dependencies in source code?
>> Was thinking of running some tests but the list of dependencies on the website seems outdated, apt-get build-dep does not work.>Is that with the ubuntu-wine ppa enabled?There are two answers to that question, surprisingly. (1) bitboxIn the instructions it looks like the wine ppa repository can be installed the Debian way. But I did that and here's the result. E: You must put some 'source' URIs in your sources.listSo, I had to add the wine-ppa by manually adding to the sources.list.(2) non bitboxThis morning a new version of the i386 photo function was added, and now the depencencies install. Conclusion: This afternoon I was able to update all dependencies and compile without a problem using (with modifications above) the bitbox instructions. Compiled only. Did not install because I needed symlinks, but at least I know where I am and what I have to do. Susan
Re: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Am Montag, 26. August 2013, 19:55:04 schrieben Sie:
> Wolfgang Walter writes:
> > Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard:
> >> You probably don't want to fail just because there's no unix fd.
> >
> > What is the correct behaviour if there ist no such handle? Should I only
> > fail in the case FD_FILE_SERIAL ?
>
> You'd want to still try the server call, so that the server can
> implement a different behavior if needed.
So like this?
NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile, IO_STATUS_BLOCK*
IoStatusBlock )
{
NTSTATUS ret;
HANDLE hEvent = NULL;
enum server_fd_type type;
unsigned int options;
int needs_close;
int unix_handle;
ret = server_get_unix_fd( hFile, FILE_WRITE_DATA, &unix_handle,
&needs_close, &type, &options );
if (!ret && type == FD_TYPE_SERIAL) {
TRACE("tcdrain %p (%d ; %d)\n", hFile, unix_handle, needs_close);
while (tcdrain( unix_handle ) == -1) {
TRACE("tcdrain %p (%d ; %d) returned -1 (%d)\n", hFile,
unix_handle, needs_close, errno);
if (errno != EINTR) {
ret = FILE_GetNtStatus();
break;
}
}
TRACE("tcdrained %p (%d ; %d)\n", hFile, unix_handle, needs_close);
} else {
SERVER_START_REQ( flush_file )
{
req->handle = wine_server_obj_handle( hFile );
ret = wine_server_call( req );
hEvent = wine_server_ptr_handle( reply->event );
}
SERVER_END_REQ;
if (!ret && hEvent)
{
ret = NtWaitForSingleObject( hEvent, FALSE, NULL );
NtClose( hEvent );
}
}
if (needs_close) close( unix_handle );
return ret;
}
Regards,
Wolfgang Walter
P.S.:
The header of NtFlushBuffersFile says:
* RETURNS
* Success: 0. IoStatusBlock is updated.
* Failure: An NTSTATUS error code describing the error.
This was the reason I added
if (ret == STATUS_SUCCESS && IoStatusBlock) {
IoStatusBlock->u.Status = ret;
}
None of the applications we use seems to care, though.
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München
Re: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Wolfgang Walter writes: > Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard: >> >> You probably don't want to fail just because there's no unix fd. > > What is the correct behaviour if there ist no such handle? Should I only fail > in the case FD_FILE_SERIAL ? You'd want to still try the server call, so that the server can implement a different behavior if needed. -- Alexandre Julliard julli...@winehq.org
Re: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Am Montag, 26. August 2013, 17:13:46 schrieb Alexandre Julliard:
> Wolfgang Walter writes:
> > @@ -2749,19 +2752,46 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile,
> > IO_STATUS_BLOCK* IoStatusBlock>
> > {
> >
> > NTSTATUS ret;
> > HANDLE hEvent = NULL;
> >
> > -
> > -SERVER_START_REQ( flush_file )
> > -{
> > -req->handle = wine_server_obj_handle( hFile );
> > -ret = wine_server_call( req );
> > -hEvent = wine_server_ptr_handle( reply->event );
> > +enum server_fd_type type;
> > +unsigned int options;
> > +int needs_close;
> > +int unix_handle;
> > +
> > +ret = server_get_unix_fd( hFile, FILE_WRITE_DATA, &unix_handle,
> > + &needs_close, &type, &options );
> > +if (ret) return ret;
>
> You probably don't want to fail just because there's no unix fd.
What is the correct behaviour if there ist no such handle? Should I only fail
in the case FD_FILE_SERIAL ?
In this case
server_get_unix_fd()
and
if (needs_close) close( unix_handle );
could be moved there, too.
>
> > +if (ret == STATUS_SUCCESS && IoStatusBlock) {
> > +IoStatusBlock->u.Status = ret;
> >
> > }
>
> This is an unrelated change and should be a separate patch, with tests
> (also for failures cases),
Ok. I have to see how to write tests.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München
Re: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Wolfgang Walter writes:
> @@ -2749,19 +2752,46 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile,
> IO_STATUS_BLOCK* IoStatusBlock
> {
> NTSTATUS ret;
> HANDLE hEvent = NULL;
> -
> -SERVER_START_REQ( flush_file )
> -{
> -req->handle = wine_server_obj_handle( hFile );
> -ret = wine_server_call( req );
> -hEvent = wine_server_ptr_handle( reply->event );
> +enum server_fd_type type;
> +unsigned int options;
> +int needs_close;
> +int unix_handle;
> +
> +ret = server_get_unix_fd( hFile, FILE_WRITE_DATA, &unix_handle,
> + &needs_close, &type, &options );
> +if (ret) return ret;
You probably don't want to fail just because there's no unix fd.
> +if (ret == STATUS_SUCCESS && IoStatusBlock) {
> +IoStatusBlock->u.Status = ret;
> }
This is an unrelated change and should be a separate patch, with tests
(also for failures cases),
--
Alexandre Julliard
julli...@winehq.org
Re: ntdll: Store all 'comClass' attributes
Nikolay Sivov writes:
> +while (min <= max)
> +{
> +int n, c;
> +
> +n = (min+max)/2;
> +
> +c = strncmpW(olemisc_values[n].name, str, len);
strncmp isn't enough.
--
Alexandre Julliard
julli...@winehq.org
Re: questions to your commit "wineps.drv: Allow for vertical text printing!"
Hello Wolfgang, Thanks for the review. On 8/24/13 2:16 PM, Wolfgang Walter wrote: > Hello Aric, > > I read commit 745e7c93c9042f62460f181daaa1f05645560b41 (wineps.drv: Allow for > vertical text printing.) and I have some questions: > > > 1) You added the parameter vertical to PSDRV_WriteSetFont() in ps.c but it > remains unused. I think it isn't needed. > > > 2) In PSDRV_WriteSetDownloadFont() in download.c you call PSDRV_WriteSetFont() > with > > (lf.lfFaceName[0] == '@') > > for this new parameter vertical. I can't see why. > You are correct here. These are artifacts of the original way I was trying to solve this problem which I failed to revert when I change to creating the vertical runs and doing all the work in download.c. I will generate a patch to remove these. > > 3) You added the parameter vertical to get_download_name() in download.c > > You use it to add "_vertical" to its name if vertical is true. I can't see why > the font needs a different name. > > This will cause PSDRV_WriteSetDownloadFont() to download a font which is used > vertically and horizontally twice. I can't see any reason why this could be > necessary. > This unfortunately is necessary because the escapement is different between the normal and vertical variations of the font. The only way I found for a font to be able to be both horizontal and vertical in a document is to download the font twice, once with each escapement. -aric
Re: [PATCH 2/7] wined3d: Use PBOs for dynamic volumes (try 2)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-08-26 16:16, schrieb Matteo Bruni:
> 2013/8/26 Stefan Dösinger :
>> Try 2: *) Require only GPU access for buffers *) Reduce number of
>> checkGLcall invocations *) Remove a return from an ERR case ---
>> dlls/wined3d/utils.c | 1 + dlls/wined3d/volume.c
>> | 168 -
>> dlls/wined3d/wined3d_private.h | 7 +- 3 files changed, 157
>> insertions(+), 19 deletions(-)
>>
>
>> +case WINED3D_LOCATION_BUFFER: +if
>> (!volume->pbo || !(volume->flags & WINED3D_VFLAG_PBO)) +
>> ERR("Trying to load WINED3D_LOCATION_BUFFER without setting it up
>> first.\n"); + +if (volume->locations &
>> WINED3D_LOCATION_DISCARDED) +{ +
>> TRACE("Volume previously discarded, nothing to do.\n"); +
>> wined3d_volume_invalidate_location(volume,
>> WINED3D_LOCATION_DISCARDED); +} +else if
>> (volume->locations & WINED3D_LOCATION_TEXTURE_RGB) +
>> { +struct wined3d_bo_address data = {volume->pbo,
>> NULL}; +volume_bind_and_dirtify(volume,
>> context); +wined3d_volume_download_data(volume,
>> context, &data); +} +else +{
>> +FIXME("Implement WINED3D_LOCATION_SYSMEM loading
>> from %s.\n", +
>> wined3d_debug_location(volume->locations)); +
>> return; +} +
>> wined3d_volume_validate_location(volume,
>> WINED3D_LOCATION_BUFFER); +break; +
>
> Not really an actual review, but that FIXME looks wrong
> (copy-paste remnant probably).
Right, good catch.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSG4LPAAoJEN0/YqbEcdMwGAwP/iqKhyveAbNI99/ZIGAIqrEj
qIcDBaeOLm6Y/17lW2VV6WqU/puRragzyN6IgAA2ikE5F68avBoYAIDuX2EOPsdm
Szy8ssm814aSULRGomzKv1ABWi0dtBU+SqoDj0o5e3k5JHM+R+3A3DglvdWfXfav
pKdi6nPuKEwJ5KM/lEdeAT6iNSjbtXlF/6FWw2DNwgQf8Tm7wbiQp5CqCN+9ZYtB
X3/uvbsGoBLgH/XGeB7P2CM5WL3hldCqjpAbW7HI9Tveg6iIvv4SR3fraMIfBmKs
CCIbLbuWOCFaKfTJFD5mVowdREOJgPLbL08UCYCPiMtaFY0wGDZinAsTBOYMJBLH
np9PyaftGJQ1uoSizk+7bIHMOOvtN+pBi+hwVqM2/wwXgb+lD8NUwmivMcjHpaH1
ofUZ6ZepFWP1mOEV5Lsr4ioAteSbcq8ExAziXfSyFQQp2WR6vZhKZXI3CWvEC5Z0
LiY1Bmr5M5shTwAn7RB3uGNTPU5G0qHN7Buz3fmycJGTPNwAfTzh9GRdEu9OdP9H
QZ1D90S68BgNXWpiShyjsCnWfEq21JV98058OOaELQMrRNcMFizitBup1t4KkO7J
Qj9KDgUcQ0czeuze422OPjfODJINeDpebtr21RNFO3v8+9+JJO4xYAToN3tq6HGW
04W0HIj+a22vGYBiY+pQ
=JWIJ
-END PGP SIGNATURE-
Re: [PATCH 2/7] wined3d: Use PBOs for dynamic volumes (try 2)
2013/8/26 Stefan Dösinger :
> Try 2:
> *) Require only GPU access for buffers
> *) Reduce number of checkGLcall invocations
> *) Remove a return from an ERR case
> ---
> dlls/wined3d/utils.c | 1 +
> dlls/wined3d/volume.c | 168
> -
> dlls/wined3d/wined3d_private.h | 7 +-
> 3 files changed, 157 insertions(+), 19 deletions(-)
>
> +case WINED3D_LOCATION_BUFFER:
> +if (!volume->pbo || !(volume->flags & WINED3D_VFLAG_PBO))
> +ERR("Trying to load WINED3D_LOCATION_BUFFER without setting
> it up first.\n");
> +
> +if (volume->locations & WINED3D_LOCATION_DISCARDED)
> +{
> +TRACE("Volume previously discarded, nothing to do.\n");
> +wined3d_volume_invalidate_location(volume,
> WINED3D_LOCATION_DISCARDED);
> +}
> +else if (volume->locations & WINED3D_LOCATION_TEXTURE_RGB)
> +{
> +struct wined3d_bo_address data = {volume->pbo, NULL};
> +volume_bind_and_dirtify(volume, context);
> +wined3d_volume_download_data(volume, context, &data);
> +}
> +else
> +{
> +FIXME("Implement WINED3D_LOCATION_SYSMEM loading from %s.\n",
> +wined3d_debug_location(volume->locations));
> +return;
> +}
> +wined3d_volume_validate_location(volume,
> WINED3D_LOCATION_BUFFER);
> +break;
> +
Not really an actual review, but that FIXME looks wrong (copy-paste
remnant probably).
Re: [patch fix]for 98152 and 98151,the encoding type was wrong.
On Sun, 25 Aug 2013 23:13:53 +0900, matyapiro31 wrote: > The first one is > 0001-add-japanese-man-page-of-wine.patch > the second one is > 0001-last-change-of-my-translation-of-man-page.patch > Please cancel 98152 and 98151and try those two. These translations are outdated. The file seems to be based on wine 1.4 release. Makefile.in has a lot of formatting errors. You'd also refine it before resubmitting. Regards, Akihiro Sagawa
Re: Does auto-apt work to get wine dependencies in source code?
Op 25-08-13 14:09, Susan Cragin schreef: > Hello, > Was thinking of running some tests but the list of dependencies on the > website seems outdated, apt-get build-dep does not work. Is that with the ubuntu-wine ppa enabled?
Re: [2/3] server: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> It's a blocking call, you can't do that on the server side. > > Can then something like in the patch from Wolfgang Walter be done > instead? Something like that, yes. -- Alexandre Julliard julli...@winehq.org
Re: [2/3] server: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Alexandre Julliard wrote: > It's a blocking call, you can't do that on the server side. Can then something like in the patch from Wolfgang Walter be done instead? -- Dmitry.
Re: [2/3] server: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Hello Dmitry,
we had this problem, too. I sent a patch to wine-devel some time ago (I think
2008). It had the same flaw as yours. I sent a different patch after Alexandre
gave me the same answer. I then posted 2009 an different one. It did not make
it into wine, though. I don't know why as there was no answer. Therefor I keep
it since then in our own repository together with other serial fixes (i.e. to
make most USB serial adapters working better).
Attached the patch (rebased on 1.6). We use it rebased on then the actual wine
versions sincd 2009 and it works for us.
Am Montag, 26. August 2013, 10:56:29 schrieb Alexandre Julliard:
> Dmitry Timoshkov writes:
> > MSDN for FlushFileBuffers says:
> > Flushes the buffers of a specified file and causes all buffered data to be
> > written to a file.
> >
> > Linux man page says:
> > tcdrain() waits until all output written to the object referred to by fd
> > has been transmitted.
>
> It's a blocking call, you can't do that on the server side.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München>From 2428481c2f68df5149ac3b0383579aa323246a19 Mon Sep 17 00:00:00 2001
From: Wolfgang Walter
Date: Tue, 20 Jan 2009 17:52:38 +0100
Subject: [PATCH] serial_flush() implements FlushFileBuffers incorrectly
FlushFileBuffers should write out any data not yet transmitted but
serial_flush() instead discards any data not yet transmitted
This is because it uses tcflush() instead of tcdrain().
Call tcdrain for serial handles directly from NtFlushBuffersFile()
(as it may block) and remove serial_flush() from server/serial.c
---
dlls/ntdll/file.c | 52 +---
server/serial.c | 11 +--
2 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c
index 5147ef5..928095c 100644
--- a/dlls/ntdll/file.c
+++ b/dlls/ntdll/file.c
@@ -66,6 +66,9 @@
#ifdef HAVE_SYS_STATFS_H
# include
#endif
+#ifdef HAVE_TERMIOS_H
+#include
+#endif
#ifdef HAVE_VALGRIND_MEMCHECK_H
# include
#endif
@@ -2749,19 +2752,46 @@ NTSTATUS WINAPI NtFlushBuffersFile( HANDLE hFile, IO_STATUS_BLOCK* IoStatusBlock
{
NTSTATUS ret;
HANDLE hEvent = NULL;
-
-SERVER_START_REQ( flush_file )
-{
-req->handle = wine_server_obj_handle( hFile );
-ret = wine_server_call( req );
-hEvent = wine_server_ptr_handle( reply->event );
+enum server_fd_type type;
+unsigned int options;
+int needs_close;
+int unix_handle;
+
+ret = server_get_unix_fd( hFile, FILE_WRITE_DATA, &unix_handle,
+ &needs_close, &type, &options );
+if (ret) return ret;
+
+TRACE("flush %p (type %d)\n", hFile, type);
+if (type == FD_TYPE_SERIAL) {
+TRACE("tcdrain %p (%d ; %d)\n", hFile, unix_handle, needs_close);
+while (tcdrain( unix_handle ) == -1) {
+TRACE("tcdrain %p (%d ; %d) returned -1 (%d)\n", hFile, unix_handle, needs_close, errno);
+if (errno != EINTR) {
+ret = FILE_GetNtStatus();
+break;
+}
+}
+TRACE("tcdrained %p (%d ; %d)\n", hFile, unix_handle, needs_close);
+} else {
+SERVER_START_REQ( flush_file )
+{
+req->handle = wine_server_obj_handle( hFile );
+ret = wine_server_call( req );
+hEvent = wine_server_ptr_handle( reply->event );
+}
+SERVER_END_REQ;
+if (!ret && hEvent)
+{
+ret = NtWaitForSingleObject( hEvent, FALSE, NULL );
+NtClose( hEvent );
+}
}
-SERVER_END_REQ;
-if (!ret && hEvent)
-{
-ret = NtWaitForSingleObject( hEvent, FALSE, NULL );
-NtClose( hEvent );
+
+if (ret == STATUS_SUCCESS && IoStatusBlock) {
+IoStatusBlock->u.Status = ret;
}
+if (needs_close) close( unix_handle );
+TRACE("flushed %p (type %d) ret=%08x\n", hFile, type, ret);
return ret;
}
diff --git a/server/serial.c b/server/serial.c
index 587fee1..aac20fa 100644
--- a/server/serial.c
+++ b/server/serial.c
@@ -61,7 +61,6 @@ static struct fd *serial_get_fd( struct object *obj );
static void serial_destroy(struct object *obj);
static enum server_fd_type serial_get_fd_type( struct fd *fd );
-static void serial_flush( struct fd *fd, struct event **event );
static void serial_queue_async( struct fd *fd, const async_data_t *data, int type, int count );
struct serial
@@ -107,7 +106,7 @@ static const struct fd_ops serial_fd_ops =
{
default_fd_get_poll_events, /* get_poll_events */
default_poll_event, /* poll_event */
-serial_flush, /* flush */
+no_flush, /* flush */
serial_get_fd_type, /* get_fd_type */
default_fd_ioctl, /* ioctl */
serial_queue_async, /* queue_async */
@@ -196,14 +195,6 @@ static
Re: [2/3] server: Use tcdrain() instead of tcflush() to implement FlushFileBuffers() for a COM port.
Dmitry Timoshkov writes: > MSDN for FlushFileBuffers says: > Flushes the buffers of a specified file and causes all buffered data to be > written to a file. > > Linux man page says: > tcdrain() waits until all output written to the object referred to by fd has > been transmitted. It's a blocking call, you can't do that on the server side. -- Alexandre Julliard julli...@winehq.org
