Многозадачность
[ Это Сообщение было отредактировано PropellerMan в 2002-02-27 2240 ]
Подскажите плз, где в инете можно найти нормальное описание того, как реализовать многозадачность в защищенном режиме?
Конечно, http://wasm.ru - очень много статей, в том числе Broken Sword "Процессор INTEL в защищённом режиме", а спрашивать можно на RusFAQ.ru
Конечно, http://wasm.ru - очень много статей, в том числе Broken Sword "Процессор INTEL в защищённом режиме", а спрашивать можно на RusFAQ.ru
а сам то ось пишешь? коннекться аська - 322615508
короче чуваки давайте по обсуждаем как организовать виртуальную память для многозадачных систем... есть два способа
- страничная
- страницы по 4 метра
- страницы по 4 кб
- сегментная
меня интересует или сегментная или страницы по 4 метра.... у кого есть принципиальные идеи?
а сам то ось пишешь? коннекться аська - 322615508
короче чуваки давайте по обсуждаем как организовать виртуальную память для многозадачных систем... есть два способа
- страничная
- страницы по 4 метра
- страницы по 4 кб
- сегментная
меня интересует или сегментная или страницы по 4 метра.... у кого есть принципиальные идеи?
Наверно и страничная и сегментная- одно другому не мешает.Сегментная позволяет определить наличие сегмента в памяти при переключении задач, а страничная позволяет не загружать весь сегмент если он большой. Кроме того возможно совместное использование страницы несколькими сегментами в случае кучи маленьких сегментов либо кусок общего кода для нескольких сегментов(функции разные, предоставляемые системой), когда одна страница отображается в несколько сегментов.
А размер я так думаю 4кб, потому как ну куда с 2/4 метрами свопить?
Наверно и страничная и сегментная- одно другому не мешает.Сегментная позволяет определить наличие сегмента в памяти при переключении задач, а страничная позволяет не загружать весь сегмент если он большой. Кроме того возможно совместное использование страницы несколькими сегментами в случае кучи маленьких сегментов либо кусок общего кода для нескольких сегментов(функции разные, предоставляемые системой), когда одна страница отображается в несколько сегментов.
А размер я так думаю 4кб, потому как ну куда с 2/4 метрами свопить?
ага... а че такого? зато реже свопить будем... сразу 4 метра вызвали ли кинилу.. и всё... ну вообще.. я ожидал что народ реальные примеры приведёт... теорию.. а не глобальный взгляд..
можь раскажежь подробней?
ага... а че такого? зато реже свопить будем... сразу 4 метра вызвали ли кинилу.. и всё... ну вообще.. я ожидал что народ реальные примеры приведёт... теорию.. а не глобальный взгляд..
можь раскажежь подробней?
Насчет реже свопить-это ещё как посмотреть. Если ты что то подкачиваешь с винта, значит ты в свое время это что-то туда сбросил, и сбросил судя по всему от недостатка памяти. Велика вероятность того что в момент подкачки этот недостаток памяти ещё присутствует, а значит тебе сначала придется сбросить на винт 4метра, а потом загрузить 4 метра, особенно весело, если это какая нибудь таблица, к которой время от времени обращаются для чтения одной-двух записей.
А на счет поподробнее-дома посмотрю что осталось(болел я в своё время этой бедой). Если нарою что-отпишу.
Насчет реже свопить-это ещё как посмотреть. Если ты что то подкачиваешь с винта, значит ты в свое время это что-то туда сбросил, и сбросил судя по всему от недостатка памяти. Велика вероятность того что в момент подкачки этот недостаток памяти ещё присутствует, а значит тебе сначала придется сбросить на винт 4метра, а потом загрузить 4 метра, особенно весело, если это какая нибудь таблица, к которой время от времени обращаются для чтения одной-двух записей.
А на счет поподробнее-дома посмотрю что осталось(болел я в своё время этой бедой). Если нарою что-отпишу.
может заюзать след. образом..... у проги есть своя LDT и память не флэт а 4 гига разделенная между 8196 сеоментов... (правда это не динамическая величина...возможно что код может быть больше чем выделенный сегмент... так что есть свои проблемы)
А почему 4 мб те ненравится?? гляди... проге нужно еще 90 мб... свопить по 4 кб... тупо... по 4 метра..круто...я ведь не расчитываю что в моей оси будут мелкие проги.... короче я не предпологаю что в системе окажуться процессы которые запросят меньше 4 метра.. моя ось ПОДОБИЕ (!!! - не клон - не совместима) MAC OS... т.е. Супер воплащение на Intel... так что ТОКА 1 объект будет не меньше 2 метров... так какой смысл юзать по 4 кб?
может заюзать след. образом..... у проги есть своя LDT и память не флэт а 4 гига разделенная между 8196 сеоментов... (правда это не динамическая величина...возможно что код может быть больше чем выделенный сегмент... так что есть свои проблемы)
А почему 4 мб те ненравится?? гляди... проге нужно еще 90 мб... свопить по 4 кб... тупо... по 4 метра..круто...я ведь не расчитываю что в моей оси будут мелкие проги.... короче я не предпологаю что в системе окажуться процессы которые запросят меньше 4 метра.. моя ось ПОДОБИЕ (!!! - не клон - не совместима) MAC OS... т.е. Супер воплащение на Intel... так что ТОКА 1 объект будет не меньше 2 метров... так какой смысл юзать по 4 кб?
Свопить по 4 кила не тупо. Во первых систему не надо загружать несколькими большими заданиями, её надо загружать кучей мелких- это дает возможность в перерывах оглядываться чего там не сделано, грамотно перераспределять ресурсы плюс есть такая беда- клинч называется. На счет MAC OS сказать нечего-не знаком, буду рад если обрадуешь ссылками.
На тему больших процессов- неважно сколько просит процесс, важно чем он работает:80% работы исполняются 20%кода, остальные 80%кода можно сбрасывать, если есть острая необходимость в памяти. На счет флэт модели-процесс может под код иметь 4гектара, под стек, и еще сегментные регистры, совсем не обязательно что бы это все лежало в одном пространстве.И зачем 4 гига разделять между процессами, если каждому можно дать по столько- на то она и виртуальная память.
А так, если смотреть в идеале-размер страницы должен определяться отдельно для каждого сегмента, и эта величина должна управляться процессами, которым лучше знать с данными какого типа они работают. Но это уже к Intel и прочим. Они когда процессор делали со мной не посоветовались, а очень зря ;)
Свопить по 4 кила не тупо. Во первых систему не надо загружать несколькими большими заданиями, её надо загружать кучей мелких- это дает возможность в перерывах оглядываться чего там не сделано, грамотно перераспределять ресурсы плюс есть такая беда- клинч называется. На счет MAC OS сказать нечего-не знаком, буду рад если обрадуешь ссылками.
На тему больших процессов- неважно сколько просит процесс, важно чем он работает:80% работы исполняются 20%кода, остальные 80%кода можно сбрасывать, если есть острая необходимость в памяти. На счет флэт модели-процесс может под код иметь 4гектара, под стек, и еще сегментные регистры, совсем не обязательно что бы это все лежало в одном пространстве.И зачем 4 гига разделять между процессами, если каждому можно дать по столько- на то она и виртуальная память.
А так, если смотреть в идеале-размер страницы должен определяться отдельно для каждого сегмента, и эта величина должна управляться процессами, которым лучше знать с данными какого типа они работают. Но это уже к Intel и прочим. Они когда процессор делали со мной не посоветовались, а очень зря ;)
хы.. дая свою асю... кстати... тут каша полусается... МЕНЯ интересует именно РЕАЛЬНАЯ теория юзанья ресурсов... т.е. как отмечать тглобальна что эта страница занята тем то процессом и не может быть забита другим... и. т.п.
К тому же можно побозарить о планирование очередей процессов (как раз то чем я ща занимаюсь)....
а насчёт 4х метров я не раздумал, да я согласен с тобой... НО когда речь идёт тока о графики, а это не 4 кб... а минимум 7-8 то базара и быть не может... а чтобы выкачить 8 метров постепенно по 4 кб... это мы винт замучаим и всё вермя запрегать менеджер памяти... а писать сервис типо GetMem(size) - ЭТО 100% чушь... так что две проблемы производительность и удобство прикладных программ... самый рац. вариант это заюзать более большими кусками - 4 мб - т.е. уменьшит кол-во действий (во всяком случае повторяющихся)... ведь картинки мы грузим целиком а не почастям =) ... может я и неправ.. НО пока сам неубежусь не отступлю...
ведь я
CodeWorld! :devil:
хы.. дая свою асю... кстати... тут каша полусается... МЕНЯ интересует именно РЕАЛЬНАЯ теория юзанья ресурсов... т.е. как отмечать тглобальна что эта страница занята тем то процессом и не может быть забита другим... и. т.п.
К тому же можно побозарить о планирование очередей процессов (как раз то чем я ща занимаюсь)....
а насчёт 4х метров я не раздумал, да я согласен с тобой... НО когда речь идёт тока о графики, а это не 4 кб... а минимум 7-8 то базара и быть не может... а чтобы выкачить 8 метров постепенно по 4 кб... это мы винт замучаим и всё вермя запрегать менеджер памяти... а писать сервис типо GetMem(size) - ЭТО 100% чушь... так что две проблемы производительность и удобство прикладных программ... самый рац. вариант это заюзать более большими кусками - 4 мб - т.е. уменьшит кол-во действий (во всяком случае повторяющихся)... ведь картинки мы грузим целиком а не почастям =) ... может я и неправ.. НО пока сам неубежусь не отступлю...
ведь я
CodeWorld! :devil:
Убеждаю.
Размер страницы в 4к не говорит о том что ты качаешь с винта по 4к. Качать за раз ты можешь те же самые 4 метра, только прикол в том что можно в любой момент остановиться и сказать - хватит, тут у нас еще кое что сделать надо, а при 4 метрах пока не закачаешь, не остановишься. Просто пишешь отдельный модуль, который отслеживает тенденции процессов и решает для какого процесса подкачать одну страницу, а для какого десяток. Только чтобы это грамотно работало тебе лучше подумать над файловой системой для свопа(как в никсах), к ней прикрутить фоновый дефрагментатор, сбор статистики запросов и её анализ в свободное время.
Аси у меня нет, не пользуюсь, рекомендую иру. :)
На счет реальной теории- дома посмотрел, голод и разруха, так что что по памяти вспомню, то и накидаю, а большего обещать не буду. Это, там про ссылочки на Mac Os чой-то было. ;)
Убеждаю.
Размер страницы в 4к не говорит о том что ты качаешь с винта по 4к. Качать за раз ты можешь те же самые 4 метра, только прикол в том что можно в любой момент остановиться и сказать - хватит, тут у нас еще кое что сделать надо, а при 4 метрах пока не закачаешь, не остановишься. Просто пишешь отдельный модуль, который отслеживает тенденции процессов и решает для какого процесса подкачать одну страницу, а для какого десяток. Только чтобы это грамотно работало тебе лучше подумать над файловой системой для свопа(как в никсах), к ней прикрутить фоновый дефрагментатор, сбор статистики запросов и её анализ в свободное время.
Аси у меня нет, не пользуюсь, рекомендую иру. :)
На счет реальной теории- дома посмотрел, голод и разруха, так что что по памяти вспомню, то и накидаю, а большего обещать не буду. Это, там про ссылочки на Mac Os чой-то было. ;)
про ссылки...чуть позже... надо все мои заметки разгребатьь.. ты мне дай лин на иру... установлю и т.д. ..... Лано убидил =)Но тока запаристо всё равно организовавать это.. это уже 2 таблица...а так бы было тока 1 сразу тыкующая на 4 метра =) я пока не отказываюсь от своей идеи ;) Ну хотя надо задуматься.. давай базарить про приоритеты... про планирование очередей..
по каким критериям можно разделить процессы? - т.е. сами очереди
и какие состояние бывают у процессов (более подробно а не так - ожидающий, выполн. =))
а как организовать приоритеты?
давай базарить про приоритеты... про планирование очередей..
по каким критериям можно разделить процессы? - т.е. сами очереди
и какие состояние бывают у процессов (более подробно а не так - ожидающий, выполн. =))
а как организовать приоритеты?
Давай говорить про очередя.
Только я вот думаю что не нужны они. Все что я тут набью- моё личное мнение, возможно никем не разделённое и никому мной не навязываемое.Многие моменты не мной придуманы, так что на оригинальность я тоже не претендую.
Вообще имеем не очередь а кучу процессов, каждый из которых ждет чего нибудь.
То есть всё на событиях.(на Microsoft не смотри, у них всё через задницу) Вот есть у нас процесс, который должен выполняться в фоне, значит он говорит системе, что он ждет следующего события-"процессор свободен, idle больше какого-то там значения".
Реакция системы на это событие- дать порулить процессу. Каждый процесс может указать несколько событий, которые он ждет и реакции на них. К примеру процесс получил управление, начинает работать и его прерывают.
Что делать с ним дальше-отдать управление когда появится возможность или ждать какого то другого события-эти вещи процесс сам сообщает системе, а та уже исходя из соображений безопасности, быстродействия и настроек администратора решает, насколько следует следовать указаниям процесса.
На самом деле схема очень простая, реализовать её тоже не архисложно, вопрос в том какие события отслеживать-тут надо найти баланс между производительностью и удобством.
Вообще отслеживать надо только те события, появления которых ждут процессы.То есть процесс поставив системе какое либо ожидение, сам порождает событие, реакция на которое примерно следующее"проверить событие, если подобное ожидается, все нормально, иначе разрешить отслеживание"
Если отслеживание разрешено, то при возникновении такой ситуации генерируется событие, иначе молчание. Но тут надо определится из какого набора процесс может выбирать. Если разрешить порождать событие на каждый push/pop, то далеко не уедешь.
Это про очередь. А про приоритеты-они нужны когда возникает событие, которого ждало несколько процессов, либо событие возникло в момент реакции на другое, а процесс, отрабатывающий реакцию ничего не сказал о том, что с ним делать в такой ситуации.
В никсах это nice, но чой-то не нравится мне, как он устроен. Приоритеты, они ведь от обстоятельств зависят, а обстоятельства разные бывают. Значит приоритет надо явно привязать к событиям.
В реалтаймных системах наверно с этим как то борятся. Посмотреть надо. По памяти из таких только QNX помню. Поройся в Сети, там этого добра валом должно быть.
Про Иру- http://www.mirc.co.uk/.
А на счет таблиц- привыкай, у тебя их не одна сотня будет :)
Лано скажу как я это представляю.. а ты прокритикуй...
Четыре очереди:
- 1ая очередь ядро
- 2ая очередь дрова
- 3ая очередь Системный сервис
- 4ый оч-дь прикладные процессы
1 и 2 очереди выпоняются почти в реальном времени.. на каждый прикладной процесс выпоняются все процессы ядра... т.е. если у нас 7 процессов прикладных то очередь ядра уже выполниться 7 раз... знаешь конешно это может большие трмоза дать... поэтому не гарантирую что я так сделаю.. это будет зависить на скоко эффективное у мя ядро получилось.. ХОТЯ на 90% всё таки это заюзаю... очередь ядра поумолчанию буквально 5 -7 процессов (вирт. консоли и еще какая нить хрень которая ждёт управления). Дроа это ясно... они не ждут управления.. но при инициализации оборудования мы пропрыгам все дрова..и в последующем при необходимости резетнуть какую нить аппаратуру прыгним туда или могут быть дрова-тестер-оборудования.. которым мы периодически передаём управление... тупая очередь.. но для структуры дрова надо отделить и НЕОБДЕЛИТЬ.. ведь может у нас замудренная аппаратура и предётся вручную передавать управления.. это очередь выполняется 1 раз за 2 процесса из очереди ядра..
3 ая очередь это ясно.. типо дополнительный прикладной сервис.. он выполняется 1 раз на два прикладных процесса...
4 ая очередь - без коментариев..
а вот с приоритетной системой у мя всё продумано.. правда у мя ПРИОРИЕТЫ тока для прикладных процессов
пример:
5 уровней приориетов..
а теперь так - на два процесса с приоритетом 1 выполняется один процесс с приоритетом 2, на два процесса с приоритетом 2 выпоняется два процесса с приоритетом 3... тут всё ок! все обговоренно.. наипрекраяснейшая стратегия... процессы не в обиде.. и всем управление передестся..
Ну ты настрочил.. быстренько пробежался... причём тут таблице не понял.... да и ёзё не понял не чё начинаю со строчки где то 3 =)
Лано скажу как я это представляю.. а ты прокритикуй...
В общем то покритиковать не получится, у меня по другому все было(собиралось быть ;) )заточено.
Пользовательские процессы как таковые отсутствуют, программы в виде исходников, а система сама решает, как их запускать- компилировать или заводить интерпретатор.
Большая часть системы тоже пишется на языке высокого уровня, но не компилируется, как в никсах.Что то вроде скриптов.
Таким образом система состоит из компактного ядра, заточенного под платформу, модулей, платформно независимых и дальше уже приложения. При переносе на другую платформу надо переписать только ядро. Далее есть промежуточные необязательные причиндалы, я их называл патчами, хотя не очень в тему. Они заменяют платформно независимые медленные модули на прлатформно зависимые быстрые.
То есть при переносе системы, переписав ядро, получаешь полностью рабочую но слегка тормознутую систему, которую уже дальше оптимизируешь.
Я так подозреваю что оптимизация уже работающего кода немножко легче, чем перенос и наладка кода нихрена работать не желающего.
Кроме того удобно в разнородных сетях. Вышел апдейт платформно независимого модуля, обновляешь его на серваке, тот сообщает станциям, что пора обновлятся, те дружно лезут к нему качать обновление, общее для всех. Ну и там много чего еще нафантазировал, всего за раз и не опишешь. Только команда нужна под это дело, и неслабая команда. В принципе человек десять-двенадцать будет если, уверенных что в течение хотя бы года не сойдут с дистанции, то можно начать.
Так что думай, нароешь людей, я согласный-генератором идей :)
А можно глупый вопрос? Как управлять памятью-то? Вот в досе есть MCB, а здесь как быть, здесь ведь защищённый режим. И ещё, как учитывать то что находится в памяти, а что в свопе. Похоже придётся ворганить сегментик размером во всю память, и делать как MCB в досе, и отдельно сделать таблицу свопа.
Что в свопе, а что в памяти в x86 организовано по железу что для страничной организации что для сегментной.
Каждый сегмент имеет признак присутствия, если происходит переключение/обращение на отсутствующий в памяти сегмент происходит прерывание, управление передается обработчику который и обеспечивает собственно свопинг. Для страниц чуть по другому, там таблица страниц организовывается для переадресации и тоже присутствие отсутствие тачкуется. Таблицы окучивать система должна(читай ты), а вот контролирует обращения процессор сам. И тоже прерывания и пр. А насчет управления памятью ты что имеешь в виду-физически присутствующую, или вирт, который организовываешь? А вообще поройся поподробнее с дескрипторами сегментов и страничной организацией,это не так сложно как кажется. Это ещё сложнее ;)
С точки зрения харда, я знаю про бит присутствия и.т.д Но сегменты могут накладываться друг на друга, и к тому жу, когда возникнет искключения из-за бита присутствия, необходимо знать, из какого места свопа загружать. Кроме того, надо знать, какие куски памяти свободны.Да много вообщем надо знать системе, и причём не просто знать, а манипулировать памятью, и размер свопа, по-моему здесь не главный вопрос, главный вопрос, как всё это реализовать???
Я ж тебе говорю, поройся поподробнее. В дескрипторе специальное поле есть, не используемое процессором, оно для того и заточено, чтоб ты в нем чего нибудь хранил, к примеру номер строки в таблице в которой хранится что делать надо-загружать весь сегмент, пометить как загруженный, вернуть назад управление и ждать исключение по отсутствию страницы, или же пометить как присутствующий, подгрузить страницы, обращение к которым наиболее вероятно в данный момент , вернуть управление и спать спокойно-до следующего раза. Только таблицу эту тебе невыгружаемой надо сделать.
Какие куски памяти свободны-тоже таблица- на каждые 4k в таблице 1бит.Свободна-ноль, занята-1.
Или тебе прямо готовые сэмплы нужны? Систему кто пишет ты или я? :) Не, а вообще почему бы и не. Посмотрим что там дальше будет. Глядишь толпой чой нибудь сварганим.
к стати приветствую на SysBin.com]www.SysBin.com .....
=========================================
http://sysbin.com/phpBB2/
=========================================
=========================================
Начну я сие повествования так сказать "с конца" (модераторы, это не то, что вы подумали, точнее, не с того конца, с какого вы подумали, и с чего я вообще узнал, что вы подумали… ну да ладно, продолжу…). Чуть не забыл, читатель, если ты сидишь по DialUp'у, и решил прочитать эту лечку - отключись, съекономишь много денег.
Итак, как я уже сказал - писать буду с конца, так, что слухай, начнем с адресного пространстра задачи, псевдографик из меня никакой, но это даже псевдографикой-то не назовешь:
Область программы:
+----------------------------------------------------------------------------------------------+
| DataS: base=0; limit="до начала библиотек" | LBS | KSS |
+----------------------------------------------------------------------------------------------+
| CodeS: base=0; limit=FFFFFFFFh |
+----------------------------------------------------------------------------------------------+
| Program code&data | Неиспользуемое(свободное) пространство | Стек | Библиотеки | KShared |
+----------------------------------------------------------------------------------------------+
| | | | |
+-00000000h +-SP +- Дно стека |FFFFFFFFh+
|
FFFFFFFFh-256kb --+
Смотреть это творение надо с нормальным шрифтом. Тогда может быть вы что-то разберете. А я буду в этот момент вас лечить этим. Итак за программой закрепленны 3 сегмента вот они:
CodeS - сегмент кода программы, независимо от размера имее размер FFFFFFFFh и независимо от расположения программы в памяти имее бызу 0.
DataS - сегмент данных имеет размер, как там и написанно "до начала библиотек". А базу - 0. Из этого следует, что модель памяти у меня - Flat.
KSS - Kernel Shared Segment. Сегмент данных имеет размер 256kb, и начинаеться с FFFFFFFFh минус 256kb. Фиктически это две очереди, если программе надо обраться к ядру она записывает необходимые ей данные в одну очередь, затем ждет специального флага, и читает реультат из другой.
Также существует несколько LBS - LiBrary Segment. Сегменты данных для кажной библиотеки, как они располагаються в памяти "см. рисунок".
Как вызвать библиотеку? Очень просто при запуске ОС должна изменить код проги(адреса), есс-тно основываясь на данных из заголовка, что прога мозла узнать по какому адресу лежит библиокека. А потом программа просто передаст ей управление. "Но этоже будет near call!" - скажете вы. Вот имменно! Как извесно в PM загрузка сегментных регистров довольно медленная операция. А если не загружать CS, а только DS, то это чуть-чуть ускорит работу. Но это позволит использовать всякие недокументированные точки входа в библиотеки. Я прекрасно это знал. Этого очень легко избежать поставив в начале точки входа в библиотеку комманду загрузки сегментного регистра. И все! Если программа нечаенно или специально передаст управнение не на ту комманду, или на середину комманды, то она никому не навредит, кроме самой себя.
Теперь плавно перетечем к расмотрению адресного пространства ядра. Вот оно:
Облать ядра:
+----------------------------------------------------------------------------------------------+
| IDT | GDT | Pag |Drv1 | Drv2 | Drv3 | DrvN | Free | Библиотеки | Stack |
+----------------------------------------------------------------------------------------------+
Итак, вот и оно. Сразу хочу заметить, что адресное пространстро (может я термин неправильно подобрал, если, что извиняйте) ядра так же имеет CodeS и DataS. Только вот DataS имеет лимит FFFFFFFFh. Также отмечу, что библиотеки во всех программах и ядре лежат по одним линейным адресам. В ядре присутствует сегмент стека, для того, чтобы очень сильно разросшийся стек случайно не повредил (затер) область библиотек. Как загручаеться программа? А вот как в начале для нее выделяеться память в области free. Вообще выделить память, это ведь на самом деле пометить ее как используемую. Как вот, выделяеться 256kb под область KShared, затем 1mb под каталог страниц (страницы по 4kb), сколько нужно под саму прогу, и 4kb(одна страница) под stack, если он будет расшираться и залезет на неинициализированную область ядро выделит еще одну страницу и продолжит программу. Затем настроит каталог страниц этой проги как надо, чтобы получилось то, что изображенно на рис.1. Ну а дальше дело техники.Вообще, как видно на рис.2 у ядра нет кода, нет данных и т.д. Так вот, в процессе работы все функции по переключению задач берут на себя драйвера. Объясняю, загрузчик лежащий в boot'e или в MBR'е, зависит от того откуда ОС стартует, читает небольшую програмку с диска и передает ей управление, он собирет эти драйвера в кучу, как на рис.2, и передает им управнение.
Ну, вот вроде и все. Вопросы / предложения / пожелания / откровения / признания (ненужное затереть) принимаються.
меня больше более подробные детали интересуют..
коннектся в аську...
кстати Exz конектся ко мне icq: 322615508
а чуваки... че молчите? можите тоже поучавствувать ;)
634 чувака посмотрела эту тему... надо этим воспользоваться... давай те дальше обсуждать...
кстати Exz конектся ко мне icq: 322615508
а чуваки... че молчите? можите тоже поучавствувать ;)
1. Не Exz, а eXz.
2. Как понять, коннектиться а icq?
3. Чет дохлый какой-то этот форум(sysbin.com). :-\
1. Не Exz, а eXz.
2. Как понять, коннектиться а icq?
3. Чет дохлый какой-то этот форум(sysbin.com). :-\
форум дохлый.. смешно.. енто ж не коденет.. а закрытый форум оси девелоперов....
можешь поотвечать там у мя вопрос в топике Inside OS
меня больше более подробные детали интересуют..
коннектся в аську...[/QUOTE]
Вроде теоретические аспекты обоим основным участникам известны, как я вижу, к тому же общая схема ОСи также набросана, какие именно детали вас, ребята, интересуют?