Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Архив форумов ЦИТФорума
Море(!) вопросов - Море(!) ответов
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 
Как правильно задавать вопросы

Операционные системы

 
Перейти:  
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Другие ОС
Предыдущая тема :: Следующая тема  
Автор Сообщение
Mr. BuS
Гость





СообщениеДобавлено: Чт Фев 28 2002 03:10    Заголовок сообщения: Операционные системы Ответить с цитатой

Кто знает устройство файловой системы NTFS?
А также NFS и другие? Буду рад за описание любой файловой системы (кроме FAT 16/32).
Мы - группа програмеров, разрабатываем новую операционную систему. Возможно, она будет иметь свою файловую систему, которая наследует все наилучшее из существующих.
Если кто хочет присоединиться, пишите на mrbus@pisem.net. (Правда, оплаты ваших трудов пока не будет. Позже, если ОС более-менее раскрутится).
Вернуться к началу
biont



Зарегистрирован: 01.03.2002
Сообщения: 2
Откуда: Рязань

СообщениеДобавлено: Пт Мар 01 2002 15:34    Заголовок сообщения: Re: Операционные системы Ответить с цитатой

Может ссылки какие по ОС дадите, а то диплом по ним пишу нужно с чегото начинать.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Ms



Зарегистрирован: 02.11.2001
Сообщения: 313
Откуда: Москва

СообщениеДобавлено: Сб Мар 02 2002 20:14    Заголовок сообщения: WWW.CITFORUM.RU Ответить с цитатой

.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Ср Мар 06 2002 18:36    Заголовок сообщения: См.выше Ответить с цитатой

Ответ я дал чуть выше. А писать собственную OS - замучаетесь делать драйверы под тьму разных писюковых устройств!
Вернуться к началу
Orc
Гость





СообщениеДобавлено: Вт Мар 12 2002 13:08    Заголовок сообщения: Re: См.выше Ответить с цитатой

Можно работать на уровне портов...
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Вт Мар 12 2002 14:06    Заголовок сообщения: Вот на уровне портов и замучаешься - такая тьма устройств! (-) Ответить с цитатой

-
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Ср Мар 13 2002 22:17    Заголовок сообщения: Re: См.выше Ответить с цитатой

>>Ответ я дал чуть выше. А писать собственную OS - замучаетесь делать драйверы под тьму разных писюковых устройств!

Так мы ж под стандартные устройства только дрова напишем. Пока. А потом, глядишь, может быть, производители устройств признают нашу операционку и станут сами дрова писать.
А операционка будет совершенно новая, чисто объектно-ориентированная (ООП поддерживается в ядре опер. системы), изучим все существующие операционки и возьмем из них самое лучшее. Или придумаем сами.
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Чт Мар 14 2002 11:18    Заголовок сообщения: Re: См.выше Ответить с цитатой

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

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

> А операционка будет совершенно новая, чисто объектно-ориентированная (ООП поддерживается в ядре опер. системы)

Я совершенно не уважаю ООП - оно резко снижает производительность как машины, так и программиста. Обычно все попытки ООП кончаются достаточно плачевно - даже самый удачный пример Java не смог добиться успеха, а C++ так и не избавился от основных недостатков C - таких как утечка памяти и работа с указателями.

> изучим все существующие операционки и возьмем из них самое лучшее. Или придумаем сами.

Хотел бы я посмотреть, как вы сможете изучить RISC-OS и другие операционки, работющин только на неписюковом железе! В том-то и дело, что проблемы подавляющего большинства операционок связаны именно с тем, что они должны идти на писюке, а там Micro$oft имеет полное преимущество из-за драйверов и из-за наличия большого количества аппликаций(прикладух). Причем любая OS, которая записывается на изменяемое устройство (диск) может быть повреждена, так что при использовании машины в качестве песональной рабочей станции Unix не имеет никаких преимуществ перед Windows. Переломить это можно только путем выпуска нового железа, а на это ни у кого не хватит сил!

Дело в том, что у писюка жесткий диск всегда был и будет "первее", чем сеть, ибо до начала работы с сетью он должен прогрузить с диска туеву хучу всяческих драйверов; даже если организовать "сетевую загрузку ОС" (которую почти никто не делает вследсктвие ублюдочности и неприменимости к писюковой архитектуре), то это организуется через эмуляцию загрузки с дисковода (так же как при загрузке с CD-ROM эмулируется загрузка с дискеты, о чем явно сообщается на экран). Новую операционку надо писАть в расчете на зашивание ее в ПЗУ - только тогда она будет "новым словом" и сможет расчитывать на интерес.
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Сб Мар 16 2002 01:18    Заголовок сообщения: Re: См.выше Ответить с цитатой

