Файловый навигатор fNav

Это потенциально удобно, но в целом не очень хорошая идея.

• Во-первых, ограничение на размер 18x18 и 32x32, а в программе размер может быть и больше, и меньше, к тому же, libimg и так уже используется(курсоры мыши ведь ещё).

• Во-вторых, "unpacked icons16.png with filled background by a working color" — как, можно заметить, иконки, используемые в списке файлов, имеют совсем другие цвета заливки: белый и синий — перекрашивать придётся в любом случае.

• В-третьих, на сколько помню, после завершения процесса ядро автоматически очищает все хендлы, дескрипторы и т.п., это означает, что придётся постоянно держать запущенной программу @reshare, только лишь ради того, чтобы удержать именованную область памяти.
  И это при том, что и так существует ограничение на количество потоков  в системе.

Считаю такое решение в корне не верным.

Вот более правильное решение:
добавить в ядро возможность указания специального флага при создании Shared Memory, который бы говорил ядру о том, что такую память не нужно уничтожать после завершения процесса.
Тогда, можно после вызова @reshare смело её завершить, а именованная память останется.

Говоря проще:

CreateSharedMemory('ICONS18', NON_CLEANABLE);

а теперь после ExitProcess память остаётся доступной.

Нужно это сделать на уровне ядра, чтобы программы не висели зря в памяти.
Заливку цветом считаю мало полезной — заранее не возможно узнать, какой именно цвет понадобится.

Сама идея "вынести общие ресурсы за скобки" — хорошая, проблема только в реализации.
Помнится, раньше похожим способом уже было кое-что реализовано, но, как-то не прижилось решение.

Кстати, а что мешает хранить иконки не в png, а в plain binary сжатый KPACK-ом?
Грузить такое можно с помощью LoadFile(SysFn68.27).
Хотя с таким же успехом можно и в ядро запихнуть, по аналогии с ядерным шрифтом.

Leency, а разве для NTFS уже появилась такая возможность на уровне ядра?
Об этой проблеме известно было и раньше.