По поводу папок: из расчета 40 программ, под которые выделены папки это получается порядка 20 Кб. Выкинуть содержимое папок demos и 3d (к содержимому которых я отношусь более, чем негативно) и никто даже не заметит. А в файловой структуре образа порядок и ресурсы программ тогда не будут валятся в одной папке.

Ещё вопрос. Есть ли какие либо ограничения по курсорам, которые загружаются через соответствующую сисфункцию? Я про размер и про глубину цвета говорю в первую очередь.
Если, к примеру, конвертировать курсор, приложенный ниже в cur файл, будет ли система его отображать?

maximYCH wrote:Ещё вопрос. Есть ли какие либо ограничения по курсорам, которые загружаются через соответствующую сисфункцию? Я про размер и про глубину цвета говорю в первую очередь.

Не больше чем 32х32 и 24 бита должно быть изображение курсора. В доке написано формат MS Windows, а он 32 бита, но на на практике только 24 бита воспринимает система. У меня во всяком случае не сработало (правда это было на старом ядре).

maximYCH wrote:Если, к примеру, конвертировать курсор, приложенный ниже в cur файл, будет ли система его отображать?

Можно. Будет работать, если будет таким, как я написал выше (пробовал делать это, в своей невышедшей ещё проге).

Точнее только 32х32. Глубина цвета 1,4,8,24 bpp. Или 32х32 RGBA в raw формате.

SII wrote:любой из трёх подходов: всё сваливается в один файл, всё присутствует в виде целой кучи файлов и всё собирается в малое число файлов

Есть ещё четвёртый подход: держать значки общих действий в системе или стандартной библиотеке. У многих программ есть операции "Вырезать", "Вставить" и т. п. И значки их более-менее стандартизованы. Почему бы нет?

SII wrote:необходимо проверять их физическое наличие и корректность, чтобы при ошибке программа не падала непонятно из-за чего и не вешалась, а явным образом сообщала, чего ей не хватает.

Прекрасно сочетается с предоставлением значков библиотекой. Выиграют, в первую очередь, небольшие утилиты, в которых собственного кода -- раз-два и обчёлся. Если в программе используются только стандартные действия, можно обойтись стандартными значками, что положительно повлияет на размер.

Только не нужно ударяться в крайности и лепить значки на все стандартные действия, вроде "OK" и "Отмена", как вначале сделал Borland. Нет большего маразма, чем лицезреть такие кнопки. Так-то.

Freeman wrote: Есть ещё четвёртый подход: держать значки общих действий в системе или стандартной библиотеке. У многих программ есть операции "Вырезать", "Вставить" и т. п. И значки их более-менее стандартизованы. Почему бы нет?

Да, есть и такое. Просто я выразился не совсем точно: три подхода, если вся поддержка обеспечивается собственно самой программой. В этом же подходе требуется уже определённая общесистемная поддержка (наличие некоей стандартной библиотеки для работы с подобными картинками, которую может использовать любая прикладная программа). Если уж совсем по-хорошему, подобная библиотека должна уметь работать как со стандартными картинками, так и с нестандартными, о которых она каким-либо образом извещается программой (типа, "ищи картинки в каталоге таком-то"). Тогда можно достичь почти полной универсальности ценой некоторого усложнения кода, включённого в эту библиотеку.

Freeman wrote:Только не нужно ударяться в крайности и лепить значки на все стандартные действия, вроде "OK" и "Отмена", как вначале сделал Borland. Нет большего маразма, чем лицезреть такие кнопки. Так-то.

Ну, тут вопрос не такой простой... ИМХО, лучше налепить значки на все действительно стандартные действия, но предоставить задаче возможность подменять их своими собственными (приоритет пользовательских значков над стандартными).

Впрочем один довод в пользу того метода могу показать: если файл с изображениями кнопок панели инструментов, к примеру, будет удален, то программа становится неработоспособной.