Видал в мастдае такое устройство - стандартный VGA-адаптер? Унас буде нечто подобное. Точнее, будет стандартный SVGA VESA-совместимый адаптер. Знаешь стандарт VESA?
А также стандартный драйвер IDE (ATAPI) устройства. То бишь практически любого HDD.

Посчет ООП. Все программы - объекты. Все документы - объекты. Юзер не видит разных там временных файлов, создаваемых программами. Сборщик мусора - знаешь такой в C#? Он будет!!! Указателей, возможно, вообще не будет. А я, как программист с опытом работы более 6 лет, знаю, что все-таки ООП лучше процедурного программирования...

Насчет наличия большого колва прог и дров для вин. Виндоус можно было бы значительно ускорить, если бы не принцип обратной совместимости - возможность запуска DOS-прог, VDM-драйверы и прочая лабуда... Насколько я знаю VDM, в нем, например, авишка проходит кучу всяких драйверов, прежде чем достигнет монитора... Причем от драйвера к драйверу информация просто копируется... Затраты времени и памяти. Зато УДОБНО типа...


А новое железо пока изобретать мы не будем. Мы просто запретим доступ прог к загрузочному сектору и секторам, в которых расположен загрузчик ОС и ядро ОС. И вообще доступ непосредственно к секторам диска будет запрещен.
Так... вроде все обдумал и все сказал.
В общем, операционка будет нового поколения. И вообще совершенно новая.

И вообще, лучше пиши на mrbus@pisem.net - я тама чаще бываю.
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Сб Мар 16 2002 10:29    Заголовок сообщения: Старые песни о том же... Ответить с цитатой

> Видал в мастдае такое устройство - стандартный VGA-адаптер? Унас буде нечто подобное. Точнее, будет стандартный SVGA VESA-совместимый адаптер. Знаешь стандарт VESA?

Я знаю, что ни один производитель софта не полагается на стандарты VGA и VESA; наверно, есть какие-то причины... Если юзер увидит 640*480 в 16 цветов, он никогда не станет работать с такой системой! (И будет прав.) Не говоря уж о том, что без поддержки 3D-ускорителей сейчас жизнь не в кайф...

> А также стандартный драйвер IDE (ATAPI) устройства. То бишь практически любого HDD.

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

> Посчет ООП. Все программы - объекты. Все документы - объекты. Юзер не видит разных там временных файлов, создаваемых программами.

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

> Сборщик мусора - знаешь такой в C#? Он будет!!!

А может, приучить систему не мусорить? Smile

> Указателей, возможно, вообще не будет. А я, как программист с опытом работы более 6 лет, знаю, что все-таки ООП лучше процедурного программирования...

Это только так кажется - самые лучшие программы написаны на простом C!

> Насчет наличия большого колва прог и дров для вин. Виндоус можно было бы значительно ускорить, если бы не принцип обратной совместимости - возможность запуска DOS-прог, VDM-драйверы и прочая лабуда... Насколько я знаю VDM, в нем, например, авишка проходит кучу всяких драйверов, прежде чем достигнет монитора... Причем от драйвера к драйверу информация просто копируется... Затраты времени и памяти. Зато УДОБНО типа...

Насчет VDM-драйверов ничего сказать не могу, хотя в сетевых средах многоуровневая система протоколов позволяет делать много разных вещей - например, без существования TCP между IP и вышележащими протоколами мы бы никогда не имели маскарадинга...
А вот DOS-совместимость обусловлена тем, что программы под DOS и проще, и компактнее, и удобнее, чем под Windiws! Сходи на http://www.pi2.ru/prof и прочитай про оконный интерфейс...

> А новое железо пока изобретать мы не будем. Мы просто запретим доступ прог к загрузочному сектору и секторам, в которых расположен загрузчик ОС и ядро ОС. И вообще доступ непосредственно к секторам диска будет запрещен.

Это мы уже проходили при переходе от W'9x к W'NT - запреты сопровождаются удвоением требований к ресурсам. Ведь иногда такой доступ реально нужен! Чтобы сделать систему действительно устойчивой, ее надо убрать с диска и поместить туда, где ее ФИЗИЧЕСКИ невозможно будет повредить - например, в ПЗУ или на сервер; но в писюково-совместимой системе это малореально...
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Сб Мар 16 2002 14:06    Заголовок сообщения: Re: Старые песни о том же... Ответить с цитатой

