[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150511130632.GA1667@openwall.com>
Date: Mon, 11 May 2015 16:06:32 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [core john] [Johnny] Windows event loop
Shinnok,
On Mon, May 11, 2015 at 03:34:00PM +0300, Shinnok wrote:
>
> > On May 10, 2015, at 6:35 PM, Mathieu Laprise <mathlaprise@...il.com> wrote:
> >
> > Thanks Aleksey for your comments.
> > Since there were no objections, yesterday, I implemented the solution #2 in Johnny on branch WindowsSupport and it's working great. I'll make a pull request soon.
>
> Sorry to disappoint you guys, but Win32 API dev is that "fun" yes.
>
> Is #2 the helper executable one? If so, then I'm afraid that is not the most viable solution for the long term.
>
> The way to go is this:
> 1. For now implement the event loop and handle WM_CLOSE. JtR core would be best.
Assuming #2 is properly implemented (and Mathieu won't waste a lot of
time debugging it for release), I think that WM_CLOSE may be not very
important now.
Oh, I thought we lag heavily, but now I realized that there are 2
weeks per version in the plan. Though 1.5 and the first release are
waiting. Patch to add --show=types to support 1.5.2 is almost done
(I'll add a bit but full.patch may already be picked from mail below).
full.patch is in
Date: Mon, 11 May 2015 00:40:02 +0300
From: Aleksey Cherepanov <lyosha@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [john-dev] displaying full meta information about hashes with --show=types
> 2. Further along the road we should convert to --no-tty option and then we can close JtR just by sending a "q\n".
>
> I'm happy with just supporting a specific version of JtR going forwards and not looking backwards. Johnny is supposed to run on modern desktops and there's no reason why such a desktop can't run a fresh JtR.
I don't know how much users use old versions of john on Windows. While
you can easily build a new version on Linux (it is common to have
compiler installed), I'd expect Windows users to keep version not
newer than last official binary build. (Though I don't really know
Windows users.) So to make WM_CLOSE convenient for users, a version of
john built for Windows should be provided (and maybe even packaged
with Johnny).
The helper executable may be used as a fallback when john does not
support WM_CLOSE.
For me, it seems to be a common pattern in Johnny's dev cycles: there
is good easy solution for part of versions and complex ugly solution
that works for all version, so the bad should be fallback and the good
should be the primary solution, but the first solution was implemented
first because the balance was biased to support all versions. Now the
balance is up to you.
Thanks!
--
Regards,
Aleksey Cherepanov
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
