On Fri, Sep 6, 2013 at 9:17 PM, Charles Davis wrote:
>
> On Sep 6, 2013, at 5:01 PM, Juan Lang wrote:
>
> On Fri, Sep 6, 2013 at 3:54 PM, Charles Davis wrote:
>
>> Maybe then the real fix is to make Wine accept either a constructor SET
>> or the custom tag (ASN_CONTEXT | ASN_CONSTRUCTOR) it curr
On Sep 6, 2013, at 5:01 PM, Juan Lang wrote:
> On Fri, Sep 6, 2013 at 3:54 PM, Charles Davis wrote:
> Maybe then the real fix is to make Wine accept either a constructor SET or
> the custom tag (ASN_CONTEXT | ASN_CONSTRUCTOR) it currently accepts, for
> either attribute set. I should come up w
On Fri, Sep 6, 2013 at 3:54 PM, Charles Davis wrote:
> Maybe then the real fix is to make Wine accept either a constructor SET or
> the custom tag (ASN_CONTEXT | ASN_CONSTRUCTOR) it currently accepts, for
> either attribute set. I should come up with a test case first, though, to
> see if that's
7;t expect to find another one. But I
suspect that in the other case (just with the "UnknownItem"), it's because
Crypto was expecting to find something in the set, but didn't. (I did, after
all, fill the set with zeroes.)
Maybe then the real fix is to make Wine accept eith
--Juan
On Thu, Sep 5, 2013 at 11:57 PM, Charles Davis wrote:
> Hi Juan,
>
> I need some advice.
>
> Attached is a patch to fix bug 34388, where an app that tries to verify
> its code signature fails because Wine, while parsing the certificates
> embedded within the signature
Hi Juan,
I need some advice.
Attached is a patch to fix bug 34388, where an app that tries to verify its
code signature fails because Wine, while parsing the certificates embedded
within the signature, encounters an item in the CMS signer info (tag 0x31, i.e.
ASN_UNIVERSAL | ASN_CONSTRUCTOR
Neil, thanks for reporting.
Could you please re-report this bug to a place where reports should be posted -
i.e. to Wine's Bugzilla which could be found at http://bugs.winehq.com/ ?
Thanks in advance.
---
Best regards,
Alexey Loukianov
HPC support and maintenance engineer,
RSC Technol
err:msi:cabinet_copy_file failed to create L"C:\\users\\Public\\Application
Data\\Adobe\\Adobe PDF\\Settings\\Standard.joboptions" (error 3)
err:msi:extract_cabinet FDICopy failed
err:msi:ACTION_InstallFiles Failed to extract cabinet: L"Data1.cab"
err:msi:ITERATE_Actions Execution halted, action L"
On Sun, Aug 18, 2013 at 6:00 PM, Ken Sharp wrote:
>
>
> On 18/08/13 17:35, Francois Gouget wrote:
>
>> On Sun, 18 Aug 2013, Ken Sharp wrote:
>> [...]
>>
>>> We have some instructions on Bugzilla's bug submission page (currently
>>>> '
On Sun, 18 Aug 2013, Ken Sharp wrote:
[...]
> So who is to blame? Is it your fault? It's not mine.
No, it is not yours. It cannot possibly be yours.
> Perhaps you are blaming Codeweavers?
Uh? How did they get brought into this.
Just stop trolling already!
--
Francois Gouget htt
On 18/08/13 17:35, Francois Gouget wrote:
On Sun, 18 Aug 2013, Ken Sharp wrote:
[...]
We have some instructions on Bugzilla's bug submission page (currently
'Please do not PASTE logs and back traces'). It may make sense to add
something for the bug links either there or on the
On Sun, 18 Aug 2013, Ken Sharp wrote:
[...]
> > We have some instructions on Bugzilla's bug submission page (currently
> > 'Please do not PASTE logs and back traces'). It may make sense to add
> > something for the bug links either there or on the page confirming
On Sun, 18 Aug 2013 11:16:27 +0200 (CEST)
Francois Gouget wrote:
> We have some instructions on Bugzilla's bug submission page (currently
> 'Please do not PASTE logs and back traces'). It may make sense to add
> something for the bug links either there or on the page c
On 18/08/13 10:16, Francois Gouget wrote:
On Fri, 16 Aug 2013, Ken Sharp wrote:
[...]
It takes longer to create a bug report than it does to link it to the
database. It really isn't that hard.
But adding a link requires going and logging into a separate web site.
That's really no
On 18/08/13 09:56, Francois Gouget wrote:
On Fri, 16 Aug 2013, Rosanne DiMesio wrote:
On Fri, 16 Aug 2013 20:51:19 +0100
Ken Sharp wrote:
I believe someone managed to run a script to find the unlinked bugs. I
can't remember who it was now, sadly, and I don't know if it was
server-side, whi
On 18 August 2013 11:16, Francois Gouget wrote:
> On Fri, 16 Aug 2013, Ken Sharp wrote:
> [...]
>> It takes longer to create a bug report than it does to link it to the
>> database. It really isn't that hard.
>
> But adding a link requires going and logging into
On Fri, 16 Aug 2013, Ken Sharp wrote:
[...]
> It takes longer to create a bug report than it does to link it to the
> database. It really isn't that hard.
But adding a link requires going and logging into a separate web site.
That's really not the part of the normal flow o
On Fri, 16 Aug 2013, Rosanne DiMesio wrote:
> On Fri, 16 Aug 2013 20:51:19 +0100
> Ken Sharp wrote:
>
> > I believe someone managed to run a script to find the unlinked bugs. I
> > can't remember who it was now, sadly, and I don't know if it was
> > server-side, which would obviously be quicke
On Sat, 17 Aug 2013 15:37:33 +0100
Ken Sharp wrote:
> I can, and do, search Bugzilla for that. It is a massive PITA having to
> do it but a script would make it easier, however...
>
>
Users can add bug links, so if someone would run an updated script and post the
results we coul
On 17/08/13 13:36, Rosanne DiMesio wrote:
On Sat, 17 Aug 2013 13:07:32 +0200
André Hentschel wrote:
So this is just with no link in "Show Apps affected by this bug"?
Beside it being outdated i think it's not exactly what Ken wants,
I can, and do, search Bugzilla for that.
On Sat, 17 Aug 2013 13:07:32 +0200
André Hentschel wrote:
>
> So this is just with no link in "Show Apps affected by this bug"?
> Beside it being outdated i think it's not exactly what Ken wants,
>
I think what Ken wants is for people to add the bug links when they
;> server-side, which would obviously be quicker.
>>
>>
> Dan Kegel. http://kegel.com/wine/unlinked.html
>
So this is just with no link in "Show Apps affected by this bug"?
Beside it being outdated i think it's not exactly what Ken wants,
we should rather have a sc
On 16/08/13 22:02, Rosanne DiMesio wrote:
Dan Kegel. http://kegel.com/wine/unlinked.html
Good find! :-)
On Fri, 16 Aug 2013 20:51:19 +0100
Ken Sharp wrote:
>
> I believe someone managed to run a script to find the unlinked bugs. I
> can't remember who it was now, sadly, and I don't know if it was
> server-side, which would obviously be quicker.
>
>
Dan Kegel. http://kegel.com/wine/unlinked.htm
On 16/08/13 19:15, Vincent Povirk wrote:
If we really want the links to be up to date, we should figure out a
way to make them show up on bugzilla, without clicking through to a
search. Otherwise, the only time someone is likely to notice a bug
that hasn't been linked is if they're l
If we really want the links to be up to date, we should figure out a
way to make them show up on bugzilla, without clicking through to a
search. Otherwise, the only time someone is likely to notice a bug
that hasn't been linked is if they're looking for it specifically and
happened to s
On Fri, Aug 16, 2013 at 2:46 PM, Ken Sharp wrote:
> There's little point in my continually asking users to add bug links to the
> AppDB if maintainers and/or administrators don't bother themselves.
>
> It takes longer to create a bug report than it does to link it to the
There's little point in my continually asking users to add bug links to
the AppDB if maintainers and/or administrators don't bother themselves.
It takes longer to create a bug report than it does to link it to the
database. It really isn't that hard.
I've added hundre
dirstack
> *dirstack, const struct expr *cond, WCHAR root, UINT *count )",
> in dlls/wbemprox/builtin.c:1086, accessing cond's member without checking
> if it's NULL! Unfortunately a NULL is passed to it. That's why my program
> crashed.
> It's a bug, right?
Please open a bug report and attach a +wbemprox trace.
unt )",
in dlls/wbemprox/builtin.c:1086, accessing cond's member without checking
if it's NULL! Unfortunately a NULL is passed to it. That's why my program
crashed.
It's a bug, right?
Dmitry Timoshkov writes:
> @@ -208,9 +233,22 @@ static TIFF* tiff_open_stream(IStream *stream, const
> char *mode)
> zero.QuadPart = 0;
> IStream_Seek(stream, zero, STREAM_SEEK_SET, NULL);
>
> +/* Workaround for broken libtiff 4.x headers on some 64-bit hosts which
> + * defi
Dmitry Timoshkov writes:
> 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 libtif
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
Dmitry Timoshkov writes:
> 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 i
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 writes:
>> 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 defined to 201209
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.
>
> TIFF_VERSION_CLASSIC reflects the TIFF format it
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
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:
> 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 dis
I had filed a bug with Gentoo:
https://bugs.gentoo.org/show_bug.cgi?id=459820
On Jul 25, 2013 5:31 PM, "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),
>
Actually, this will be a problem on libtiff 3.x, where toff_t really
is supposed to be 32-bit.
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?
the postinstall scripts now all run without catastrophic runtime
errors or hangs. I have added all the details about my experience with
that breakthrough to that bug report. I have included an attachment
there of a script to allow convenient updating of cygwin1.dll with the
fork-fixed version.
--- On Mon, 1/7/13, David Laight wrote:
> On Mon, Jul 01, 2013 at 06:13:26PM
> +0200, Peter Rosin wrote:
> >
> > I would like to point out that it seems that the
> current bug does not
> > appear to be *in* setup.exe, but rather occurs when
> setup.exe runs
> &g
they don't back up that
> anecdotal
> evidence with a solid bug report. For example, you
> stated some
> anecdotal evidence about a bug in Cygwin "cat", but when I
> requested a
> reference for your associated bug report to Cygwin you were
> silent.
> That told m
On Mon, Jul 1, 2013 at 7:11 PM, Alan W. Irwin wrote:
> On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:
>
>> --- On Mon, 1/7/13, Alan W. Irwin wrote:
>> ... I hope your negative
>>>
>>> attitude
>>> toward the Cygwin toolchain is not typical of such
>>> developers. After
>>> all, even though the Wi
ressed here on the Cygwin tool chain are
biased. That is because I have my own bias. In short, I have a
prejudice against anyone stating anecdotal evidence concerning issues
with _any_ open-source software if they don't back up that anecdotal
evidence with a solid bug report. For example,
On Mon, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote:
>
> I would like to point out that it seems that the current bug does not
> appear to be *in* setup.exe, but rather occurs when setup.exe runs
> a bash post-install script, where the bash.exe that interprets the
> sc
--- On Mon, 1/7/13, Alan W. Irwin wrote:
... I hope your negative
> attitude
> toward the Cygwin toolchain is not typical of such
> developers. After
> all, even though the Windows GNU toolchain code bases have
> diverged
> between the two groups of developers, there is still a
> common interest
On 2013-06-28 23:37, Hin-Tak Leung wrote:
> --- On Fri, 28/6/13, Alan W. Irwin wrote:
>
> ... However, because of the Cygwin fork
>> bug, Cygwin on
>> Wine has largely been untested for the last three years so
>> this could
>> be a good opportunity to do such
far superior to
Wine-1.4 so some of those bugs may have just disappeared. I hope to
find out about the actual status of Cygwin on Wine
bugs once I can get setup.exe to work on Wine.
I would like to point out that it seems that the current bug does not
appear to be *in* setup.exe, but rather occurs
Cygwin GNU toolchain without mention of any bug reports from you to
Cygwin to back up that assertion. Your constant repetition of this
theme made me curious so I looked you up on the web, and it appears
you are a MinGW developer.
If you really are a MinGW developer, I hope your negative attitude
or to
> Wine-1.4 so some of those bugs may have just disappeared. I hope to
> find out about the actual status of Cygwin on Wine
> bugs once I can get setup.exe to work on Wine.
I would like to point out that it seems that the current bug does not
appear to be *in* setup.exe, but rather
--- On Sun, 30/6/13, André Hentschel wrote:
> On 29.06.2013 23:34, Hin-Tak Leung
> wrote:
> > --- On Sat, 29/6/13, Alan W. Irwin
> wrote:
> >
> > ...
> >>> Also, running cygwin on wine, compared to other
> windows
> >> software
> >> which has no unix/linux equivalents, is hardly a
> priority.
>
--- On Fri, 28/6/13, Alan W. Irwin wrote:
... However, because of the Cygwin fork
> bug, Cygwin on
> Wine has largely been untested for the last three years so
> this could
> be a good opportunity to do such testing for the combination
> of Cygwin
> (with the fork fix) and r
On 29.06.2013 23:34, Hin-Tak Leung wrote:
> --- On Sat, 29/6/13, Alan W. Irwin wrote:
>
> ...
>>> Also, running cygwin on wine, compared to other windows
>> software
>> which has no unix/linux equivalents, is hardly a priority.
>>
>> That is obviously personally true for you. And for my
>> perso
--- On Sat, 29/6/13, Alan W. Irwin wrote:
...
> > Also, running cygwin on wine, compared to other windows
> software
> which has no unix/linux equivalents, is hardly a priority.
>
> That is obviously personally true for you. And for my
> personal needs
> Cygwin on Wine is a "would be nice" soft
with official Cygwin bug reports rather
than
asserting stuff here in an anecdotal way.
Anytime that a piece of windows software (including Cygwin) works on windows
but not on wine, is a wine problem.
No question. In fact I stated bug reports to Cygwin would probably
only be taken serious
--- On Sat, 29/6/13, Alan W. Irwin wrote:
...
> > The Mingw GNU toolchain works wells under wine. The
> cygwin GNU toolchain don't, the last time I checked.
>
> That may be true, but the best way to make that point about
> the Cygwin
> GNU toolchain is with official
On 2013-06-28 22:37+0100 Hin-Tak Leung wrote:
--- On Fri, 28/6/13, Alan W. Irwin wrote:
... However, because of the Cygwin fork
bug, Cygwin on
Wine has largely been untested for the last three years so
this could
be a good opportunity to do such testing for the combination
of Cygwin
(with
ial Cygwin bug reports rather than
asserting stuff here in an anecdotal way.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equatio
--- On Fri, 28/6/13, Alan W. Irwin wrote:
... But I _know_ the MSYS version of cat works fine on recent
> Wine just
> like the rest of the GNU toolchain used for building
> software so if
> the MSYS and Cygwin GNU toolchain code bases have not
> diverged too
> much it should be straightforward (a
ke e.g. "cat fileA fileB > fileC", if you
need convincing.
Have you reported this to Cygwin as a bug? Their response to the
fork issue was extraordinarily fast.
By the way, when you report that possible cat bug to Cygwin, I am sure they will
insist you use standard means (e.g., se
pertise to take on the additional
> distraction of getting
> > the debugging process for bug 24018 started with the
> Cygwin
> > developers.
>
> Because of the bad timing from the Wine developer
> perspective, I asked
> Arjen Markus, a PLplot colleague of mine with Cygwin
mising. It turned out the "fork bomb" test
programme failed after only 500 iterations, and the Cygwin developer,
Corinna Vinschen thinks she knows what the issue is with more to come.
So stay tuned to that thread if you have an interest in bug 24018.
The bug has now been fixed to the
On Sat, Jun 29, 2013 at 12:34 AM, Juan Lang wrote:
> Ah. Thanks for following the existing style then :-/ No, don't bother
> changing the existing code. I leave it up to you whether to follow my
> suggestion or ignore it, either is fine in this case.
Patch sent, thanks Juan Lang and Daniel Jelińs
On Fri, Jun 28, 2013 at 9:16 AM, Qian Hong wrote:
> Dear Juan,
>
> Thanks for reviewing!
>
> On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> > It's more in line with most C code to use !memcmp(...) instead of
> > memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to
> !
>
Dear Juan,
Thanks for reviewing!
On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang wrote:
> It's more in line with most C code to use !memcmp(...) instead of
> memcmp(...)==0. I find it easier to scan, anyway, as I've gotten used to !
> comparisons to check equality in memcmp, strcmp, and variants.
>
Hi Qian,
On Fri, Jun 28, 2013 at 3:44 AM, Qian Hong wrote:
> Hi Daniel, new patches sent with improving from your hints, would you
> mind have a look? Thanks in advance!
>
nice work! These look fine to me, but a stylistic nit:
+
ok(memcmp(pbData,cTestData[i].decstr,cTestData[1].enclen)==0,"dec
Hi Daniel, new patches sent with improving from your hints, would you
mind have a look? Thanks in advance!
Hi Daniel,
On Fri, Jun 28, 2013 at 4:47 PM, Daniel Jeliński wrote:
> I'm not convinced that a failed call to CryptDecrypt actually resets
> the key state. It's also possible that CryptDecrypt returns FALSE
> before even trying to decrypt if data length is invalid. To check it,
> you would need to
Hi Qian Hong,
I'm not convinced that a failed call to CryptDecrypt actually resets
the key state. It's also possible that CryptDecrypt returns FALSE
before even trying to decrypt if data length is invalid. To check it,
you would need to change the key state by (successfully) calling
CryptDecrypt wi
Hi Daniel,
On Fri, Jun 28, 2013 at 3:43 AM, Daniel Jeliński wrote:
> It is definitely valid to call CryptDecrypt multiple times with the same
> key. Calls with Final = FALSE change the internal state of the key, calls
> with Final = TRUE restore the initial state. Subsequent calls with Final =
>
CryptDecrypt changes the value of dwLen, which
you do not restore before calling the function again.
Regards,
Daniel
2013/6/27 Qian Hong
> Hello,
>
> I was investigating Bug 33898 [1] hardly and get a partial result, I
> have a special test case demonstrate the behavior of Aliwangwang [2],
On 2013-06-26 18:14-0700 Alan W. Irwin wrote:
Note in retrospect I realized that this period leading up to the
release of Wine-1.6.0 has been a lousy time to ask wine developers
with Cygwin expertise to take on the additional distraction of getting
the debugging process for bug 24018 started
Hello,
I was investigating Bug 33898 [1] hardly and get a partial result, I
have a special test case demonstrate the behavior of Aliwangwang [2],
however, I failed to expand the special case to a common test case. My
attempting is shown in [3]. The hack in [3] works for Aliwangwang, but
the test
MinGW,
MSYS, and Wine as a Windows build platform. But I haven't
even been
able to get started with Cygwin on Wine because of this
showstopping
bug. Therefore, I am mentioning the situation here in the
hope that
some wine developer on this list with some knowledge of
Cygwin will
take the responsib
and Wine as a Windows build platform. But I haven't
> even been
> able to get started with Cygwin on Wine because of this
> showstopping
> bug. Therefore, I am mentioning the situation here in the
> hope that
> some wine developer on this list with some knowledge of
> Cygwin wi
Andrey Turkin has stated at
http://bugs.winehq.org/show_bug.cgi?id=24018 that this is really a
Cygwin bug. I frankly don't understand the technical details
but his current test (an infinite loop with Cygwin fork
calls) may need some beefing up to convince the Cygwin developers they
On Mon, 2013-06-24 at 19:57 +0900, 中川祥 wrote:
> diff --git a/dlls/winhttp/session.c b/dlls/winhttp/session.c
> index 660eae5..dfe23d4 100644
> --- a/dlls/winhttp/session.c
> +++ b/dlls/winhttp/session.c
> @@ -1316,6 +1316,8 @@ BOOL WINAPI WinHttpDetectAutoProxyConfigUrl( DWORD
> flags, LPWSTR *url
> -Original Message-
> From: wine-devel-boun...@winehq.org [mailto:wine-devel-
> boun...@winehq.org] On Behalf Of Paul Chitescu
> Sent: Wednesday, June 12, 2013 2:37 AM
> To: wine-devel@winehq.org
> Subject: Re: Possible wine bug concerning the case of the DbgHelp.h head
On 2013-06-12 12:37+0300 Paul Chitescu wrote:
Hi!
The Platform SDK creates DbgHelp.h however it shouldn't matter for Windows
programs as they are case insensitive.
The problem here is that MinGW somehow operates case sensitive so raise a bug
for that.
You are right. So I put toget
t of the hits were for DbgHelp.h rather than dbghelp.h so I can
> understand why the ninja developers used
>
> #include
>
> rather than the lower-case version of that name.
>
> If the wine developers here decide this is definitely a wine issue, I
> am willing to write up the
On 12 June 2013 01:49, Alan W. Irwin wrote:
> I successfully built the ultra-fast ninja build tool on Wine using the
> MinGW g++ compiler. To achieve that success I had to deal with a
> small number of issues including
> one wine/ninja header name inconsistency which is that DbgHelp.h
> (#includ
hat name.
If the wine developers here decide this is definitely a wine issue, I
am willing to write up the bug report on your bugtracker so this issue
doesn't get lost. A search there for did not
turn up anything relevant.
Alan
__
Alan W. Irwin
Astronomical
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://testbot.winehq.org/JobDetails.pl?Key=25614
Your paranoid android
> Did you forget to remove the todo_wine introduced in [patch 1/2]?
I forgot it. I'll have more check and resend once latter. And I get a
little more to understand what todo_wine means this time. Thank you.
--
Regards,
Guo Jian
Hello Guo Jian,
On Fri, May 10, 2013 at 1:36 AM, Guo Jian wrote:
> A window should not lose mouse capture even when it's parent window is
> disabled.
Did you forget to remove the todo_wine introduced in [patch 1/2]?
Thanks for your work on it.
--
Regards,
Qian Hong
On Wed, Nov 7, 2012 at 3:22 AM, Dan Kegel wrote:
> After gstreamer, gcrypt is also dropping support for alternative
> thread libraries.
> Good thing secur32/schannel_gnutls.c doesn't use it. (Right?)
>
Right.
If someone were motivated, we could begin to transition winhttp and wininet
to schann
After gstreamer, gcrypt is also dropping support for alternative
thread libraries.
Good thing secur32/schannel_gnutls.c doesn't use it. (Right?)
- Dan
-- Forwarded message --
From: Werner Koch
Date: Wed, Nov 7, 2012 at 1:31 AM
Subject: Re: Bug#566351: libgcrypt11: shoul
I'd like to know if there's any simple way to implement a
command line sort program which we can call from the command shell. This
has subsequently been raised as bug 27933.
My first thought was to avoid reinventing the wheel and to have a windows
program called sort which parses its p
> IStream is not exposed to the user, but an internal interface would probably
> end up looking a lot like IStream because we need read/write/seek operations,
> reference counting and the ability to create clones. So we might as well use
> IStream.
Hmmm... Then I want exactly the same as SHCrea
On Wed, 2012-06-20 at 12:13 +0200, robert.van.h...@serioustoys.com wrote:
> IStream is not exposed to the user, but an internal interface would
> probably end up looking a lot like IStream because we need read/write/seek
> operations, reference counting and the ability to create clones. So we
> mig
On Tue, 2012-06-19 at 21:45 +0200, robert.van.h...@serioustoys.com wrote:
> > We don't have to call SHCreateStreamOnFileEx, we can add a suitable
> > implementation to msi.
>
> Ah, I see.
>
> I guess this stream cannot escape from MSI. The only way it can be accessed is
> through MsiRecordReadSt
> We don't have to call SHCreateStreamOnFileEx, we can add a suitable
> implementation to msi.
Ah, I see.
I guess this stream cannot escape from MSI. The only way it can be accessed is
through MsiRecordReadStream and MsiRecordSetStream, but it can never be
accessed directly?
In that case, we
> Yes, the concern is that the file could be changed or removed. We should
> test what native does here but it probably means that we need to create a
> stream
> on the file with a sharing mode that denies writing.
So... I tried this out. I do not understand what I found though!
On Windows, afte
I am not able to reproduce the bug anymore :-S.
I hope it'll pop up in the coming days again, if so, I will send you the trace
:-).
I'll also give the sharing thing / SHCreateFileStream a try and see if I can
come up with a unit test...
Regar
megs, but then when the final MSI is baked, something
seems to go wrong... (?)
Would you have any idea of how this could be?
Maybe some race-condition?
It seems to be unrelated to the other bug (the one described before:
GlobalAllocing a big block to copy file contents into), because before this
On Tue, 2012-06-19 at 20:55 +0200, robert.van.h...@serioustoys.com wrote:
> > Yes, the concern is that the file could be changed or removed. We should
> > test what native does here but it probably means that we need to create a
> > stream
> > on the file with a sharing mode that denies writing.
>
1 - 100 of 2223 matches
Mail list logo
