OSDev

Спасибо за мнения!
Ну собственно интерфейс "Новая ОС - прикладные программы" и является самым ценным и трудоёмким в разработке ОС.
ОС обеспечивает выполнение прикладных задач как раз засчёт того, что прикладные задачи могут пользоваться функциями такого интерфейса.
Разумеется этот интерфейс будет отражён в структуре программ, причём на уровне исходных текстов. Двоичный формат (PE/ELF/что-то ещё) несущественен.
На уровне исходников изменения могут быть как минимальными так и существенными в зависимости от того, насколько интерфейс ОС будет отличаться от существующих.
Соответственно в этот интерфейс и встраивайте всякие там возможности распределённого выполнения и тому подобные плюшки.

dragon,
Вы сравнивали заголовки исполняемых файлов.
Что на Ваш взгляд хорошего в одно и другом формате?

С точки зрения общей системологии, учитывая то, что
Windows это в основе машина манипулирования окнами,
а UNIX (Linux) в основе машина манипулирования потоками,
то и преобразование одного формата исполняемого
файла в другой без потерь невозможно.
Насколько по Вашему мои выводы верны?

Сравнение файлов надо вести на разных архитекторах и платформах. А это довольно узкие специалисты. Тут с ходу ни я ни кто либо другой не ответит.


Ни насколько. Мухи отдельно котлеты отдельно. Да даже не мухи. Это как спрашивать есть ли зависимость между котлетой и диодом?
Любой маломальский программист под виндоус должен прочитать "Ритхер виндоус для профисионалов". После прочтения вы будете знать как это работает и в чём отличия: оконных программ от консольных. И ещё раз напоминаю что в линуксе окна есть и в виндоусе консольные приложения есть.
Не говоря уже о специализированной литературе по осдеву "Таненбаум Э.С.,Вудхалл А.С. Операционные системы Разработка и реализаци2005г.576с.ISBN5-469-00148-2".

pavia,
я не программист, а системщик. Приходилось и программировать
когда-то, оригинальный ГРИД даже сам сотворил. Операционками
не занимался. Поэтому как конкретные специалисты вы можете меня быстро
уловить в некомпетентности. А вот на системном уровне не получится.
Тем и интересно может быть наше общение, разноуровневые взгляды
на один и тот же обьект. Вы, занимаясь конкретикой, неминуемо
перестаёте видеть общие очертания, прочитанные книги с толковыми
мыслями по построению ОС позволяют что-то делать конкретное,
но навязывая готовые решения, мешают находить совершенно
иные подходы и принцыпы построения системы.

Занимаюсь системами в самых разных областях. Беру конкретную
систему, кладу мысленно в авоську и стукаю о косяк, пока там
не останется совокупность основных элементов числом до 10
и связей между ними... и сразу становится все понятно что там и к чему.
Есть еще важный источник более трудоемкий - история возникновения
и эволюции.

Так что ответ на вопрос - что в основе Вин и что в основе Уних примерно
понятен. Причем сравниваю всё это еще и со своей базовой идеей,
которую можно положить в основу ОС.

Проектирование ОС у меня идет на уровне общего схемного моделирования
с проработкой функциональных деталей и подробностей пока без
привязки к конкретному железу, однако учитывая его текущие и
потенциальные возможности.

Если получится что-то стоящее можно будет как-то это двигать
дальше или хотя бы опубликовать.

Основы проектирования интерфейсов хорошо описаны в пособиях по объектно-ориентированному программированию. Обычно интерфейс скрывает внутреннюю механику процедур, так что основная кухня находится внутри реализации процедур. Интерфейс же может быть обычным, стандартным.

Обьектное программирование удобно для быстрого написания
прикладных программ, но скрывает всю кухню, что
происходит во взаимодействии ОС и программы.

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

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

Пишу здесь об этом, чтобы и другие разработчики
об этом подумали.

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


Интерфейс - это описание входных и выходных параметров и протокола взаимодействия с входами и выходами.

Так вот описание протокола как раз и раскрывает устройство метода, его семантику. Но при этом скрывает его реализацию.
Семантика - от греч. "обозначающий". Обозначающий внутренний или глубокий смысл.

Мутация - изменение чего либо.
Видимо вы хотели сказать не про сокрытие, а про мутацию. Сокрытие как раз и позволяет использовать разные реализации при одном интерфейсе. Т.е мутировать классам. Но консольный интерфейс и графический как раз таки разные интерфейсы, а не реализации. И совмещать их не представляется возможным так как отличаются протоколами общения. А вернее шаблоном управления.
Суть в том что используется инвертирования шаблона управления.
Model-View-Controller - контроль внутри шаблона
FrontEnd-Model-BackEnd -в этом шаблоне контроль осуществляется из вне.

Конечно есть и консольные программы которые позволяют рисовать в псевдографике. И они построены по шаблону MVC. Но это пожалуй исключение, чем практика. Да и используют они для взаимодействия с ядром ОС 3-разновидность интерфейса для вывода.

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

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

Кстати, про общую концепцию ОС и про интерфесы с прикладными
программами.

Интерфейс - это описание границы, в данном случае между ОС
и прикладной программой. Нужен и протокол, то есть некое
общее описание возможного потока через эту границу.

Однако, вспомним старушку DOS.
Там ОС всего лишь запускала программы и предоставляла им
какой-то сервис, которым можно было и не пользоваться.
Программы получали при желание полный контроль над
железом. Запретил прерывания, поставил свои обработчики
и всё в распоряжении программы, твори что хочешь.
Все конечно сегодня привыкли к многозадачности, но
и этот подход не стоит забывать, для определенного
класса задач повышенной надежности он вполне может
быть востребован и сегодня, причем на существующем
железе. А все навороты и сервис можно поместить не
в ОС, а в компилятор и соответствующие библиотеки.

Юрий, насчёт разници между PE/ELF я собственно и завёл тему, т.к. раньше думал что они братья близнеци, оказалось, как минимум различие в принципах импортирования. Остальное вроде как похоже, но не ручаюсь что на 100%.

К вопросу о системах, ОС делится на подсистемы, и в линуксе и в винде есть подсистема управления окнами, и там и там есть подсистема работы с потоками, какая конкретно подсистема будет более востребована, это уже второй вопрос.

Преобразование файлов без потерь возможно при условии, что в целевой системе есть все теже интерфейсы подсистем как и в исходной, и затрагиваемые подсистемы работают схожим образом. Только такое преобразование вероятно окажется много дороже в реализации чем может показаться на первый взгляд.

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

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