Не согласен. Программист должен обрабатывать такие моменты правильно, и если нету картинок, то например заменять их надписями.

...необходимо проверять их физическое наличие и корректность, чтобы при ошибке программа не падала непонятно из-за чего и не вешалась, а явным образом сообщала, чего ей не хватает.

Обязательно. Это банальная "защита от дурака".

s1n wrote:если нету картинок, то например заменять их надписями.

Подумал о том же. Опять же, прекрасно выносится в библиотеку.

Я вновь вынужден повторить свой вопрос.
Как сделать так, что бы из любой программы, в которой была строка вида Извлечь это значение?
Буду особо благодарен за код.

maximYCH
Если сама "любая программа" этого не хочет - никак. Разве что ввести новое обязательное поле в стандартный заголовок программы, и переписать под него все приложения.

На самом деле можно размещать в коде уникальный идентификатор в конце упакованной программы и после него свою структуру. Потребуется специальная маркируюшая программа, либо делать вручную в Hex Editor.
Я например так делал в KPACK, который последний под Колибри, чтобы отличать упакованное ядро от распакованного, но некоторым программистам сообщества даже потеря 8 байт дико не понравилась, а ты всякие логотипы пихать собираешься.

Мне ничего не мешает сделать свой образ дискеты, ровно, как никто не мешает сделать бранч

З.Ы. Я не понял - ты написал маркировщик, или ты ручками в HEXе правил?

KPACK маркирует ядро при сжатии. Больше ничего не маркируется - не было необходимости. Да и твои устремления непонятны и вряд ли будут поддержаны остальными разработчиками. Сдается мне ты сам до конца еще не разработал идею в деталях, и даже обсуждать нечего особенно.

Если так уж нужны разные атрибуты, в частности, версия, можно ввести "полутребование" формировать в программе программную секцию с определённым именем, в которой по фиксированным смещениям и будут размещаться все нужные атрибуты. Но для этого необходимо, чтобы выполняемый файл имел в своём составе информацию о секциях, чтобы при загрузке разместить её в памяти и предоставить коду адрес начала этой секции. COFF и ELF имеют необходимые для этого возможности, ну а что используется в КОС, я не знаю. Ну а назвал я это "полутребованием" потому, что на работоспособность программы наличие подобной информации никак не влияет, а значит, она не должна являться необходимой.

KPACK маркирует ядро при сжатии. Больше ничего не маркируется - не было необходимости. Да и твои устремления непонятны и вряд ли будут поддержаны остальными разработчиками. Сдается мне ты сам до конца еще не разработал идею в деталях, и даже обсуждать нечего особенно.

Я хочу добавить в каждую программу строчку с версией, которую можно будет узнать и png иконку 48*48.
Если с версией все понятно, то по поводу иконки:
1) Больше чем 48*48 в системе нигде не используется, следовательно, этого хватит.
2) Формат png выгодно отличается от ico (в среднем png 48*48 весит 3Кб, а ico - 9 Кб).
3) Кому надо размер меньше, чем 48*48 - смасштабирует.
4) Кто будет спрашивать про размер на диске, отвечаю: удалить половину из demos/3d - никто ничего даже не заметит с точки зрения размера, а вот иконки появятся.

Почему я против иконки программы вне самой программы (иконки действий - пожалуйста, а вот иконка программы - внутри):
- Иконка является неотъемлемой частью программы.
- Нет риска, что пользователь удалит иконку, сделав, к примеру, файловые менеджеры, её использующие не работоспособными)
- В конце концов, это просто бред. Сами посмотрите: иконка потенциально используется помимо рабочего стола в заголовке окна (маленькая иконка 16*16, если её таки реализовать) и в @menu, если его переписать на манер 7ки (опционально или как не важно - я бы переписал). И для всех этих системных вещей использовать внешние файлы, которые могут быть удалены в любой момент? Мне одному это кажется странным?