Nikolay Sivov wrote:
> +FreeLibrary(mod);
Please add the tests for FreeLibrary return value.
--
Dmitry.
Alistair Leslie-Hughes wrote:
> +static HRESULT WINAPI metahostpolicy_QueryInterface(ICLRMetaHostPolicy
> *iface, REFIID riid, void **ppvObject)
> +{
> +TRACE("%s %p\n", debugstr_guid(riid), ppvObject);
> +
> +if ( IsEqualGUID( riid, &IID_ICLRMetaHostPolicy ) ||
> + IsEqualGUID(
Henri Verbeet wrote:
> +static HRESULT WINAPI
> IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface,
> REFIID riid, void **out)
> {
> -TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), ret_iface);
> +TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(rii
Dmitry Timoshkov wrote:
> diff --git a/server/file.c b/server/file.c
> index 2ecf97c..94d3060 100644
> --- a/server/file.c
> +++ b/server/file.c
> @@ -459,7 +459,7 @@ static mode_t file_access_to_mode( unsigned int access )
>
> access = generic_file_map_access( access
Alexandre Julliard wrote:
> > Do you propose to leave NtWriteFile/NtReadFile in the state when they
> > return STATUS_SUCCESS for overlapped writes and reads? But that's clearly
> > not how Windows implements this accordingto the tests, and that would
> > require changing all the tests to accept
Alexandre Julliard wrote:
> >> I don't see the point. Do you actually have an app that depends on this?
> >
> > When I started to work on this I had an app that has one of the reasons to
> > require running under Vista+ was the difference in overlapped IO behavior.
> > On the other hand the tests
Alexandre Julliard wrote:
> I don't see the point. Do you actually have an app that depends on this?
When I started to work on this I had an app that has one of the reasons to
require running under Vista+ was the difference in overlapped IO behavior.
On the other hand the tests clearly show that
Francois Gouget wrote:
> > > > This VM is broken,
> > >
> > > How so? That is: what should I do to fix it?
> >
> > Investigate, find the source of failures and fix it? Note, that all
> > other VMs pass this test just fine, moreover, this same w7pro64 VM
> > doesn't always fail.
>
> You obvious
Francois Gouget wrote:
> > > === w7pro64 (32 bit comm) ===
> > > comm.c:863: Test failed: WaitCommEvent failed with a timeout
> > > comm.c:875: recovering after WAIT_TIMEOUT...
> > > comm.c:886: Test failed: WaitCommEvent error 0
> > > comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY,
Dmitry Timoshkov wrote:
> Marvin wrote:
>
> > === w7pro64 (32 bit comm) ===
> > comm.c:863: Test failed: WaitCommEvent failed with a timeout
> > comm.c:875: recovering after WAIT_TIMEOUT...
> > comm.c:886: Test failed: WaitCommEvent error 0
> > comm.c:888:
Marvin wrote:
> === w7pro64 (32 bit comm) ===
> comm.c:863: Test failed: WaitCommEvent failed with a timeout
> comm.c:875: recovering after WAIT_TIMEOUT...
> comm.c:886: Test failed: WaitCommEvent error 0
> comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0
> comm.c:892: WaitCommE
Thomas Faber wrote:
> I noticed a couple of tests structured like this:
>
> status = pNtWriteFile(hfile, 0, NULL, NULL, &iob, contents,
> sizeof(contents), &offset, NULL);
> ok(status == STATUS_PENDING || broken(status == STATUS_SUCCESS) /* see
> below */, "expected STATUS_PENDING, got %#x\n", s
Nikolay Sivov wrote:
> > --- a/dlls/ntdll/tests/file.c
> > +++ b/dlls/ntdll/tests/file.c
> > @@ -1985,6 +1985,22 @@ static void test_read_write(void)
> >
> > bytes = 0xdeadbeef;
> > SetLastError(0xdeadbeef);
> > +ret = ReadFile(INVALID_HANDLE_VALUE, buf, 0,&bytes, NULL);
> > +todo
Vincent Povirk wrote:
> Maybe the format for 32-bit bitmaps should be determined by the alpha
> channel options?
Probably, but as the patch comment says the code is based on gdiplus
implementation, and there is no such an option flag in the corresponding
gdiplus API params. I'd suggest to accept
Francois Gouget wrote:
> That tree was a bit out of date causing the patch to fail to apply. I
> updated it and rediffed.
I'd appreciate if you could postpone sending this sort of patches
when they could conflict with other pending patches in that area.
Thanks.
--
Dmitry.
Nikolay Sivov wrote:
> >> It looks like it belongs to kernel32/tests.
> > Since actual access checks are done by ntdll APIs I believe that ntdll/tests
> > is appropriate place, kernel32 file APIs are just wrappers around the tested
> > functionality.
> >
> It doesn't matter what it uses internall
Nikolay Sivov wrote:
> It looks like it belongs to kernel32/tests.
Since actual access checks are done by ntdll APIs I believe that ntdll/tests
is appropriate place, kernel32 file APIs are just wrappers around the tested
functionality.
--
Dmitry.
Ken Thomases wrote:
> >> +@ cdecl __wine_get_min_max_info(long ptr ptr ptr ptr) WINPOS_GetMinMaxInfo
> >
> > What's wrong with calling SendMessage(WM_GETMINMAXINFO) from the driver?
>
> Because I would have to duplicate all of the rest of the logic in
> WINPOS_GetMinMaxInfo(), too.
Do you rea
Alexandre Julliard wrote:
> > This matches WriteFile behaviour and ensures that invalid parameters are
> > properly handled and fields in the OVERLAPPED structure are initialized.
>
> This is again causing test failures. Please do a full test run before
> sending patches.
Could you please list
Marvin wrote:
> === wxppro (32 bit comm) ===
> comm.c:863: Test failed: WaitCommEvent failed with a timeout
> comm.c:875: recovering after WAIT_TIMEOUT...
> comm.c:886: Test failed: WaitCommEvent error 0
> comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0
> comm.c:892: WaitCommEv
Ken Thomases wrote:
> +@ cdecl __wine_get_min_max_info(long ptr ptr ptr ptr) WINPOS_GetMinMaxInfo
What's wrong with calling SendMessage(WM_GETMINMAXINFO) from the driver?
--
Dmitry.
Wolfgang Walter wrote:
> -if (commio->iosb) commio->iosb->u.Status = *commio->events ?
> STATUS_SUCCESS : STATUS_CANCELLED;
> +if (commio->iosb) {
> +commio->iosb->u.Status = *commio->events ? STATUS_SUCCESS :
> STATUS_CANCELLED;
> +if (*commio->events)
> +co
Alexandre Julliard wrote:
> Why do you need that? It doesn't look to me like an improvement.
IMO it simplifies the code and avoids using two different code paths
for normal files.
--
Dmitry.
Alexandre Julliard wrote:
> > +if (offset && offset->QuadPart == (LONGLONG)-1 /*
> > FILE_WRITE_TO_END_OF_FILE */)
> > +offset->QuadPart = lseek( unix_handle, 0, SEEK_END );
> > +
>
> This looks very wrong, offset belongs to the caller.
Of course you are correct, thanks.
-
Jonas Maebe wrote:
> > The tests must pass under Wine without any additional "fixes" as they do
> > currently under Windows. If you add some code to the tests which suddenly
> > makes them pass under Wine - that's not a fix, Wine implementation should
> > be fixed instead.
>
> What I understood
Wolfgang Walter wrote:
> > > > No, the source of the failures is still there.
> > >
> > > What do you mean with that? The tests indeed do succeed now and there is a
> > > reason they do: when you call WaitCommEvent() while the tx buffer is not
> > > empty
> > > yet the wine code will detect tha
Wolfgang Walter wrote:
> > > With my patches 1/2 and 2/2 I get:
> > >
> > > fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped 0x10ee8ec):
> > > stub wine: configuration in '/home/walterw/.wine' has been updated.
> > > fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented s
Wolfgang Walter wrote:
> > > > > With my patches 1/2 and 2/2 I get:
> > > > >
> > > > > fixme:iphlpapi:NotifyAddrChange (Handle 0x10ee8e0, overlapped
> > > > > 0x10ee8ec):
> > > > > stub wine: configuration in '/home/walterw/.wine' has been updated.
> > > > > fixme:comm:set_queue_size insize 102
Bruno Jesus <00cp...@gmail.com> wrote:
> +INT validprotocols[] = { WS_IPPROTO_TCP,
> + WS_IPPROTO_UDP,
> + NSPROTO_IPX,
> + NSPROTO_SPX,
> + NSPROTO_SPXII,
> + 0 };
This should
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.dll -T ../../.. -q -p
> kernel32_test.exe.so comm.c
>
> fixme:comm:set_queue_size insize 1024 outsize 1024 unimplemented stub
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 the tx buffer if the tests fails.
>
> And why it does not make the next tests fail even if wine would
> behave co
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 a problem with real COM-port and serial-USB cable
> > > > under
Wolfgang Walter wrote:
> > > > WaitCommEvent always returns FALSE when device is opened in overlapped
> > > > mode.>
> > > Not according to MSN documentation of WaitCommEvent():
> > >
> > > "If the overlapped operation cannot be completed immediately, the function
> > > returns FALSE and the Ge
Wolfgang Walter wrote:
> > WaitCommEvent always returns FALSE when device is opened in overlapped mode.
>
> Not according to MSN documentation of WaitCommEvent():
>
> "If the overlapped operation cannot be completed immediately, the function
> returns FALSE and the GetLastError function return
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 a problem with real COM-port and serial-USB cable
> > under Windows or Linux here an
Wolfgang Walter wrote:
> 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_IO_PENDING), "%d
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-serial cable this test takes
> > no longer than 890 ms, usually it's even shorter like 8
Wolfgang Walter wrote:
> -ok(!res && GetLastError() == ERROR_IO_PENDING, "%d: WaitCommEvent
> error %d\n", i, GetLastError());
> +ok(res || (!res && GetLastError() == ERROR_IO_PENDING), "%d:
> WaitCommEvent error %d\n", i, GetLastError());
This change looks spurious and unrelat
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 a problem with real COM-port and serial-USB cable
under Windows or Linux here and under testbot VMs.
--
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-serial cable this test takes
no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs
a
Austin English wrote:
> Anastasius mentioned at
> http://bugs.winehq.org/show_bug.cgi?id=32673#c6 that a keyword for
> bugs that are caused by applications using broken/deprecated behavior
> might be useful. I'm in favor of it, but wanted some more opinions
> (and potentially a better naming sche
Marvin wrote:
> === w7pro64 (32 bit comm) ===
> comm.c:850: Test failed: WaitCommEvent failed with a timeout
> comm.c:862: recovering after WAIT_TIMEOUT...
> comm.c:874: Test failed: WaitCommEvent error 0
> comm.c:876: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0
> comm.c:880: WaitCommE
Alexandre Julliard wrote:
> >> > Printing complete lsr value in the log may help with diagnosing
> >> > test failures on Alexandre's machine.
> >>
> >> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
> >> actually have a driver that returns other status?
> >
> > I don't, but
Alexandre Julliard wrote:
> > Printing complete lsr value in the log may help with diagnosing
> > test failures on Alexandre's machine.
>
> I don't see how, since TIOCSER_TEMT is the only defined bit. Do you
> actually have a driver that returns other status?
I don't, but maybe yours does. The
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.
Dmitry Timoshkov wrote:
> Based on a patch of Wolfgang Walter.
Is there anything wrong with this patch?
--
Dmitry.
Dmitry Timoshkov wrote:
> 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
> > * w
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()
Alexandre Julliard wrote:
> >> I assume it's a real hardware and not a VM? Is this with a real COM port,
> >> or USB-serial cable? If the latter one what driver is it using?
> >
> > Looking at the failure messages above once again, I can say that WriteFile
> > failure is definitely not caused by
Dmitry Timoshkov wrote:
> Alexandre Julliard wrote:
>
> > It doesn't work here:
> >
> > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
> > kernel32_test.exe.so comm.c && touch comm.ok
> > comm.c:835: Test failed: WriteFile t
Alexandre Julliard wrote:
> It doesn't work here:
>
> ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
> kernel32_test.exe.so comm.c && touch comm.ok
> comm.c:835: Test failed: WriteFile took 1 ms to write 17 Bytes at 150 Baud
> comm.c:848: Test failed: WaitCommEvent failed with
Andrew Cook wrote:
> On 27/08/13 22:02, Dmitry Timoshkov wrote:
> > Andrew Cook wrote:
> >> --- a/include/wine/server_protocol.h
> >> +++ b/include/wine/server_protocol.h
> >
> > And don't include autogenerated stuff in the patch.
> >
>
Andrew Cook wrote:
> +typedef struct _JOBOBJECT_ASSOCIATE_COMPLETION_PORT {
> + PVOID CompletionKey;
> + HANDLE CompletionPort;
> +} JOBOBJECT_ASSOCIATE_COMPLETION_PORT, *PJOBOBJECT_ASSOCIATE_COMPLETION_PORT;
This needs to go into its owm header.
> +static DWORD getProcess(PHANDLE handle) {
Hi Wolfgang,
Wolfgang Walter wrote:
> 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.
What patch doesn't work for you? Do you have a test case or a specific
scenario which doesn't work? Wha
Marvin wrote:
> === WVISTAX64 (32 bit comm) ===
> comm.c:835: Test failed: WriteFile took 16 ms to write 0 Bytes at 150 Baud
Failure is not caused by this patch, probably a VM is very slow.
--
Dmitry.
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.
Alexandre Julliard wrote:
> > +if (type == FD_TYPE_FILE)
> > +{
> > +io_status->u.Status = status;
> > +io_status->Information = total;
> > +}
>
> I don't see why this would have to be specific to files.
There is a test for pipes which fails if th
Mislav Blazevic wrote:
> Same way its used in windows, obviously... Does wine somehow explicitly
> forbids applying binary patches on loaded executables? Can you please tell
> me which feature of apphelp won't work on wine?
You didn't actually answer the question and for some reason ignored
> >
Marvin wrote:
> === WXPX64 (64 bit file) ===
> file.c:1791: Test failed: expected STATUS_SUCCESS, got 0
> file.c:1817: Test failed: expected STATUS_SUCCESS, got 0
> file.c:1844: Test failed: expected STATUS_END_OF_FILE, got 0xc011
> file.c:1855: Test failed: expected STATUS_END_OF_FILE, got 0
[please bottom post when replying]
Mislav Blazevic wrote:
> It mostly comes from feeding SdbTagToString all valid inputs. Some
> constants are from msdn. I do not know of a *real* program calling this API
> other than winapi itself. kernel32 uses it for backwards compatibility. I
> wrote plenty
Mislav Blazevic wrote:
> ---
> dlls/apphelp/apphelp.c | 10 +-
> dlls/apphelp/apphelp.h | 272
> +
> 2 files changed, 273 insertions(+), 9 deletions(-)
> create mode 100644 dlls/apphelp/apphelp.h
Where all of this comes from? Is there an applic
Vincent Povirk wrote:
> if (!(format_flags & StringFormatFlagsNoClip) &&
> -scaled_rect.Width != 1 << 23 && scaled_rect.Height != 1 << 23)
> +scaled_rect.Width != 1 << 23 && scaled_rect.Height != 1 << 23 &&
> +rect->Width > 0.0 && rect->Height > 0.0)
> {
>
Alexandre Julliard wrote:
> You shouldn't check the version, but the actual problem (i.e. the size
> of the offending type). Also please avoid unnecessary changes.
The offending type is toff_t, it's size is either 32 or 64-bit depending
on whether it's libtiff 3.0 or 4.0, or whether it's broken
Alexandre Julliard wrote:
> >> TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defined
> >> to 42, TIFF_VERSION_BIG introduced in 4.x defined to 43.
> >>
> >> Unfortunately TIFFLIB_VERSION define reflects the date, not the real
> >> version. So for instance libtiff 3.9.7 has it define
Dmitry Timoshkov wrote:
> > There's a TIFF_VERSION define that seems to have been renamed to
> > TIFF_VERSION_CLASSIC in 4.0.
> >
> > It doesn't make sense to do the check at runtime, given we're only
> > going to link to one of the versions.
>
Vincent Povirk wrote:
> There's a TIFF_VERSION define that seems to have been renamed to
> TIFF_VERSION_CLASSIC in 4.0.
>
> It doesn't make sense to do the check at runtime, given we're only
> going to link to one of the versions.
TIFF_VERSION_CLASSIC reflects the TIFF format itself, it's defin
Vincent Povirk wrote:
> I have no opinion on this sort of work-around (it should work afaict,
> and I haven't found any other places where we currently use toff_t),
> but did you file a bug with whatever distro has such broken headers?
As far as I can see it's not a distro problem, it's a libtif
Vincent Povirk wrote:
> I'm curious what happens if the world transform has some rotation. It
> seems like transform_rectf would break in that case.
It works just fine in the samples I have here, why would it break?
--
Dmitry.
Nikolay Sivov wrote:
> >> +#include "ddk/wdm.h"
> > Please don't do that, this breaks compilation with PSDK headers. If you need
> > some specific definitions, types or API prototypes - replicate them in the
> > test
> > itself.
> What breaks exactly? The fact that PSDK doesn't have DDK headers
Nikolay Sivov wrote:
> +#include "ddk/wdm.h"
Please don't do that, this breaks compilation with PSDK headers. If you need
some specific definitions, types or API prototypes - replicate them in the test
itself.
--
Dmitry.
Detlef Riekenberg wrote:
> -/* global palette */
> +/* global palette. This succeed since win7sp1 with platform update /
> win8 */
This comment is not helpful.
> hr = IWICBitmapDecoder_CopyPalette(decoder, palette);
> -ok(hr == WINCODEC_ERR_FRAMEMISSING,
> - "expected WI
André Hentschel wrote:
> +#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) ||
> defined(__ARM_ARCH_7R__)
> +static inline void set_tpidrurw(DWORD tpidrurw)
> +{
> +__asm__ volatile ("mcr p15, 0, %0, c13, c0, 2" : : "r" (tpidrurw));
> +}
> +
> +static inline DWORD get_tpidrurw(void)
Francois Gouget wrote:
> So should we go with the flow and switch to using ellipsis characters or
> should we stick with three dots?
3 dots should be used in order to keep compatibility with bitmap fonts, fonts
that don't have the ellipsis glyph and ansi APIs
(GetMenuItemInfoA/GetWindowTextA).
Alexandre Julliard wrote:
> > This patch fixes the problem reported in the bug 2770, hopefully it's still
> > acceptable during code freeze.
>
> Is there an application that's fixed by this? According to bug 2770,
> that app only crashes a little further on (which is of course an
> improvement,
George Stephanos wrote:
> +res = RegOpenKeyExA( hkey, "subkey1", 0, KEY_READ, &hkeysub1 );
> +ok(res != ERROR_SUCCESS, "test key found in user's classes: %d\n", res);
...
> +res = RegOpenKeyExA( hklm, "subkey1", 0, KEY_READ, &hklmsub1 );
> +ok(res != ERROR_SUCCESS, "test key found
Alexandre Julliard wrote:
> > The patch actually removes the casts, the only cast that remains is the cast
> > on the caller's side for the vtable pointer (which is much cleaner IMO since
> > every COM object implements IUnknown), but the implementation itself is cast
> > free, and looks now as a
Alexandre Julliard wrote:
> > This patch should be quite obvious in its intent: it changes vtable type
> > to IUnknown which helps to remove This* to IUnknown* casts in order to
> > avoid obvious problems with vtable pointer placement inside of object
> > implementation. Basically this is just a
This patch should be quite obvious in its intent: it changes vtable type
to IUnknown which helps to remove This* to IUnknown* casts in order to
avoid obvious problems with vtable pointer placement inside of object
implementation. Basically this is just a clean up patch.
Is there anything else to c
Marcus Meissner wrote:
> > > --- a/dlls/ole32/ifs.c
> > > +++ b/dlls/ole32/ifs.c
> > > @@ -217,6 +217,8 @@ static LPVOID WINAPI IMalloc_fnRealloc(LPMALLOC
> > > iface,LPVOID pv,DWORD cb) {
> > > IMallocSpy_Release(Malloc32.pSpy);
> > > Malloc32.SpyReleasePending = FALSE;
> >
Marcus Meissner wrote:
> --- a/dlls/ole32/ifs.c
> +++ b/dlls/ole32/ifs.c
> @@ -217,6 +217,8 @@ static LPVOID WINAPI IMalloc_fnRealloc(LPMALLOC
> iface,LPVOID pv,DWORD cb) {
> IMallocSpy_Release(Malloc32.pSpy);
> Malloc32.SpyReleasePending = FALSE;
> Mall
Daniel Jeliński wrote:
> I'm quite sure you didn't mean to ignore return value of GetStockObject and
> leave logfont uninitialized here.
GetStockObject(DEFAULT_GUI_FONT) can't fail.
--
Dmitry.
Rafał Mużyło wrote:
> Going on an assumption, that 0 is a magic value (standing for 'point'),
> compare against it. Fixes 6ab04040e52465e77558a067309e8a54bdc0f32c regression,
> so would be nice if this got into wine 1.6.
It would be nice to see some test cases first.
--
Dmitry.
Aric Stewart wrote:
> Looking to improve our Arabic support, I found that our Tahoma heavily uses
> glyphs from DejaVu fonts already, which are public domain.
Before making such claims I'd suggest to investigate first history behind
creation of Tahoma font replacement in Wine, and at least read
Marcus Meissner wrote:
> > > > 1030106 Resource leak
> > > > 1030105 Resource leak
> > > > 1030104 Resource leak
> > >
> > > These cases are of the kind 'freeing resources at process exit is not
> > > useful'.
> >
> > Well, it is code that is run within a library.
> >
> > The usage pattern
Marcus Meissner wrote:
> > > 1030106 Resource leak
> > > 1030105 Resource leak
> > > 1030104 Resource leak
> >
> > These cases are of the kind 'freeing resources at process exit is not
> > useful'.
>
> Well, it is code that is run within a library.
What do you mean by "library" in this con
Marcus Meissner wrote:
> 1030106 Resource leak
> 1030105 Resource leak
> 1030104 Resource leak
These cases are of the kind 'freeing resources at process exit is not useful'.
--
Dmitry.
André Hentschel wrote:
> diff --git a/include/delayloadhandler.h b/include/delayloadhandler.h
> new file mode 100644
> index 000..e48e415
> --- /dev/null
> +++ b/include/delayloadhandler.h
I don't see such file in PSDK 7.1, where does it come from?
> diff --git a/include/winnt.h b/include/w
Alexandre Julliard wrote:
> If it's a test app meant to investigate the behavior, that's fine, but
> then there's no reason to put it in the test suite.
>
> Just use it to figure out the behavior, and then write a proper test
> that checks for that behavior using ok() and the like. At that point
Alexandre Julliard wrote:
> >> Launching the server in responce to say CoCreateInstance is out of our
> >> control, happens behind the scene, and the server runs in its own console,
> >> so it's impossible make a simple redirection by passing in/out handles to
> >> CreateProcess. So using a pipe
Dmitry Timoshkov wrote:
> Alexandre Julliard wrote:
>
> > It seems to be awfully complicated. In particular I don't think you need
> > a shared mapping plus a pipe plus a mutex just to log tracing
> > output. Redefining standard macros is also not a good idea.
Ken Thomases wrote:
> ---
> dlls/winemac.drv/cocoa_app.h |2 ++
> dlls/winemac.drv/cocoa_app.m |3 ++-
> 2 files changed, 4 insertions(+), 1 deletions(-)
I wonder, do you actually run 'make test' in dlls/user32/tests with
your changes? My guess is that you don't.
--
Dmitry.
Alexandre Julliard wrote:
> It seems to be awfully complicated. In particular I don't think you need
> a shared mapping plus a pipe plus a mutex just to log tracing
> output. Redefining standard macros is also not a good idea.
Launching the server in responce to say CoCreateInstance is out of ou
Dmitry Timoshkov wrote:
> With minor clean ups and with increased timeout to wait for server termination
> to please some really slow VMs (that allowed to remove broken() statements).
It would be helpful to provide some feedback and explain the 'pending' state
of the patch w
Christian Costa wrote:
> and no modern gcc/other compiler that I can find cares.
> >>> It was probably added because of a tool that warned of the unused
> >>> parameter ... So it all goes in circles. ;)
> >>>
> >>> Ciao, Marcus
> >>>
> >>>
> >>>
> >> So what about action = NULL instead?
> >
Christian Costa wrote:
> >> and no modern gcc/other compiler that I can find cares.
> > It was probably added because of a tool that warned of the unused
> > parameter ... So it all goes in circles. ;)
> >
> > Ciao, Marcus
> >
> >
> >
> So what about action = NULL instead?
A checker tool should
Aric Stewart wrote:
> +ascent = GET_BE_WORD(tt_os2.usWinAscent);
> +descent = GET_BE_WORD(tt_os2.usWinDescent);
> +cell_height = ascent + descent;
> +ok(ntm->ntmCellHeight == cell_height, "%s: ntmCellHeight %u != %u,
> os2.usWinAscent/os2.usWinDescent %u/%u\n",
>
Alexandre Julliard wrote:
> >> >> > --- a/server/handle.c
> >> >> > +++ b/server/handle.c
> >> >> > @@ -165,7 +165,6 @@ static void handle_table_destroy( struct object
> >> >> > *obj )
> >> >> > for (i = 0, entry = table->entries; i <= table->last; i++,
> >> >> > entry++)
> >> >> > {
Alexandre Julliard wrote:
> >> > --- a/server/handle.c
> >> > +++ b/server/handle.c
> >> > @@ -165,7 +165,6 @@ static void handle_table_destroy( struct object *obj
> >> > )
> >> > for (i = 0, entry = table->entries; i <= table->last; i++, entry++)
> >> > {
> >> > struct object
Alexandre Julliard wrote:
> > --- a/server/handle.c
> > +++ b/server/handle.c
> > @@ -165,7 +165,6 @@ static void handle_table_destroy( struct object *obj )
> > for (i = 0, entry = table->entries; i <= table->last; i++, entry++)
> > {
> > struct object *obj = entry->ptr;
> > -
Christian Costa wrote:
> Out of curiosity. Not freeing these memory allocations shouldn't disturb
> Valgrind to report false memory leaks?
Avoiding heap access on process exit should avoid possible dead locks
in case a terminated by ExitProcess thread holds the heap lock.
--
Dmitry.
1 - 100 of 2797 matches
Mail list logo
