Все пишут свои оськи... Предлагаю объединиться и написать хорошую промышленную ОС.
Итак, ПромОС, с чем его едят и чем он отличается от.
Экологическая ниша промосей в настоящий момент заполнена довольно странными продуктами эволюции. Это обрезанные "ЭнТишки", это промверсии Линуха, это жутковатые и дорогущие "местечковые" изобретения типа VxWorks, не совместимые ни с чем вменяемым.
Вся эта пестрая звиздобратия, по сути, не промышленные ОСи. Ни одна из них не приспособлена изначально для такого применения, и являет собой или попытки приспособить паровоз в качестве парохода (NT, Linux), или просто пыточный инструмент для программиста (ВыксВоркс и иже с ним).
Действительно, станок, автомобиль или баллистическая ракета очень мало напоминают секретутку с трехсантиметровыми ногтями и равного размера мозгом, и те решения, которые подходят к задачам, которые она ставит, весьма мало подходят для решения задач, которые ставит, скажем, ДВС во время разгона.
Система, к созданию которой я хочу сейчас собрать кворум, имеет только один заранее закладываемый огрех: она только x86-я, лишенная легкости портирования "на что угодно" путем абстрагирования от оборудования. Это жертва, на которую приходится идти ради эффективности. Да и, в конце концов, задача портирования тоже довольно надуманная сама по себе и в особенности она бессмысленна для промосей. Грамотно откомментированный и структурированный проект легко переделывается с ежа на ужа и обратно, а портирование БЕЗ перекомпиляции для ПромОС бессмысленно, как апгрейд видюхи в ядерной боеголовке.
Итак, особенности ПромОС перед остальным миром.
1) ПромОС совместим с DOS и, главное, DOS32, а именно -- DOS4GW расширением. Собственно, это DOS на новый лад. Это, пожалуй, удобнейшая для пром-управления среда, уже дающая достаточную опору, но еще не сковывающая движений.
2) Интерфейс ПромОСа одновременно дружественный пользователю и очень незатейливый. Изучать ради работы какого-то станка консольные команды еще одной ОС никто не станет, но и народ с кратких курсов начинающего идиота под ПромОС не пишет. Встроенный шелл напоминает NC: две панельки, выпадающее меню и в нем -- все настройки, сгруппированные по логическому смыслу. Коротко и ясно.
3) ПромОС не имеет никакой защиты ядра от действий прикладных программ. Напротив, все предельно документировано, и программы могут осознанно курочить ядро как хотят, запрещая собственные прерывания, стопоря друг друга и так далее. Аналогично, нет никаких мер, защищающих ядро от полной гибели при отказе одного процесса, кроме минимально-отладочных (аналогично тому же DOS4GW). Если в станке, скажем, отказал процесс привода каретки, то, что "выжило" ядро и процесс трансляции чертежей, никому уже не нужно. В ПромОС просто не должен глючить ни один процесс, это аксиома промышленных ОСей и задача программиста. Другая чаша весов -- гибкость и настраиваемость -- решительно перевешивает.
4) Мультизадачность в ПромОС обеспечивается, с одной стороны, аппаратными прерываниями, позволяющими "развешивать" процессы на те события, которые реально требуют обслуживания, и, с другой стороны, опциональным разделением времени самой ОС. Опциональным я называю его потому, что в 90% случаев оно не используется, концентрируя всю вычислительную мощь на нужной задаче и не отвлекаясь. Так, возьмем бытовой пример. Допустим, мы слушаем OGG'овую музычку и работаем в каком-нибудь слепленном под ПромОС фотожабе. Плеер при запуске "хватает" прерывание таймера, и при каждом тике сверяется с RTSC, расшифровывает и закидывает в буфер саундкарты кусок музыки и вызывает по цепочке предыдущий обработчик. Фотожаб работает сам собой, периодически "отрываясь" плеером от работы ровно на столько, на сколько нужно, не в квантах времени, а с точностью до одной команды.
Теперь мы начали рендерить что-то крупное. Плеер не начал сбиваться: он как сидел на таймере, так и сидит, и выделяется ему ровно столько времени, сколько ему надо. Фотожаб же использует 100% оставшихся ресурсов. Теперь кто-то злой, пусть это будет тетрис, поменял частоту таймера ради себя любимого. Что произошло?
А ничего. Плеер писали грамотные люди, он сверяется с RTSC И поэтому ему все равно, с какой частотой его зовет таймер. Лишь бы не реже, чем хардварный буфер карты кончается. А жабу тем более до лампочки.
Для обеспечения этой мультизадачности в ДОС16/32-совместимый набор просто впедриваются дополнительные службы переключения процесса. Некоторые из них опционально вызываются из стандартного обработчика таймера (например, после плеера он будет решать, кому отдать тик -- тихо рендерящему "в фоне" жабу или тетрису, который, к слову сказать, тоже на этот таймер имеет планы). Некоторые -- из клавиатурного прерывания, они-то и позволяют сменить фокус ввода/вывода или подспаунить какую-нибудь задачку типа временно выгруженного шелла. Некоторые -- из других функций ПромОС. Так, при завершении рендеринга жаб позовет функцию "Жду Ввода", а та, посмотрев, что мы не в фокусе, позовет функцию менеджера задач "До Возвражения Фокуса Мне Квантов Не Выделяй". И жаб встанет, перестав жрать время, ибо тут наш бытовой пример мы отложим, а то, что позволено прикладному ПО, в случае со станком, нарезающим резьбу методом программной синхронизации каретки со шпинделем, не позволительно никак.
5) Система аппаратных драйверов отдает небольшим извращением, но опять же мощи ради. Это ЭСО -- Эмуляция Стандартного Оборудования. Это значит, что драйверов практически не нужно, поскольку стандартное оборудование в них не нуждается, но при необходимости можно установить драйвер-эмулятор для какого-нибудь "левака". Работа же с СО обеспечивается на уровне... прикладной программы. Интерфейс СО взаимодействует напрямую с ПО, поскольку... поскольку больше ничего не нужно. По сути, это давно реализовано в виде разных SCSI BIOS, VESA BIOS и прочих экстеншнов-на-платах. В промышленности не так остро стоит проблема "вот куплю себе стерео-очки, а мой вольфенштейн их не поддерживает". Если у автомобиля появился встроенный локатор -- ПО просто дописывается и перекомпилируется. При установке локатора на готовую машину скачивается апдейт.
И не потому, что я такой жадный до ресурсов и злой. Просто промышленность -- не вольфенштейн, и попытки прорицательствовать все равно БЕЗУСПЕШНЫ, старое ПО не станет работать со вновь изобретенным, скажем, ABS'ом. Незачем тратить свои силы и ресурсы системы на беспомощные трепыхания, еще и убивая в ноль надежность системы.
6) Такого понятия, как "разграничение доступа", в ПромОС нет. Автомобиль заводится ключом. На заводе есть вахтер. Боеголовка летит. Безопасность системы обеспечивается физическим ограничением доступа. И опять же не потому, что я такой злой, просто, если физический доступ свершился, пароль на root уже не поможет. Только мешать будет и ресурсы отжирать. Причем в этот раз прослойка жрет реально МНОГО, ведь фильтровать все надо, включая HDD I/O.
Я уж не говорю о таких вещах, как встроенное сетевое ядро. Его даже представить на такой ОС смешно, такие вещи в промышленности нужны раз через три и встраиваются в прикладное ПО. Никто не будет листать веб-порнуху из-под станка, а доступ к заводскому серверу за чертежами встраивается в прикладное ПО, с использованием при необходимости ЭСО-драйвера сетевухи и небольшой сырцовой библиотечки TCP/IP.
Думаю, про бессмысленность понятия локали и языка системы и упоминать не надо... Разве что из-за того, чтобы упомянуть интерфейс прикладного ПО, который должен быть "национализируемым", поскольку юзером, в отличие от разработчика и "админа" (ремонтника), может быть кто угодно. Ну да это уже не ОС, он может быть и графическим, и набор символов подгружать...
7) ПромОС компактен и прост по структуре. Загрузочный сектор, Kernel.sys -- ядро, Command.Com -- транзитный шелл, Autoexec.Bat -- скрипт начальных настроек. Процесса инсталляции не существует. ПромОС может выступать в качестве ядра Win9x для облегчения запуска компиляторов... и вообще положительно смотрит на привлечение сторонних экстендеров. Естественно, при этом встроенная мультизадачность теряется к черту и ПромОс "косит под дурачка". 16-битного дурачка.
ПромОС реентерабелен по функциям, динамически загружает-выгружает драйверы, переназначает диски, может вместо имен файлов обращаться к стримдевайсам (например, запускать файл "COM2"). Бездисковая конфигурация для ПромОС -- тривиальная банальность. Бездисковая совсем, без флэш-диска или LiveCD. Например, загрузка с сериальной микросхемы флэша, сетевого ресурса или... платы расширения в PCI-слоте. Единственное -- чтобы BIOS подцепил загрузочник, а тот, если текущее устройство не диск и не его эмуляция, может быть легко переассемблирован, ибо крохотный, задокументированный, открытый и делает очень простую вещь. Kernel.SYs так или иначе попадает в память, а он уже приучен ничему не удивляться. Даже, если вместо Command.com нужно грузить COM1, вместо autoexec.bat -- опять COM1, а из последнего вызывается системный драйвер COM1, который, оказывается, драйвер потокового устройства COM2. Имена задокументированным образом правлены в хексе в самом kernel.sys, а драйвер так и прописан в autoexec'е -- LoadDriver COM1 /Name=Com2 или какие там у него параметры, у этого драйвера второго порта.
И, наконец, о прочих применениях.
Что у нас получилось?
ОС. ОС, идущая почти диаметрально противоположно современным тенденциям в силу экзотики решаемых задач. Очень старомодная ОС.
Быстрая, как черт, и очень гибкая. Рациональная в ресурах. Неудобная в фичуризме, но легкая в работе. Очень секьюрная для домашнего пользования, взлом по сети практически исключен: если браузер без дыр, весь комплекс без дыр.
Это не только ПромОС, это ОС. Только "малости" не хватает -- портировать WinE, чтобы совместимость была не только с DOS и не ценой потери ее аккуратной, экономной мультизадачности.
Экологическая ниша промосей в настоящий момент заполнена довольно странными продуктами эволюции. Это обрезанные "ЭнТишки", это промверсии Линуха, это жутковатые и дорогущие "местечковые" изобретения типа VxWorks, не совместимые ни с чем вменяемым.
Вся эта пестрая звиздобратия, по сути, не промышленные ОСи. Ни одна из них не приспособлена изначально для такого применения, и являет собой или попытки приспособить паровоз в качестве парохода (NT, Linux), или просто пыточный инструмент для программиста (ВыксВоркс и иже с ним).
Действительно, станок, автомобиль или баллистическая ракета очень мало напоминают секретутку с трехсантиметровыми ногтями и равного размера мозгом, и те решения, которые подходят к задачам, которые она ставит, весьма мало подходят для решения задач, которые ставит, скажем, ДВС во время разгона.
Система, к созданию которой я хочу сейчас собрать кворум, имеет только один заранее закладываемый огрех: она только x86-я, лишенная легкости портирования "на что угодно" путем абстрагирования от оборудования. Это жертва, на которую приходится идти ради эффективности. Да и, в конце концов, задача портирования тоже довольно надуманная сама по себе и в особенности она бессмысленна для промосей. Грамотно откомментированный и структурированный проект легко переделывается с ежа на ужа и обратно, а портирование БЕЗ перекомпиляции для ПромОС бессмысленно, как апгрейд видюхи в ядерной боеголовке.
Итак, особенности ПромОС перед остальным миром.
1) ПромОС совместим с DOS и, главное, DOS32, а именно -- DOS4GW расширением. Собственно, это DOS на новый лад. Это, пожалуй, удобнейшая для пром-управления среда, уже дающая достаточную опору, но еще не сковывающая движений.
2) Интерфейс ПромОСа одновременно дружественный пользователю и очень незатейливый. Изучать ради работы какого-то станка консольные команды еще одной ОС никто не станет, но и народ с кратких курсов начинающего идиота под ПромОС не пишет. Встроенный шелл напоминает NC: две панельки, выпадающее меню и в нем -- все настройки, сгруппированные по логическому смыслу. Коротко и ясно.
3) ПромОС не имеет никакой защиты ядра от действий прикладных программ. Напротив, все предельно документировано, и программы могут осознанно курочить ядро как хотят, запрещая собственные прерывания, стопоря друг друга и так далее. Аналогично, нет никаких мер, защищающих ядро от полной гибели при отказе одного процесса, кроме минимально-отладочных (аналогично тому же DOS4GW). Если в станке, скажем, отказал процесс привода каретки, то, что "выжило" ядро и процесс трансляции чертежей, никому уже не нужно. В ПромОС просто не должен глючить ни один процесс, это аксиома промышленных ОСей и задача программиста. Другая чаша весов -- гибкость и настраиваемость -- решительно перевешивает.
4) Мультизадачность в ПромОС обеспечивается, с одной стороны, аппаратными прерываниями, позволяющими "развешивать" процессы на те события, которые реально требуют обслуживания, и, с другой стороны, опциональным разделением времени самой ОС. Опциональным я называю его потому, что в 90% случаев оно не используется, концентрируя всю вычислительную мощь на нужной задаче и не отвлекаясь. Так, возьмем бытовой пример. Допустим, мы слушаем OGG'овую музычку и работаем в каком-нибудь слепленном под ПромОС фотожабе. Плеер при запуске "хватает" прерывание таймера, и при каждом тике сверяется с RTSC, расшифровывает и закидывает в буфер саундкарты кусок музыки и вызывает по цепочке предыдущий обработчик. Фотожаб работает сам собой, периодически "отрываясь" плеером от работы ровно на столько, на сколько нужно, не в квантах времени, а с точностью до одной команды.
Теперь мы начали рендерить что-то крупное. Плеер не начал сбиваться: он как сидел на таймере, так и сидит, и выделяется ему ровно столько времени, сколько ему надо. Фотожаб же использует 100% оставшихся ресурсов. Теперь кто-то злой, пусть это будет тетрис, поменял частоту таймера ради себя любимого. Что произошло?
А ничего. Плеер писали грамотные люди, он сверяется с RTSC И поэтому ему все равно, с какой частотой его зовет таймер. Лишь бы не реже, чем хардварный буфер карты кончается. А жабу тем более до лампочки.
Для обеспечения этой мультизадачности в ДОС16/32-совместимый набор просто впедриваются дополнительные службы переключения процесса. Некоторые из них опционально вызываются из стандартного обработчика таймера (например, после плеера он будет решать, кому отдать тик -- тихо рендерящему "в фоне" жабу или тетрису, который, к слову сказать, тоже на этот таймер имеет планы). Некоторые -- из клавиатурного прерывания, они-то и позволяют сменить фокус ввода/вывода или подспаунить какую-нибудь задачку типа временно выгруженного шелла. Некоторые -- из других функций ПромОС. Так, при завершении рендеринга жаб позовет функцию "Жду Ввода", а та, посмотрев, что мы не в фокусе, позовет функцию менеджера задач "До Возвражения Фокуса Мне Квантов Не Выделяй". И жаб встанет, перестав жрать время, ибо тут наш бытовой пример мы отложим, а то, что позволено прикладному ПО, в случае со станком, нарезающим резьбу методом программной синхронизации каретки со шпинделем, не позволительно никак.
5) Система аппаратных драйверов отдает небольшим извращением, но опять же мощи ради. Это ЭСО -- Эмуляция Стандартного Оборудования. Это значит, что драйверов практически не нужно, поскольку стандартное оборудование в них не нуждается, но при необходимости можно установить драйвер-эмулятор для какого-нибудь "левака". Работа же с СО обеспечивается на уровне... прикладной программы. Интерфейс СО взаимодействует напрямую с ПО, поскольку... поскольку больше ничего не нужно. По сути, это давно реализовано в виде разных SCSI BIOS, VESA BIOS и прочих экстеншнов-на-платах. В промышленности не так остро стоит проблема "вот куплю себе стерео-очки, а мой вольфенштейн их не поддерживает". Если у автомобиля появился встроенный локатор -- ПО просто дописывается и перекомпилируется. При установке локатора на готовую машину скачивается апдейт.
И не потому, что я такой жадный до ресурсов и злой. Просто промышленность -- не вольфенштейн, и попытки прорицательствовать все равно БЕЗУСПЕШНЫ, старое ПО не станет работать со вновь изобретенным, скажем, ABS'ом. Незачем тратить свои силы и ресурсы системы на беспомощные трепыхания, еще и убивая в ноль надежность системы.
6) Такого понятия, как "разграничение доступа", в ПромОС нет. Автомобиль заводится ключом. На заводе есть вахтер. Боеголовка летит. Безопасность системы обеспечивается физическим ограничением доступа. И опять же не потому, что я такой злой, просто, если физический доступ свершился, пароль на root уже не поможет. Только мешать будет и ресурсы отжирать. Причем в этот раз прослойка жрет реально МНОГО, ведь фильтровать все надо, включая HDD I/O.
Я уж не говорю о таких вещах, как встроенное сетевое ядро. Его даже представить на такой ОС смешно, такие вещи в промышленности нужны раз через три и встраиваются в прикладное ПО. Никто не будет листать веб-порнуху из-под станка, а доступ к заводскому серверу за чертежами встраивается в прикладное ПО, с использованием при необходимости ЭСО-драйвера сетевухи и небольшой сырцовой библиотечки TCP/IP.
Думаю, про бессмысленность понятия локали и языка системы и упоминать не надо... Разве что из-за того, чтобы упомянуть интерфейс прикладного ПО, который должен быть "национализируемым", поскольку юзером, в отличие от разработчика и "админа" (ремонтника), может быть кто угодно. Ну да это уже не ОС, он может быть и графическим, и набор символов подгружать...
7) ПромОС компактен и прост по структуре. Загрузочный сектор, Kernel.sys -- ядро, Command.Com -- транзитный шелл, Autoexec.Bat -- скрипт начальных настроек. Процесса инсталляции не существует. ПромОС может выступать в качестве ядра Win9x для облегчения запуска компиляторов... и вообще положительно смотрит на привлечение сторонних экстендеров. Естественно, при этом встроенная мультизадачность теряется к черту и ПромОс "косит под дурачка". 16-битного дурачка.
ПромОС реентерабелен по функциям, динамически загружает-выгружает драйверы, переназначает диски, может вместо имен файлов обращаться к стримдевайсам (например, запускать файл "COM2"). Бездисковая конфигурация для ПромОС -- тривиальная банальность. Бездисковая совсем, без флэш-диска или LiveCD. Например, загрузка с сериальной микросхемы флэша, сетевого ресурса или... платы расширения в PCI-слоте. Единственное -- чтобы BIOS подцепил загрузочник, а тот, если текущее устройство не диск и не его эмуляция, может быть легко переассемблирован, ибо крохотный, задокументированный, открытый и делает очень простую вещь. Kernel.SYs так или иначе попадает в память, а он уже приучен ничему не удивляться. Даже, если вместо Command.com нужно грузить COM1, вместо autoexec.bat -- опять COM1, а из последнего вызывается системный драйвер COM1, который, оказывается, драйвер потокового устройства COM2. Имена задокументированным образом правлены в хексе в самом kernel.sys, а драйвер так и прописан в autoexec'е -- LoadDriver COM1 /Name=Com2 или какие там у него параметры, у этого драйвера второго порта.
И, наконец, о прочих применениях.
Что у нас получилось?
ОС. ОС, идущая почти диаметрально противоположно современным тенденциям в силу экзотики решаемых задач. Очень старомодная ОС.
Быстрая, как черт, и очень гибкая. Рациональная в ресурах. Неудобная в фичуризме, но легкая в работе. Очень секьюрная для домашнего пользования, взлом по сети практически исключен: если браузер без дыр, весь комплекс без дыр.
Это не только ПромОС, это ОС. Только "малости" не хватает -- портировать WinE, чтобы совместимость была не только с DOS и не ценой потери ее аккуратной, экономной мультизадачности.
Итак, проектный документ оглашен. Если набирается погромная команда добровольцев, готов начать киберштурм. Где-то я новайс полный, где-то имею немалый опыт, но с одним у меня точно хоршо: общую архитектуру системы, общее направление движения я задавать умею. По крайней мере, на клады команду уже выводил не раз, а в болото под моим руководством пока никто не заходил.
Естественно, я собираю воедино разумные мнения, однако критерий разумности у меня субъективный.
Если желающих не наберется -- нет так нет.
Естественно, я собираю воедино разумные мнения, однако критерий разумности у меня субъективный.
Если желающих не наберется -- нет так нет.
Цитата:
Это обрезанные "ЭнТишки", это промверсии Линуха, это жутковатые и дорогущие "местечковые" изобретения типа VxWorks, не совместимые ни с чем вменяемым.
Если не ошибаюсь - в качестве промоборудования ныне часто используются ARM камешки, и софт, соответственно по большей части winCE и аналоги. Вроде даже под palmOS что-то было. В плане ресурсоёмкости они сильно отличаются от старших собратьев (т.к. и ресурсов там не очень..)
Кстати по описанию по крайнеё мере палмОС несколько похожа на твою задумку :)
(про остальных не знаю)
Цитата:
2) Интерфейс ПромОСа одновременно дружественный пользователю и очень незатейливый. Изучать ради работы какого-то станка консольные команды еще одной ОС никто не станет, но и народ с кратких курсов начинающего идиота под ПромОС не пишет. Встроенный шелл напоминает NC: две панельки, выпадающее меню и в нем -- все настройки, сгруппированные по логическому смыслу. Коротко и ясно.
Интерфейс является частью опрерационки? Кстати, см выше про палм/вын и пр.
Цитата:
3) ПромОС не имеет никакой защиты ядра от действий прикладных программ. Напротив, все предельно документировано, и программы могут осознанно курочить ядро как хотят, запрещая собственные прерывания, стопоря друг друга и так далее. Аналогично, нет никаких мер, защищающих ядро от полной гибели при отказе одного процесса, кроме минимально-отладочных (аналогично тому же DOS4GW). Если в станке, скажем, отказал процесс привода каретки, то, что "выжило" ядро и процесс трансляции чертежей, никому уже не нужно. В ПромОС просто не должен глючить ни один процесс, это аксиома промышленных ОСей и задача программиста. Другая чаша весов -- гибкость и настраиваемость -- решительно перевешивает.
Ну, в общем тоже самое. Вспомнить хотя бы хаки в палм. Можно всю систему с ног на голову перевернуть
Цитата:
4) Мультизадачность в ПромОС обеспечивается, с одной стороны, аппаратными прерываниями, позволяющими "развешивать" процессы на те события, которые реально требуют обслуживания, и, с другой стороны, опциональным разделением времени самой ОС. Опциональным я называю его потому, что в 90% случаев оно не используется, концентрируя всю вычислительную мощь на нужной задаче и не отвлекаясь. Так, возьмем бытовой пример. Допустим, мы слушаем OGG'овую музычку и работаем в каком-нибудь слепленном под ПромОС фотожабе. ...
Ну, в общем тоже самое. Т.к. многозадачности нермальной в них нет, то всё именно так и работает.
Цитата:
5) Система аппаратных драйверов отдает небольшим извращением, но опять же мощи ради. Это ЭСО -- Эмуляция Стандартного Оборудования. Это значит, что драйверов практически не нужно, поскольку стандартное оборудование в них не нуждается, но при необходимости можно установить драйвер-эмулятор для какого-нибудь "левака". Работа же с СО обеспечивается на уровне... прикладной программы. Интерфейс СО взаимодействует напрямую с ПО, поскольку... поскольку больше ничего не нужно. По сути, это давно реализовано в виде разных SCSI BIOS, VESA BIOS и прочих экстеншнов-на-платах. В промышленности не так остро стоит проблема "вот куплю себе стерео-очки, а мой вольфенштейн их не поддерживает". Если у автомобиля появился встроенный локатор -- ПО просто дописывается и перекомпилируется. При установке локатора на готовую машину скачивается апдейт.
А чем плохо просто погрузить драйвер?
Вобще микроядерная архитектура удобная штука.
И чем, собственно, это отличается от существующих ос?
Цитата:
6) Такого понятия, как "разграничение доступа", в ПромОС нет. Автомобиль заводится ключом. На заводе есть вахтер.
А ещё на заводе есть пьяный дворник, который ради интереса может поковырять железяку пальцем.. А Рабочий просто заснуть на станке (и не такое бывает)
Цитата:
Боеголовка летит.
А ещё она лежит. На складе. Где какие-нибуть обкурившиеся срочники её могут просто домой сп...ть.
Цитата:
Безопасность системы обеспечивается физическим ограничением доступа. И опять же не потому, что я такой злой, просто, если физический доступ свершился, пароль на root уже не поможет.
Пароль от профессионального взломщика естественно не поможет, а вот от 99.5% случайно попавших людей вполне... Да и оставшиеся скорее физически сломают девайс, чем смогут подобрать нормальный пароль.
Цитата:
Только мешать будет и ресурсы отжирать. Причем в этот раз прослойка жрет реально МНОГО, ведь фильтровать все надо, включая HDD I/O.
Такая защита - действительно перебор. Причём, на мой взгляд, даже на домашних машинах. Все эти новоумные системы, в которых каждый девайс авторизуется на аппаратном уровне - это полный трыныдец. "У вашей мышки нет сертификата безопасности, она будет отключена". А ведь к и этому идёт...
Цитата:
Я уж не говорю о таких вещах, как встроенное сетевое ядро. Его даже представить на такой ОС смешно, такие вещи в промышленности нужны раз через три и встраиваются в прикладное ПО. Никто не будет листать веб-порнуху из-под станка, а доступ к заводскому серверу за чертежами встраивается в прикладное ПО, с использованием при необходимости ЭСО-драйвера сетевухи и небольшой сырцовой библиотечки TCP/IP.
Думаю, про бессмысленность понятия локали и языка системы и упоминать не надо... Разве что из-за того, чтобы упомянуть интерфейс прикладного ПО, который должен быть "национализируемым", поскольку юзером, в отличие от разработчика и "админа" (ремонтника), может быть кто угодно. Ну да это уже не ОС, он может быть и графическим, и набор символов подгружать...
Думаю, про бессмысленность понятия локали и языка системы и упоминать не надо... Разве что из-за того, чтобы упомянуть интерфейс прикладного ПО, который должен быть "национализируемым", поскольку юзером, в отличие от разработчика и "админа" (ремонтника), может быть кто угодно. Ну да это уже не ОС, он может быть и графическим, и набор символов подгружать...
Не буду оригинальным, см выше :-)
Кстати, в чём, собственно, сложность замены языка системы? Зачем его вобще делать частью ядра?
Зачем драйвера встраивать в ядро не очень понятно, ну, кроме 1-го единственного, обеспечивающего первоначальную загрузку.
Цитата:
7) ПромОС компактен и прост по структуре. Загрузочный сектор, Kernel.sys -- ядро, Command.Com -- транзитный шелл, Autoexec.Bat -- скрипт начальных настроек. Процесса инсталляции не существует.
Загрузочный сектор пишем вручную? (Если инсталляции не существует)
Цитата:
Бездисковая совсем, без флэш-диска или LiveCD. Например, загрузка с сериальной микросхемы флэша, сетевого ресурса или... платы расширения в PCI-слоте.
сетевого ресурса? Пардон, а tcp\ip же только что выкинули из ядра? Загрузка откуда бы нибыло, кроме собственно биоса потребует как минимум драйвер для первоначальной работы с этим девайсом.
Цитата:
ПромОС может выступать в качестве ядра Win9x для облегчения запуска компиляторов...
imho копилятор любой вменяемый программер способен запустить и из консоли. makefile и аналоги тоже вещь полезная
а win хоть 95, хоть 3.11 - это несколько противоречит всему вышеперечисленному. Процентов на 95 :-)
Цитата:
и вообще положительно смотрит на привлечение сторонних экстендеров. Естественно, при этом встроенная мультизадачность теряется к черту и ПромОс "косит под дурачка". 16-битного дурачка
а смысл тогда вобще всей этой затеи? ДОС поставил и вперёд.
Цитата:
ПромОС реентерабелен по функциям, динамически загружает-выгружает драйверы, переназначает диски, может вместо имен файлов обращаться к стримдевайсам (например, запускать файл "COM2").
А смысл последнего?
Драйверы можно сделать обычными резидентами. Чем плохо?
Переназначать? А чем не нравится единая ф.с. типа POSIX? кстати, там, вроде и com2 запустить можно (хотя не уверен, не пробовал)
Цитата:
Бездисковая конфигурация для ПромОС -- тривиальная банальность. Бездисковая совсем, без флэш-диска или LiveCD. Например, загрузка с сериальной микросхемы флэша, сетевого ресурса или... платы расширения в PCI-слоте. Единственное -- чтобы BIOS подцепил загрузочник, а тот, если текущее устройство не диск и не его эмуляция, может быть легко переассемблирован, ибо крохотный, задокументированный, открытый и делает очень простую вещь. Kernel.SYs так или иначе попадает в память, а он уже приучен ничему не удивляться. Даже, если вместо Command.com нужно грузить COM1, вместо autoexec.bat -- опять COM1, а из последнего вызывается системный драйвер COM1, который, оказывается, драйвер потокового устройства COM2. Имена задокументированным образом правлены в хексе в самом kernel.sys, а драйвер так и прописан в autoexec'е -- LoadDriver COM1 /Name=Com2 или какие там у него параметры, у этого драйвера второго порта.
Palm и прочие априори бездисковые :-), а linux неплохо живёт на месте bios-а (см. linuxbios)
Кстати ядро в linux можно весьма кардинально порезать (список устройств, на которых его удалось запустить, вполне красноречив)
Цитата:
Быстрая, как черт, и очень гибкая. Рациональная в ресурах. Неудобная в фичуризме, но легкая в работе. Очень секьюрная для домашнего пользования, взлом по сети практически исключен: если браузер без дыр, весь комплекс без дыр.
Это не только ПромОС, это ОС. Только "малости" не хватает -- портировать WinE, чтобы совместимость была не только с DOS и не ценой потери ее аккуратной, экономной мультизадачности.
Это не только ПромОС, это ОС. Только "малости" не хватает -- портировать WinE, чтобы совместимость была не только с DOS и не ценой потери ее аккуратной, экономной мультизадачности.
Если вынуть из вынды её многозадачность и пр., то, собственно, что там останется? Окошки? Так их нарисовать дело не хитрое..
Наконец-то ругань по теме, а не просто жмых в голосовалку :)
>ныне часто используются ARM камешки
Кстати, ПромОС саму можно, строго говоря, перелепить опционально под ту или иную платформу, а раз за совместимостью "вслепую" мы не гонимся, то портирование прикладного ПО сведется к перекомпиляции и замене нескольких аппаратных констант.
Те, кто работал с WATCOM C++, наверняка знают, как приятно компилировать "букетиком", выдавая сразу несколько таргетов под разные платформы с одного сырца.
>Кстати по описанию по крайнеё мере палмОС несколько похожа на твою задумку :)
Польщен %) Только у нее мультизадачностью все-таки похуже ПромОСа %(
>Интерфейс является частью опрерационки?
Формалист %) "Интерфейс дефолтовой оболочки". Так пойдет? :)
>Можно всю систему с ног на голову перевернуть
Опять мерси за комплимент :)
>многозадачности нормальной в них нет
В ПромОС мультизадачность вполне нормальная (могу поподробнее расписать, если по краткому описанию этого не заметно), но часть ПО развешивается по аппаратным прерываниям в силу его философского смысла и легкости этого "развеса".
>А чем плохо просто погрузить драйвер?
ЭСО отличается от "драйверной" системы только тем, что интерфейс "драйвер-ПО" совпадает для СО с интерфейсом "железо-драйвер". Т.е. для СО драйвер есть, но он равен нулю :) Для не-СО не равен.
Положим, у тебя 40 собак и 20 кошек. Ты можешь причесать их под кошку, под собаку или под сурка. Win чешет под сурка, я предлагаю под собаку, ибо тогда 2/3 зверья можно оставить как есть. ЭСО -- вопрос выбора общего драйверного интерфейса, если точно.
>И чем, собственно, это отличается от существующих ос?
От каждой из или от всех вместе?
>Пароль от профессионального взломщика естественно не поможет, а вот от 99.5% случайно попавших людей вполне...
...и от вируса не поможет, и от изобретательного идиота... После настройки с системного флэш-диска снимается джампер "Write Enable" и закрывается кожух. А все программные защиты ядра-от-глупого-юзера безнадежны. Это все равно что анатомически сделать человека таким, чтобы он не мог покончить с собой. Даже если сделать так, чтобы у него руки вовнутрь не поворачивались, он при желании способ найдет...
>Кстати, в чём, собственно, сложность замены языка системы?
Есть очень много несложных, но совершенно ненужных вещей...
>Зачем драйвера встраивать в ядро
А их никто и не встраивает... Они отдельно грузятся, обеспечивая ЭСО, если нужны, конечно...
>Загрузочный сектор пишем вручную? (Если инсталляции не существует)
Дефолтная оболочка берет на себя роль некоторых элементарных утилит. В частности, копирования секторов.
>Загрузка откуда бы ни было, кроме собственно биоса потребует как минимум драйвер для первоначальной работы с этим девайсом.
Ай-яй-яй, а как драйвер для ОС может загрузиться раньше ОС? Для этого на сетевухах BOOT ROM стоит, без него В ПРИНЦИПЕ с сетевого ресурса грузиться нельзя. А с ним -- хоть дос шесть и третий.
>imho копилятор любой вменяемый программер способен запустить и из консоли. makefile и аналоги тоже вещь полезная
Не из консоли, а из дефолтовой оболочки. :) Естественно, ПО под ПромОС в виндах не нуждается. Я неправильно выразился -- ну, на ранней стадии м.б. понадобится какую-нибудь утильку запустить, которая только под вынь есть, win.com дернул, поработал, потом ресет...
>а win хоть 95, хоть 3.11 - это несколько противоречит всему вышеперечисленному. Процентов на 95 :-)
LOL
На 98! На 2000! На ХР! :D
>а смысл тогда вобще всей этой затеи? ДОС поставил и вперёд.
В каком-то смысле это и есть ДОС. DOS4GW, точнее. Причем мультизадачный. Наследник их, можно сказать.
>Драйверы можно сделать обычными резидентами. Чем плохо?
"-- Так канделябрами б его!
-- Я так и сделал..."
Пусть и резидентами...
>Переназначать? А чем не нравится единая ф.с. типа POSIX? кстати, там, вроде и com2 запустить можно (хотя не уверен, не пробовал)
Надо подумать.
>Palm и прочие априори бездисковые :-)
Третье сходство... :)
>см. linuxbios
...и под каждую мамку свой... Не, меру надо знать :) BIOS -- вот хороший уровень абстракции аппаратуры :)
>Кстати ядро в linux можно весьма кардинально порезать (список устройств, на которых его удалось запустить, вполне красноречив)
...паровоз в качестве парохода, как и было сказано...
>Если вынуть из вынды её многозадачность
Вот-вот. Мультитаскинг у нас свой, осталось только API и немного графики...
Кстати, про ёдерную систему кэширования не рассказал. Алгоритм чтения/записи, не валимый внезапным повер фолтом. Потом расскажу, счас сил нету :)
>ныне часто используются ARM камешки
Кстати, ПромОС саму можно, строго говоря, перелепить опционально под ту или иную платформу, а раз за совместимостью "вслепую" мы не гонимся, то портирование прикладного ПО сведется к перекомпиляции и замене нескольких аппаратных констант.
Те, кто работал с WATCOM C++, наверняка знают, как приятно компилировать "букетиком", выдавая сразу несколько таргетов под разные платформы с одного сырца.
>Кстати по описанию по крайнеё мере палмОС несколько похожа на твою задумку :)
Польщен %) Только у нее мультизадачностью все-таки похуже ПромОСа %(
>Интерфейс является частью опрерационки?
Формалист %) "Интерфейс дефолтовой оболочки". Так пойдет? :)
>Можно всю систему с ног на голову перевернуть
Опять мерси за комплимент :)
>многозадачности нормальной в них нет
В ПромОС мультизадачность вполне нормальная (могу поподробнее расписать, если по краткому описанию этого не заметно), но часть ПО развешивается по аппаратным прерываниям в силу его философского смысла и легкости этого "развеса".
>А чем плохо просто погрузить драйвер?
ЭСО отличается от "драйверной" системы только тем, что интерфейс "драйвер-ПО" совпадает для СО с интерфейсом "железо-драйвер". Т.е. для СО драйвер есть, но он равен нулю :) Для не-СО не равен.
Положим, у тебя 40 собак и 20 кошек. Ты можешь причесать их под кошку, под собаку или под сурка. Win чешет под сурка, я предлагаю под собаку, ибо тогда 2/3 зверья можно оставить как есть. ЭСО -- вопрос выбора общего драйверного интерфейса, если точно.
>И чем, собственно, это отличается от существующих ос?
От каждой из или от всех вместе?
>Пароль от профессионального взломщика естественно не поможет, а вот от 99.5% случайно попавших людей вполне...
...и от вируса не поможет, и от изобретательного идиота... После настройки с системного флэш-диска снимается джампер "Write Enable" и закрывается кожух. А все программные защиты ядра-от-глупого-юзера безнадежны. Это все равно что анатомически сделать человека таким, чтобы он не мог покончить с собой. Даже если сделать так, чтобы у него руки вовнутрь не поворачивались, он при желании способ найдет...
>Кстати, в чём, собственно, сложность замены языка системы?
Есть очень много несложных, но совершенно ненужных вещей...
>Зачем драйвера встраивать в ядро
А их никто и не встраивает... Они отдельно грузятся, обеспечивая ЭСО, если нужны, конечно...
>Загрузочный сектор пишем вручную? (Если инсталляции не существует)
Дефолтная оболочка берет на себя роль некоторых элементарных утилит. В частности, копирования секторов.
>Загрузка откуда бы ни было, кроме собственно биоса потребует как минимум драйвер для первоначальной работы с этим девайсом.
Ай-яй-яй, а как драйвер для ОС может загрузиться раньше ОС? Для этого на сетевухах BOOT ROM стоит, без него В ПРИНЦИПЕ с сетевого ресурса грузиться нельзя. А с ним -- хоть дос шесть и третий.
>imho копилятор любой вменяемый программер способен запустить и из консоли. makefile и аналоги тоже вещь полезная
Не из консоли, а из дефолтовой оболочки. :) Естественно, ПО под ПромОС в виндах не нуждается. Я неправильно выразился -- ну, на ранней стадии м.б. понадобится какую-нибудь утильку запустить, которая только под вынь есть, win.com дернул, поработал, потом ресет...
>а win хоть 95, хоть 3.11 - это несколько противоречит всему вышеперечисленному. Процентов на 95 :-)
LOL
На 98! На 2000! На ХР! :D
>а смысл тогда вобще всей этой затеи? ДОС поставил и вперёд.
В каком-то смысле это и есть ДОС. DOS4GW, точнее. Причем мультизадачный. Наследник их, можно сказать.
>Драйверы можно сделать обычными резидентами. Чем плохо?
"-- Так канделябрами б его!
-- Я так и сделал..."
Пусть и резидентами...
>Переназначать? А чем не нравится единая ф.с. типа POSIX? кстати, там, вроде и com2 запустить можно (хотя не уверен, не пробовал)
Надо подумать.
>Palm и прочие априори бездисковые :-)
Третье сходство... :)
>см. linuxbios
...и под каждую мамку свой... Не, меру надо знать :) BIOS -- вот хороший уровень абстракции аппаратуры :)
>Кстати ядро в linux можно весьма кардинально порезать (список устройств, на которых его удалось запустить, вполне красноречив)
...паровоз в качестве парохода, как и было сказано...
>Если вынуть из вынды её многозадачность
Вот-вот. Мультитаскинг у нас свой, осталось только API и немного графики...
Кстати, про ёдерную систему кэширования не рассказал. Алгоритм чтения/записи, не валимый внезапным повер фолтом. Потом расскажу, счас сил нету :)
Цитата:
>Кстати по описанию по крайнеё мере палмОС несколько похожа на твою задумку :)
Польщен %) Только у нее мультизадачностью все-таки похуже ПромОСа %(
Польщен %) Только у нее мультизадачностью все-таки похуже ПромОСа %(
Исключительно потому, что она там нафиг не сдалась. Кому надо -сами висят на таймере. mp3, например, прекрасно и в фоне работает.
Цитата:
Формалист %) "Интерфейс дефолтовой оболочки". Так пойдет? :)
Нет, т.к. оболчка к ОСи отношения не имеет. И судя по идее встраиваемости некоторых спец. функций в неё - она не дефолтовая, а добровольно-принудительно дефолтовая. Кого-то это мне напоминает... ;-)
Цитата:
>Можно всю систему с ног на голову перевернуть
Опять мерси за комплимент :)
Опять мерси за комплимент :)
Комплимент палму.. :)
Цитата:
>многозадачности нормальной в них нет
В ПромОС мультизадачность вполне нормальная (могу поподробнее расписать, если по краткому описанию этого не заметно), но часть ПО развешивается по аппаратным прерываниям в силу его философского смысла и легкости этого "развеса".
В ПромОС мультизадачность вполне нормальная (могу поподробнее расписать, если по краткому описанию этого не заметно), но часть ПО развешивается по аппаратным прерываниям в силу его философского смысла и легкости этого "развеса".
незаметно, по крайней мере мне.. А чем плох мултизадачный дос в таком случае?
Цитата:
>А чем плохо просто погрузить драйвер?
ЭСО отличается от "драйверной" системы только тем, что интерфейс "драйвер-ПО" совпадает для СО с интерфейсом "железо-драйвер". Т.е. для СО драйвер есть, но он равен нулю :) Для не-СО не равен.
Положим, у тебя 40 собак и 20 кошек. Ты можешь причесать их под кошку, под собаку или под сурка. Win чешет под сурка, я предлагаю под собаку, ибо тогда 2/3 зверья можно оставить как есть. ЭСО -- вопрос выбора общего драйверного интерфейса, если точно.
ЭСО отличается от "драйверной" системы только тем, что интерфейс "драйвер-ПО" совпадает для СО с интерфейсом "железо-драйвер". Т.е. для СО драйвер есть, но он равен нулю :) Для не-СО не равен.
Положим, у тебя 40 собак и 20 кошек. Ты можешь причесать их под кошку, под собаку или под сурка. Win чешет под сурка, я предлагаю под собаку, ибо тогда 2/3 зверья можно оставить как есть. ЭСО -- вопрос выбора общего драйверного интерфейса, если точно.
С одной стороны логично, но с другой всё равно для остальных придётся писать ОЧЕНЬ хитрый драйвер, т.к. надо будет уже работать не как обычно вызываемое промежуточное звено, а как партизан на телефонной линии. Перехватывать обращения к несуществующему оборудованию и эмулить его. При этом ещё возникает проблема совместимости. Если железка не совсем совместима с СО (а она по определению не совместима) - то придётся ДЛЯ каждой пытаться транслировать команды, посылаемые СО в команды, понимаемые этим девайсом, что не так просто. А если автор ПО по привычке (вспомни ДОС) будет использовать какие-то хитрые способы работы с железом? (стандартный X-mode на VGA например? или работа с развёрткой на нём-же?) Не лучше ли ставить по дефолту некие стандартные интерфейсы, позволяющие на относительно низком уровне работать с железом? Возможность прямого доступа можно оставить(в специально оговариваемых в конфигах случаях), хотя это может оказаться серьёзным ударом по мультитаскингу. Представь одновременную попытку работы со звуком 2х программ...
Ещё. Если всё оборудование стандартно, то никаких нововведений быть не может. Или каждая программа как в старые добрые времена будет вынужденна таскать за собой комплект драйверов на все случаи жизни и пытаться подобрать необходимый (что им не всегда удавалось).imho некоторый уровень абстракции от оборудования необходим.
Цитата:
Дефолтная оболочка берет на себя роль некоторых элементарных утилит. В частности, копирования секторов.
см. выше
Цитата:
Не из консоли, а из дефолтовой оболочки. :) Естественно, ПО под ПромОС в виндах не нуждается. Я неправильно выразился -- ну, на ранней стадии м.б. понадобится какую-нибудь утильку запустить, которая только под вынь есть, win.com дернул, поработал, потом ресет...
Чем тебе так консоль насолила, что ты её принципиально не хочешь видеть? Я думаю, со мной многие согласятся, что это для привыкшего человека вещь КРАЙНЕ удобная. Из личного опыта - в ACAD даже последних версий сохранилась консоль, т.к. работать через неё несравненно быстрее.
На счёт win.com... А не кажется тебе, что для этого придётся эмулятор машины делать? Вында вряд-ли согласится, чтобы её отрезали от железа, а допустить её туда - потом не выковырнешь.. Опять-же придётся грузить вындовые дрова, без которых она жить не может (и сами они, вроде, из памяти удаляться не умеют)
А если потом ресет - то не проще ДОС запустить?
Кстати, заниматься таким геморроем, чтобы "на ранней стадии м.б. понадобится какую-нибудь утильку запустить"?
Цитата:
В каком-то смысле это и есть ДОС. DOS4GW, точнее. Причем мультизадачный. Наследник их, можно сказать.
Насколько я помню, мультизадачный дос существует уже...
Цитата:
...и под каждую мамку свой... Не, меру надо знать :) BIOS -- вот хороший уровень абстракции аппаратуры :)
Перекомпилится под конкретную мать он, вроде, без особых проблем.
А если учесть "Если у автомобиля появился встроенный локатор -- ПО просто дописывается и перекомпилируется." - то вобще не понятно, в чём проблема. Тут не только каждая мать, но и каждый девайс учитывается. :-)
Цитата:
>Кстати ядро в linux можно весьма кардинально порезать (список устройств, на которых его удалось запустить, вполне красноречив)
...паровоз в качестве парохода, как и было сказано...
...паровоз в качестве парохода, как и было сказано...
Есть подозрение, что тебе сама идея противна. А паровоз от парохода не так сильно отличается, чтобы не было соблазна небольшой модификацией переделать одно в другое. Не вижу в этом ничего плохого.
Цитата:
Вот-вот. Мультитаскинг у нас свой, осталось только API и немного графики...
А нафиг графику? Окошки рисовать? Так любая программа залезет в видеопамять и хана таким окошкам... При такой философии доступа - imho только набор консолей, каждая в локальном фулскрине (придётся перехватывать весь доступ к видеооборудованию, запрет на работу в специфических режимах) Кстати - набор консолей - вещь весьма удобная. Только не фиксированный, как в линух, и динамический - при запуске самостоятельной программы просто дать ей возможность создать себе консоль (если она ей нужна)
Подчинённые программы по дефолту просто наследуют родительскую. Оставить только 0-ю консоль для управления или под дефолтовый шелл, это уж как больше нравится...
Цитата:
Кстати, про ёдерную систему кэширования не рассказал. Алгоритм чтения/записи, не валимый внезапным повер фолтом. Потом расскажу, счас сил нету :)
Вот так всегда, на самом интересном месте...
Цитата:
Originally posted by Николай Коровин
Итак, ПромОС, с чем его едят и чем он отличается от.
Экологическая ниша промосей в настоящий момент заполнена довольно странными продуктами эволюции. Это обрезанные "ЭнТишки", это промверсии Линуха, это жутковатые и дорогущие "местечковые" изобретения типа VxWorks, не совместимые ни с чем вменяемым.
Итак, ПромОС, с чем его едят и чем он отличается от.
Экологическая ниша промосей в настоящий момент заполнена довольно странными продуктами эволюции. Это обрезанные "ЭнТишки", это промверсии Линуха, это жутковатые и дорогущие "местечковые" изобретения типа VxWorks, не совместимые ни с чем вменяемым.
все обсуждение началось с неверных посылок. поэтому прокомментирую их. автор похоже разбирается в строении ОС... правда я не вникал в текст - "букафф многа". но вроде как есть умные слова и предложения. а вот в том что такое ПРОМЫШЛЕННАЯ ОС... вы слышали такие названия как QNX, LynxOS? это - промышленные ОС. жесткого реального времени. чтобы влезть в этот, безусловно прибыльный сегмент - нужно вбухать огромные деньги в разработку. а писать очередные рулилки для ЧПУ.. извините - кому оно надо?
>Нет, т.к. оболочка к ОСи отношения не имеет.
Не убедил. С философской точки зрения не имеет, а вот впечатление человека, слившего дистрибутив и знакомящегося, от дефолтовой рожи зависит очень сильно. Только не надо мне прочить рабочее место в M$ -- ты понял прекрасно, что я имею в виду не цветочки и не облака на рабстоле, а возможность приступить к ознакомительной работе тут же, врубившись без пол-литры.
>И судя по идее встраиваемости некоторых спец. функций в неё - она не дефолтовая, а добровольно-принудительно дефолтовая.
Спецфункции? Это ты про кластеры и автогенерацию конфиги через менюшный интерфейс? Да еще задокументированные? Вот уж не проблема переписать, как заблагорассудилось...
>незаметно, по крайней мере мне.. А чем плох мултизадачный дос в таком случае?
А это что, как не мультизадачный ДОС?
>как партизан на телефонной линии.
:-D Это пять :)
>Перехватывать обращения к несуществующему оборудованию и эмулить его.
Оборудование немного виртуализовано, что не сказывается на работе реального железа, но драйверу жизнь облегчает.
>При этом ещё возникает проблема совместимости. Если железка не совсем совместима с СО (а она по определению не совместима)
...то программа, послав запрос типа "какие режимы есть" для VESA, будет работать с теми, что есть %) Судьба ее такой.
>А если автор ПО по привычке (вспомни ДОС) будет использовать какие-то хитрые способы работы с железом? (стандартный X-mode на VGA например? или работа с развёрткой на нём-же?)
...то он будет молодец, ибо ЭСО VGA -- это что-то сверхъестественное :) Пусть только галочку сделает "не юзать хмод", а то вдруг действительно у кого-нибудь CGA с ЭСО VGA :)
...но это уже "бытовуха", ибо специфика промосей в том, что такая задача почти не встречается...
>Представь одновременную попытку работы со звуком 2х программ...
...а в ОС в принудительном порядке микшер встраивать на уровне драйвера звука -- лучше? Это закон природы, с ним не поборешься. Если плеер захватил 16-битный канал SB, для кваки остался только 8-битный. Если захватил MIDI port -- Doom будет без своей музыки. Опять же бытовуха, в промоси весь "оркестр" репетирует вместе, ибо специфика.
>некоторый уровень абстракции от оборудования необходим.
А он и есть. ЭСО -- слегка виртуальная штука, СО -- частный случай спецификации ЭСО. Например, SB16 -- это частный случай ЭСО звуковухи с 2 каналами, 8- и 16-разрядным синтезом етц. Общий случай имеет N каналов (квадра, 5.1, моно :) )...
>Чем тебе так консоль насолила, что ты её принципиально не хочешь видеть?
Кто сказал? Я не зря адресовался к NC -- консоль дефолтовой оболочки есть ее часть. Но не единственная. Не надо мне приписывать ложных злодеяний, у меня своих хватает :)
Я ее очень хочу видеть :)
>А не кажется тебе, что для этого придётся эмулятор машины делать? Вында вряд-ли согласится, чтобы её отрезали от железа, а допустить её туда - потом не выковырнешь..
Да не, не кажется, ибо винда, налетев на ЭСО, решит, что она дома на своем родном ДОС-ядре. А выковырять ее ресетом можно.
>Кстати, заниматься таким геморроем, чтобы "на ранней стадии м.б. понадобится какую-нибудь утильку запустить"?
Можно сразу "Вино" прилаживать. Хотя и геморрой-то невелик, если можно работать с собственным 32-экстендером, выгрузив "родной" 4GW-совместимый, то и винда почти уже готова на этом идти.
>Насколько я помню, мультизадачный дос существует уже...
И не один вроде... И какое-то их среднее -- хорошая отправная точка, плюс OpenWATCOM с его Dos4GW, только все вместе просто так не сольешь -- говидло получится. Поковыряться придется.
>Перекомпилится под конкретную мать он, вроде, без особых проблем.
...в силу абстракции оборудования. Которое сразу дает паровозоход.
>Тут не только каждая мать, но и каждый девайс учитывается. :-)
По кругу пошли.
>А паровоз от парохода не так сильно отличается, чтобы не было соблазна небольшой модификацией переделать одно в другое. Не вижу в этом ничего плохого.
...только пока шторм не начнется. То есть пока не понадобится обслуживать прерывание от железа за сто двадцать тактов при любой погоде и любом состоянии прочего ПО. И если залагать хоть раз -- хана. Ключевое слово "пром".
>А нафиг графику? Окошки рисовать? Так любая программа залезет в видеопамять и хана таким окошкам...
...только для WinE. Ибо MDI. Естественно, какая-нибудь ПромОС native фоновуха может в них влезть, если захочет. На здоровье ей.
>При такой философии доступа - imho только набор консолей, каждая в локальном фулскрине (придётся перехватывать весь доступ к видеооборудованию, запрет на работу в специфических режимах)
В локальном фулскрине, но не консоль. Ну, еще вертикальный сплитскрин разделением видеопамяти, но это мы рассматривать не будем, ибо изврат. Нестандартные режимы требуют запрет смены фокуса (если пишешь под сильно нестандартный режим, изволь заблочить соответствующую службу и потом разблочить). Стандартные -- слил туда-сюда видеобуфер и переставил разрешение/частоту.
>Кстати - набор консолей - вещь весьма удобная. Только не фиксированный, как в линух, и динамический - при запуске самостоятельной программы просто дать ей возможность создать себе консоль (если она ей нужна)
Подчинённые программы по дефолту просто наследуют родительскую. Оставить только 0-ю консоль для управления или под дефолтовый шелл, это уж как больше нравится...
Вот-вот-вот...
>Вот так всегда, на самом интересном месте...
Да там все слишком просто. Просто я спал уже на ходу. Мы начинаем запись сразу, а сами ждем еще данных, которые, пока девайс занят, сыплются в буфер. Когда буфер заполнен -- приостанавливаем прием, а когда девайс освобождается -- сливаем уже большой, буферизованный вывод (и снова начинаем принимать). Вроде как он и не ждет заполнения буфера, чтобы актуализировать содержимое -- надежность, и с каждым кластером не трясется, теряя время, а пишет все, кроме первого, оптом.
Если доступ не прямой, а файловый -- тем паче, мы буферизуем "втупую", а актуализируем по заполнению или закрытию файла. Тут все логично -- если файл не закрыт, то сбрасывать его на винт бессмысленно, программа с ним явно не закончила работать. Редкий случай, когда пол-файла тоже имеют ценность (отладочный лог) реализуются через открытие-закрытие "спокон веку и посейчас".
Не ругайся на вторичность -- так делают все нормальные люди, и я это знаю, но в NT почему-то не так и даже закрытый файл, если винда умерла по питанию, а не закрытию собственными средствами, может быть побит. Это бред.
>все обсуждение началось с неверных посылок.
Или не совсем понятых...
>автор похоже разбирается в строении ОС...
Надеюсь. Не хотелось бы так масштабно в себе разочароваться :)
>что такое ПРОМЫШЛЕННАЯ ОС... вы слышали такие названия как QNX, LynxOS? это - промышленные ОС. жесткого реального времени.
Выксворкс в этот же пугающий списочек...
>чтобы влезть в этот, безусловно прибыльный сегмент - нужно вбухать огромные деньги в разработку.
...или достигнуть сложных целей простыми средствами. Сейчас, правда, этот подход сильно не в моде.
"Простота, простота и еще раз простота! Пусть все дела ваши будут как два или три, а не как сотня или тысяча; вместо миллиона считайте до полудюжины и все свои расчеты ведите на ногте большого пальца". ©Генри Дэвид Торо
Несоблюдение этого великого завета -- вот причина всех бед, начиная от глюков винды и заканчивая переходниками с USB на LPT. Других причин нет и искать не дОлжно.
Не убедил. С философской точки зрения не имеет, а вот впечатление человека, слившего дистрибутив и знакомящегося, от дефолтовой рожи зависит очень сильно. Только не надо мне прочить рабочее место в M$ -- ты понял прекрасно, что я имею в виду не цветочки и не облака на рабстоле, а возможность приступить к ознакомительной работе тут же, врубившись без пол-литры.
>И судя по идее встраиваемости некоторых спец. функций в неё - она не дефолтовая, а добровольно-принудительно дефолтовая.
Спецфункции? Это ты про кластеры и автогенерацию конфиги через менюшный интерфейс? Да еще задокументированные? Вот уж не проблема переписать, как заблагорассудилось...
>незаметно, по крайней мере мне.. А чем плох мултизадачный дос в таком случае?
А это что, как не мультизадачный ДОС?
>как партизан на телефонной линии.
:-D Это пять :)
>Перехватывать обращения к несуществующему оборудованию и эмулить его.
Оборудование немного виртуализовано, что не сказывается на работе реального железа, но драйверу жизнь облегчает.
>При этом ещё возникает проблема совместимости. Если железка не совсем совместима с СО (а она по определению не совместима)
...то программа, послав запрос типа "какие режимы есть" для VESA, будет работать с теми, что есть %) Судьба ее такой.
>А если автор ПО по привычке (вспомни ДОС) будет использовать какие-то хитрые способы работы с железом? (стандартный X-mode на VGA например? или работа с развёрткой на нём-же?)
...то он будет молодец, ибо ЭСО VGA -- это что-то сверхъестественное :) Пусть только галочку сделает "не юзать хмод", а то вдруг действительно у кого-нибудь CGA с ЭСО VGA :)
...но это уже "бытовуха", ибо специфика промосей в том, что такая задача почти не встречается...
>Представь одновременную попытку работы со звуком 2х программ...
...а в ОС в принудительном порядке микшер встраивать на уровне драйвера звука -- лучше? Это закон природы, с ним не поборешься. Если плеер захватил 16-битный канал SB, для кваки остался только 8-битный. Если захватил MIDI port -- Doom будет без своей музыки. Опять же бытовуха, в промоси весь "оркестр" репетирует вместе, ибо специфика.
>некоторый уровень абстракции от оборудования необходим.
А он и есть. ЭСО -- слегка виртуальная штука, СО -- частный случай спецификации ЭСО. Например, SB16 -- это частный случай ЭСО звуковухи с 2 каналами, 8- и 16-разрядным синтезом етц. Общий случай имеет N каналов (квадра, 5.1, моно :) )...
>Чем тебе так консоль насолила, что ты её принципиально не хочешь видеть?
Кто сказал? Я не зря адресовался к NC -- консоль дефолтовой оболочки есть ее часть. Но не единственная. Не надо мне приписывать ложных злодеяний, у меня своих хватает :)
Я ее очень хочу видеть :)
>А не кажется тебе, что для этого придётся эмулятор машины делать? Вында вряд-ли согласится, чтобы её отрезали от железа, а допустить её туда - потом не выковырнешь..
Да не, не кажется, ибо винда, налетев на ЭСО, решит, что она дома на своем родном ДОС-ядре. А выковырять ее ресетом можно.
>Кстати, заниматься таким геморроем, чтобы "на ранней стадии м.б. понадобится какую-нибудь утильку запустить"?
Можно сразу "Вино" прилаживать. Хотя и геморрой-то невелик, если можно работать с собственным 32-экстендером, выгрузив "родной" 4GW-совместимый, то и винда почти уже готова на этом идти.
>Насколько я помню, мультизадачный дос существует уже...
И не один вроде... И какое-то их среднее -- хорошая отправная точка, плюс OpenWATCOM с его Dos4GW, только все вместе просто так не сольешь -- говидло получится. Поковыряться придется.
>Перекомпилится под конкретную мать он, вроде, без особых проблем.
...в силу абстракции оборудования. Которое сразу дает паровозоход.
>Тут не только каждая мать, но и каждый девайс учитывается. :-)
По кругу пошли.
>А паровоз от парохода не так сильно отличается, чтобы не было соблазна небольшой модификацией переделать одно в другое. Не вижу в этом ничего плохого.
...только пока шторм не начнется. То есть пока не понадобится обслуживать прерывание от железа за сто двадцать тактов при любой погоде и любом состоянии прочего ПО. И если залагать хоть раз -- хана. Ключевое слово "пром".
>А нафиг графику? Окошки рисовать? Так любая программа залезет в видеопамять и хана таким окошкам...
...только для WinE. Ибо MDI. Естественно, какая-нибудь ПромОС native фоновуха может в них влезть, если захочет. На здоровье ей.
>При такой философии доступа - imho только набор консолей, каждая в локальном фулскрине (придётся перехватывать весь доступ к видеооборудованию, запрет на работу в специфических режимах)
В локальном фулскрине, но не консоль. Ну, еще вертикальный сплитскрин разделением видеопамяти, но это мы рассматривать не будем, ибо изврат. Нестандартные режимы требуют запрет смены фокуса (если пишешь под сильно нестандартный режим, изволь заблочить соответствующую службу и потом разблочить). Стандартные -- слил туда-сюда видеобуфер и переставил разрешение/частоту.
>Кстати - набор консолей - вещь весьма удобная. Только не фиксированный, как в линух, и динамический - при запуске самостоятельной программы просто дать ей возможность создать себе консоль (если она ей нужна)
Подчинённые программы по дефолту просто наследуют родительскую. Оставить только 0-ю консоль для управления или под дефолтовый шелл, это уж как больше нравится...
Вот-вот-вот...
>Вот так всегда, на самом интересном месте...
Да там все слишком просто. Просто я спал уже на ходу. Мы начинаем запись сразу, а сами ждем еще данных, которые, пока девайс занят, сыплются в буфер. Когда буфер заполнен -- приостанавливаем прием, а когда девайс освобождается -- сливаем уже большой, буферизованный вывод (и снова начинаем принимать). Вроде как он и не ждет заполнения буфера, чтобы актуализировать содержимое -- надежность, и с каждым кластером не трясется, теряя время, а пишет все, кроме первого, оптом.
Если доступ не прямой, а файловый -- тем паче, мы буферизуем "втупую", а актуализируем по заполнению или закрытию файла. Тут все логично -- если файл не закрыт, то сбрасывать его на винт бессмысленно, программа с ним явно не закончила работать. Редкий случай, когда пол-файла тоже имеют ценность (отладочный лог) реализуются через открытие-закрытие "спокон веку и посейчас".
Не ругайся на вторичность -- так делают все нормальные люди, и я это знаю, но в NT почему-то не так и даже закрытый файл, если винда умерла по питанию, а не закрытию собственными средствами, может быть побит. Это бред.
>все обсуждение началось с неверных посылок.
Или не совсем понятых...
>автор похоже разбирается в строении ОС...
Надеюсь. Не хотелось бы так масштабно в себе разочароваться :)
>что такое ПРОМЫШЛЕННАЯ ОС... вы слышали такие названия как QNX, LynxOS? это - промышленные ОС. жесткого реального времени.
Выксворкс в этот же пугающий списочек...
>чтобы влезть в этот, безусловно прибыльный сегмент - нужно вбухать огромные деньги в разработку.
...или достигнуть сложных целей простыми средствами. Сейчас, правда, этот подход сильно не в моде.
"Простота, простота и еще раз простота! Пусть все дела ваши будут как два или три, а не как сотня или тысяча; вместо миллиона считайте до полудюжины и все свои расчеты ведите на ногте большого пальца". ©Генри Дэвид Торо
Несоблюдение этого великого завета -- вот причина всех бед, начиная от глюков винды и заканчивая переходниками с USB на LPT. Других причин нет и искать не дОлжно.
Цитата:
Спецфункции? Это ты про кластеры и автогенерацию конфиги через менюшный интерфейс? Да еще задокументированные? Вот уж не проблема переписать, как заблагорассудилось...
под win загрузчик тоже переписать можно... Даже любым дискэдитом.. но это не значит, что ситемный диск все предпочитают делать именно так.
Цитата:
А это что, как не мультизадачный ДОС?
уже существующий в нескольких ипостасях.
Цитата:
Оборудование немного виртуализовано, что не сказывается на работе реального железа, но драйверу жизнь облегчает.
усложняет. причём существенно. imho
Цитата:
...то программа, послав запрос типа "какие режимы есть" для VESA, будет работать с теми, что есть %) Судьба ее такой.
и не сможет работать с теми, что появились со времени его создания.
Цитата:
...то он будет молодец, ибо ЭСО VGA -- это что-то сверхъестественное :) Пусть только галочку сделает "не юзать хмод", а то вдруг действительно у кого-нибудь CGA с ЭСО VGA :)
...но это уже "бытовуха", ибо специфика промосей в том, что такая задача почти не встречается...
...но это уже "бытовуха", ибо специфика промосей в том, что такая задача почти не встречается...
"почти" не считается. или есть, или нет.
Цитата:
...а в ОС в принудительном порядке микшер встраивать на уровне драйвера звука -- лучше? Это закон природы, с ним не поборешься. Если плеер захватил 16-битный канал SB, для кваки остался только 8-битный. Если захватил MIDI port -- Doom будет без своей музыки. Опять же бытовуха, в промоси весь "оркестр" репетирует вместе, ибо специфика.
внимательнее. "позволяющие на относительно низком уровне работать с железом" - значит не работать с портами, а послать драйверу команду на изменение громкости, а как он её выполнит применительно к данной машине- кинет что в порты или ещё как (в зависимости от девайса - это уже его проблемы.
драйвер должен легко и однозначно транслировать общие команды в команды оборудования. всё.
А микшер.. Если он необходим - значит пусть будет. Если он не необходим - не надо его использовать. У драйвера вполне можно запросить, какие функции поддерживаются аппаратно. Да и написать оптимизированный под железку драйвер (особенно с учётом постоянного роста интеллектуальности самих девайсов) imho гораздо проще, чем пытаться в программе учесть особенности конкретной реализации данной СТАНДАРТНОЙ железки. Или на этом можно потерять изрядно так дорожимого тобой времени.
Цитата:
Кто сказал? Я не зря адресовался к NC -- консоль дефолтовой оболочки есть ее часть. Но не единственная. Не надо мне приписывать ложных злодеяний, у меня своих хватает :)
Я ее очень хочу видеть :)
Я ее очень хочу видеть :)
Ты сказал. Как иначе трактовать твои постоянные поправки "не консоль" (см. свои же комменты)
Цитата:
Да не, не кажется, ибо винда, налетев на ЭСО, решит, что она дома на своем родном ДОС-ядре. А выковырять ее ресетом можно.
Как обычно главное проигнорированно...
Ладно, повторюсь: если переключение режимов идёт ресетом, то почему нельзя просто при загрузке выбрать, в чём работать? Сложность реализации различается на порядки. Или "мы не ищем лёгких путей"?
Цитата:
Можно сразу "Вино" прилаживать. Хотя и геморрой-то невелик, если можно работать с собственным 32-экстендером, выгрузив "родной" 4GW-совместимый, то и винда почти уже готова на этом идти.
...
Цитата:
И не один вроде... И какое-то их среднее -- хорошая отправная точка, плюс OpenWATCOM с его Dos4GW, только все вместе просто так не сольешь -- говидло получится. Поковыряться придется.
Поковыряться и писать с нуля - всё-таки разные вещи
кстати наткнулся на такую весч:"Многотерминальная многопользовательская мультизадачная MS DOS-совместимая операционная система реального времени RTS-386"
Больше инфы не нашел.
Цитата:
>Перекомпилится под конкретную мать он, вроде, без особых проблем.
...в силу абстракции оборудования. Которое сразу дает паровозоход.
>Тут не только каждая мать, но и каждый девайс учитывается. :-)
По кругу пошли.
...в силу абстракции оборудования. Которое сразу дает паровозоход.
>Тут не только каждая мать, но и каждый девайс учитывается. :-)
По кругу пошли.
Угу. Твоя позиция по этому вопросу понятна и явно принципиальна.
Цитата:
...только пока шторм не начнется. То есть пока не понадобится обслуживать прерывание от железа за сто двадцать тактов при любой погоде и любом состоянии прочего ПО. И если залагать хоть раз -- хана. Ключевое слово "пром".
Переделать паровоз в пароход - отнюдь не означает привязать вместо колёс 2 байдарки...
Цитата:
...только для WinE. Ибо MDI. Естественно, какая-нибудь ПромОС native фоновуха может в них влезть, если захочет. На здоровье ей.
красивая картинка получится...
Цитата:
В локальном фулскрине, но не консоль. Ну, еще вертикальный сплитскрин разделением видеопамяти, но это мы рассматривать не будем, ибо изврат.
локальный фускрин - это и есть консоль.
Цитата:
Нестандартные режимы требуют запрет смены фокуса (если пишешь под сильно нестандартный режим, изволь заблочить соответствующую службу и потом разблочить). Стандартные -- слил туда-сюда видеобуфер и переставил разрешение/частоту.
а в это время соседний процесс решил поставить другое разрешение/частоту...
Залочил, а другй решил в это время переключить режим.. и будет ждать до скончания веков, пока это ему позволят. многозадачность, это когда много задач озадачены ожиданием...
imho столь свободное обращение с оборудованием подразумевает лишь один интерактивный процесс. все остальные лишь фоновые и вычислительние. наличие 2х интерактивных процессов приведёт к зависанию юзера.
Цитата:
Да там все слишком просто. Просто я спал уже на ходу. Мы начинаем запись сразу, а сами ждем еще данных, которые, пока девайс занят, сыплются в буфер. Когда буфер заполнен -- приостанавливаем прием, а когда девайс освобождается -- сливаем уже большой, буферизованный вывод (и снова начинаем принимать). Вроде как он и не ждет заполнения буфера, чтобы актуализировать содержимое -- надежность, и с каждым кластером не трясется, теряя время, а пишет все, кроме первого, оптом.
а в это время ему приходит большой ресет.
Цитата:
Если доступ не прямой, а файловый -- тем паче,
Не понял. А раньше обсуждался ПРЯМОЙ ДОСТУП К ДИСКУ? А ФС тебе не жалко? Тут и ресет не нужен...
Цитата:
мы буферизуем "втупую", а актуализируем по заполнению или закрытию файла. Тут все логично -- если файл не закрыт, то сбрасывать его на винт бессмысленно, программа с ним явно не закончила работать.
Угу.. в тупую файл в 2 гига... ню-ню.. или 20 гиг...
Цитата:
Редкий случай, когда пол-файла тоже имеют ценность (отладочный лог) реализуются через открытие-закрытие "спокон веку и посейчас".
офф. про функцию fflush ты явно не слышал.. Открытием/закрытием это реализуется только на васике, у которого с функциональностью вобще проблемы. Работая на нём можно стать проффесиональным проктологом.
Цитата:
Не ругайся на вторичность -- так делают все нормальные люди, и я это знаю, но в NT почему-то не так и даже закрытый файл, если винда умерла по питанию, а не закрытию собственными средствами, может быть побит. Это бред.
1.Это не бред, а многозадачность. Открытых и закрываемых файлов под NT может быть ой как много. Запусти filemon и ужаснись. А потом запусти handlmon (или как там её зовут, давно не юзал) и посмотри список используемых хендлов, в т.ч. файловых, и ужаснись ещё больше.
2. кэшируются не файлы, дисковый ввод-вывод. Чтобы всякие любители(таких есть) открывать/закрывать файлы по 20 раз в минуту не тормозили систему до полного аута. И в этом есть своя правда. Кстати, в вын. кэшированием файлов можно управлять при их открытии.
3. оффтоп. вын и глюки неотделимы.. там и не такое бывает. Из личной практики - вында как-то раз потеряла содержимое своих кешей и, благополучно не заметив потери, сбросила их на диск. Как не трудно догадаться в кэше хранились в первую очередь каталоги...
Читал…. 3 раза … Все пытаюсь понять о чем речь. Возникли вопросы:
1 Что первично , материя или сознание. Мы тут пишем ОС , а вы господа производители пароходов и паровозов уж постарайтесь подогнать свои железные интерфейсы к оной , а дрова мы органически , хотя ну ладно ,так и быть. А паролет тут ваще не предусмотрен. А не проще дровам (все-таки дровам) сделать приоритет выше ядра ОС , как в принципе все и поступают. Хотя идея загрузить винду как задачу многозадачного ДОС , и ставить дрова в ней мне тоже очень понравилась. Это наверно для гибкости системы.
2 Как все-таки здорово , подходишь к фрезерному станку , запускаешь деталь на обработку и думаешь , со скуки , какую музыку на сем станке послушать , или фильму на его дисплее посмотреть.
3 У нас тут одну линию открыли, так пришлось , блин , вставлять на управление самый обычный комп. Не беда , что данные считывали по сети в другом конце города, надеюсь сырцовая tcp/ip библиотека бы справилась с установкой транспортного канала , и ftp трафик держала бы , да только вот монитор , понимаете svga в панель встроен. Хотя не понял , если вечная консоль , то на кой ваще им графика.
4 А больше всего мне понравилось решение проблемы с загрузкой. Хотя буква D в абвеатуре dos и звучит как “дисковая”, но загружать контроллер паровозохода по сети мне очень понравилась.
5 Хорошая идея – выкинуть из винды все лишнее и в результате получится ДОС , круто.
А теперь о том что понял – при аварийном снятии питания с диска теряется только один файл – тот который в настоящий момент железно писался, просто по тому, что в каталоге не определена его длинна , а последний ссылаемый кластер вместо EOF имеет кашу. Больше не теряется ничего , вне зависимости от открытых или закрытых указателей.
1 Что первично , материя или сознание. Мы тут пишем ОС , а вы господа производители пароходов и паровозов уж постарайтесь подогнать свои железные интерфейсы к оной , а дрова мы органически , хотя ну ладно ,так и быть. А паролет тут ваще не предусмотрен. А не проще дровам (все-таки дровам) сделать приоритет выше ядра ОС , как в принципе все и поступают. Хотя идея загрузить винду как задачу многозадачного ДОС , и ставить дрова в ней мне тоже очень понравилась. Это наверно для гибкости системы.
2 Как все-таки здорово , подходишь к фрезерному станку , запускаешь деталь на обработку и думаешь , со скуки , какую музыку на сем станке послушать , или фильму на его дисплее посмотреть.
3 У нас тут одну линию открыли, так пришлось , блин , вставлять на управление самый обычный комп. Не беда , что данные считывали по сети в другом конце города, надеюсь сырцовая tcp/ip библиотека бы справилась с установкой транспортного канала , и ftp трафик держала бы , да только вот монитор , понимаете svga в панель встроен. Хотя не понял , если вечная консоль , то на кой ваще им графика.
4 А больше всего мне понравилось решение проблемы с загрузкой. Хотя буква D в абвеатуре dos и звучит как “дисковая”, но загружать контроллер паровозохода по сети мне очень понравилась.
5 Хорошая идея – выкинуть из винды все лишнее и в результате получится ДОС , круто.
А теперь о том что понял – при аварийном снятии питания с диска теряется только один файл – тот который в настоящий момент железно писался, просто по тому, что в каталоге не определена его длинна , а последний ссылаемый кластер вместо EOF имеет кашу. Больше не теряется ничего , вне зависимости от открытых или закрытых указателей.
>но это не значит, что ситемный диск все предпочитают делать именно так.
sys c: -- нормально? Зайти в классическом "двупанельнике" выше корневого, выше таблицы разделов (если винт), подцепить там первый сектор и F5-м швырнуть на другой диск -- несложно?
Это уже такие детали, то есть мелочи...
>усложняет. причём существенно. imho
Вопрос грамотности выбора этой архитекторы СО.
>и не сможет работать с теми, что появились со времени его создания.
Полная чушь, извини. Допустим, с новой четырехканальной или объемной системой раотать он не сможет, но какое ПО на такое способно и с какой системой? Практически никакое. А вот режим 10240x7680, появись он вдруг, даст нам только две константы, которые надо грамотно обработать.
Все количественные различия "сжираются" без проблем.
>"почти" не считается. или есть, или нет.
...и на этот случай галочка "юзать хмод" снимается...
>пытаться в программе учесть особенности конкретной реализации данной СТАНДАРТНОЙ железки. Или на этом можно потерять изрядно так дорожимого тобой времени.
Опять же, вопрос аккуратности выбора ЭСО. При аккуратном выборе программа почти не усложняется.
И, кстати, если нам НУЖНО стерео, скажем, мы гоним пару сигналов управления, мы можем работать только со стерео, программа с моно не заработает, но ведь она физически не может обойтись одним каналом! Аналогично, если нам нужно речевое подтверждение и мы паяем один динамик, мы о стерео и не думаем... Специфика прома -- нам нужно то, что нужно, и железо обычно конфигурится под софт, кстати говоря.
Кстати, тот уникальный случай, когда в проме нужен микшер, микширующий две программы-"черных ящика" (а черных ящиков в проме вообще мало), решается драйвером типа "партизан на телефонной линии", эмулирующий несколько устройств там, где оно одно. Решение корявое, но для очень экзотической ситуации.
Кстати, мерси за термин. Пусть будет "драйвер-партизан", очень метко :)
>Ты сказал. Как иначе трактовать твои постоянные поправки "не консоль" (см. свои же комменты)
Как "нечто, где консоль -- важная, но только часть" :)
>Ладно, повторюсь: если переключение режимов идёт ресетом, то почему нельзя просто при загрузке выбрать, в чём работать? Сложность реализации различается на порядки. Или "мы не ищем лёгких путей"?
Учитывая то, как хорошо запрятаны эти недокументированные функции, я склоняюсь к согласию с твоей точкой зрения...
>Поковыряться и писать с нуля - всё-таки разные вещи
Я разве говорил "с нуля"? Отправную точку, точнее, набор опорных точек, я даже не определял еще :)
> кстати наткнулся на такую весч:"Многотерминальная многопользовательская мультизадачная MS DOS-совместимая операционная система реального времени RTS-386"
Больше инфы не нашел.
Не вижу слова "открытая" :) Хотя вот это -- очень хорошая была бы опорная точка...
>Угу. Твоя позиция по этому вопросу понятна и явно принципиальна.
Вооот :) Именно принципиальна, и принципиальность упирается в юношески-максималистическое "лучшая ОС -- это та, которой как будто нет вовсе".
Достичь максимально возможного предела управляемости предельно простыми средствами и сохранить достаточное удобство работы -- вот это "тема".
>Переделать паровоз в пароход - отнюдь не означает привязать вместо колёс 2 байдарки...
...только все равно параметры не те.
>красивая картинка получится...
Near bird. Винное окно можно испортить точно так же, как любое другое. Оно не в лучшем и не в худшем положении.
Мы отталкиваемся от предпосылки, что человек не враг сам себе и окна не портят друг друга намеренно. См. пример с руками вовнутрь. А если портят, то по строго заданному плану.
>а в это время соседний процесс решил поставить другое разрешение/частоту...
И с какого пива он это решил?
>Залочил, а другй решил в это время переключить режим.. и будет ждать до скончания веков, пока это ему позволят.
Тут скорее надо отталкиваться от принципа "если процесс необязательно одинок, он должен сам заботиться о том, чтобы другим не вредить". Он и переключит, и под откос все пустит, только он не должен этого делать.
Военный коммунизм: все держится на личной совести, бессовестные расстреливаются юзером при помощи кн. "F8" :)
>imho столь свободное обращение с оборудованием подразумевает лишь один интерактивный процесс. все остальные лишь фоновые и вычислительние. наличие 2х интерактивных процессов приведёт к зависанию юзера.
Те, что не в фокусе, предупреждены об этом и делают то, что можно делать фоновой задаче. Считают, ждут вывода, отрекаются от квантов...
>а в это время ему приходит большой ресет.
Большой ресет приходит, когда закончилось I/O и погас огонек харда. Если ты нажмешь ресет в ходе копирования файла, ты FAT корежишь по любому. С любыми кэшами и без них тоже.
>Не понял. А раньше обсуждался ПРЯМОЙ ДОСТУП К ДИСКУ? А ФС тебе не жалко? Тут и ресет не нужен...
Не жалко. Это не вынь, который только тем и занят, что пишет логи, конфиги и свопы. Он делает то и только то, что прикажешь ты. Если ты закрыл все приложения, можешь запускать свой дискЪедит и впрямую работать с диском. Вселенная замерла и ждет покорно, когда ты закончишь.
>Угу.. в тупую файл в 2 гига... ню-ню.. или 20 гиг...
И при чем тут размер? Скажи-ка, как ты меня понял, ибо "размер не имеет значения" (© Йода) и, следовательно, я что-то двусмысленно сказал.
>офф. про функцию fflush ты явно не слышал..
Слышал, слышал. Не подумал.
А Васик -- это язык программируемого калькулятора. Выкидыш МатКада. На очень раней стадии выкинутый.
>Открытых и закрываемых файлов под NT может быть ой как много.
А под ПромОС -- файлы данных прикладного ПО и редко command.com.
>кэшируются не файлы, дисковый ввод-вывод. Чтобы всякие любители(таких есть) открывать/закрывать файлы по 20 раз в минуту не тормозили систему до полного аута.
Грамотно кэшировать можно на обоих уровнях.
А "любители" на промосях ходят исключительно лесом, смазав ж. и руки вазелином.
>Из личной практики - вында как-то раз потеряла содержимое своих кешей
:(
Мои соболезнования... :(
sys c: -- нормально? Зайти в классическом "двупанельнике" выше корневого, выше таблицы разделов (если винт), подцепить там первый сектор и F5-м швырнуть на другой диск -- несложно?
Это уже такие детали, то есть мелочи...
>усложняет. причём существенно. imho
Вопрос грамотности выбора этой архитекторы СО.
>и не сможет работать с теми, что появились со времени его создания.
Полная чушь, извини. Допустим, с новой четырехканальной или объемной системой раотать он не сможет, но какое ПО на такое способно и с какой системой? Практически никакое. А вот режим 10240x7680, появись он вдруг, даст нам только две константы, которые надо грамотно обработать.
Все количественные различия "сжираются" без проблем.
>"почти" не считается. или есть, или нет.
...и на этот случай галочка "юзать хмод" снимается...
>пытаться в программе учесть особенности конкретной реализации данной СТАНДАРТНОЙ железки. Или на этом можно потерять изрядно так дорожимого тобой времени.
Опять же, вопрос аккуратности выбора ЭСО. При аккуратном выборе программа почти не усложняется.
И, кстати, если нам НУЖНО стерео, скажем, мы гоним пару сигналов управления, мы можем работать только со стерео, программа с моно не заработает, но ведь она физически не может обойтись одним каналом! Аналогично, если нам нужно речевое подтверждение и мы паяем один динамик, мы о стерео и не думаем... Специфика прома -- нам нужно то, что нужно, и железо обычно конфигурится под софт, кстати говоря.
Кстати, тот уникальный случай, когда в проме нужен микшер, микширующий две программы-"черных ящика" (а черных ящиков в проме вообще мало), решается драйвером типа "партизан на телефонной линии", эмулирующий несколько устройств там, где оно одно. Решение корявое, но для очень экзотической ситуации.
Кстати, мерси за термин. Пусть будет "драйвер-партизан", очень метко :)
>Ты сказал. Как иначе трактовать твои постоянные поправки "не консоль" (см. свои же комменты)
Как "нечто, где консоль -- важная, но только часть" :)
>Ладно, повторюсь: если переключение режимов идёт ресетом, то почему нельзя просто при загрузке выбрать, в чём работать? Сложность реализации различается на порядки. Или "мы не ищем лёгких путей"?
Учитывая то, как хорошо запрятаны эти недокументированные функции, я склоняюсь к согласию с твоей точкой зрения...
>Поковыряться и писать с нуля - всё-таки разные вещи
Я разве говорил "с нуля"? Отправную точку, точнее, набор опорных точек, я даже не определял еще :)
> кстати наткнулся на такую весч:"Многотерминальная многопользовательская мультизадачная MS DOS-совместимая операционная система реального времени RTS-386"
Больше инфы не нашел.
Не вижу слова "открытая" :) Хотя вот это -- очень хорошая была бы опорная точка...
>Угу. Твоя позиция по этому вопросу понятна и явно принципиальна.
Вооот :) Именно принципиальна, и принципиальность упирается в юношески-максималистическое "лучшая ОС -- это та, которой как будто нет вовсе".
Достичь максимально возможного предела управляемости предельно простыми средствами и сохранить достаточное удобство работы -- вот это "тема".
>Переделать паровоз в пароход - отнюдь не означает привязать вместо колёс 2 байдарки...
...только все равно параметры не те.
>красивая картинка получится...
Near bird. Винное окно можно испортить точно так же, как любое другое. Оно не в лучшем и не в худшем положении.
Мы отталкиваемся от предпосылки, что человек не враг сам себе и окна не портят друг друга намеренно. См. пример с руками вовнутрь. А если портят, то по строго заданному плану.
>а в это время соседний процесс решил поставить другое разрешение/частоту...
И с какого пива он это решил?
>Залочил, а другй решил в это время переключить режим.. и будет ждать до скончания веков, пока это ему позволят.
Тут скорее надо отталкиваться от принципа "если процесс необязательно одинок, он должен сам заботиться о том, чтобы другим не вредить". Он и переключит, и под откос все пустит, только он не должен этого делать.
Военный коммунизм: все держится на личной совести, бессовестные расстреливаются юзером при помощи кн. "F8" :)
>imho столь свободное обращение с оборудованием подразумевает лишь один интерактивный процесс. все остальные лишь фоновые и вычислительние. наличие 2х интерактивных процессов приведёт к зависанию юзера.
Те, что не в фокусе, предупреждены об этом и делают то, что можно делать фоновой задаче. Считают, ждут вывода, отрекаются от квантов...
>а в это время ему приходит большой ресет.
Большой ресет приходит, когда закончилось I/O и погас огонек харда. Если ты нажмешь ресет в ходе копирования файла, ты FAT корежишь по любому. С любыми кэшами и без них тоже.
>Не понял. А раньше обсуждался ПРЯМОЙ ДОСТУП К ДИСКУ? А ФС тебе не жалко? Тут и ресет не нужен...
Не жалко. Это не вынь, который только тем и занят, что пишет логи, конфиги и свопы. Он делает то и только то, что прикажешь ты. Если ты закрыл все приложения, можешь запускать свой дискЪедит и впрямую работать с диском. Вселенная замерла и ждет покорно, когда ты закончишь.
>Угу.. в тупую файл в 2 гига... ню-ню.. или 20 гиг...
И при чем тут размер? Скажи-ка, как ты меня понял, ибо "размер не имеет значения" (© Йода) и, следовательно, я что-то двусмысленно сказал.
>офф. про функцию fflush ты явно не слышал..
Слышал, слышал. Не подумал.
А Васик -- это язык программируемого калькулятора. Выкидыш МатКада. На очень раней стадии выкинутый.
>Открытых и закрываемых файлов под NT может быть ой как много.
А под ПромОС -- файлы данных прикладного ПО и редко command.com.
>кэшируются не файлы, дисковый ввод-вывод. Чтобы всякие любители(таких есть) открывать/закрывать файлы по 20 раз в минуту не тормозили систему до полного аута.
Грамотно кэшировать можно на обоих уровнях.
А "любители" на промосях ходят исключительно лесом, смазав ж. и руки вазелином.
>Из личной практики - вында как-то раз потеряла содержимое своих кешей
:(
Мои соболезнования... :(
>Все пытаюсь понять о чем речь.
Я тоже :D
>Мы тут пишем ОС , а вы господа производители пароходов и паровозов уж постарайтесь подогнать свои железные интерфейсы к оной
Ничего подобного и даже в темноте не похоже. "Мы тут пишем ОС, а вы, господа, соблюдайте стандарты VESA, ATA, некоторые негласные, ну, а кто не соблюдает, для тех дрова напишем, хотя это и ай-яй-яй не соблюдать стандарты".
>Хотя идея загрузить винду как задачу многозадачного ДОС
Идея была вовсе не в этом.
>Как все-таки здорово , подходишь к фрезерному станку , запускаешь деталь на обработку и думаешь , со скуки , какую музыку на сем станке послушать
Гы :) Хорошо сказано :) Только скучать там не будешь, побежишь от одного к другому турманом, запуская по очереди :)
А вообще -- бытовые примеры не должны создавать "буквального" понимания. Я специально пишу -- "на бытовом примере, возьмем MP3 плеер" -- естественно, это не значит, что там будет MP3 плеер. Не надо издеваться :P
> сырцовая tcp/ip библиотека бы справилась с установкой транспортного канала , и ftp трафик держала бы
А куда ж она денется. Как родная "присосется", если не кривая. А она не кривая. Это основополагающая предпосылка.
И она есть давно, тцпип постарше виндей.
>да только вот монитор , понимаете svga в панель встроен.
И чего? SVGA и SVGA, если нужен 320х200 -- и VGA пойдет, и SVGA, если нужно больше -- SVGA VESA или с VESA-драйвером ЭСО.
>Хотя не понял , если вечная консоль , то на кой ваще им графика.
Не консоль. Но GUI-библиотеки по минимуму и в фулскрин.
>но загружать контроллер паровозохода по сети мне очень понравилась.
Очень частый промслучай, сто плат грузят ОС по сети с общего серванта, если не нужна автономность. ОЧЕНЬ частый.
>выкинуть из винды все лишнее и в результате...
...получится гибид DOS4GW с ReactOS'ом.
>А теперь о том что понял – при аварийном снятии питания с диска теряется только один файл
...поскольку в "отложенном" состоянии запись бывает ТОЛЬКО во время работы харда, т.е. когда девайс физически занят. Во всех остальных случаях она не откладывается, даже если объем на запись мал.
Это даже не какой-то гениальный алгоритм, это называется "политика кэширования, на которой мы остановились".
Я тоже :D
>Мы тут пишем ОС , а вы господа производители пароходов и паровозов уж постарайтесь подогнать свои железные интерфейсы к оной
Ничего подобного и даже в темноте не похоже. "Мы тут пишем ОС, а вы, господа, соблюдайте стандарты VESA, ATA, некоторые негласные, ну, а кто не соблюдает, для тех дрова напишем, хотя это и ай-яй-яй не соблюдать стандарты".
>Хотя идея загрузить винду как задачу многозадачного ДОС
Идея была вовсе не в этом.
>Как все-таки здорово , подходишь к фрезерному станку , запускаешь деталь на обработку и думаешь , со скуки , какую музыку на сем станке послушать
Гы :) Хорошо сказано :) Только скучать там не будешь, побежишь от одного к другому турманом, запуская по очереди :)
А вообще -- бытовые примеры не должны создавать "буквального" понимания. Я специально пишу -- "на бытовом примере, возьмем MP3 плеер" -- естественно, это не значит, что там будет MP3 плеер. Не надо издеваться :P
> сырцовая tcp/ip библиотека бы справилась с установкой транспортного канала , и ftp трафик держала бы
А куда ж она денется. Как родная "присосется", если не кривая. А она не кривая. Это основополагающая предпосылка.
И она есть давно, тцпип постарше виндей.
>да только вот монитор , понимаете svga в панель встроен.
И чего? SVGA и SVGA, если нужен 320х200 -- и VGA пойдет, и SVGA, если нужно больше -- SVGA VESA или с VESA-драйвером ЭСО.
>Хотя не понял , если вечная консоль , то на кой ваще им графика.
Не консоль. Но GUI-библиотеки по минимуму и в фулскрин.
>но загружать контроллер паровозохода по сети мне очень понравилась.
Очень частый промслучай, сто плат грузят ОС по сети с общего серванта, если не нужна автономность. ОЧЕНЬ частый.
>выкинуть из винды все лишнее и в результате...
...получится гибид DOS4GW с ReactOS'ом.
>А теперь о том что понял – при аварийном снятии питания с диска теряется только один файл
...поскольку в "отложенном" состоянии запись бывает ТОЛЬКО во время работы харда, т.е. когда девайс физически занят. Во всех остальных случаях она не откладывается, даже если объем на запись мал.
Это даже не какой-то гениальный алгоритм, это называется "политика кэширования, на которой мы остановились".
Цитата:
sys c: -- нормально? Зайти в классическом "двупанельнике" выше корневого, выше таблицы разделов (если винт), подцепить там первый сектор и F5-м швырнуть на другой диск -- несложно?
Это уже такие детали, то есть мелочи...
Это уже такие детали, то есть мелочи...
1. Если мне не изменяет память - бутсектор в тупую копировать нельзя. Там кроме загрузчика ещё кое-какая инфа специфичная для драйва есть.
2. хм. Таблица разделов находится в 0 секторе харда. Если мы поднимемся выше таблицы разделов, то первый сектор ЧЕГО копировать???
Цитата:
>усложняет. причём существенно. imho
Вопрос грамотности выбора этой архитекторы СО.
Вопрос грамотности выбора этой архитекторы СО.
Содержательный ответ. В таком случае не менее содержательное - не согласен.
Цитата:
>и не сможет работать с теми, что появились со времени его создания.
Полная чушь, извини. Допустим, с новой четырехканальной или объемной системой раотать он не сможет, но какое ПО на такое способно и с какой системой? Практически никакое. А вот режим 10240x7680, появись он вдруг, даст нам только две константы, которые надо грамотно обработать.
Все количественные различия "сжираются" без проблем.
Полная чушь, извини. Допустим, с новой четырехканальной или объемной системой раотать он не сможет, но какое ПО на такое способно и с какой системой? Практически никакое. А вот режим 10240x7680, появись он вдруг, даст нам только две константы, которые надо грамотно обработать.
Все количественные различия "сжираются" без проблем.
НЕ полная чушь. Ты выбрал видеоадаптер, как ЕДИНСТВЕННОЕ железо, с новыми возможностями которого можно работать без изменения кода.
А вот добавь туда VBE2 и твоя прога идёт лесом.
Цитата:
Опять же, вопрос аккуратности выбора ЭСО. При аккуратном выборе программа почти не усложняется.
И, кстати, если нам НУЖНО стерео, скажем, мы гоним пару сигналов управления, мы можем работать только со стерео, программа с моно не заработает, но ведь она физически не может обойтись одним каналом! Аналогично, если нам нужно речевое подтверждение и мы паяем один динамик, мы о стерео и не думаем... Специфика прома -- нам нужно то, что нужно, и железо обычно конфигурится под софт, кстати говоря.
И, кстати, если нам НУЖНО стерео, скажем, мы гоним пару сигналов управления, мы можем работать только со стерео, программа с моно не заработает, но ведь она физически не может обойтись одним каналом! Аналогично, если нам нужно речевое подтверждение и мы паяем один динамик, мы о стерео и не думаем... Специфика прома -- нам нужно то, что нужно, и железо обычно конфигурится под софт, кстати говоря.
Железо под софт? Тогда вся эта дискуссия бессмысленна. Напиши любую хрень, а кому понравится - железо подберут. Если смогут. Идрайвера тогда вообще не нужны.
Цитата:
Вооот :) Именно принципиальна, и принципиальность упирается в юношески-максималистическое "лучшая ОС -- это та, которой как будто нет вовсе".
Достичь максимально возможного предела управляемости предельно простыми средствами и сохранить достаточное удобство работы -- вот это "тема".
Достичь максимально возможного предела управляемости предельно простыми средствами и сохранить достаточное удобство работы -- вот это "тема".
Не уверен, что отсутствие драйверов - предельно простой способ для программиста прикладного софта. Только для того, кто пишет ОС.
Максимализм - путь, конечно, интересный, но не практичный. imho
Цитата:
>Переделать паровоз в пароход - отнюдь не означает привязать вместо колёс 2 байдарки...
...только все равно параметры не те.
...только все равно параметры не те.
Параметры различаются только внешним корпусом.
Цитата:
>а в это время соседний процесс решил поставить другое разрешение/частоту...
И с какого пива он это решил?
А вот понадобилось ему...
Цитата:
Тут скорее надо отталкиваться от принципа "если процесс необязательно одинок, он должен сам заботиться о том, чтобы другим не вредить". Он и переключит, и под откос все пустит, только он не должен этого делать.
Военный коммунизм: все держится на личной совести, бессовестные расстреливаются юзером при помощи кн. "F8" :)
Военный коммунизм: все держится на личной совести, бессовестные расстреливаются юзером при помощи кн. "F8" :)
Если вспомнить твои слова про автомобиль - туда почти наверняка будут ставить и сторонний софт, так что конфликтов не избежать.
Цитата:
>а в это время ему приходит большой ресет.
Большой ресет приходит, когда закончилось I/O и погас огонек харда.
Не уверен, что пьяный электрик будет ждать, пока у тебя "погаснет огонёк харда".
Цитата:
Если ты нажмешь ресет в ходе копирования файла, ты FAT корежишь по любому. С любыми кэшами и без них тоже.
Про журналируемые фс слышал?
Цитата:
>Не понял. А раньше обсуждался ПРЯМОЙ ДОСТУП К ДИСКУ? А ФС тебе не жалко? Тут и ресет не нужен...
Не жалко. Это не вынь, который только тем и занят, что пишет логи, конфиги и свопы. Он делает то и только то, что прикажешь ты. Если ты закрыл все приложения, можешь запускать свой дискЪедит и впрямую работать с диском. Вселенная замерла и ждет покорно, когда ты закончишь.
Не жалко. Это не вынь, который только тем и занят, что пишет логи, конфиги и свопы. Он делает то и только то, что прикажешь ты. Если ты закрыл все приложения, можешь запускать свой дискЪедит и впрямую работать с диском. Вселенная замерла и ждет покорно, когда ты закончишь.
Чесно говоря чем дальше, тем больше я прихожу к выводу, что собственно ОС тебе не нужна вобще. О чём тогда идёт речь, если каждый программер сам за себя?
Цитата:
И при чем тут размер? Скажи-ка, как ты меня понял, ибо "размер не имеет значения" (© Йода) и, следовательно, я что-то двусмысленно сказал.
->"Тут все логично -- если файл не закрыт, то сбрасывать его на винт бессмысленно, программа с ним явно не закончила работать."
Цитата:
>Открытых и закрываемых файлов под NT может быть ой как много.
А под ПромОС -- файлы данных прикладного ПО и редко command.com.
А под ПромОС -- файлы данных прикладного ПО и редко command.com.
А под NT тоже файлы прикладного по. кто сказал, что их будет мало?
command.com? ты туда писать собираешься??? всё интереснее и интереснее...
Цитата:
Грамотно кэшировать можно на обоих уровнях.
А "любители" на промосях ходят исключительно лесом, смазав ж. и руки вазелином.
А "любители" на промосях ходят исключительно лесом, смазав ж. и руки вазелином.
Да вы, батенька, оптимист...
>1. 2.
Защщитано.
>Содержательный ответ. В таком случае не менее содержательное - не согласен.
Ответ типа "EB FE". И не надейся, не зависну. Ладно, ща расшифрую.
При грамотно построенной ЭСО, в смысле грамотно формализованном интерфейсе, на программу практически не ложится дополнительной нагрузки. Даже учитывая то, что об ЭСО никто не думал, когда создавали то оборудование, которое мы принимаем за наиболее характерный случай СО в ЭСО.
>А вот добавь туда VBE2 и твоя прога идёт лесом.
...и она идет на старом VBE1. И, если деталь и раньше обрабатывалась без VBE2, она и сейчас будет обрабатываться не хуже. И мало что из VBE2 может нам быть полезным.
Если появился стереомонитор (левый-правый глаз), программа должна как минимум уметь строить два изображения. Никакой драйвер ее не научит использовать эту "новую возможность".
А теперь я возвращаюсь к предыдущему пункту и хочу сказать пару слов про "грамотную архитектуру ЭСО".
Пусть она содержит некоторую абстракцию типа "числа экранных плоскостей". Обычный экран содержит одну плоскость.
Двуэкранный адаптер имеет две плоскости, стереоочки -- эмулированные две.
Как мы делаем такую "закладку на будущее" в ЭСО и как она потом работает?
Мы делаем такую закладку, исходя из наиболее грамотного математически (не забываем, господа, дядю Кнута и то, что все мы, собссно, математикой занимаемся) решения. Соответствие будущего оборудования этому решению бывает трех типов:
1) Мы угадали чей-то, тоже самый грамотный, ход мыслей или производитель пошел по нашему пути. Это самый редкий случай, но я так вслепую попадал и оно и по сей день работает, поэтому скинуть со счетов не могу. "Смейтесь-смейтесь, а мальчика нет". Не попадем -- будет тоскливо выводить на стереодисплей монокартинку до появления пункта 2.
2) Драйвер-партизан. Поскольку ему нужно перебить один байт чьего-то статуса в байт нашего статуса, драйвер несложный.
3) Самый частый промслучай. Поскольку мы делаем конечный прибор, стереовидеоадаптер мы же сами и делаем. Обычно так и есть, и ЭСО в таком случае -- что-то вроде "конвенции детей лт. Шмидта", общая договоренность, чтобы все наши самоделки говорили на одном языке.
Не забываем, ключевое слово -- "Пром".
>Железо под софт? Тогда вся эта дискуссия бессмысленна. Напиши любую хрень, а кому понравится - железо подберут.
Ну, с философской точки зрения, кое-кто ради Doom 3 апгрейдился, так что это "единство и борьба противоположностей" всегда и везде есть. Я говорю, что в промышленности сперва есть задача, типа "управлять станком", потом есть математика, которая ее решает, а потом уже собирается вычислитель, на котором эта математика пойдет. Поэтому соотношение весов этих "противоположностей" совсем другое, т.к. задача определяется назначением, а не выходит на трех DVD через год после покупки прибора.
Однако, как ты наверное заметил, суть ЭСО как раз в том, чтобы не доводить этот перевес до абсурда. Тогда бы ни ОС, ни ЭСО были не нужны.
Выделил жирным, т.к., не задумываясь над ЭСО, почти все читавшие воспринимают эту концепцию именно как такое "доведение до абсурда", "машину с нуля под каждую программу". ЭСО -- это в первую очередь драйверы-"партизаны", которые во многих случаях выпадают из-за самодельности или стандартности (VESA, SB, USB, ATA...) оборудования.
>Не уверен, что отсутствие драйверов - предельно простой способ для программиста прикладного софта. Только для того, кто пишет ОС.
Ой ли? Повеситься на прерывание и напрямую адресовать порты vs писать собственный драйвер, который только и имеет право на порты, клянчить у системы кванты времени и исходить матом от того, что она имеет квантизацию 1 мС, а тебе 50 мкС нужно? О неееееет, без меня. Я за OpenWATCOM полез, ща пджи мнутку, разрулим твой станочек вручную.
>Максимализм - путь, конечно, интересный, но не практичный. imho
Может быть. Однако, чтобы увезти золото, мало быть сильным. Нужно еще, чтобы ты не был согласен на бронзу.
>Параметры различаются только внешним корпусом.
Паровой движок паровоза оптимизирован под разгон/выбег, пароходный же работает в постоянном режиме наибольшей экономичности. Разница эта буквально в каждом размере механики.
>А вот понадобилось ему...
Прочитал статус и перехотелось. А безграмотным софтом можно что угодно свалить. Особено управляя PCI напрямую, что в проме в 90% случаев нужно.
>Если вспомнить твои слова про автомобиль - туда почти наверняка будут ставить и сторонний софт, так что конфликтов не избежать.
Сторонний софт должен быть либо абсолютно надежен, но тогда он не сторонний, либо абсолютно развязан от "жизнеобеспечения", но это невозможно на уровне ОС, а возможно только на уровне виртуальной машины, которая сама по себе должна быть абсолютно надежна и идти в комплекте ПО.
Определение "абсолютно надежного": вероятность отказа равняется допустимой вероятности отказа бортового вычислителя и перехода на полностью ручное управление до ремонта.
>Не уверен, что пьяный электрик будет ждать, пока у тебя "погаснет огонёк харда".
...или питание само оборвется, без него. Просто на системный диск ничего вообще не пишется, а юзерский -- вещь эфемерная. Главное, чтобы не умерло то, что было раньше скачано.
>Про журналируемые фс слышал?
И все равно недокачанный с заводского сервера чертеж в докачанный не превратится...
>Чесно говоря чем дальше, тем больше я прихожу к выводу, что собственно ОС тебе не нужна вообще.
Гаки, голодный демон ада :) Ну почему ж не нужна-то? А ЭСО? Стандарты? Библиотеки GUI, file system, "общая" мультизадачность?
По-моему, ты чересчур увлекся :)
>О чём тогда идёт речь, если каждый программер сам за себя?
? ? ?
>"Тут все логично -- если файл не закрыт, то сбрасывать его на винт бессмысленно, программа с ним явно не закончила работать."
"Сбрасывать" в смысле "опустошать остатки из буферов". Очевидно, что по мере заполнения буфер сбрасывается, тут имеется в виду остаточный хвост.
Это я настолько криво сказал, ты настолько криво понял или ты глумишься? :)
>тоже файлы прикладного по. Кто сказал, что их будет мало?
Главное не "много-мало", а для I, O, I/O и на какой момент времени.
>command.com? ты туда писать собираешься??? всё интереснее и интереснее...
Чудесатой Алисы на тебя нет, блин :) Вот придира, ну для ЧТЕНИЯ он открывается, ясный пельмень, просто в общий список ОТКРЫТЫХ попадает %)
>Да вы, батенька, оптимист...
Да нет, я тот самый слон... Козолупов александрийских по любому к проекту подпускать нельзя. В программерском мануале, окромя перечня служб, дается соглашение по архитектуре, где всё перечислено, и "кто не все, того накажем".
Защщитано.
>Содержательный ответ. В таком случае не менее содержательное - не согласен.
Ответ типа "EB FE". И не надейся, не зависну. Ладно, ща расшифрую.
При грамотно построенной ЭСО, в смысле грамотно формализованном интерфейсе, на программу практически не ложится дополнительной нагрузки. Даже учитывая то, что об ЭСО никто не думал, когда создавали то оборудование, которое мы принимаем за наиболее характерный случай СО в ЭСО.
>А вот добавь туда VBE2 и твоя прога идёт лесом.
...и она идет на старом VBE1. И, если деталь и раньше обрабатывалась без VBE2, она и сейчас будет обрабатываться не хуже. И мало что из VBE2 может нам быть полезным.
Если появился стереомонитор (левый-правый глаз), программа должна как минимум уметь строить два изображения. Никакой драйвер ее не научит использовать эту "новую возможность".
А теперь я возвращаюсь к предыдущему пункту и хочу сказать пару слов про "грамотную архитектуру ЭСО".
Пусть она содержит некоторую абстракцию типа "числа экранных плоскостей". Обычный экран содержит одну плоскость.
Двуэкранный адаптер имеет две плоскости, стереоочки -- эмулированные две.
Как мы делаем такую "закладку на будущее" в ЭСО и как она потом работает?
Мы делаем такую закладку, исходя из наиболее грамотного математически (не забываем, господа, дядю Кнута и то, что все мы, собссно, математикой занимаемся) решения. Соответствие будущего оборудования этому решению бывает трех типов:
1) Мы угадали чей-то, тоже самый грамотный, ход мыслей или производитель пошел по нашему пути. Это самый редкий случай, но я так вслепую попадал и оно и по сей день работает, поэтому скинуть со счетов не могу. "Смейтесь-смейтесь, а мальчика нет". Не попадем -- будет тоскливо выводить на стереодисплей монокартинку до появления пункта 2.
2) Драйвер-партизан. Поскольку ему нужно перебить один байт чьего-то статуса в байт нашего статуса, драйвер несложный.
3) Самый частый промслучай. Поскольку мы делаем конечный прибор, стереовидеоадаптер мы же сами и делаем. Обычно так и есть, и ЭСО в таком случае -- что-то вроде "конвенции детей лт. Шмидта", общая договоренность, чтобы все наши самоделки говорили на одном языке.
Не забываем, ключевое слово -- "Пром".
>Железо под софт? Тогда вся эта дискуссия бессмысленна. Напиши любую хрень, а кому понравится - железо подберут.
Ну, с философской точки зрения, кое-кто ради Doom 3 апгрейдился, так что это "единство и борьба противоположностей" всегда и везде есть. Я говорю, что в промышленности сперва есть задача, типа "управлять станком", потом есть математика, которая ее решает, а потом уже собирается вычислитель, на котором эта математика пойдет. Поэтому соотношение весов этих "противоположностей" совсем другое, т.к. задача определяется назначением, а не выходит на трех DVD через год после покупки прибора.
Однако, как ты наверное заметил, суть ЭСО как раз в том, чтобы не доводить этот перевес до абсурда. Тогда бы ни ОС, ни ЭСО были не нужны.
Выделил жирным, т.к., не задумываясь над ЭСО, почти все читавшие воспринимают эту концепцию именно как такое "доведение до абсурда", "машину с нуля под каждую программу". ЭСО -- это в первую очередь драйверы-"партизаны", которые во многих случаях выпадают из-за самодельности или стандартности (VESA, SB, USB, ATA...) оборудования.
>Не уверен, что отсутствие драйверов - предельно простой способ для программиста прикладного софта. Только для того, кто пишет ОС.
Ой ли? Повеситься на прерывание и напрямую адресовать порты vs писать собственный драйвер, который только и имеет право на порты, клянчить у системы кванты времени и исходить матом от того, что она имеет квантизацию 1 мС, а тебе 50 мкС нужно? О неееееет, без меня. Я за OpenWATCOM полез, ща пджи мнутку, разрулим твой станочек вручную.
>Максимализм - путь, конечно, интересный, но не практичный. imho
Может быть. Однако, чтобы увезти золото, мало быть сильным. Нужно еще, чтобы ты не был согласен на бронзу.
>Параметры различаются только внешним корпусом.
Паровой движок паровоза оптимизирован под разгон/выбег, пароходный же работает в постоянном режиме наибольшей экономичности. Разница эта буквально в каждом размере механики.
>А вот понадобилось ему...
Прочитал статус и перехотелось. А безграмотным софтом можно что угодно свалить. Особено управляя PCI напрямую, что в проме в 90% случаев нужно.
>Если вспомнить твои слова про автомобиль - туда почти наверняка будут ставить и сторонний софт, так что конфликтов не избежать.
Сторонний софт должен быть либо абсолютно надежен, но тогда он не сторонний, либо абсолютно развязан от "жизнеобеспечения", но это невозможно на уровне ОС, а возможно только на уровне виртуальной машины, которая сама по себе должна быть абсолютно надежна и идти в комплекте ПО.
Определение "абсолютно надежного": вероятность отказа равняется допустимой вероятности отказа бортового вычислителя и перехода на полностью ручное управление до ремонта.
>Не уверен, что пьяный электрик будет ждать, пока у тебя "погаснет огонёк харда".
...или питание само оборвется, без него. Просто на системный диск ничего вообще не пишется, а юзерский -- вещь эфемерная. Главное, чтобы не умерло то, что было раньше скачано.
>Про журналируемые фс слышал?
И все равно недокачанный с заводского сервера чертеж в докачанный не превратится...
>Чесно говоря чем дальше, тем больше я прихожу к выводу, что собственно ОС тебе не нужна вообще.
Гаки, голодный демон ада :) Ну почему ж не нужна-то? А ЭСО? Стандарты? Библиотеки GUI, file system, "общая" мультизадачность?
По-моему, ты чересчур увлекся :)
>О чём тогда идёт речь, если каждый программер сам за себя?
? ? ?
>"Тут все логично -- если файл не закрыт, то сбрасывать его на винт бессмысленно, программа с ним явно не закончила работать."
"Сбрасывать" в смысле "опустошать остатки из буферов". Очевидно, что по мере заполнения буфер сбрасывается, тут имеется в виду остаточный хвост.
Это я настолько криво сказал, ты настолько криво понял или ты глумишься? :)
>тоже файлы прикладного по. Кто сказал, что их будет мало?
Главное не "много-мало", а для I, O, I/O и на какой момент времени.
>command.com? ты туда писать собираешься??? всё интереснее и интереснее...
Чудесатой Алисы на тебя нет, блин :) Вот придира, ну для ЧТЕНИЯ он открывается, ясный пельмень, просто в общий список ОТКРЫТЫХ попадает %)
>Да вы, батенька, оптимист...
Да нет, я тот самый слон... Козолупов александрийских по любому к проекту подпускать нельзя. В программерском мануале, окромя перечня служб, дается соглашение по архитектуре, где всё перечислено, и "кто не все, того накажем".
Николай Коровин
О чем вы тут огород городите?
ОС-это программа для разделения ресурсов системы.
Прочел все из всего понял только первый пост.
Железа можно поделить на 2 типа. Первый тип это впринципи железо которое работоет самостоятельно только создает прирывание которые нужно обробатывать. Второй тип это которое нужно кантролировать вести проверять.
Если с первым все понятно там нужен небольшой код который устанавливает регистры и все.Это современное оборудование. То за вторым нужен контроль здесь и нужна система реального времени. Но так ли она нужна? Да если нужно обработать и передать данные в жостка ограниченном времени. Но с другой стороны если программа успивает выполнять свои необходимые действия то почему бы неодать свободное время другой программы. По этому много задачьность для системы возможна, даже нужна, необходима. Драйвера безусловна нужны. Самый простой пример. Два различныйх устройства должны быть завязаны на таймере(ули еще чем нибудь). Так как программы обслуживающии их тоже разные. То нужен драйвер который будет управлять всем этим. Да и наних можно повесить опрос устройств которые будут находиться в ожидании. Спрашиваеться чем такая ОС отличаеться от остальных? Да в принцапи от Win тем, что каждая задаче должно выполняться строгое время или не строгое на усмотрение программы. Но я считаю что нужно вынести возможность настройки.
Кто-то говорил о перезагрузке? Ребят вы что какая перезагрузка это же уйма простояв. Можно просто на просто создать консоль. Которую можно будет вызватьи обрабатывать без ущерба остальным программам. Мы не будем переключать задачи, а просто будем передавать на короткое время управление. Ее оверлею.
Через нее и будет происходить управление.
Еще немного о процессах и драйверах. Для того что бы система работала быстра. Каждый драйвер будет представлять из себя подпрограмму которая обрабатывает прирывания или наоборот опрашывает его. Драйверы вызываються очень часто если им это требуеться для опроса оборудование. Общение между драйвером и программой заключается тем что драйер говорит что с такого устройства пришли те данные или ушли. Осуществляеться вызывам соотвествующей процедуры процесса не каких отолежжных вызывов. Переключение между процессами заключаеться в полной остановки первого и запуска другого.
Что еще требуеться от ос? Да в принцапи только возможнос стандартного работа с устройствами. Так как драйвер этого не осуществляет. То просто набор библеотек которые будут стандартерезировать работу разных программ с одним устройством. И для разных версий устройств через одну программу.
Насчет защиты системы. Если программу ограничеть средствами ОС. То система будет защищенной. При условии что нет других дыр.
О чем вы тут огород городите?
ОС-это программа для разделения ресурсов системы.
Прочел все из всего понял только первый пост.
Железа можно поделить на 2 типа. Первый тип это впринципи железо которое работоет самостоятельно только создает прирывание которые нужно обробатывать. Второй тип это которое нужно кантролировать вести проверять.
Если с первым все понятно там нужен небольшой код который устанавливает регистры и все.Это современное оборудование. То за вторым нужен контроль здесь и нужна система реального времени. Но так ли она нужна? Да если нужно обработать и передать данные в жостка ограниченном времени. Но с другой стороны если программа успивает выполнять свои необходимые действия то почему бы неодать свободное время другой программы. По этому много задачьность для системы возможна, даже нужна, необходима. Драйвера безусловна нужны. Самый простой пример. Два различныйх устройства должны быть завязаны на таймере(ули еще чем нибудь). Так как программы обслуживающии их тоже разные. То нужен драйвер который будет управлять всем этим. Да и наних можно повесить опрос устройств которые будут находиться в ожидании. Спрашиваеться чем такая ОС отличаеться от остальных? Да в принцапи от Win тем, что каждая задаче должно выполняться строгое время или не строгое на усмотрение программы. Но я считаю что нужно вынести возможность настройки.
Кто-то говорил о перезагрузке? Ребят вы что какая перезагрузка это же уйма простояв. Можно просто на просто создать консоль. Которую можно будет вызватьи обрабатывать без ущерба остальным программам. Мы не будем переключать задачи, а просто будем передавать на короткое время управление. Ее оверлею.
Через нее и будет происходить управление.
Еще немного о процессах и драйверах. Для того что бы система работала быстра. Каждый драйвер будет представлять из себя подпрограмму которая обрабатывает прирывания или наоборот опрашывает его. Драйверы вызываються очень часто если им это требуеться для опроса оборудование. Общение между драйвером и программой заключается тем что драйер говорит что с такого устройства пришли те данные или ушли. Осуществляеться вызывам соотвествующей процедуры процесса не каких отолежжных вызывов. Переключение между процессами заключаеться в полной остановки первого и запуска другого.
Что еще требуеться от ос? Да в принцапи только возможнос стандартного работа с устройствами. Так как драйвер этого не осуществляет. То просто набор библеотек которые будут стандартерезировать работу разных программ с одним устройством. И для разных версий устройств через одну программу.
Насчет защиты системы. Если программу ограничеть средствами ОС. То система будет защищенной. При условии что нет других дыр.
Не понимаю, как можно обсуждать промышленные ОС на "падоннкафскам" языке, но, если Вы так настаиваете, попробую...
>О чем вы тут огород городите?
Букаф многа? Перечитай, херр Штирлиц, мож шыфровка дайдет.
>ОС-это программа для разделения ресурсов системы.
Нитолька.
>Прочел все из всего понял только первый пост.
Убей сибя.
>Железа можно поделить на 2 типа. Первый тип это впринципи железо которое работоет самостоятельно только создает прирывание которые нужно обробатывать. Второй тип это которое нужно кантролировать вести проверять.
КГ/А*. Никакие железа сами не работают, только с софтом. Два типа бывают типа сразу с софтом и через драйвер с софтом, патамушта замарочинные и софт сам их нипанимаит.
Тема в том, чтобы заставить дривером втарыи касить пад первыи. Тагда первым касить уже ниподкаво нинада.
>Да если нужно обработать и передать данные в жостка ограниченном времени.
Ф завацких условиях такои фсигда нада.
>По этому много задачьность для системы возможна, даже нужна, необходима.
Разумеица. Перечитай шыфрофку.
И пра таймер там тожы сказана.
>Кто-то говорил о перезагрузке? Ребят вы что какая перезагрузка это же уйма простояв.
Гаварили ни то шо ты услышал. Учи алб... лучши наш.
Астальное просто паток сазнания.
>О чем вы тут огород городите?
Букаф многа? Перечитай, херр Штирлиц, мож шыфровка дайдет.
>ОС-это программа для разделения ресурсов системы.
Нитолька.
>Прочел все из всего понял только первый пост.
Убей сибя.
>Железа можно поделить на 2 типа. Первый тип это впринципи железо которое работоет самостоятельно только создает прирывание которые нужно обробатывать. Второй тип это которое нужно кантролировать вести проверять.
КГ/А*. Никакие железа сами не работают, только с софтом. Два типа бывают типа сразу с софтом и через драйвер с софтом, патамушта замарочинные и софт сам их нипанимаит.
Тема в том, чтобы заставить дривером втарыи касить пад первыи. Тагда первым касить уже ниподкаво нинада.
>Да если нужно обработать и передать данные в жостка ограниченном времени.
Ф завацких условиях такои фсигда нада.
>По этому много задачьность для системы возможна, даже нужна, необходима.
Разумеица. Перечитай шыфрофку.
И пра таймер там тожы сказана.
>Кто-то говорил о перезагрузке? Ребят вы что какая перезагрузка это же уйма простояв.
Гаварили ни то шо ты услышал. Учи алб... лучши наш.
Астальное просто паток сазнания.
А я то думал, что тема пойдет в другом русле. А она скатываеться все ниже и ниже. :(
ЭСО вот ты говоришь, что ЭСО преднозначено для стандерезации. Да но позволь она сама выподает из стандарта, так как программа работает с железом напримую, по твоему плану. То как только нужно подключить за место стандартного устройства не стондартное. А программма это не уммеет работать с не стандартными устройсвами. Что делать? Переписывать программу? Вот для этих целий и преднозначены драйверы. Они разрабатываються как прослойка между железом и прогрраммой. Что бы сделать возможным переписания только драйвер. Ты также говорил про Биус что он и представляет прослойку. Он преднозначен только для минимальной настройки железа с которого можно запустить ОС. Большенство оборудование через него не работуют или работуют не в полнуую силу.
ЭСО вот ты говоришь, что ЭСО преднозначено для стандерезации. Да но позволь она сама выподает из стандарта, так как программа работает с железом напримую, по твоему плану. То как только нужно подключить за место стандартного устройства не стондартное. А программма это не уммеет работать с не стандартными устройсвами. Что делать? Переписывать программу? Вот для этих целий и преднозначены драйверы. Они разрабатываються как прослойка между железом и прогрраммой. Что бы сделать возможным переписания только драйвер. Ты также говорил про Биус что он и представляет прослойку. Он преднозначен только для минимальной настройки железа с которого можно запустить ОС. Большенство оборудование через него не работуют или работуют не в полнуую силу.
>А я то думал, что тема пойдет в другом русле. А она скатываеться все ниже и ниже. :(
Да я-то тоже надеялся. А оно вона как повернулось.
Ну ладно, САБЖ.
>ЭСО вот ты говоришь, что ЭСО преднозначено для стандерезации. Да но позволь она сама выподает из стандарта, так как программа работает с железом напримую, по твоему плану.
ЭСО == Эмуляция Стандартного Оборудования.
Оборудование либо вписывается в стандарт, немного варьируясь в его пределах (довольно узких, чтобы не усложнять прикладное ПО), либо не вписывается. Программа в любом случае работает так, как она бы работала напрямую со стандартным оборудованием, но, если оно "левое", оно сопровождается ЭСО-драйвером, который эмулирует на его базе стандартное оборудование.
Т.е. ЭСО -- это не бездрайверная, это "редкодрайверная" архитектура.
>Ты также говорил про Биус что он и представляет прослойку.
БИОС с экстеншнами -- и впрямь часть навеки прошитого в ROM еще до нас ЭСО. Он берет на себя не всю, конечно, но довольно болезненную часть ЭСО. Например, 16-битную работу с дисками, переключение VBE-режимов и страниц да еще кой-чего по мелочи.
Естественно, он далеко не всемогущ, например, работать с дисками в 32-битном режиме (когда нужна нормальная скорость) нужно через функции ОС, которые адресуются либо прямо к портам контроллера, либо к ЭСО-драйверу, смотря что за контроллер нам достался.
Да я-то тоже надеялся. А оно вона как повернулось.
Ну ладно, САБЖ.
>ЭСО вот ты говоришь, что ЭСО преднозначено для стандерезации. Да но позволь она сама выподает из стандарта, так как программа работает с железом напримую, по твоему плану.
ЭСО == Эмуляция Стандартного Оборудования.
Оборудование либо вписывается в стандарт, немного варьируясь в его пределах (довольно узких, чтобы не усложнять прикладное ПО), либо не вписывается. Программа в любом случае работает так, как она бы работала напрямую со стандартным оборудованием, но, если оно "левое", оно сопровождается ЭСО-драйвером, который эмулирует на его базе стандартное оборудование.
Т.е. ЭСО -- это не бездрайверная, это "редкодрайверная" архитектура.
>Ты также говорил про Биус что он и представляет прослойку.
БИОС с экстеншнами -- и впрямь часть навеки прошитого в ROM еще до нас ЭСО. Он берет на себя не всю, конечно, но довольно болезненную часть ЭСО. Например, 16-битную работу с дисками, переключение VBE-режимов и страниц да еще кой-чего по мелочи.
Естественно, он далеко не всемогущ, например, работать с дисками в 32-битном режиме (когда нужна нормальная скорость) нужно через функции ОС, которые адресуются либо прямо к портам контроллера, либо к ЭСО-драйверу, смотря что за контроллер нам достался.
Кто хочет писать не промышленную ось, а для начала хотя бы просто реально работающую, бегом на ветку "Открытая ось с нуля", а-то там на данный момент кисловато что-то :) В смысле среда совсем безжизненная :) Буду признателен ;)
P.S. Заранее предупреждаю, что моя признательность никогда не сопровождается денежными перечислениями...
P.S. Заранее предупреждаю, что моя признательность никогда не сопровождается денежными перечислениями...
>Кто хочет писать не промышленную ось, а для начала хотя бы просто реально работающую
Ну спасибо. Плюнул так плюнул. :( :( :(
>бегом на ветку "Открытая ось с нуля"
Не говорите мне, что мне делать етц...
>а-то там на данный момент кисловато что-то
"ООССН" и "ПромОС" -- это совершенно разные, почти непересекающиеся вещи, разные как по личым пристрастиям авторов, так и по параметрам и целям. Мою ветку, например, могут спасти от полной гибели только старые ДОСовики, страдающие ностальгией. Вашу -- линуксоиды-экспериментаторы.
>В смысле среда совсем безжизненная
Здесь не лучше, и не надо ее дополнительно портить...
Ну спасибо. Плюнул так плюнул. :( :( :(
>бегом на ветку "Открытая ось с нуля"
Не говорите мне, что мне делать етц...
>а-то там на данный момент кисловато что-то
"ООССН" и "ПромОС" -- это совершенно разные, почти непересекающиеся вещи, разные как по личым пристрастиям авторов, так и по параметрам и целям. Мою ветку, например, могут спасти от полной гибели только старые ДОСовики, страдающие ностальгией. Вашу -- линуксоиды-экспериментаторы.
>В смысле среда совсем безжизненная
Здесь не лучше, и не надо ее дополнительно портить...
Чё вы болтаете,вы хоть что-то делаете?Главное чтоб прогресс был,а там уж и идеи!
>Чё вы болтаете,вы хоть что-то делаете?
Если Вы не заметили, пока идет набор желающих. И пока желающий я один, он же организатор.
>Главное чтоб прогресс был,а там уж и идеи!
Главное -- идти, а куда -- дело десятое. Гениальное предложение, нечего сказать.
Довольно флуда на общефилософские темы, "подход", "не подход", "вы тут чиста канкретна"... Тут сейчас обсуждается архитектура ПромОС с параллельным набором желающих ее воплотить в жизнь.
Все остальное -- оффтопик и флуд.
Если Вы не заметили, пока идет набор желающих. И пока желающий я один, он же организатор.
>Главное чтоб прогресс был,а там уж и идеи!
Главное -- идти, а куда -- дело десятое. Гениальное предложение, нечего сказать.
Довольно флуда на общефилософские темы, "подход", "не подход", "вы тут чиста канкретна"... Тут сейчас обсуждается архитектура ПромОС с параллельным набором желающих ее воплотить в жизнь.
Все остальное -- оффтопик и флуд.
Николай Коровин, я весьма добродушный человек и вовсе не собирался никуда плевать... Ты просто не понял смысл моего сообщения, которое было предназначено исключительно для тех, кто придерживается кардинально другой концепции построения ОС. Я абсолютно не против, если ты тоже заглянешь к нам и выцепишь из нашего форума приверженцев вашей концепции, правда, таких там скорее всего не будет, так как там практически никого нет вообще. Более того, я даже сам могу проделать эту работу за тебя, потому что не хочу, чтобы у нас вывешивались предложения типа "нафиг нам нужна межпроцессная защита, когда все процессы друг другу родные братья" (без обид :)
Искренне надеюсь, что данный оффтопик будет у вас последним :)
Искренне надеюсь, что данный оффтопик будет у вас последним :)
>исключительно для тех, кто придерживается кардинально другой концепции построения ОС.
И что характерно, обе концепции правильные -- каждая в своей ситуации :) Я тоже за отделение пирога с вишнями от пирога с мясом :)
>таких там скорее всего не будет, так как там практически никого нет вообще.
А тут тоже :) Вообще везде народу маловато, если честно :(
>нафиг нам нужна межпроцессная защита, когда все процессы друг другу родные братья (без обид :)
Никаких обид :)
>Искренне надеюсь, что данный оффтопик будет у вас последним :)
А это уже и не оффтопик, это организационная деятельность :)
И что характерно, обе концепции правильные -- каждая в своей ситуации :) Я тоже за отделение пирога с вишнями от пирога с мясом :)
>таких там скорее всего не будет, так как там практически никого нет вообще.
А тут тоже :) Вообще везде народу маловато, если честно :(
>нафиг нам нужна межпроцессная защита, когда все процессы друг другу родные братья (без обид :)
Никаких обид :)
>Искренне надеюсь, что данный оффтопик будет у вас последним :)
А это уже и не оффтопик, это организационная деятельность :)
Возражения по существу :
1) я люблю дос , но пром оборудование в наше время редко комплектуется дос дровами (или хотябы толковыми описаниями).
Обычно вынь дрова (по распространённости), потом юник(лин)овые .
2) большая часть пром оборудования с стандартным устройствам не приводиться (или это бессмыслено , затраты кода в реалтайме иногда критичны например ) . К томуж стандартные интерфейсы не очень удобны (лпт,ком - порты например ).
3)те пром устройства которые имеют в своём составе стандартный интерфейс (gps приёмники например) тоже нельзя унифицировать т.к. разные реализации и возможности (дают прерывание или нет , разние кодировки и т.д.) .
и вообще - пром оборудование чаще нестандортизировано .
(пасмотри например на пром ацп - микрухи вроде ещё более - менее похожи , но разроботчики плат используют их как бил гей на душу положит )) )
1) я люблю дос , но пром оборудование в наше время редко комплектуется дос дровами (или хотябы толковыми описаниями).
Обычно вынь дрова (по распространённости), потом юник(лин)овые .
2) большая часть пром оборудования с стандартным устройствам не приводиться (или это бессмыслено , затраты кода в реалтайме иногда критичны например ) . К томуж стандартные интерфейсы не очень удобны (лпт,ком - порты например ).
3)те пром устройства которые имеют в своём составе стандартный интерфейс (gps приёмники например) тоже нельзя унифицировать т.к. разные реализации и возможности (дают прерывание или нет , разние кодировки и т.д.) .
и вообще - пром оборудование чаще нестандортизировано .
(пасмотри например на пром ацп - микрухи вроде ещё более - менее похожи , но разроботчики плат используют их как бил гей на душу положит )) )
Николай, возможно, я смогу участвовать в проекте, только так я и не совсем понял, чем ПромОС должна отличаться от других. Споры по поводу свободы процессов в ОС, кажется, слишком преувеличены, надо реализовать истинную модульность не только для программера, как есть в юниксах, где можно перекомпилировать ядро, а так, чтобы можно было ОС менять без перекомпиляции.
М-да, похоже, что идея накрылась.
Судьба такой.
Судьба такой.
>редко комплектуется дос дровами (или хотябы толковыми описаниями).
DOS-дрова не помогут, а толковое описание аппаратного интерфейса нужно в любом случае, если ОС "левая". И в нашем тоже. Это большой нам всем ферботен.
> большая часть пром оборудования с стандартным устройствам не приводиться (или это бессмыслено , затраты кода в реалтайме иногда критичны например
ЭСО-драйвер не хуже просто драйвера абстрактного уровня. Если можно дотянуть до абстракции, почти наверняка можно и до СО. Если нельзя -- тут ПО должно работать прямо с железом и там, и тут. К счастью, такое железо обычно является "целевым" и программа вся ради него и пишется.
>те пром устройства...
...нестандартизировано.
Эт' точно. Но и "фирменный" интерфейс ПО-драйвер у "целевого" оборудования черт-те-какой обычно. Что так, что так "к общему знаменателю" ПО не приводится %)
2 aftnc: про различия я уже ОЧЕНЬ много написал :) А насчет "менять без перекомпиляции" -- это делается драйверами и гибкой настройкой :) Драйвер уровня FS, драйвер уровня sector R/W, рекурсия драйвера из драйвера, плюс все это хорошо задокументировать -- что угодно написать можно, за полчаса в килобайт запихнуть подключение сетевого диска по FTP через laplink от Total Commander :)
Да, кстати. Пришло на ум сравнение: ПромОС -- это MenuetOS, примирившийся с суровой реальностью :) Минимализм, прямая работа со всем, с чем можно и совместимость с тем, с чем все-таки пришлось :)
DOS-дрова не помогут, а толковое описание аппаратного интерфейса нужно в любом случае, если ОС "левая". И в нашем тоже. Это большой нам всем ферботен.
> большая часть пром оборудования с стандартным устройствам не приводиться (или это бессмыслено , затраты кода в реалтайме иногда критичны например
ЭСО-драйвер не хуже просто драйвера абстрактного уровня. Если можно дотянуть до абстракции, почти наверняка можно и до СО. Если нельзя -- тут ПО должно работать прямо с железом и там, и тут. К счастью, такое железо обычно является "целевым" и программа вся ради него и пишется.
>те пром устройства...
...нестандартизировано.
Эт' точно. Но и "фирменный" интерфейс ПО-драйвер у "целевого" оборудования черт-те-какой обычно. Что так, что так "к общему знаменателю" ПО не приводится %)
2 aftnc: про различия я уже ОЧЕНЬ много написал :) А насчет "менять без перекомпиляции" -- это делается драйверами и гибкой настройкой :) Драйвер уровня FS, драйвер уровня sector R/W, рекурсия драйвера из драйвера, плюс все это хорошо задокументировать -- что угодно написать можно, за полчаса в килобайт запихнуть подключение сетевого диска по FTP через laplink от Total Commander :)
Да, кстати. Пришло на ум сравнение: ПромОС -- это MenuetOS, примирившийся с суровой реальностью :) Минимализм, прямая работа со всем, с чем можно и совместимость с тем, с чем все-таки пришлось :)
Есть идеи , как применять продукт, может знаешь кому продать можно ? Я как то писал програмку , переводящую процессор в защищённый режим, встало всё на том что нужно было переделывать 16 рязрядный код обработчиков прерываний в 32 рязрядный .......поскольку описания не смог тогда найти. С тех пор лежит каркасик, печатает строку на экране и потом обратно в дос идёт). Его можно применить для управления каким нибудь станком , только драйверочек нужен . По замыслу , обработчик вешаеться на прерывание , которое возникает по активности какого нибудь датчика , ну и далее всё в таком духе . Вообще
,конечно , писать код в отрыве от того что будет им управляться напоминает просто безсмысленное шатание , я против безсмысленности . Готов поучаствовать....если проект выресуеться, даже если это будет просто ПО для управления станком хитрым ). Есть предложение, кстате , написать ОС для управления несколкими десятками ветро генераторов, вот это дельный проект был бы .
,конечно , писать код в отрыве от того что будет им управляться напоминает просто безсмысленное шатание , я против безсмысленности . Готов поучаствовать....если проект выресуеться, даже если это будет просто ПО для управления станком хитрым ). Есть предложение, кстате , написать ОС для управления несколкими десятками ветро генераторов, вот это дельный проект был бы .
Здрайсвуйте, люди-человеки-программеры...
я б тож не против написать ОСьку какую-нть...
я почитал всё вышесказанное и почти ничего не понял... давайте меньше там всяких кошек, собачек, параходов, поконкретней и попроще плиз... не плохо было-бы перейти в асю чтоль - 258464925 (моя)...
и еще на чем вы собираетесь писать?
и мне главное скажите что конкретно написать...
(понимаю Basic :), Pascal, но предпочитаю - C++ (Builder) и tasm)
До связи...
я б тож не против написать ОСьку какую-нть...
я почитал всё вышесказанное и почти ничего не понял... давайте меньше там всяких кошек, собачек, параходов, поконкретней и попроще плиз... не плохо было-бы перейти в асю чтоль - 258464925 (моя)...
и еще на чем вы собираетесь писать?
и мне главное скажите что конкретно написать...
(понимаю Basic :), Pascal, но предпочитаю - C++ (Builder) и tasm)
До связи...