+<li><b>Tasks with which non-programmers can help:</b>
+
+ <ul>
+
+ <li>Testing! rEFIt was complex enough that changes such as the ones
+ I've made have the potential to disrupt the program's operation in
+ unexpected ways. Since the initial 0.2.0 release, I've continued to
+ add features to rEFInd, and every new feature is another way for
+ bugs to get into the program. I can only test on a handful of
+ systems with a limited number of configurations. Therefore, if you
+ try rEFInd and run into bugs, please report them to me!</li>
+
+ <li>I have little talent with graphics manipulation programs, so
+ rEFInd's boot logo, such as it is, is pretty weak. If you have
+ artistic talent and would like to create a rEFInd logo, please feel
+ free to send it to me. I won't make any final decision about
+ changes until at least June 30 of 2012.</li>
+
+ <li>rEFIt's original design, and hence rEFInd's design, enables easy
+ theming by replacing icon files. If you'd like to design a new
+ theme for rEFInd, feel free to submit it. I might or might not
+ replace the icons it uses now (most of which come from the Oxygen
+ Icons package), but I may provide links to themes on this Web site
+ (or even host them on the project's Sourceforge page). For more
+ information on designing themes for rEFInd, see the <a
+ href="themes.html">Theming rEFInd</a> page.</li>
+
+ </ul></li> <!-- Non-programmer help -->
+
+<li><b>Improvements to existing features:</b>
+
+ <ul>
+
+ <li>The support for booting legacy (BIOS) OSes on UEFI-based PCs
+ currently has a number of limitations. Most importantly, it works
+ off of the list of boot devices stored in the computer's NVRAM. I'd
+ prefer to have it scan disks and partitions, as the Mac's legacy
+ boot support does. Also, the UEFI legacy boot code presents empty
+ optical drives and uses generic icons rather than OS-specific
+ icons.</li>
+
+ <li>Currently, rEFInd can detect whether it's compiled for <i>x</i>86
+ or <i>x</i>86-64 systems and displays this information in its
+ "About" screen (<tt>AboutrEFInd()</tt> in <tt>main.c</tt>). I'd
+ like to add detection for Itanium and ARM systems, but I have no
+ way to test such changes.</li>
+
+ <li>The code could be more flexible in its handling of the sizes of
+ various graphical elements, and particularly drawn text. Prior to
+ version 0.2.2, submenu text was invisible on UEFI-based PCs with
+ 800x600 and smaller displays because of an inability to properly
+ crop the graphics fields that hold the text. With version 0.2.2,
+ I've put a band-aid on this problem by reducing the field size so
+ that it now works on 800x600 displays, but smaller displays still
+ suffer from this problem. This is just an example of the
+ inflexibility of certain layout issues within rEFInd.</li>
+
+ <li>Although the ICNS file format used by rEFInd supports multiple
+ image sizes, if a size that rEFInd needs isn't present in the file,
+ rEFInd can't use the icon. The ability to scale images to the
+ desired size would be useful.</li>
+
+ <li>I would like to be able to specify the volume on which a boot
+ loader resides using a partition GUID value, but extracting a GUID
+ from the partition data is harder than extracting the volume's
+ label or counting up the filesystem numbers.</li>
+
+ <li>The default_selection option in refind.conf could be improved by
+ supporting a list of default options, so that if the first item
+ isn't found, rEFInd will try to boot the second one in the list,
+ and so on. This could be handy in case a driver fails to load, or
+ to provide an override in case the user inserts a specific
+ removable disk—by placing the removable disk's name first in
+ the list, it will take precedence over the normal hard disk
+ default.</li>
+
+ <li>Along the lines of the previous item, the default_selection might
+ be expanded to support some form of specification of disk types, as
+ in a special entry for any optical disk or any external disk, no
+ matter what its name is.</li>
+
+ <li>It would be useful to be able to specify paths to boot loaders
+ and/or initial RAM disks relative to the rEFInd directory (or the
+ boot loader's directory, in the case of initrds).</li>
+
+ <li>Various options (<tt>dont_scan_dirs</tt>, <tt>also_scan_dirs</tt>,
+ <tt>scan_driver_dirs</tt>, etc.) refer to directories or files,
+ either on the ESP or on all partitions. A way to identify specific
+ partitions for these options would be useful in some
+ situations.</li>
+
+ </ul></li> <!-- Improvements -->
+
+<li><b>Known bugs that need squashing:</b>
+
+ <ul>
+
+ <li>When in Secure Boot mode, rEFInd can launch just one driver that's
+ signed with a shim key or MOK. The second and later drivers
+ generate "access denied" errors. <!-- I think this is because of
+ the fast-and-loose sample code I borrowed from shim, which re-uses
+ rEFInd's own image handle (the <tt>image_handle</tt> variable in
+ <tt>start_image()</tt>) for launching shim/MOK-signed binaries. The
+ result is that when the second driver is loaded, it can't register
+ itself with the firmware because the firmware believes it's already
+ been registered. The solution is likely to involve creating a child
+ image handle rather than re-using rEFInd's own image handle, but
+ this is likely to be tedious to do—see
+ <tt>/usr/local/UDK2010/MyWorkSpace/MdeModulePkg/Core/Dxe/Image/Image.c</tt>
+ for the reference UEFI implementation. --> </li>
+
+ <li>The <a href="http://www.rodsbooks.com/gb-hybrid-efi/">Gigabyte
+ Hybrid EFI</a> has a bug that causes the allegedly case-insensitive
+ <tt>StriCmp()</tt> function to perform a case-sensitive comparison.
+ This causes any number of bugs in file matching. For instance:
+ Changing the case of icon filename extensions (or various other
+ parts of icon filenames) causes icons to be replaced by ugly
+ "generic" ones; and rEFInd sometimes appears in its own menu (the
+ firmware sometimes returns an all-caps version of the filename, but
+ other times returns the filename with the correct case, causing a
+ mismatch if the path includes lowercase elements). Some of these
+ problems can be overcome by converting both strings to be compared
+ to one case before doing the comparison, but others aren't so easy,
+ since I think <tt>StriCmp()</tt> is being called internally to the
+ EFI. In any event, it'd be nice to fix some of these problems.
+ OTOH, this is a workaround for a bug on just one EFI
+ implementation, and a dismal one at that, so I'm inclined to just
+ let it go.</li>
+
+ <li>The Shutdown option works correctly on Macs, but not on UEFI-based
+ PCs. On such systems, Shutdown reboots the computer. This should be
+ fixed.</li>
+
+ <li>The media-ejection feature (F12) should be extended to work on
+ UEFI-based PCs and early Macs. At the moment, it relies on an
+ Apple-specific EFI extension, and I know of no standard EFI way to
+ do it.</li>
+
+ <li>The re-scan feature occasionally produces odd results, such as
+ ignoring new media or keeping old media that have been ejected.
+ This should be investigated and fixed.</li>
+
+ <li>The "scanning for new boot loaders" message that appears during the
+ re-scan feature is primitive. Some sort of dynamic icon would be
+ nice, but perhaps impractical, given the single-tasking nature of
+ EFI.</li>
+
+ <li>On my Mac Mini, launching a shell, returning, and performing a
+ re-scan causes the system to be unable to launch the shell again. I
+ have not observed this behavior on UEFI-based PCs. It seems to be
+ caused by a truncated DevicePath to the shell, which includes the
+ shell's pathname but not the device identifier.</li>
+
+ <li>The code is in need of review to search for memory leaks and
+ similar problems.</li>
+
+ </ul></li> <!-- Known bugs -->
+
+<li><b>New features I'd like to add:</b>
+
+ <ul>
+
+ <li>With the arrival of PCs preloaded with Windows 8 and with Secure
+ Boot enabled, some way to cope is in order. I'm thinking of adding
+ code to limit or prohibit booting of unsigned boot loaders if
+ rEFInd detects that Secure Boot is active, and link with the <a
+ href="http://mjg59.dreamwidth.org/18945.html">Shim</a>
+ pre-bootloader to help handle signing and authentication. I need to
+ research the technical details more, though.</li>
+
+ <li>EFI supports network boots. rEFInd doesn't, but it would be nice if
+ it would.</li>
+
+ <li>There's currently no way to create a manual boot stanza for a
+ BIOS-booted OS. This isn't a big priority for me personally, but I
+ can see how it could be for some people.</li>
+
+ <li>I've received queries about rEFInd's ability to work with Apple's
+ whole-disk encryption scheme that's new with OS X 10.7.
+ Unfortunately, I lack the hardware to test this, but my
+ understanding is that it will work correctly <i>if</i> rEFInd is
+ installed in the ESP rather than on the Mac OS X root partition.
+ See <a
+ href="https://sourceforge.net/p/refind/discussion/general/thread/5c7d0195/">this
+ forum thread</a> for more information.</li>
+
+ <li>I'd like to find a way to enable users to enter customizations for
+ boot options and then save them to the <tt>refind.conf</tt> file.
+ One possible way to implement this would be to have manual boot
+ stanzas override auto-detected boot loader definitions for the same
+ boot loader file.</li>
+
+ <li>It should be possible to override specific auto-detected boot
+ loader settings—say, to disable one specific boot loader or
+ change its icon.</li>
+
+ <li>A way to read boot options set via <tt>efibootmgr</tt>,
+ <tt>bless</tt>, or similar options from NVRAM to add to the boot
+ set would be useful.</li>
+
+ <li>A way to examine and change the NVRAM settings could be useful.
+ This would enable a CD-based boot of rEFInd to fix a broken disk
+ boot. Perhaps this could be done via a separate tool that could be
+ launched much like the shell or <tt>gptsync</tt>.</li>
+
+ <li>I'd like to give the user the ability to set custom options on a
+ single-boot basis, similar to what's possible in GRUB.</li>
+
+ <li>A way to set the color of the font would be useful for theming
+ purposes.</li>
+
+ <li>Going further, the ability to load arbitrary other fonts, ideally
+ in a standard format, would be desirable for theming purposes.</li>
+
+ <li>A GUI configuration tool would be nice, but it's low on my personal
+ priority list. If you'd like to contribute, I prefer something
+ written in a cross-platform GUI toolkit, so that a single code base
+ can be used on any of the major OSes.</li>
+
+ <li>A way to "source" one configuration file from another one would be
+ helpful for some types of configuration scripts. (This would enable
+ overriding options in a secondary file without modifying the
+ default original file, for instance.)</li>
+
+ </ul></li> <!-- New features -->
+
+ <li><b>Improvements to the EFI drivers:</b>
+
+ <ul>
+
+ <li>Drivers for additional filesystems are required. Given the recent
+ shift to ext4fs, that should be the priority; however, other Linux
+ filesystems, UDF, and perhaps others would all be welcome
+ additions. Also along these lines, adding drivers for Linux LVM and
+ RAID setups would be useful, too.</li>
+
+ <li>As detailed on the <a href="drivers.html">drivers page,</a> there
+ are performance issues with the drivers on some systems. I suspect
+ that most "real" computers aren't greatly affected (in my tests,
+ the problem is worst with VirtualBox, and the next worst is a
+ system that uses <a
+ href="http://www.rodsbooks.com/bios2uefi/">DUET</a>). Nonetheless,
+ I'd like to track down the cause and fix it.</li>
+
+ <li>The HFS+ driver returns a volume label of "HFS+ volume", no matter
+ what the volume's real label is.</li>