Стандартного устройства как такового не существует. Просто все устройства (скажем, видеоадаптеры) совместимы с так называемым стандартным SVGA VESA-адаптером.

SVGA VESA: может, никто и не полагается, но поддерживает Smile. А 640х480 16 цветов - это VGA, а не SVGA.
Большинство современных видеокарт поддерживают хотя бы несколько стандартных VESA-режимов.

А насчет IDE (ATAPI), там дела обстоят еще лучше. Стандартный драйвер работает ненамного медленнее
родного. Сам писал Smile (точнее, работал с диском на уровне портов и прерываний).

И вообще, кто сказал, что написание операционки - это легко? Придется потрудиться.
И что плохого в ООП, я честно говоря не понимаю.
А зачем юзверю видеть, скажем, какой-нибудь msw001.tmp, созданный вордом? Удалит еще ненароком...
Вот тады точно глюкавить будет Smile
А насчет мусорщика - не СИСТЕМУ надо приучать не мусорить, а ПРОГРАМЕРА. Это он забывает удалять
за собой созданные с помощью new или LocalAlloc (или что-нибудь такое) объекты. А сборщик мусора
позволяет их вообще не удалять - сам удалит, как только будут невостребованы. А ООП этому
способствует. А вот как раз писать проги на просто C - ЗАМУЧАЕШЬСЯ... Возни как с написанием дров Sad

И я не говорил, что операционка наша будет идеально защищена.

И вообще, тама все еще надо будет обдумать. Это пока на этапе проектирования. А если она не получится,
то хотя бы крутые фирмы увидят ее, подумают что мы крутые програмеры и возьмут нас на работу Smile))
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Сб Мар 16 2002 21:35    Заголовок сообщения: Re: Старые песни о том же... Ответить с цитатой

> Стандартного устройства как такового не существует. Просто все устройства (скажем, видеоадаптеры) совместимы с так называемым стандартным SVGA VESA-адаптером.
SVGA VESA: может, никто и не полагается, но поддерживает Smile. А 640х480 16 цветов - это VGA, а не SVGA. Большинство современных видеокарт поддерживают хотя бы несколько стандартных VESA-режимов.

Если использовать только VESA-совместимые возможности видеокарты, это существенно снизит эффективность ее использования как в плане возможностей, так и в плане скорости. Юзеры не одобрят...

> А насчет IDE (ATAPI), там дела обстоят еще лучше. Стандартный драйвер работает ненамного медленнее родного. Сам писал Smile (точнее, работал с диском на уровне портов и прерываний).

А какая там разница, если скорость определяется механикой?

> И что плохого в ООП, я честно говоря не понимаю.

Снижение эффективности и рост ресурсоемкости не в счет?

> А зачем юзверю видеть, скажем, какой-нибудь msw001.tmp, созданный вордом? Удалит еще ненароком... Вот тады точно глюкавить будет Smile

Так не надо создавать временный файл! Файловая система д.б. только для чтения, по кр.мере, бОльшая ее часть.

> А насчет мусорщика - не СИСТЕМУ надо приучать не мусорить, а ПРОГРАМЕРА. Это он забывает удалять за собой созданные с помощью new или LocalAlloc (или что-нибудь такое) объекты.

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

> А сборщик мусора позволяет их вообще не удалять - сам удалит, как только будут невостребованы. А ООП этому способствует. А вот как раз писать проги на просто C - ЗАМУЧАЕШЬСЯ... Возни как с написанием дров Sad

Интересно, как это сборщик мусора определяет, что объекты более не нужны?

> И я не говорил, что операционка наша будет идеально защищена.

Тогда это будет еще одна Windows'9x, только с малым количеством приложений и поддерживаемого железа. А смысл?

> И вообще, тама все еще надо будет обдумать. Это пока на этапе проектирования. А если она не получится, то хотя бы крутые фирмы увидят ее, подумают что мы крутые програмеры и возьмут нас на работу Smile))

Ну, удачи... Только не лучше ли присоединиться к разработке OS с открытым кодом? Там проще получить известность - круг юзеров и программистов намного шире, а требования к квалификации примерно те же.
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Вс Мар 17 2002 16:50    Заголовок сообщения: Re: Старые песни о том же... Ответить с цитатой

