Improve Support under Mono

[GoogleCodeExporter]

Although Microsoft's .NET Framework is the primary target for Cryptnos for 
Windows, we should make a concerted effort to improve support for Cryptnos 
running under Mono (http://www.mono-project.com/). This will help expand the 
application's user base beyond the Windows platform, especially since the pure 
Java version has been very slow to get started.

I haven't had much chance to test Cryptnos under Mono, in large part just 
because it's been a "nice to have" and I haven't have time to tackle it. I also 
spent a good chunk of this year without a working Linux box when a motherboard 
died and killed my in-house server (the only non-headless Linux box I have 
access to on which I can run X). I have since tested Cryptnos under Mono 2.10.8 
on Fedora 17 with disappointing results. The main window launches, but pretty 
much any attempt to much beyond that fails with a stream of exceptions.

There may need to be a major overhaul of the storage mechanism in order to get 
this to work. Cryptnos currently uses the Windows Registry to store its data 
(encrypted, of course), but I don't know how well (if at all) this is emulated 
under Mono. This would probably be a good idea anyway as I'd prefer to get away 
from using the Registry for storage; some early design decisions there have 
proven problematic over time, and it seriously hampers user requests to make 
Cryptnos run in a "portable" mode.

As I get to research this, I'll update this ticket with my findings. I'm going 
to mark this as low priority for now, mostly because I'm not sure how much time 
I'll get to devote to it. There may be a volunteer available to look into this, 
however, which might make this move more quickly.

Original issue reported on code.google.com by jeff.darlington@gmail.com on 13 Nov 2012 at 12:49

[GoogleCodeExporter]

Original comment by jeff.darlington@gmail.com on 6 Sep 2013 at 7:27

• Changed state: Started

[GoogleCodeExporter]

This issue was updated by revision r65.

A number of first attempts to improve support for Cryptnos under Mono.

MoMA reports one P/Invoke and one "to-do" warning, both of which are used to 
prevent multiple instances of the app from running at the same time under 
Windows. This code obviously doesn't work under other OSes, so we check to see 
if the app is running under Mono and, if so, we skip that check. It will be 
upon the user's shoulders to kill other open instances before a new instance 
can be launched. The caveat will be that we will get this same behavior for 
Windows users running under Mono, but since the code is .NET specific, we can't 
avoid that.

Several of the "dialog boxes" (actually other forms) use a little kludge for 
passing values back to the main form. This kludge causes a stack overflow under 
Mono. If we detect that we're running under Mono, we now avoid the kludge and 
let the flow go without it; it still seems to produce the desired behavior.

Our main form is *REALLY* poorly designed, and Mono highlights this. 
Specifically, switching to "daily mode" crops parts of the form (at least under 
GNOME/Linux) and renders it difficult if not impossible to use. For the time 
being, we are disabling "daily mode" when Cryptnos is run under Mono until we 
can improve this behavior.

The "copy password to clipboard" feature technically works, but perhaps not as 
expected. Under Linux, there are often two separate clipboards: one use by X 
applications and one used by command-line apps (Ctrl+C and Ctrl+V). Cryptnos 
successfully copies to one of these, but I'm not entirely sure which. 
Unfortunately, it may take some experimentation on the user's part to find out 
for themselves.

The URL link for the Cryptnos site in the About dialog does not seem to launch 
the browser, although the Help button does successfully launch the local help 
file. Go figure.

There are still a few visual artifacts under GNOME/Linux, but as far as I can 
tell, the app seems fully functional. There's still a need for extensive 
testing, of course.

I have done absolutely no testing under Mac OS X, since I unfortunately do not 
have a Mac to test with. We may have to claim OS X is officially unsupported 
until we can find a volunteer tester or I finally break down and buy a Mac. 
(I've been thinking of tinkering with iOS development anyway.)

Tentatively bumping this to version 1.3.4. (No tags just yet.)

Original comment by jeff.darlington@gmail.com on 6 Sep 2013 at 8:30

[GoogleCodeExporter]

This issue was updated by revision r66.

Another Mono-related fix: Tweaked the Export dialog to prevent the same stack 
overflow referenced in Revision 65.

Another caveat I just thought about: The automated update mechanism is 
currently very Windows centric. If a new version is available for download, the 
current process offers to download a Windows installation executable and 
automatically run it. This obviously won't work under Mac OS or Linux. 
Unfortunately, this is more a function of the update check library 
(GPFUpdateChecker) than Cryptnos itself. I may implement a notify-only method 
in that library and call that version when running under Mono.

Original comment by jeff.darlington@gmail.com on 7 Sep 2013 at 12:36

[GoogleCodeExporter]

I've added an issue under the GPFUpdateChecker project for the notify-only 
update check mentioned above:

https://code.google.com/p/gpfupdatechecker/issues/detail?id=1

Original comment by jeff.darlington@gmail.com on 7 Sep 2013 at 12:50

[GoogleCodeExporter]

Original comment by jeff.darlington@gmail.com on 7 Sep 2013 at 6:10

• Added labels: Milestone-1.3.4

[GoogleCodeExporter]

This issue was updated by revision r67.

Upgraded GPFUpdateChecker to version 1.2. Now when a new update is found, the 
behavior is different under Windows/.NET and any platform running Mono. Under 
Windows/.NET, the old behavior is maintained: if the user says it's OK, the 
installer will be downloaded and executed automatically. Under Mono, however, 
the user will be notified, but instead of downloading the installer, it will 
open a web page where Cryptnos can be downloaded.

Original comment by jeff.darlington@gmail.com on 11 Sep 2013 at 8:03

[GoogleCodeExporter]

This issue was updated by revision r68.

Updated the HTML help file with changes related to Issue 9 and increased Mono 
support.

Original comment by jeff.darlington@gmail.com on 12 Sep 2013 at 5:56

[GoogleCodeExporter]

This issue was updated by revision r69.

Complete hide the "daily mode" checkbox on the main form when running under 
Mono. This should be a bit less confusing to Mono users than seeing a disabled 
box they can never use.

Fixed the interactive update check on the settings dialog under Mono. While I 
added the necessary code to make the alternate download method work in the 
weekly automatic check (this opens a Web page rather than downloading an 
installer), I failed to port this same code to the interactive update check in 
the settings dialog. Both update checks should now work identically.

Original comment by jeff.darlington@gmail.com on 23 Jan 2014 at 4:54

[GoogleCodeExporter]

This issue was updated by revision r70.

Attempted to fix the website link and Help button on the About dialog, which 
apparently haven't been working for who knows how long. The website link should 
now work under both .NET and Mono, but the Help button currently only works 
under .NET. While the code that generates the location of the help file is 
working, the code to actually launch the browser and show the help file isn't 
cooperating.

Original comment by jeff.darlington@gmail.com on 23 Jan 2014 at 5:53