Hi Daniel,
On Fri, Jun 28, 2013 at 3:43 AM, Daniel Jeliński djelins...@gmail.com 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
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
Hi Daniel,
On Fri, Jun 28, 2013 at 4:47 PM, Daniel Jeliński djelins...@gmail.com 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,
Dmitry Timoshkov dmi...@baikal.ru writes:
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
Hi Daniel, new patches sent with improving from your hints, would you
mind have a look? Thanks in advance!
Alexandre Julliard julli...@winehq.org 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
On Fri, Jun 28, 2013 at 9:16 AM, Qian Hong fract...@gmail.com wrote:
Dear Juan,
Thanks for reviewing!
On Fri, Jun 28, 2013 at 11:31 PM, Juan Lang juan.l...@gmail.com wrote:
It's more in line with most C code to use !memcmp(...) instead of
memcmp(...)==0. I find it easier to scan, anyway,
On Sat, Jun 29, 2013 at 12:34 AM, Juan Lang juan.l...@gmail.com 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
On 2013-06-27 09:39-0700 Alan W. Irwin wrote:
[...]I asked
Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try
and get the debugging process started with the Cygwin developers. The
response http://cygwin.com/ml/cygwin/2013-06/msg00666.html to his
post looks quite promising.
--- On Thu, 27/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
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
On 2013-06-28 22:07+0100 Hin-Tak Leung wrote:
--- On Thu, 27/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
[...]I asked
Arjen Markus, a PLplot colleague of mine with Cygwin
contacts, to try
and get the debugging process started with the Cygwin
developers. The
response
--- On Fri, 28/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca 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
On 2013-06-28 23:13+0100 Hin-Tak Leung wrote:
--- On Fri, 28/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca 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
On 2013-06-28 22:37+0100 Hin-Tak Leung wrote:
--- On Fri, 28/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca 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
14 matches
Mail list logo