Сборщик мусора предполагает прежде всего объектную ориентированность. Каждый объект имеет такое поле - счетчик ссылок. При создании объекта он равен 1. При передаче адреса объекта, например, в качестве параметра в функцию, счетчик ссылок увеличивается. Соответственно, при выходе из функции - уменьшается. Когда счетчик станет равным 0, объект самоуничтожается. Точнее, его сборщик мусора уничтожает. По крайней мере, большинство ООП-языков устроены так (но не C++).
Можно узнать, а вы сами программированием занимаетесь?
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Вс Мар 17 2002 19:38    Заголовок сообщения: Это утащено из классического Unix, написанного на обычном C! Ответить с цитатой

Счетчик ссылок использовался еще в первой фаловой системе Unix - это позволяло иметь несколько равноправных имен одного файла и сохранять удаленный файл пока его не закроют все исполняемые программы (процессы), которые этот файл открыли. Сам Unix был написан на обычном C, никакой объектности. Должен сказать, что файлловая система - один из самых тормознутых компонентов, но т.к. жесткий диск еще более тормозной (потому что он механический), с тормознутостью файловой системы можно мириться. А вот пускать эти методы к работе с оперативной памаятью - значит тормозить всю машину. Проще пользоваться скриптовыми языками, которые вызывают и связывают между собой написанные на обычном C компоненты, но эти компоненты хорошо отлажены.
Вернуться к началу
Serzhant



Зарегистрирован: 17.03.2002
Сообщения: 3

СообщениеДобавлено: Пн Мар 18 2002 17:33    Заголовок сообщения: А почему бы вам MinuetOs не продолжить? Ответить с цитатой

На kalashnikoff.ru есть эксперт у него страничка "ос с нуля", адрес незнаю, а если заинтересовала найдете Wink
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Mr. BuS
Гость





СообщениеДобавлено: Вт Мар 19 2002 00:05    Заголовок сообщения: Re: См.выше Ответить с цитатой

НУ ДЫК ЧЕ ТАКОЕ КОМПОНЕНТЫ? Не объекты ли? Не классы ли???!!!
Скриптовые языки работают через интерпретатор. Это гораздо медленнее любого ООП... Снижение быстродействия в ООП происходит ТОЛЬКО при работе с виртуальными функциями (некоторое) и виртуальным множественным наследованием (большое), но последнее является редкостной вещью и реализовано, насколько мне известно, только в С++. Фактически, ООП - то же процедурное программирование, просто в качестве первого аргумента функциям передается указатель на объект. Если он не нужен, функция объявляется статической. Вряд ли все описанное выше вызовет сильное снижение быстродействия, если примерно представить себе машинный код, который все это породит (сравните со скриптовыми языками - для выполнения каждой команды вызывается интерпретатор, который сначала интерпретирует команду (ДЛИИИННЫЙ ЦИКЛ), а лишь затем ее выполняет. Использование компонентов (может, вы имели в виду функции?), написанных на С, вполне возможно и в ООП-языках, тем более, что так и делается. Кроме того, ядро операционки будет написано вообще на ассемблере (быстрее С).
В общем, ядро самой опер. системы пишется на асм-е, а прикладные проги - на ООП-языках (что существенно понизит вероятность появления ошибок в программах за счет незначительного снижения быстродействия).
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Вт Мар 19 2002 11:46    Заголовок сообщения: Скрипты и ООП Ответить с цитатой

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

Разумеется, скрипты выполняются медленнее откомпилированных процедур, но насколько? Допустим, мы манипулируем регулярными выражениями (специфическая, но очень удобная для работы с текстом вещь, что-то типа шаблонов для имен файлов через звездочку и вопр.знак, но гораздо круче). Программа, разбирающая регулярные выражения и сопоставляющая с ними стрОки текста, давно откомпилирована, а скрипт лишь передает выражение откомпилированной программе.

Более того - скрипт часто бывает меньше откомпилированной программы, так что при одновременной работе многих скриптов даже с учетом интерпретатора размер занимаемой памяти оказывается меньше, чем если эти программы откомпилировать - а что такое "свопец", я думаю, многие знают не по наслышке...
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Чт Мар 21 2002 02:37    Заголовок сообщения: Re: Скрипты и ООП Ответить с цитатой

1) Давайте разберемся. Что вы понимаете под "скриптом"? Конкретно.
2) Суть наследования в том и состоит, что код наследуемых функций в наследуемом классе никоим образом не дублируется - это нарушает саму суть наследования.
3)Скрипты - очень хорошая и удобная вещь. Одно плохо - если их каждый раз программа-интерпретатор будет разбирать, то получится довольно медленно... Поэтому скрипты нашли наибольшее применение в Интернет-программировании - потому что там скорость связи существенно ниже скорости исполнения скрипта. Но вот хорошая идея - пишется скрипт, но затем он компилируется в исполняемый код (один раз) и выполняется уже гораздо быстрее (многократно)... Я б не сказал, что исполнимый код займет много больше места, нежели исходный. Просто exe-файл так устроен - в нем куча заголовков, таблиц экспортируемых имен и т. д... А если все это исключить?
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Чт Мар 21 2002 13:11    Заголовок сообщения: Скрипты -рулез Ответить с цитатой

