Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

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 the

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

On 2013-06-28 23:13+0100 Hin-Tak Leung wrote: --- 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 to

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

--- 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

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

On 2013-06-28 22:07+0100 Hin-Tak Leung wrote: --- On Thu, 27/6/13, 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

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

--- On Thu, 27/6/13, Alan W. Irwin 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 additional > dist

Bug 24018 which appears to be a showstopper for running Cygwin on Wine

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 to his post looks quite promising.

Re: Need help with a rsaenh bug

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

Re: Need help with a rsaenh bug

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 > ! >

Re: Need help with a rsaenh bug

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. >

Re: Need help with a rsaenh bug

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

Re: ntdll: NtAllocateVirtualMemory should fail to commit if an address range is already committed for a memory mapped file.

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,

Re: Need help with a rsaenh bug

Hi Daniel, new patches sent with improving from your hints, would you mind have a look? Thanks in advance!

Re: ntdll: NtAllocateVirtualMemory should fail to commit if an address range is already committed for a memory mapped file.

Dmitry Timoshkov 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 improvement, but not wort

Re: Need help with a rsaenh bug

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

Re: Need help with a rsaenh bug

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