>> Я тут подумал и мне кажется список можно сократить до примерно такого.

> К вопросу о привязке к абсолютным путям ;) Я не хочу захламлять
корневой каталог.

Я полностью согласен и именно поэтому я настаивал на гибкой системе. Чтобы каждый мог настроить ее под себя. Я уверен найдутся люди которых не устроят оба приведенных варианта.
Например, кто-то может захотеть, разместить все программы на read-only диске, а %SETTING% перенаправить на read-write диск. Вариантов масса.

> Кроме того на мой взгляд такая структура не логична.
> Logs, Libs и Temp куда уместнее расположить внутри каталога Software.

Как мне кажется, из трех только Libs можно в какой-то мере отнести к Software. Хотя в общем это что-то среднее между System и Software. Лучше конечно чтобы библиотеками управляла система, но этого, к сожалению, пока нет. Что же касается Logs и Temp это в целом временные данные, различной ценности. Они могут находиться по большому счету много где.

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

> О самостоятельности речь не идёт.

ну автоматически, суть то одна и таже, должен быть сдерживающий фактор.

>> Надо чтобы как минимум была возможноть спросить пользователя "А оно
>> ему надо?".

> Т.е. при установке и настройке текстового процессора, пользователь
> должен будет думать о том стоит ли ему ставить шрифты, или поставить

Для тех кто не хочет думать, эту возможность можно сделать настраиваемой, но она должна быть.

> всё кроме них, и удивляться куда его этот процессор посылает после
> попытки открыть файл в котором используется стандартный, но не
> установленный пользователем шрифт ? ;)

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

>> Соответственно подобные операции лучше делать через API, а не прямым
>> копированием в каталог.

> Есть специальный класс программ предназначенный для установки ПО. К
> примеру амижный Installer. Его задача проверить наличие устанавливаемых
> компонентов, их версии, спросить разрешение пользователя на установку
> и предупредить о возможных последствиях при отказе от их установки.

Именно это я и имел ввиду. :) Только такой "Installer" должен стоять у человека, а не идти в комплекте с ПО.
Хотя может разумнее завести несколько вызовов в системе.

InstallSoftware(Title, Version, file)
InstallLibrary(Name, Version, file)
InstallDriver(Type, Device, Version, file)
InstallFont(Name, Family, , , file)
и т.п.

В этом смысле, installer программы может обращатся к системе:
InstallLibrary("PRINTF", 1.0, "printf.lib");
Система смотрит в своих записях, допустим уже стоит такая библиотека.
Система говорит "OK". При этом у пользователя ничего не спрашивают. И реально ничего нового не ставится.

Если же, такой библиотеки нет или используется более старая версия.
то система (если это включено) спрашивает пользователя "Приложение ProgName запрашивает разрешение на установку библиотеки PRINTF v1.0 (c) anycompany [Yes], [No], [Yes for all]?"
Если "Yes", то необходимый файл копируется, записи обновляются, программе говорят "OK".
Если "No", то программе говорят "NO" и она уже решает ставиться дальше или нет.
Если "Yes to all", то дальнейшие вызовы данной программы происходят без запросов пользователю.

Точно также поступать со шрифтами, драйверами и др. компанетами.

> [...]
> Я полностью согласен и именно поэтому я настаивал на гибкой
> системе.

Хм. Я всего лишь предложил названия каталогов, их относительные пути для тех, которые асположены внутри других, и ассигны к ним. Всё обсуждение должно было свестись к простому анализу для того, что-бы выявить недостающие каталоги и ассигны. Абсолютные пути - последнее дело в этом обсуждении. Конкретизирую вопрос: каких каталогов и ассигнов в предложенной структуре не хватает ?

> [...]
> Как мне кажется, из трех только Libs можно в какой-то мере
> отнести к Software. Хотя в общем это что-то среднее между
> System и Software.

По-моему это исключительно системный компонент.

> Лучше конечно чтобы библиотеками управляла система, но этого,
> к сожалению, пока нет.

Да, с библиотеками и интерфейсом к ним надо разобраться до того, как они начут появляться в большом количестве. Т.е. самое время ;)

> [...]
> :) Вылетать из-за отсутствия какого-то конкретного шрифта, когда
> у пользователя стоят другие стандартные, не есть хорошо.

Речь не идёт о незапуске программы, а только о том, что пользователь увидит не то что задумывалось автором. Это наглядный пример.

> [...]
> Именно это я и имел ввиду. :) Только такой "Installer" должен стоять
> у человека, а не идти в комплекте с ПО.

Конечно. Например в AmigaOS и QNX такие программы поставляются вместе с файлами системы и всегда доступны любому ПО.

> Хотя может разумнее завести несколько вызовов в системе.

Не думаю. Вся установка сводится к элементарному копированию файлов из каталога/архива в стандартные ассигны. Куда проще ввести стандарт на способ размещения информации о номере версии файла (например, как это сделано в AmigaOS - есть стринг $VER:, за которым следует номер версии и дата создания программы в ASCII), и небольшую программу, которая эту версию проверяет, возвращая его в переменной среды, затем в скрипте установки происходит проверка того что эта программ возвращает и соответствующая реакция на это. Т.к. писать и "таскать с собой" целую программу только для установки, как делается в Windows, ненормально.

> [...]
> Система смотрит в своих записях, допустим уже стоит такая библиотека.

В каких записях ? Ведь если есть файл с таким именем в ассигне Libs:, то надо всего лишь проверить его версию.