1) В качестве примера скрипта приведу такой:
(
cat /etc/namedb/$1.rev

Этот скрипт делает из файла /etc/dhcpd.conf одну прямую и одну реверсную DNS-зону, причем по выбору (у меня несколько прямых и столько же обраьных зон для внутренних "серых" IP-адресов). Основная вычислительная сложность приходится на интерпретацию регулярных выражений, оптимизировать которую компилятор скрипта не сможет, т.к. сам интерпретатор уже откомпилирован, а скрипт лишь передает туда шаблоны.

2а) Не надо путать язык и его реализацию. Если две программы используют один и тот же класс, то код будет продублирован. Доказательство: если два программиста создали разные классы с одинаковыми именами и внутренними именами, то при попытке использовать код не того класса последствия будут фатальны, а различить при попытке использовать общий код их будет невозможно.

2б) При переопределении некоторых методов и свойств класса-родителя в наследнике меняется структура данных, т.е. процедуры (медоды) придется перекомпилять, создав на основе того же исходного кода новый исполняемый код.

2-резюме) На разных апаратных платформах и на разных операционках один исходный код может порождать разный исполнямый код; в разных классах действует то же самое.

3) Раз это никто не исключает, значит, это невозможно. Поэтому мое высказывание о том, что исполняемый код существенно больше исходного интерпретируемого остается в силе, а замечание насет свопинги при большом коде вообще очевидно.
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Вс Май 05 2002 03:46    Заголовок сообщения: Re: Скрипты -рулез Ответить с цитатой

Насколько я понимаю, интерпретатор работает так:
1) допустим, в некоторой строке скрипта встретился вызов некоей функции. Интерпретатор ее распознает.
2) Собственно тело самой функции содержится в интерпретаторе. Тогда интерпретатор передает на нее управление.
3) Интерпретатор переходит к следующей строке (оператору, и т. д.) скрипта.
Таким образом, имеем:
a) Исходник скрипта.
b) Программу-интерпретатор, загруженную в память. Вместе со всеми функциями, плюс машинный код, осуществляющий собственно интерпретацию.
Выполнение строки скрипта:
1) распознавание строки.
2) передача управления на нужную функцию.

А если поступить так:
1) Берем исходник и компилируем его. Причем все те функции, которые были раньше в интерпретаторе, будут не в самой проге, а в отдельно выделенной dll-ке.
2) Теперь полученный машинный код можно запускать.
Имеем:
a) машинный код программы.
b) dll-библиотеку, содержащую необходимые функции, загруженную в память однократно.
Выполнение каждой строки (оператора, и т. д.) программы:
1) Вызов необходимой функции (одна-единственная машинная команда: call, не считая передачу параметров).
Сравним:
1) Предположим даже, что скомпилированный код будет больше исходного (я проиграл)
2) dll-библиотека не содержит ненужных функций распознавания скрипта (я выиграл).
3) распознавания каждой строки программы не происходит. Программа ПРОСТО ВЫПОЛНЯЕТСЯ. (я выиграл)
4) И программа-интерпретатор, и dll-библиотека загружаются в память лишь однажды даже если программ, использующих их, много (ничья).
Общий счет: 2:1 в мою пользу. Все-таки я считаю, что повышение быстродействия будет достаточно заметным, ведь распознавание команды довольно часто сравнимо по времени выполнения с собственно выполнением команды.
А насчет повторного использования классов в разных прогах - дык ведь собственно классы тоже можно засунуть в dll (что уже широко применяется в Windows).
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Вс Май 05 2002 15:43    Заголовок сообщения: И все-таки скрипты - рулез Ответить с цитатой

Интересная арифметика "2:1 в мою пользу". Надо сравнивать не по числу преимуществ, а по получаемому от них эффекту.

