designPlansGoingForward.txt

    I'm no longer interested in these two, I'll stick the folder-specific stuff in a block allocated chunk on the heap, which will also reduce the number of allocations:
        If static polymorphism for COwnerDrawnListItem works out, these two will become unfeasable, as it'd mean reintroduction of the vfptr.

        1: Refactor CItemBranch into two classes:

            a folder class - will store      the attributes, name, parent pointer, m_rect, m_done, & child vector.

            a file class   - will store only the attributes, name, parent pointer, m_rect, size, & lastChange.


        2: Move "recursive" information out of CItemBranch, and into VISIBLEINFO structure:

            Storing the recursive number of children, size, and number of incomplete jobs is VERY storage intensive.
            
            We can build/gather that information when needed, and cache it.

3: Open file with NtCreateFile, Query info with NtQueryInformationFile, and THEN close the handle with NtClose

    Right now, we have a two/three step process for reading info about a file:
        Open a handle ( via FileFind ), read name & attributes, then close handle
        If the file has FILE_ATTRIBUTE_COMPRESSED, then schedule an operation to retrieve the actual compressed size
            Then GetCompressedFileSizeW opens ANOTHER handle, calls ZwQueryInformationFile, and closes the handle
    
    Will need FILE_BASIC_INFORMATION ( for time and attributes ), and FILE_STANDARD_INFORMATION ( for size )
    
    May need to include ntifs.h or fltkernel.h
    
    Success!
        4: Decouple directory enumeration from the CItemBranch object itself:

            The CItemBranch class is a monster class even without directory enumeration.
            
            The coupling thereof strongly impedes asynchrony in enumeration, which is critical.
            
    
    Partially complete:
        5: Refactor directory enumeration to be entirely asynchronous (step 3 required):

            Niall Douglas, developer of BOOST.AFIO, told me: "[T]he NT kernel really thrives on asynchronicity If you load up queue depth to a hundred or so, it does a really outstanding job of reducing amortised completion times to optimal", in a private email. This makes sense, as Windows can then exploit all sorts of I/O optimizations - it can reorder requests to serve them faster, it can queue them in batches to the disk (Command Queuing), where the disk's internal controllers can optimize - and can make a tremendous difference in (spinning-disk) hard drives.

6: Implement many other tricks from BOOST.AFIO
    
    I'd like to call NtQueryDirectoryFile directly - which requires only a single system call to enumerate all items in a directory, and avoids all sorts of compatibility overhead
    
    The following point is much less relevant, as BOOST.AFIO is now modularized :)
        I'd like to AVOID using BOOST.AFIO itself, despite the fact that it is an incredibly well designed library, because then I'd have to drag the entirety of Boost in with it. Boost is humongous, and I'd like to keep this project small and simple.
    
    
7: Use Direct2D/DirectComposition for rendering:
    
    Direct2D/DirectComposition would enable faster drawing (think of the rendering performance of AAA games), and enable fluid and real-time rendering of the treemap - perhaps even __while__ scanning.
    
    
8: Keep it under 20,000 lines of code:

    Software complexity is a problem, and simpler code is always better. I want to transform this into the best codebase that I'm capable of producing.
    
9: Refactor to use ATL/WTL exclusively, or almost exclusively.

    This will mean SMALLER executables, and faster code. Win-win.

10: For enumerating whole drives, memory map the MFT, then touch each 'page'. The granularity of the cache manager is 64k (see "Windows Kernel Internals", "Cache Manager"), so we need to touch one of every 8 pages.