The purpose of this work is to eventually encorporate all the useful features into a pre-existing tool such as sfdisk. I see no reason why another tool or suite of tools needs to be included to the large range of existing programs available in a standard release of Linux.
First possibility
Current position
The Parts group of routines are built for Linux since they handle the device (ie. hard disk) as a file, which is not supported in DOS (However this is not considering the possibility of virtualising).
Next step
Once the prototype is finalised I will begin work on a standard C release for Linux. The main reason behind rewriting Parts in C is to then replace the components that perform the reading and writing to the device with EIDE calls so as to have a release available for DOS systems. For example make a FreeDOS bootdisk available with the Parts tools so as to make things as easy/simple as can be.
Dare I say, the final step
Once the command line based routines are all provided I think it would be worth providing a GUI as a front end to the underlying routines. I suppose there are two possibilities either create independent GUI's one for Linux, one for Windows... Or simply provide the one GUI available in... well Java seems like a good choice.
Second possibility
On the other hand
Instead of making the tools available on several different types of systems ie. Linux, DOS... if I just stick to Linux I can't think of any reasons why anyone would be being left out. I think the most likely course of action will be to get Parts working as well as it can and then with nothing more to do on it, look to building the DOS/MS Windows based release.
Not built
The routines that are currently missing are Partsmake and Partsfind, forgetting about the GUI of course.
Since Partsedit is no angel when it comes to doing anything major to the partition table due to the sheer detail required. Now hang on a second I'm not thinking of providing a standard partitioning tool like fdisk am I, well the answer is perhaps. You see Partslist & Partsedit are designed to deal with situations where other tools keal over, malfunction or simply, well lie, but the majority of the work is already done. The idea behind providing Partsmake is to bypass inferior routines and get the job done right, first time everytime. I think I'll hold off on Partsmake and wait to see if there is any real need for it, I'm more than willing to build however I don't think there'll be any need for it if or when build the Parts functionality in to a tool such as sfdisk.
Partsfind is intended for when the !@#$ has literally hit the fan and you have to resort to a brut force search in an attempt to recover your data. Now admittedly once again tools already exist to do this such as gpart. I have done a little looking around at the issue and I'm thinking about looking into the programming of gpart. If I feel there are still some significant things that can be improved upon, at some stage, I'll start on it :)