Итак, рассмотрим использование DLL в сравнении с интерпретатором. Начнем с того, что функции, спрятанные в DLL, вызываются не как статически прилинкованные (т.е. операцией 'CALL адрес'), а либо через специальный редиректор (вызывается отдельная вункция, ей передается в качестве главного параметра имя вызываемой функции), либо перед выполнением программы происходит "связывание" - подстановка правильных адресов.
В случае редиректора трудоемкость не очень отличается от интерпретатора, а "связывание" хоть и работает быстро, но порождает свои неудобства - надо очень корректно обработать кучу возможных вариантов, иначе полезут всякие General Protection Fault.

Но главное не в производительности (ее как раз сейчас выше крыши), сколько в удобстве написания программы и надежности ее работы. Интепретируемую программу можно легко переносить под другую OS и на CPU другого типа, а для компилируемой программы надо сначала найти исходник, а потом мучиться с кучей проблем из-за различий в компиляторах и библиотеках.

А главное - интепретируемая программа распространяется в виде исходных текстов, любой может посмотреть, как она работает, а при необходимости даже подправить ее (на свой страх и риск, разумеется). Конечно, есть вероятность повредить программу, но ведь и откомпилированные файлы тоже разрушаются - например, заражаются вирусами. Smile Людям из мира Wыndows это трудно понять, но именно так были созданы Linux, FreeBSD, Apache, Squid, GIMP и куча других рулезных и при этом бесплатных продуктов.

Теперь о производительности. Если программист оперирует такими понятиями, как сложение/вычитание/умножение/деление/сравнение целых и плавающих чисел, которые реализованы в виде команд процессора, то разница в производительности интепретируемой и откомпилированной программ будет колоссальная. Но если значительная часть работы делается через регулярные выражения (что-то вроде шаблонов файлов, где звездочка - любой набор символов, а вопр.знач - один любой символ, только гораздо гибче), то скорость работы интепретируемой и откомпилированной программ будет почти одинакова.

PS: Настоятельно рекомендую попробовать поработать в OS, отличной от Wыndows - в Unix, а еще лучше - в RISC-OS: это сильно расширяет кругозор. А то неужели все вокруг такие дураки, что используют Perl, PHP и JavaScript?
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Сб Авг 03 2002 18:48    Заголовок сообщения: ВАЖНАЯ ИНФОРМАЦИЯ ОТ АВТОРА Ответить с цитатой

Здарова, братцы програмеры. Важная информация. Нужны люди по различным категориям:
1) Хорошо разбирающиеся в объектно-ориентированном анализе, проектировании и программировании.
2) Шарящие в сетевых технологиях.
3) Досконально знающие архитектуры различных процессоров (х86, Alpha, MIPS, ...), ассемблер.
4) Разбирающиеся в программировании аппаратуры, устройстве системных шин (PCI, AGP, USB, ISA...).
5) (Это связано с 4 пунктом) Люди, писавшие драйвера и хорошо это делающие (лучше всего под Wind'ы NT).
6) Специалисты по защите информации по различным разделам:
а) Защита программ от незаконного копирования, распространения, использования, взлома.
б) Защита информации, передаваемой по сетям.
в) Защита системной информации (системных паролей, системных файлов...).

Еще информация по нашей ОСи - мы пока приостановили работу. Отчасти из-за отсутствия финансов и кадров. Пока пишем мелкие програмульки, зарабатываем денюжку. Но идею не забываем.
ЧЕЛ! ЕСЛИ ты шаришь в одном из вышеуказанных пунктов, мы тебе в общем-то будем рады только. Обращайся на mrbus@pisem.net. Говорю сразу: денег скоро не обещаем. Вообще не обещаем. Но мы ведь крутые програмеры, да Smile Мы сделаем прорыв! По крайней мере, очень надеемся... И Заработаем Заслуженные Мегабаксы! Главное, не терять веру, не вешать нос и работать. И побольше пива Smile
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Сб Авг 03 2002 18:55    Заголовок сообщения: ВАЖНАЯ ИНФОРМАЦИЯ ОТ АВТОРА 2 Ответить с цитатой

