tomas-nestorovic / ride Goto Github PK

In most of the cases, the main RIDE thread creates a worker thread that carries out some task with a container, e.g. the data dumping thread. The main thread then just spins in the Windows message loop, eventually doing nothing, waiting for the worker to complete. So in most of the cases, containers are accessed from within just one thread (main thread or a single worker thread).

However, if switched to the Track Map tab with its own worker thread, there now can be two workers that might want to access a single container simultaneously. At this moment, such uncoordinated access can lead to memory leaks (container is commanded from two threads to create the same cylinder), memory corruptions (container is commanded to dispose the same cylinder from two threads) and generally data inconsistencies (one thread commands floppy head over Cylinder 5, the other over Cylinder 13, and then both receive some random data, if any).

Synchronization assets should be used to prevent from above sketched problems.

It might be a good idea to add browsing of image/disk raw sector data in existing hexa-editor (e.g. through a new Image → Browse in hexa mode command).
Apart of this basic functionality, another useful commands might be accessible from the File Manager's context menu for individual files:

• ✔ Go to directory entry,
• ✔ Go to first data sector (available only if any data really exist, e.g. zero-length files in MS-DOS don't have any).

This topic includes everything around current implementation of the File Manager. This, however, excludes any modifications tailored for a particular DOS - these should be committed in their own issues.
The general modifications of the File Manager should include all of these improvements:

• creation of a mechanism to allow user to choose which columns they want to see, hiding all the others,
• creation of a directory tree, ideally dockable on either on the left (default as in Explorer) or on the right, or hidden altogether,
• information on current selection should be shown in the status-bar (e.g. at least the count of items selected),
• history of folder browsing for current session (like in a web browser, possibility to "go back" and "go forth"),
• the Backspace key should correspond to going to the immediate parent folder (if any, e.g. root directory); this should, in general, be a different action from the above "going back" like in a web browser,
• items that are to be cut should be marked, e.g. with brighter text color like in Explorer,
• ✓ there should be a context menu for each item, allowing common actions like copying, cutting, pasting into, but also actions like displaying the underlying directory entry, or navigating to the first sector of the file,
• if there are any issues with the directory (e.g. some of its sectors are not found, or are marked as bad, or are read with error), the status-bar should indicate such condition in red color,
• file search, including wild chars, e.g. "*.jpg" etc.,
• ✓ the Insert key toggles the selection status for the currently focused file and moves the focus to the immediatelly following file (if any),
• implementation of simple breadcrumbs (e.g. using the SysLink control).
• color the background of "File name" and "Extension" columns with light gray as in many file-handling applications, e.g. WinRar

Here should come anything on TR-DOS implementation that doesn't regard big new features and doesn't regard critical bug fixes. Instead, this issue should focus on the following minor changes to the source code for which it's not worth creating a separate issue:

• source code readability improvements (indenting, formatting, etc.),
• commentary improvements (typos, English, clarity, etc.)
• syntax improvements,
• etc.

Similarly as under real ZX Spectrum, CapsLock key should be taken into account when typing. It's suggested to introduce the "C" mode into the filename editor, CSpectrumDos::CSpectrumFileManagerView::CVarLengthFileNameEditor. Modes should be switched between as they are now, except that the new "C" mode should be interchangeable with existing "L" mode as follows:
{L/C} - E - G - K.

So far, George K's File Manager (GKFM) existing data can only be read from and modified in the MDOS disk boot sector. It might be a good idea to also support the creation of these data, e.g. through a button next to the "Status: Not recognized" item in the PropertyGrid, indicating that GKFM is not present on the disk. Once such button is pressed the existing dialog regarding GKFM is shown with default values. Once the dialog is confirmed, the data in the boot sector are created.

Methods that serve as "interface" to DOS file name and/or extension retrieval and modification cannot contain DOS-specific characters - Windows native C-style strings are a too weak means to represent them (see the below CDos class declaration snippet).

class CDos
{
    typedef TStdWinError (CDos::*TFnCreateSubdirectory)(LPCTSTR name,DWORD winAttr,PFile &rCreatedSubdir);
    typedef TStdWinError (CDos::*TFnMoveFileToCurrDir)(PFile file,LPCTSTR fileNameAndExt,PFile &rMovedFile);

    virtual bool GetFileNameOrExt(PCFile file,PTCHAR bufName,PTCHAR bufExt) const=0;
    PTCHAR GetFileNameWithAppendedExt(PCFile file,PTCHAR bufNameExt) const;
    bool HasFileNameAndExt(PCFile file,LPCTSTR fileName,LPCTSTR fileExt) const;
    virtual TStdWinError ChangeFileNameAndExt(PFile file,LPCTSTR newName,LPCTSTR newExt,PFile &rRenamedFile)=0;
    PFile FindFileInCurrentDir(LPCTSTR fileName,LPCTSTR fileExt,PCFile ignoreThisFile) const;
};

A more robust way to represent, for instance, null-character (0x00), valid in all Spectrum platforms, should be created. Moreover, the C-style character arrays are unsafe - buffer overrun at stake!

It's thus suggested to create a new data type encapsulating both C-style character array (big enough to accommodate a valid Windows long name) along with the count of valid characters in it. To indicate the constrained usage, it's further suggested to name this data type CPathString.

After migration to new implementation of the PropertyGrid, the instance of PropertyGrid in the Boot sector tab remains editable even if the disk or image are write-protected. The correct behaviour is being not able to edit values in the PropertyGrid while the disk is write-protected.

Offering {K,L,E,G,C} modes, the line composer enables the user to create a line as they would on a real hardware. For instance, switching to the E mode and pressing the Z key, the LN keyword appears.

There are currently some imperfections to the CSpectrumBase::CLineComposerPropGridEditor class.

• Non-printable characters are not displayed. This is a major drawback as non-printable characters may appear in tweaked header files, particularly in name field. For instance, the name of the program of the Skull and Crossbones game is (hexa-decimally) 0x16, 0x01, 0x00, 0x53, 0x4B, 0x55, 0x4C, 0x4C, 0x06, 0x20. When loading, the name of the game looks as follows.
  
• Non-printable characters cannot be typed in. To solve for this, a new mode "X" should be introduced in which user can type in hexa-decimal numbers, which immediately translate to corresponding (printable) characters, UDG graphics, or keywords.
• The content doesn't scroll horizontally. It's thus impossible to edit the line "beyond" the visible rectangle. Instead, the line should be horizontally scrolled so that the cursor (and a bit of the line before and after it) is always visible.
• The cursors {K,L,E,G,C} are just a painting. It thus may lead to confusing situations in which there are suddenly two "cursors" on the screen - one in the line composer component and one in another component (e.g. hexa-editor). Instead, the cursor should be represented as a caret, so that it's guaranteed that at any moment there is just one "cursor" on the screen.
• The editor is mouse-unaware. When clicked into the line content, the ZX cursor should be positioned so that it's as close to the mouse cursor.

Currently, the volume labels in boot sectors of MDOS and TR-DOS disks are edited using the standard text editor built into the PropertyGrid. This functions well but the labels cannot contain Spectrum keyword tokens (and possibly other features added in the future to the Spectrum line composer editor). For instance, a disk version of Return to Doom game might had the label "RETURN TO DOOM" where the words RETURN and TO would actually be Spectrum standard keywords (so the text would actually occupy just six Bytes in the label field).

It's thus suggested that the specialized "Spectrum line composer editor" is used at place of the PropertyGrid's default text editor to enable the above tricks in the label fields.

Each of implemented DOSes currently lacks the functionality of verifying disk integrity, usually under disabled menu item DOS → Verification.

This issue aims to prepare the necessary general foundation so that disk integrity of each DOS can be easily implemented without the burden of paying attention at recurrent details (and logical action flows) that may arise when implementing the verification for individual DOSes. This issue should thus give the following common assets, leveraged by all DOSes:

• A dialog with options of what integrity checks are possible and where the user could interactively choose which ones to perform, just a little bit detailed than the following one.
  
• A progress window in which particular action currently running is displayed in bold in a list of actions to perform (and eventually with additional note under it), in similar fashion as the following Windows 95 dialog. Naturally, modern assets must be injected into the window appearance (e.g. more advanced layout, or thread priority selection).
  
• A disk surface checker thread, common for verification in all DOSes. The range of sectors checked for readability (and eventually writeability) should be constrained to only those part of the current volume (e.g. MS-DOS disks may contain more volumes).

The following problems have been found:

• Some DOSes in their CDos::ValidateFormatChangeAndReportProblem implementation may want to not only validate the new format but also adjust somehow the boot sector or FAT length (e.g. BS-DOS). However, the problem is that checking whether cylinders to reformat or remove are empty comes after the CDos::ValidateFormatChangeAndReportProblem method is called - this may put the disk into an inconsistent state. The correct behavior should first check whether cylinders are empty, and afterwards call the CDos::ValidateFormatChangeAndReportProblem method.
• The CDos::ValidateFormatChangeAndReportProblem method is sometimes called with incorrect parameter describing whether the disk is being formatted from scratch or just partly adjusted (cylinders reformatted or removed).
• There is no need to compile a list of tracks to format or remove. Tracks are not formatted randomly - instead, they are formatted in consecutive blocks (e.g. Cylinders 3 to 5, all heads).
• Different DOSes use different values to mark standard sectors from removed tracks "unavailable". For instance, MDOS marks them Unavailable, whereas BS-DOS marks them Unknown. When removing tracks, it should be specified with which value to reset corresponding part of the FAT.
• On failure, sometimes the reported error is ERROR_SUCCESS which makes no sense (probably a missing call to ::SetLastError).

There are two major cosmetical issues:

• Redundancy. To edit, for example, a 16-bit value, one must add an item for which the size of value has been declared to be 2 Bytes, and at the same time attach an 16-bit editor. There's no need to explicitly declare the size of the value for each single item - the size is given implicitly by the editor used to edit the value.
• Encapsulation. To distinguish between editors, their respective creation functions are encapsulated as static members of sealed structures. A better way is encapsulating them in namespaces.

Here should come anything that doesn't regard new features and doesn't regard big bug fixes. Instead, this issue should regard the following minor changes to the source code for which it's not worth to create a separate issue:

• source code readability improvements (indenting, formatting, etc.),
• commentary improvements (typos, English, clarity, etc.)
• syntax improvements,
• etc.

Some users complain that they must be always connected to the Internet it they want to access application's help pages, available only on-line. It thus might be a good idea to cache all application-related web pages browsed on-line.

With this modification, an incoming request to display an application-related web page should

• first, try to retrieve it from an on-line source,
• if unavailable (e.g. computer not connected), a cached webpage should be displayed with warning that information in it might be outdated,
• finally, a standard "Page not found" message should be displayed.

This topic includes everything around current implementation of the Track Map. This, however, excludes any eventual modifications tailored for a particular container (e.g. KryoFlux in the future) - these should be committed in their own issues.
The general modifications of the Track Map should include all of these improvements:

• ✔ zooming sectors in and out (for instance for the whole track to fit in the window width),
• add legend on which color represents what kind of sector (e.g. purple means system sector, blue means occupied one, etc.),
• add "cursor" to show on which sector the cursor is currently hovering (to facilitate interpretation of information shown in the status-bar),
• show FAT path along with its eventual error (black if FAT path OK, red otherwise),
• add settings of Track Map tab; one of them should be the color of rectangle drawn around belonging to files selected in the File Manger, the other setting should be whether the rectangle should blink,
• ✔ add horizontal scroll-bar,
• add command "Go to cylinder"; in the shown dialog, add check-box to "Show the cylinder on top of the window, if possible" (otherwise show it in the vertical centre of the window) - a handy option for working with real media,
• add option to group by cylinders (the default) or heads,
• ✔ add display of timing of sectors on each track,
• add "double-view" on the same data (e.g. as in Visual Studio one can have two views at the same source code),
• ✔ add "Ignore file selection" option to speed up the drawing if the directory, from which files have been selected, contains too many files,
• usage of the Header common control to display the labels of columns, which remains always on top

Currently, each of DOSes implements its own way of how to search for a healthy sector that is reported empty (unallocated to any file or directory). Virtually all of the DOSes use a common strategy to find an empty healthy sector - they import an artificial single-Byte file to the disk using CDos::__importFileData__ method and retrieve the sector allocated to this file via CFatPath::GetItems method. This approach should thus be made a common functionality available to all DOSes via CDos class-based method.

Apart of previewing a file in binary mode and as a "Screen$", it might be useful to preview a file as a Spectrum BASIC program. This listing should support in-program colouring of text (incl. ink/paper/bright/inverse attribute changes).
In the first step, mere listing as plotted above should be added. In the second step, a listing of in-program variables should be added.
Allowing modifications of the program and variables is not needed (as it's not needed to draw into the "Screen$" preview).

Here should come anything that doesn't regard new features and doesn't regard big bug fixes. Instead, this issue should regard the following minor changes to the source code for which it's not worth to create a separate issue:

• source code readability improvements (indenting, formatting, etc.),
• commentary improvements (typos, English, clarity, etc.)
• syntax improvements,
• etc.

The application is developed under nowadays older version of Visual Studio 2010. There are reported problems with compilation under newer versions of Visual Studios, e.g. the latest 2017 version. It might be a good idea to fix the compilation issues so that the statement "Simply click Build → Build Solution while having selected either the Debug or Release configuration, and that's it", advertised in the application introduction page here on GitHub, holds.

Internal 5.25" floppy drives are known to be physically present as drives B: on a typical retro computer. To mediate access to them, a new switch in the "FDD access options" should be added, allowing to select either Drive A (usually 3.5") or Drive B (usually 5.25").

This way should also be fine with the idea of allowing direct dumping/patching between floppies inserted at a time in drives A and B (e.g. because they are both 3.5", or because they have common geometry).

It musn't be fotgotten to change the hyperlink caption in the Open dialog from current "Access floppy inserted in internal drive A" to "Access floppy inserted in internal drive A or B".

This topic includes everything around current implementation of the CBootView base class. This, however, excludes any modifications tailored for a particular DOS - these should be committed in their own issues. The general modifications of the Boot Sector tab should include all of these improvements:

• possibility to add to the property grid the cluster size and sector size already at the CBootView::GetCommonBootParameters method level (instead of adding these manually in the CBootView::AddCustomBootParameters method),
• highlight in the hexa-editor regions of the boot sector which cannot be modified but through the property grid (e.g. the number of sectors on a track),
• highlight in the hexa-editor regions which correspond to values in the property grid (e.g. by hovering on the value in the property grid),
• add possbility to verify that the boot sector is still recognizable after the user has made some changes to it (e.g. through a main menu or through a toolbar),
• add a new column to property grid showing the beginning of the value in boot sector,
• other minor improvements that might increase the usability of the Boot Sector tab.

Some users think that dropping an image file over the File Manager will import files contained in that image. It thus might be a good idea to inform them that they are about to import an image file and offer them to open the image in a separate instance of RIDE for the purpose of exchanging files between the two images.

Along with existing TR-DOS implementations, it might be a good idea to also add support for the latest official release of TR-DOS 5.05.
Opening of a *.SCL image should offer a dialogue in which all of the implemented TR-DOSes should be offered for "interpreting" the contents of the SCL image. Although this might seen unnecessary, there are known TR-DOS versions which don't swallow disks created under other versions of TR-DOSes (e.g. TR-DOS 5.04T).

Normally unoccupied sectors in the system track are reserved for special purposes, e.g. when creating a snapshot. There are, however, known cases in which these sectors contain files (e.g. Boot.B in the Mirror game). Such file layout is usually accompanied by other copy-protection assets.

It thus might be a good idea to allow importing to zeroth system track to make filesystem tweaking easier, e.g. using a new switch in TR-DOS menu. Turning this switch on would enable importing to system track (preceeded with warning on entering a serious DOS setting). It should not be possible to turn the switch on when there already are some files on the disk or in the image. Contrarily, turning the switch off should be possible at any time (be or be not there any files on the disk).

So far, many general improvements of the built-in hexa-editor have been "sticked" to either Issue #6 or Issue #13 or Issue #30. To keep all changes at one place and thus increase traceability, all general improvements and bugfixes that don't relate to any special functionality (e.g. currently Issues #6 and #30) should be committed to this thread. For any new special functionalities, new issues should be created instead of committing the changes to the general Issue #13.

If an image with sectors with the same ID Field on a single track is dumped to a real floppy (e.g. the first and last sector in Cylinder 5 on Side A image of The Untouchables), the later duplicated sector doesn't seem to be rightly addressed. This can be seen in the Track Map of the floppy the image was dumped to.

If a 2DD floppy disk has already been formatted, reformatting it functions well (e.g. via the Image → New command). However, if a 2DD floppy has not been formatted at all before (or if just its zeroth track is not formatted or damaged), such floppy fails to format, resulting in ERROR_INVALID_DATA ("The data is invalid") error. This error hasn't been observed for HD floppies, so the problem seems to be a residue of disk density determination sequence, in which an unsuccessfull 2DD density reading attempt is followed by HD density reading attemt (which remains set after that).

Currently, the Spectrum tape class (in CSpectrumDos::CTape) is derived from CDos, thus not easily leveraging assets that CSpectrumDos offers to disk systems - actually, the disk system must manually forward all requests that a tape may want, which is inefficient and error-prone. Apart of that, a Spectrum tape's CSpectrumDos::CTape::GetFileExportNameAndExt method doesn't well encode unprintable characters and doesn't preserve Spectrum keywords - such functionality is provided by CSpectrumDos class, not by CDos.

It's thus suggested that functionalities common for all Spectrum-based media be extracted to an intermediate class called CSpectrumBase, from which both CSpectrumDos and CSpectrumDos::CTape are derived. The same idea is valid for CSpectrumDos::CSpectrumFileManagerView - an intermediate CSpectrumBase::CSpectrumBaseFileManagerView should be introduced, stripped off of disk-specific functionalities.

If dumping to an already formatted floppy, it seems unnecessary to format it once again during dumping. It might be a good idea to add a checkbox to the Dump to destination dialogue indicating user's wish to format the target medium. If the medium is an image, the checkbox should be in a non-modifiable checked state (always format), whereas if the medium is a floppy, the checkbox should be modifiable and un-tickable.

Mouse wheel interaction hasn't been explicitly implemented - all support actually comes from MFC's out-of-the-box solutions. However, for windows that don't derive from MFC windows, or derive from MFC windows that don't support it, the mouse wheel interaction doesn't function. This is for instance the case of the CHexaEditor class that implements the built-in hexa editor. Another case where the mouse wheel doesn't function is traversing the ZX Spectrum screens (the "Screen$" window implemented in CSpectrumDos::CScreenPreview class).
There may be also other undiscovered cases beyond the above two. They should all be fixed in scope of this issue before it's closed.

The Creator field in DSK header is currently set to empty string (unlike with all other tools that support DSK). It might be good idea to set it to this application name, or eventually allow the user of RIDE to sign it with their name.

As there are few tools to extract tape blocks from sound files (e.g. just ZXwav2tap and Taper, to name the only discoveries) it thus might be a good idea to add a native support for this functionality. As a starter, only raw sound files (WAV, VOC, IFF, etc.) should be supported. The application should analyze the sound and extract available valid blocks from it (with correct and incorrect checksum, and fragments). Here is a tutorial to getting started with the analysis. Apart of the basic functionality, these advanced features were suggested:

• The implementation should visualize where leader tones (and other kinds of tones) were recognized. It ideally should also display the bits which were recognized from individual half-waves similarly as some oscilloscopes do when decoding RS232 and other kinds of signals (e.g. this one by Rhode & Schwarz).
• The implementation should emphasize places which might be the cause of eventual error. For instance, it should be easy to display half-waves whose frequency is unexpected in a given context (e.g. out of tolerances for 0 and 1 bits).
• The implementation should allow manual adjustment of half-wave frequencies (and dynamically recalculate the checksum for non-fragment blocks). The motivation is that sometimes, the physical tape is stretched (e.g., due to the tooth of time) and it's necessary to slow down some part of the recording.
• The implementation should allow manual insertion/deletion of bits. The motivation is mainly the archiving: saving what can be saved. For instance, it's better to lose a part of a picture (which can be reconstructed by a skilled human archivist) than lose everything; the same holds for text. It's questionable whether the same approach can be used for code, but a human has at least a chance - the computer doesn't. If implemented, this feature would be brand new in the realm of decoding software!

With the development of universally usable verification functions (see Issue #45), it would be desirable to use these universal functions and implement remaining custom ones for verification of MDOS 1.0 and 2.0 disks.

Similarly as with George K's File Manager for MDOS it might be a good idea to add support for similar boot applications for TR-DOS, e.g. CygnusBoot and eventually others.

The current state of file size retrieval suffers from two main problems:

• method names (after a while it's not clear that, for instance, CDos::__getFileSize__ returns the number of occupied Bytes, that is number of effective data Bytes plus eventual metadata before and/or after these data, as TR-DOS and GDOS have), and
• file size retrieval isn't unified (each DOS implements its own approach to file size determination, most notably the implementation of TR-DOS).

As a consequence, there are several implied problems in various edges of the application:

• the listing of GDOS Basic program interprets even prepended metadata as Basic program,
• the listing of TR-DOS Basic program interprets appended metadata as Basic program (similarly as when the Export whole sectors checkbox is ticked),
• GDOS wrongly determines the space files really occupy the disk,
• GDOS wrongly compares the sizes of files (when commanded to sort them by size in the File Manager tab),
• the statistics on selected items (File Manager → Selection → Properties) wrongly determines effective and real size of files on the disk.

So the way file size is determined should be reworked and all of the above listed problems fixed in this issue.

For common purposes, visualization of date and time of files should be added, informing the user on when a file was created, last read, and last written to. These values should be, upon request, automatically modified by the application. For eventual filesystem tweaking purposes, possibility to manually modify (or remove altogether) these values should be added.

Whether an instance of this application is up to date or not is currently determined by downloading the usingLatest.html and checking the <title/> tag. If it contains a string that matches given application instance's version, the page is shown, informing on using the latest. If the tag contains any other string, the application loads and shows the usingOld.html website instead, informing on being outdated.

The problem with this approach is that I usually forget to immediatelly change the <title/>, so the usingOld.html website is shown even if running the really up-to-date version. It thus might be a good idea to determine the application's recency not from the <title/> tag but through a direct connection to GitHub (tutorial).

Currently, only very basic values are displayed in the Boot Sector tab of MS-DOS - even the intrinsic Label value is missing, for instance. To comply with the application's idea of displaying "ALL available information for a given platform," it might be a good idea to add the missing values. It will be necessary to distinguish between {FAT12,FAT16} and {FAT32} as these two groups are represented slightly differently in the boot sector. As there is a lot of values, another good idea might be to classify them as "standard" (safe to modify) and "advanced" (modifyable with caution).

During implementation of the MS-DOS filesystem, this document was used. The same document seems to provide detailed-enough information to present the values to the user.

Apart of currently existing support of George K's File Manager (GKFM), the application should also offer the remaining two mainstream alternatives for it, namely the UniRUN (predecessor of GKFM, also by Proxima) and Booter (a competitor of GKFM, by Jan Hanousek Computer Software).

Humble feature request to implementation of *.mbd image format of MB-02 disk interface which is pretty straightforward and well documented.

Can you please create a new release? This is a really interesting project and since the release 1.4.6 you added several new features and improvements. But unfortunately, I can't compile it myself. (I'm using Linux, but it seems it works with Wine so far.)

Currently for a DOS selected in the New image dialog, containers are filtered by their "compatibility" with the formats required by the DOS (e.g. by the capability to store data by cylinders or sides, or by the sector length). However, it's quite confusing for some users to see a Didaktik *.D80 image when they select MS-DOS, for instance. It thus might be a good idea to preselect a "typical" image for each of available DOSes (e.g. *.IMG, in case of MS-DOS).

An even better solution might be to preselect the image and draw its name in bold to distinguish the "typical" image from the others.

Here should come anything on MS-DOS implementation that doesn't regard big new features and doesn't regard critical bug fixes. Instead, this issue should focus on the following minor changes to the source code for which it's not worth creating a separate issue:

• source code readability improvements (indenting, formatting, etc.),
• commentary improvements (typos, English, clarity, etc.)
• syntax improvements,
• etc.

It's been spotted that some phrases are not completely clear while some other contain grammatical bugs. It may be good to completely revise the String Table, add textual descriptions to new commands, and fix English grammar.

Currently, a raw image cannot be dumped unless it's recognized by one of implemented DOSes (this doesn't hold for images with internal organization of sectors, e.g. DSK images). It might be a good idea to allow manual setting of raw image geometry in case that it hasn't been recognized by any of implemented DOSes. This would easily allow for dumping such raw images to a floppy or to other containers, and extend the application's usability for platforms that are currently not supported (e.g. HP disk systems).

The access to a floppy disk inserted in the floppy drive is unnecessarily inefficient when dumping the floppy contents to an image:

• The dumping thread has the THREAD_PRIORITY_IDLE. Instead, at least THREAD_PRIORITY_NORMAL should be considered to improve the throughput from/to the floppy drive. Also, the THREAD_PRIORITY_TIME_CRITICAL might be used upon user's consideration.
• If a floppy is already formatted it sounds reasonable that there's no reason to format it once again during dumping (e.g. to a TR-DOS structure). Instead, the user should be given the possibility to skip formatting if they know for sure that the disk is already well formatted.
• Other improvements may be considered over time.

For debug purposes (and interested users) it might be a good idea to implement a preview of current directory entires. The preview should be accessible from within the File Manager tab (a new menu item). The preview should appear as a new tab in the main window's TDI. From the technical point of view, it should be just a simple wrapper around the existing CHexaEditor with "records" representing individual directory entires.

Emulators which emulate hardware like for instance DivIDE, MB-03+ Ultimate, etc., use as a hard-disk image a HDF file. This file is virtually a raw image prepended with a thin header (full specification). Therefore, a new CHDF container should simply extend the existing CRawImage container.

Programs which already support HDF images are HDF Monkey or SamDisk, both open-source.

Some users used to pure dump applications like SamDisk or MagicISO complain that the application is not well intuitive. For instance, to dump a real disk to an image requires accessing the drive via Image → Open command, followed by Image → Dump command.

To increase user friendliness it thus might be a good idea to add an introductory guidepost window with most recently used files, frequently asked questions, and other handy options quickly available right at the start of the application. Below an illustration of the idea as implemented in Adobe Indesign.