Am Sonntag, 8. September 2013, 11:32:26 schrieb Francois Gouget:
> On Thu, 5 Sep 2013, Wolfgang Walter wrote:
> [...]
>
> > To see that my later patches are needed you must modify the test a little
> > bit:
> >
> > - dlls/kernel32/tests/comm.c.old 20
effect that this test makes the next test fail which tests
the EV_TXEMPTY handling even if that it would work perfectly.
So:
test A
test B
test A fails on wine and this influences test B in such a way that it will
always fail, too.
I remove this dependency.
Now test B succeeds. This is not
Am Donnerstag, 5. September 2013, 23:32:00 schrieben Sie:
> Wolfgang Walter wrote:
> > > > > > With my patches 1/2 and 2/2 I get:
> > > > > >
> > > > > > fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped
> > > > &
Am Donnerstag, 5. September 2013, 21:12:37 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > > Does 'make test' pass without failures for you?
> >
> > Without patch 1/2 and 2/2 I get for
> >
> > $ ../../../tools/runtest -P wine -M kernel32.
Am Donnerstag, 5. September 2013, 19:40:13 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > This is not a work around.
> >
> > todo_wine will not magically undo sending the bytes.
> > Please explain why you think that there will be now pending
> > bytes in
Am Donnerstag, 5. September 2013, 18:55:55 schrieben Sie:
> Wolfgang Walter wrote:
> > > > > > +if (res || (!res && GetLastError() == ERROR_IO_PENDING))
> > > > > > +/* if data has been sent: wait for termination */
> > > > &g
Am Donnerstag, 5. September 2013, 18:31:45 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > > WaitCommEvent always returns FALSE when device is opened in overlapped
> > > mode.>
> > Not according to MSN documentation of WaitCommEvent():
> >
> &
Am Donnerstag, 5. September 2013, 17:54:58 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > > > +if (res || (!res && GetLastError() == ERROR_IO_PENDING))
> > > > +/* if data has been sent: wait for termination */
> > > > +
Am Donnerstag, 5. September 2013, 17:52:42 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > On Thursday 05 September 2013 10:42:40 you wrote:
> > > Wolfgang Walter wrote:
> > > > -ok(!res && GetLastError() == ERROR_IO_PENDING, "%d:
&
Am Donnerstag, 5. September 2013, 17:51:18 schrieb Dmitry Timoshkov:
> Wolfgang Walter wrote:
> > > > When we send 17 bytes with 150 baud, no parity, one stop bit then
> > > > we need to wait at least 17*10/150 seconds > 1000 ms
> > >
> > > Unde
On Thursday 05 September 2013 10:37:22 you wrote:
> Wolfgang Walter wrote:
> > +if (res || (!res && GetLastError() == ERROR_IO_PENDING))
> > +/* if data has been sent: wait for termination */
> > +Sleep(timeout);
>
> I don't see such
On Thursday 05 September 2013 10:42:40 you wrote:
> Wolfgang Walter wrote:
> > -ok(!res && GetLastError() == ERROR_IO_PENDING, "%d: WaitCommEvent
> > error %d\n", i, GetLastError()); +ok(res || (!res &&
> > GetLastError() == ERROR
On Thursday 05 September 2013 10:32:15 Dmitry Timoshkov wrote:
> Wolfgang Walter wrote:
> > When we send 17 bytes with 150 baud, no parity, one stop bit then
> > we need to wait at least 17*10/150 seconds > 1000 ms
>
> Under Windows with both real COM-port and USB-seri
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()
> &
hat WriteFile
> failure is definitely not caused by this patch. Does running the test
> several times cause the same failures? In any case it would be interesting
> to see the +comm log with "ntdll: Add a trace for transmitter's buffer
> empty flag." applied.
>
> And current lo
ys sets the flag to a not zero value if ioctl(TIOCOUTQ) succeeds.
Yes, but this should be no problem for the test.
If you only have TIOCOUTQ it is very difficult to do otherwise. You would have
to monitor any write to the serial port by any thread.
The applications I know write something and then wait, so the imperfect
emulation we have now is enough.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Recht
Abteilungsleiter IT
Leopoldstraße 15
80802 München
mm.ok] Error 5
I think TIMEOUT (1s) in kernel32/tests/comm.c is too short and the test for <
900, too.
Here it tooks often 1100 milliseconds and more (with vanilla 1.6). And I
checked the actual git-tree: the test fails here, too (but not always).
Regards,
--
Wolfgang Walter
Studentenw
Am Dienstag, 27. August 2013, 22:00:59 schrieben Sie:
> Wolfgang Walter wrote:
> > > Wolfgang Walter wrote:
> > > > I made similar changes so that several applications we use work. I
> > > > tested
> > > > your patches, all but one do wor
Hello,
I made similar changes so that several applications we use work. I tested your
patches, all but one do work. I don't know why one does not, though.
I attached my patch, maybe it is usefull to you.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen R
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 behavio
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>
> > {
> >
> > NTSTATU
rain() 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
back
and of course the callers, too (in builtin.c and download.c)
* get_download_name() should also be changed back
(and its call in PSDRV_WriteSetDownloadFont())
Regards,
--
Wolfgang Walter
Studentenwerk München
e4cfeee3adcb0fe2c0502909c87b2740a8de08e5
00851b246b095bdf4cafd3e6f9965c811d1c87a4 M dlls
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Abteilungsleiter IT
Leopoldstraße 15
80802 München
Am Donnerstag, 28. Juli 2011 schrieb Huw Davies:
> On Thu, Jul 28, 2011 at 04:14:56PM +0200, Wolfgang Walter wrote:
> > I think that
> >
> > bitmapinfo_from_user_bitmapinfo()
> >
> > is the real culprit. I think colors gets to big (> 256) and t
Am Mittwoch, 27. Juli 2011 schrieben Sie:
> On Wed, Jul 27, 2011 at 6:44 PM, Wolfgang Walter wrote:
> > - char src_bmibuf[FIELD_OFFSET( BITMAPINFO, bmiColors[256] )];
> > - BITMAPINFO *src_info = (BITMAPINFO *)src_bmibuf;
> > - char dst_bmibuf[FIELD_OFFSET( BITM
of the old one is
still displayed.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Am Dienstag, 19. April 2011 schrieb Alexandre Julliard:
> Wolfgang Walter writes:
> > So this is my theorie:
> >
> > * wait_on() is called.
> >
> > * wait_on() calls RtlQueueWorkItem(wait_for_event, commio, 0 /* FIXME */)
> > and returns with STATUS_PEND
Am Dienstag, 19. April 2011 schrieb Alexandre Julliard:
> Wolfgang Walter writes:
> > set status field of piosb to STATUS_PENDING before calling wait_on(). If
> > wait_on returns with STATUS_PENDING don't touch piosb.
> >
> > Reason: if wait_on returns with ST
mp;& nOutBufferSize == sizeof(DWORD))
{
piosb->u.Status = STATUS_PENDING;
piosb->Information = sz;
if (!(status = wait_on(hDevice, fd, hEvent, piosb, lpOutBuffer)))
sz = sizeof(DWORD);
else if (status == STATUS_PEND
Am Mittwoch, 3. Juni 2009 schrieben Sie:
> 2009/6/3 Wolfgang Walter :
> > I posted the patch on wine-patches. But nobody commented on it so I don't
> > know if it is ok or not. As we need it for several applications we use I
> > have a version for newer wine versions. I
h serial devices not supporting TIOCGICOUNT
(Most drivers of usb2serial adapters do not support TIOCGICOUNT, nor do pseudo
terminals)
Fix for 3) could be separated from 1) und 2) but I can't test 1) and 2)
without 3).
Regards
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Re
On Monday 22 December 2008, Alexandre Julliard wrote:
> Wolfgang Walter writes:
>
> > @@ -201,7 +202,17 @@ static void serial_flush( struct fd *fd, struct event
> > **event )
> > /* MSDN says: If hFile is a handle to a communications device,
> > *
m). I tested it on a wide range of kyocera printer models and
two hp models. Of course I tested it with ghostscript.
I would appreciate any comments and ideas.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leiter EDV
Leopoldstraße 15
80802 München
Am Dienstag, 16. Dezember 2008 11:51 schrieb Kai Blin:
> On Tuesday 16 December 2008 11:42:55 Wolfgang Walter wrote:
> > I have not received any comment yet.
>
> That's probably because not too many people know much about this. Detlef
> Riekenberg is probably the person who
comment yet.
Regards,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leiter EDV
Leopoldstraße 15
80802 München
as OpenOffice don't do either.
The following patch changes wineps.drv such that it uses show (for downloaded
truetype fonts). It still contains code which inserts postscript comments in
its output for debugging purpose. It's meant for discussion.
Regards,
Wolfgang Walter
--
Wolfg
37 matches
Mail list logo