Забыл сказать... ОС будет полностью объектно-ориентированной. Не будет такого, как в wind-ах - процедурно-ориентированный WinAPI и как надстройка над ним объектно-ориентированный MFC. Поддержка классов, инкапсуляции, наследования, виртуальных функций и проч. свойств ООП будет на уровне ядра ОС. Однако это не исключает возможности написания прог на не-ООП-языках и даже на ассемблере. Хошь узнать подробности - присоединяйся к нам. Узнаешь много нового. Мыло: mrbus@pisem.net
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Вс Авг 04 2002 10:11    Заголовок сообщения: Re: И все-таки скрипты - рулез Ответить с цитатой

И еще пару слов насчет "свопца"... Машинный код исполняемых программ не "свопится" в файл подкачки. Он "свопится" непосредственно в свой собственный exe-файл!!! И таким образом места на диске (в файле win386.swp) не потребляет.
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Пн Авг 05 2002 13:41    Заголовок сообщения: В нормальных системах код скриптов тоже не сврпится Ответить с цитатой

В современных системах имеется такой метод работы с файлом как "мапирование в память" (этот метод имеет недостаток - затруднено изменение размера файла, но для кода скриптов это неактуально). Именно этот метод применяется к выполняемому коду, и с таким же спехом интерпретатор может его применять к интепртетируемым кодам скриптов.

Кроме тоо, скрипты обычно работают в режиме "запустился, выполнился и закончился", а не висят часами в ожилании разных событий, поэтому их код и данные исключительно редко подвергаются свопингу.
Вернуться к началу
Dmitry.Karpov http://www.
Гость





СообщениеДобавлено: Пн Авг 05 2002 13:48    Заголовок сообщения: Претензии по пунктам Ответить с цитатой

3) В списке отсутствуют процессоры Arm/StrongARM/XScale, зато имеются MIPS полумертвый и Alpha от почившей в бозе DEC.

5) Ориентация на "драйвера под Wind'ы NT" мне кажется странной - IMHO, драйверы под Linux/FreeBSD ничем не хуже (по кр.мере, ядро у них намного компактнее).

Ну а объекно-ориентированность на уровне OS API вообще выглядит странно...
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Сб Авг 10 2002 17:46    Заголовок сообщения: поправка к ВАЖНОЙ ИНФОРМАЦИИ ОТ АВТОРА Ответить с цитатой

Учитывая во внимание "претензии по пунктам" г-на Д. Карпова и всецело полагаясь на его компетентность в данных вопросах, вношу следующие поправки (см. выше - ВАЖНАЯ ИНФОРМАЦИЯ ОТ АВТОРА).
3) Досконально знающие архитектуры различных процессоров (x86, Arm, StrongARM, XScale, можно и других - Alpha, MIPS и проч.).
5) Люди, писавшие драйвера и хорошо это делающие (лучше всего под Linux, FreeBSD, WinNT).

Кроме указанных поправок, хотелось бы заметить неточность в статье "претензии по пунктам" вышеуказанного г-на: ОС API будет, конечно, объектно-ориентированной (чего же странного, большинство программ (не интернет-апплетов, скриптов и пр., а непосредственно исполняемых приложений, включающих машинный код) пишутся на объектно-ориентированных платформах, либо на MFC, либо на самостоятельно созданных. Неточность статьи, однако, заключалась не в этом: в моей статье "ВАЖНАЯ ИНФОРМАЦИЯ ОТ АВТОРА 2" (на которую, по всей видимости, ссылался г-н Карпов) не было упоминания об "объектно-ориентированности на уровне ОС API", а было упоминание об "ООП на уровне ядра ОС". Вот это, в самом деле, можно счесть несколько странным.
Булат "Mr. BuS", он же "Теперь я Чебурашка"
Вернуться к началу
paul



Зарегистрирован: 27.01.2002
Сообщения: 39

СообщениеДобавлено: Чт Окт 10 2002 23:10    Заголовок сообщения: Re: поправка к ВАЖНОЙ ИНФОРМАЦИИ ОТ АВТОРА Ответить с цитатой

Госпада! Молодцы, что взялись за такое дело!
Я, к сожелению, серьезно помоч не могу, но у меня есть пара вопросов. Я давно и серьезно работаю с плоской графикой, и пока, ничего более мощного чем пара-тройка прог под Форточкой не видел. Соответственно хотелось бы знать будут ли работать Форточкини проги под Вашей системой?
Спасиюо.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Mr. BuS
Гость





СообщениеДобавлено: Пт Ноя 22 2002 11:12    Заголовок сообщения: Насчет запуска форточкиных прог Ответить с цитатой

Скорее всего, проблема запуска программ других ОС на нашей ОС хотябы частично будет решена. Хотя мы вообще-то планируем разработать свой формат исполнимого файла.
Вернуться к началу
Mr. BuS
Гость





СообщениеДобавлено: Пт Ноя 22 2002 11:21    Заголовок сообщения: З.Ы. Насчет запуска форточкиных прог Ответить с цитатой

Вообще-то, сразу так, навскидку возникает несколько вариантов:
1) делаем виртуальную "Форточко-машину" (типа Java-машины);
2) делаем перекомпилятор исполнимых файлов из PE-формата в наш;
3) еще че-нить придумаем Smile
Вернуться к началу
William Henry Gates
Гость





