I updated the poll on the web page today to find out, where i should spend time developing.
The number of builds and versions is getting a bit out of control and i have to focus on the stuff that I use and the community uses. At the moment there are:
KeePassPPC for: PocketPC 2003, Windows Mobile 5.0 PocketPC & PhoneEdition - Square screens not supported
KeePassSD Viewer for: PocketPC 2003, Windows Mobile 5.0 PocketPC & PhoneEdition, Windows Mobile 5.0 Smartphone
These versions come from three different source-trees: KeePassPPC, KeePassSD_sp, KeePassSD_ppc.
And you can imagine that this tends to be a bit too much maintenance effort. Especially applying the same change to the C++ MFC code of KeePassPPC and then inventing the same wheel again for the .Net CF 2.0 C# code of KeePassSD is a bit of a pain in the back. Also it seems to be pretty impossible to use one source across all platforms.
So unless some C++ and/or C# developer joins me in my efforts, keeping all these versions alive is a bit difficult. There are also other things to do than spend your spare-time in front of the PC, especially if that's what you do for a living in the job as well *grin*.
Also note that my C# knowledge is on a very beginner level, so i would really not mind if some skilled person could help here and there.
Please take part in the vote. I have a hunch that the Smartphone version might win, but lets see how it turns out.
Hi and thanks for this great software!
For your poll I recommend you somewhere clearly show the differences of your 3 versions (small comparison table?) and what these differences mean for the end user and for the safety aspect.
Well from a "safety aspect" all versions should be the same. I am no big shakes with cryptography so my small contribution in this game is just to use Daniels encryption libraries as is and put a GUI for the PDA on top.
I thought the poll was quite self-explaining, well maybe i was wrong. Ok so here is a little explanation:
KeePassPPC - MFC C++ application based on Donchos original KeePass port.
This version can only support PocketPC devices with touchscreen.
That means: PocketPC 2003(SE), Windows Mobile 5.0 PocketPC & PhoneEdition.
Smartphone devices can't be supported.
The code will run pretty fast, but the decoupling of the KeePass library from Daniel
and the GUI is not very good. This is a big monolithic jumble-up of code, which makes
it quite easy to mess up things and potentially add security leaks.
KeePassSD - The idea is to have a clean separation between encryption library and GUI.
So all that really happens is: Daniels original KeePass libraries are compiled as a
C++ DLL. The C++ DLL is then being called by a separate application. That way there
is a defined interface between DLL and GUI which should make it much easier to maintain
the code and keep things "clean".
Of course the application calling the DLL could be also written in C++ now. However I
thought i give C# a go. It is a really nice programming language and it can avoid a lot
of problems an unskilled programmer can have when writing C++ code (Yep, that's me! I
really live in ANSI C land usually poking registers on an embedded system).
C# applications written with Visual Studio 2005 run on top of the so called
.Net Compact Framework, which is a kind of sandpit execution enviroment for applications
similar to a Java Virtual Machine. The idea is: No memory leaks, no access violations,
no crashes. The .NetCF should make all this impossible.
An application running in this virtual machine enviroment can call native OS functions
via the so called PINVOKE. Again thanks to Daniel there is a C# wrapper for KeePass,
so the GUI can call into the KeePassLibC.dll and use it as is.
The .NetCF 2.0 exists for PockerPC 2003(SE), WindowsMobile 5.0 PocketPC,
PhoneEdition & Smartphone. Due to the differences in the GUI - PDAs are controlled via
touchscreen and Smartphones completely via the keyboard - there will be two different
versions, but the major part of the code should be identical. So with a manageable amount
of work, we get a Smartphone version as well. Also in C# many common GUI problems are
very easy to solve. So hopefully adding a new feature will take much less time, than adding
the same feature for the KeePassPPC version.
The con side of using the .NetCF 2.0 is:
It still is quite slow on startup. Especially loading image resources takes a while.
From a security perspective my only concern is, that the garbage collection which deletes
no-longer-used-data runs at any point in time. So some additional code to
overwrite/erase/fill discarded data with some random values is maybe a good idea.
Another point might be that some evil application specially written to highjack KeePass
databases could be linked between GUI and the DLL. This is the price to pay for a clean
interface. If there is a clean interface, people might try doing nasty things.
Well, there are countermeasures of course: Add some authentification between C# GUI and
KeePassLibC.dll, but as all of this is open source, anybody can grab the code and build
a specially prepared version, so i don't know if such an exersise would be really worth it.
Hm guess you got more confusing tech talk that you asked for. So in short:
KeePassPPC - Fast, Difficult to maintain, Difficult to add new features, Security risk is the complexity
of the code. Potential bugs lurking everywhere :*)
KeePassSD - Slow startup, Easy to maintain, Easy to add new features, Security risk in the .NetCF
itself and in the managed-unmanaged DLL calls. Smartphone version possible.
I personally didn't vote because I didn't know what's the difference between SD & PPC. Have I read this thread before I would've voted for PPC.
Just some questions / comments...
Hhow "Slow" is slow ?
If it's 2x, probably not a biggie as today it's near instantaneous on my WM5 device and I assume on others' as well (I don't have an 80mb database ;)
However if it's significantly slower, say it takes at least 4-6 seconds to open pretty much anything, then it loses one of the main attractive points over alternative methods (e.g. using an OTFE container to store passwords).
Also you call it "KeePassSD Viewer", does it mean it won't be able to add/edit entries ? To me, this would be a major problem. (I am only speaking for myself, but I am probably fairly representative of most users).
Please don't view this as criticism - you're helping a whole lot of people, and it's ultimately your decision in the end.
Well the major problem is the startup-time of the .Net Compact Framework 2.0 itself. Once that runs you won't see any difference between KeePassSD and KeePassPPC.
So one thing that i'd like to add for KeePassSD is a propper Auto-Lock, where the database is locked, when the application is put in the background. That way you can leave it running and don't have the hit of the startup delay whenever you want to look at the database.
If one decides to go with the .Net Compact Framework only the application startup time iself can be influenced. The compact framework startup time is something only Microsoft can reduce.
You can compare it with a Java applications: The JRE has to startup before any Java application can run.
It's called a Viewer, because the first Alpha version will just be a viewer application. Of course it will be possible to add/delete/edit entries in the long run. However i have to start "small" and before messing up everybodys database with untested C# code a Viewer application is probably a reasonable first step.
There are a lot of people out there with Smartphones and if they are given the choice between no KeePass at all and just a viewer, they most probably will go for the viewer :-))
A comment on using .NET2CF's slow start up time. I would have to say that it is probably a non-issue. I already have two (2) other application that requires the .NET2CF. And as new developers start coding for WM5 or SD, I'd say they'd probably will also use .NET2CF as well due to it's features (no memory leaks, no access violations,
no crashes, etc.) -- no one wants their application to crash the OS and lock up a device; bad business all-around.
P.S. How does .NET2CF help in dealing with different screen sizes & orientation?
Yes well I - the developer - totally agree with you, that the benefits of the .NetCF are greater than a slightly longer startup time. Especially if i manage to add the auto-lock feature so that the application can be kept running in the background. Also code maintenance is much easier for me. Maintaining a C# application i have written myself is much easier than to try to add fixes to "foreign" C++ code i inherited from Doncho. Only drawback is that Smartphone and PocketPC/PhoneEdition still require a separate GUI.
Well at the end the new KeePass windows version is also a .Net Framework application written in C#. So the only way to keep database compatibility is to also go forward with a .Net CF 2.0 application.
The unfortunate/fortunate truth is, that there will be a hard cut:
* KeePassPPC is compatible with KeePass V1.06
* KeePassSD should be compatible with KeePass V2.0
There is NO WAY to make the C++ source or KeePassPPC compatible with C# KeePass V2.0.
Or in other words: The effort to do this is much higher than to write a new GUI in C# using the .Net CF 2.0 from scratch.
P.S.: Screen orientation is not a problem, as all GUI elements are "docked" and automatically stretched/resized accordingly when the screen size changes. Square screens are also not a big problem, if you design the forms in a way that all GUI elements fit on a square screen and when run on a non-square device the important elements are stretched to fill the whole screen.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.