СообщениеДобавлено: Пт Янв 14 2005 12:29    Заголовок сообщения: Ответить с цитатой

самые скоростные и безглючные проги делаются на ассемблере. только долго.
Вернуться к началу
MaxP



Зарегистрирован: 04.12.2003
Сообщения: 38
Откуда: Москва

СообщениеДобавлено: Вт Авг 23 2005 11:22    Заголовок сообщения: Re: З.Ы. Насчет запуска форточкиных прог Ответить с цитатой

Mr. BuS писал(а):
Вообще-то, сразу так, навскидку возникает несколько вариантов:<BR>1) делаем виртуальную "Форточко-машину" (типа Java-машины);<BR>2) делаем перекомпилятор исполнимых файлов из PE-формата в наш;<BR>3) еще че-нить придумаем Smile

Ребята, а вам знакома такая операционка как OS/2? Посмотрите что с ней стало... Может Вам не изобретать велосипед, а если есть такое желание то может быть приложите усилия в данном направлении?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
mirzman



Зарегистрирован: 16.11.2006
Сообщения: 1

СообщениеДобавлено: Чт Ноя 16 2006 15:25    Заголовок сообщения: Ответить с цитатой

Я тут пишу почти ось, почти с нуля. Smile
В общем, это будет надстройка над Досом, рализующая в нем многозадачность. Звучит неплохо? Smile
Все драйвера досовские, с совместимостью проблем наверное не будет.
Но раз система многозадачная, необходима синхронизация, разделение доступа между процессами.
Некоторые устройства (таймер, контроллер прерываний) я эмулирую на уровне портов: программа пишет в порт, а я перехватываю это обращение и делаю то, что мне нужно. Но винчестер, скажем, там не проэмулировать. Я тут придумал такой ход: первый, кто успел, работает с винчестером нормально. Ну а кто не успел - придется подождатьSmile Но это не совсем хорошо. У кого-нибудь есть идеи, как это сделать лучше? А еще: может есть какая-нибудь функция, которую вызывают все остальные функции при обращении к диску? Тогда можно будет централизовать этот процесс.
А что делать с дисплеем я пока даже не придумал. В графическом режиме. Ведь нельзя же просто запретить вызывать Int 10h, если процесс неактивен. Нужно проверять обращение к каждой функции и смотреть, можно ее вызывать или нет. Но это страшно как-то. Может есть кто поумнее меня?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
критикан



Зарегистрирован: 18.02.2005
Сообщения: 247

СообщениеДобавлено: Пт Апр 20 2007 18:34    Заголовок сообщения: ЮСовский десантник получает оружие на отдельном парашюте Ответить с цитатой

Я согласен и не согласен с уважаемым Карповым относительно ООП. Согласен в том, что на ООП-языках программы пишутся дольше, а получаются больше и медленнее. Не согласен в том, что это качество ООП, а не программистов, пишущих на ООП-языках. В частности, думаю, что его сообщение от Вт Мар 19 2002 12:46 "Скрипты и ООП" неточно отражает существующее положение вещей в ООП-компиляторах. ООП провоцирует программистов писать плохо и одновременно позволяет некомпетентным программистам писать то, что они сами называют "программами", а это, в свою очередь, провоцирует таких "программистов" писать ещё хуже. Чтобы хорошо писать, нужно придерживаться структурного стиля программирования, одновременно понимая, что объекты, которыми манипулирует программа, в действительности являются объектами в понимании ООП (ООП как парадигмы, а не как ООП-компилятора).
----------------------------
ООП и не-ООП: Американским десантникам при высадке оружие доставляется на отдельном парашюте, а у русских десантников водители БМП десантируются в самих БМП
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Другие ОС Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2002 phpBB Group
Русская поддержка phpBB

 

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 6608306, ICQ 232284597
Пресс-релизы — pr@citforum.ru
Послать комментарий
Информация для авторов
This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2006 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...