OSDev

для всех
Текущее время: 16 дек 2017, 10:10

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 351 ]  На страницу 1, 2, 3, 4, 5 ... 36  След.
Автор Сообщение
 Заголовок сообщения: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 19:37 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
Представляю вашему вниманию инструментарий разработчика – набор для загрузки ОС.
Данный набор позволит тем разработчикам, которые не хотят использовать монстроидальные Linux-овые загрузчики GRUB/SYSLINUX/LILO, а хотят быстро и просто загружать собственный бинарный образ с любых носителей (дискеты, жёсткие диски, флеш-накопители, компакт-диски...) с файловыми системами FAT12/16/32, exFAT, NTFS, Ext2/3/4, Minix1/2/3, ISO9660, с дисков, разбитых на разделы как в традиционной схеме MBR, так и в прогрессивной схеме GUID (GPT) даже с разделов лежащих за пределами отметки 2ТБ. Поддерживается Dual boot. Также в комплект входит утилита Windows/Linux, которая позволяет записывать соответствующие загрузочные секторы на любое устройство или в файл, представляющий собой виртуальный образ носителя. Этот комплект позволяет приступить непосредственно к разработке образа, не разбираясь на ранних стадиях со структурой файловых систем и не впадая в ступор от нехватки места для отладки своего загрузчика. В архиве есть демонстрационное ядро, показывающее корректную инициализацию, сохранение и использование переданных загрузчиком параметров, вы можете его использовать в качестве стартапа для своего ядра.
К достоинствам набора относятся:
– Простота подготовки носителя к загрузке, при этом данные на диске не пострадают;
– Предельная простота использования – после подготовки носителя просто копируете на него свой файл образа ОС любым удобным способом и грузитесь с него;
– Ваш образ может иметь достаточно большой размер – до 620кБ;
– Ваша ОС легко узнает, с какого носителя она загружена;
– Вашу ОС можно будет легко продемонстрировать друзьям (проверить/отладить) – просто передайте файл, другие запишут его на подготовленный таким же образом носитель.
Набор не отменяет существующие загрузчики, такие, как GRUB или SYSLINUX. Он их дополняет! Эти загрузчики имеют убогую первичную загрузку, делающую процесс установки загрузчика на новый диск непростым и рискованым занятием. В комплекте приложены версии загрузчиков, не требующих процедуры установки, они непосредственно могут быть загружены этим набором.
Спецификации, использование и много чего другого можно прочитать на официальной странице проекта.

Заходим, скачиваем, используем...
OS Boot Tools v3.3
...обсуждаем здесь.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Последний раз редактировалось Yoda 24 янв 2013, 18:55, всего редактировалось 6 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 20:15 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1196
Если бы сделал 1-килобайтный загрузчик для FAT32, то возможно не пришлось бы делать две разные версии.

Про идентификатор раздела расскажи поподробнее. Я идентифицирую раздел одним 8-разрядным числом, передаваемым в dh. Первичные загрузчики могут получать это значение в том числе и от MBR-загрузчиков.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 20:33 

Зарегистрирован: 13 окт 2008, 17:38
Сообщения: 46
Откуда: Владимир
Я понимаю, что для ядра маленькой системы 608к вполне достаточно, но просто интересно с чем связано такое ограничение, почему не больше?

PS. Еще хотелось бы видеть поддержку Cdfs (Etfs).


Последний раз редактировалось valeri 12 янв 2012, 20:36, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 20:35 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1196
Чего непонятного? Загружаем ядро в базовую память. При правильном подходе этого более чем достаточно.

valeri писал(а):
PS. Еще хотелось бы видеть поддержку Cdfs (Etfs).
+1. Я тоже хотел это написать. Именно этого загрузчика недостает до моего полного комплекта.


Последний раз редактировалось phantom-84 12 янв 2012, 20:45, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 20:44 

Зарегистрирован: 13 окт 2008, 17:38
Сообщения: 46
Откуда: Владимир
А, тьфу, что-то я ступил, извиняюсь, я думал управление на ядро передается уже в защищенном режиме, невнимательно описание прочитал.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 21:03 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1057
Yoda, есть проверка базовой памяти и размера файла?
Наличие MBR, не решает проблемы.
Всё равно, надо будет писать функцию чтения с диска и записи на него. И будут тежи вопросы. А простой helloword можно и в MBR записать.
Иметься ли наличие поддержки GPT?

Лично у меня свой такой же набор файлов. И грузит он как COM, так MZ-EXE файлы.
С флопика гружусь в дос пишу и отлаживаю KLOADER.EXE очень удобно закончил отладки скинул в корень.
Гружусь с жесткого тот загружает мой KLOADER.EXE


MZ-EXE, выбран в виду любви к продукции Borland.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 12 янв 2012, 21:26 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1196
Цитата:
7. Максимальный размер загружаемого файла зависит от типа файловой системы и её параметров. В данный момент во всех файловых системах загружается файл размером не менее 608 кб при размере кластера файловой системы не более 32к.
Во-первых, здесь видимо имелось в виду "не более 608 кб", а во-вторых, очень плохо, что "максимальный размер загружаемого файла зависит от типа файловой системы и её параметров" - нужно, чтобы он зависел исключительно от размера доступной (базовой) памяти. Из-за того, что вы выбрали такую низкую базу загрузки, вам и кэшировать секторы CD/DVD, FAT и т.п. особо некуда, а большие "последние" кластеры при необходимости можно считывать частично, т.е. читать только те секторы кластера, которые содержат данные файла. У меня база загрузки файла ядра равна 8000h. Сразу за файлом ядра загружается еще один файл - его база загрузки кратна 1 кб, т.к. размер файла ядра должен быть кратен 1 кб. При использовании упрощенных загрузчиков оба файла должны быть упакованы в один.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 13 янв 2012, 11:44 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
phantom-84 писал(а):
Если бы сделал 1-килобайтный загрузчик для FAT32, то возможно не пришлось бы делать две разные версии.

Да. Но я ставил целью сделать код, пригодный для ЛЮБОЙ валидной файловой системы. В принципе, ничто не мешает FAT32 выкинуть резервную копию бут-сектора и оставить только два зарезервированных сектора - один загрузочный и один FSInfo. В таком случае килобайтный бут уже не поместится.

phantom-84 писал(а):
Про идентификатор раздела расскажи поподробнее. Я идентифицирую раздел одним 8-разрядным числом, передаваемым в dh. Первичные загрузчики могут получать это значение в том числе и от MBR-загрузчиков.

DL, а не DH. Да, там номер загрузочного диска BIOS. Мой MBR передаёт полученное от BIOS значение дальше по цепочке.
Идентификатор раздела - это 4 байта, уникальный ID (Volume Serial Number), прописываемый при форматировании в бут-сектор по адресам 43h-46h для FAT32 и 27h-2Ah для FAT12/16. В принципе, имея номер загрузочного диска можно оттрассировать цепочку загрузки и самостоятельно определить раздел, с которого загружена ОС. Однако, если используются какие-то бут-менеджеры, то решение задачи может оказаться нереальным. Определение раздела по переданному VolumeID намного надёжней.

valeri писал(а):
PS. Еще хотелось бы видеть поддержку Cdfs (Etfs).

Будет обязательно. Сейчас как раз работаю над ней.

pavia писал(а):
Yoda, есть проверка базовой памяти и размера файла?

Проверки базовой памяти нет. Сначала ввёл, затем отказался от неё.
Проверки размера файла тоже нет. За ненадобностью.

pavia писал(а):
Наличие MBR, не решает проблемы.

Я написал, какие именно проблемы решает загрузчик. И проблемы вполне реальные. Вспомни, что ранние версии MS-DOS требовали, чтобы IO.SYS/MSDOS.SYS были первыми именами в корневой директории и IO.SYS располагался непрерывно в начале диска. Более поздние версии сняли ЧАСТЬ ограничений. Это всё от острой нехватки места. Любой, кто пишет загрузчик нулевого уровня так или иначе столкнётся с серьёзными сложностями подобного рода. А ведь гораздо приятней сразу иметь нулевой загрузчик, не имеющий НИКАКИХ ограничений на размещение файла, его имя и положение в корневой директории и не парясь процессом начальной загрузки.

pavia писал(а):
Всё равно, надо будет писать функцию чтения с диска и записи на него.

С данным загрузчиком дальнейшую работу с дисками через BIOS по INT13 уже можно и не писать. 608к вполне достаточно, чтобы в них вписать перевод в защищённый режим, часть ядра, драйверы дисков и файловых систем без промежуточных стадий. А в случае мини-систем и вообще целиком грузить всё ядро ОС.

pavia писал(а):
А простой helloword можно и в MBR записать.

Ну да, конечно. Посмотри на мучения Станислава, нещадно терзающего свою флешку нестандартными форматами :)

pavia писал(а):
Иметься ли наличие поддержки GPT?

Сейчас нет, но стоит в ближайших планах.

phantom-84 писал(а):
Во-первых, здесь видимо имелось в виду "не более 608 кб"

Нет-нет, именно не менее! Иными словами, файл не превышающий в размере 608к будет гарантированно загружен целиком. А вот если он больше, то всё зависит от ряда тонкостей.

phantom-84 писал(а):
очень плохо, что "максимальный размер загружаемого файла зависит от типа файловой системы и её параметров" - нужно, чтобы он зависел исключительно от размера доступной (базовой) памяти.

Полностью зависимость убрать малореально. Во-первых, BIOS сам отъедает немалую часть базовой памяти. Во-вторых, сектор устройства документированно может быть до 4к (уже в этом есть неизбежная вариативность!). В третьих ещё минус 1.5к векторов прерываний и переменных BIOS. Ещё нужно место для самого кода, промежуточных данных и т.д. На всё я отвожу максимум 32к. Остальное (640-32) и есть те самые гарантированные 608к, что на самом деле немало. Реальный максимум - 627к для FAT12/16 и 625к для FAT32, но лишние 20к - слабое утешение. Если файл не вписался в 608к уже сейчас, то надёжней будет всё же ввести промежуточный загрузчик или распаковку в ОЗУ, чем закладываться на негарантированный бонус в 20к.

phantom-84 писал(а):
Из-за того, что вы выбрали такую низкую базу загрузки, вам и кэшировать секторы CD/DVD, FAT и т.п. особо некуда

Не вижу связи. Это лишь вопрос выбора адреса, КУДА что кэшировать/писать. База 600h позволяет мини-ОС полней и удобней использовать имеющуюся в распоряжении память.

phantom-84 писал(а):
У меня база загрузки файла ядра равна 8000h. Сразу за файлом ядра загружается еще один файл - его база загрузки кратна 1 кб, т.к. размер файла ядра должен быть кратен 1 кб. При использовании упрощенных загрузчиков оба файла должны быть упакованы в один.

Вот видите, у вас уже начались какие-то искусственные ограничения :)

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 13 янв 2012, 18:02 

Зарегистрирован: 10 май 2007, 11:33
Сообщения: 1196
Yoda писал(а):
Да. Но я ставил целью сделать код, пригодный для ЛЮБОЙ валидной файловой системы. В принципе, ничто не мешает FAT32 выкинуть резервную копию бут-сектора и оставить только два зарезервированных сектора - один загрузочный и один FSInfo. В таком случае килобайтный бут уже не поместится.
Да. Но в отличии от FAT1x в FAT32 обычно с этим нет проблем. В любой винде загрузчик имеет размер минимум 1 кб, а резерв часто делается еще больше. Есть и другие вменяемые способы увеличения размера пространства, доступного загрузчику. Например, у меня для FAT1x используется единый (для обоих типов ФС) расширитель загрузчика, размещаемый в файле bootex.bin размером 512 байт. Можно даже сделать вариативное размещение расширителя либо в файле, либо в резервной области.

Цитата:
DL, а не DH. Да, там номер загрузочного диска BIOS. Мой MBR передаёт полученное от BIOS значение дальше по цепочке.
Я говорил про свой идентификатор раздела. Он передается в dh и является просто "географическим" (сейчас) или каким-либо иным (в перспективе) номером раздела. Выдержки из моей спецификации на эту тему можно найти здесь.

Цитата:
Идентификатор раздела - это 4 байта, уникальный ID (Volume Serial Number), прописываемый при форматировании в бут-сектор по адресам 43h-46h для FAT32 и 27h-2Ah для FAT12/16. В принципе, имея номер загрузочного диска можно оттрассировать цепочку загрузки и самостоятельно определить раздел, с которого загружена ОС. Однако, если используются какие-то бут-менеджеры, то решение задачи может оказаться нереальным. Определение раздела по переданному VolumeID намного надёжней.
У такого подхода (я его называю "лэйбльным") есть как преимущества, так и недостатки. Чтобы идентифицировать раздел, нужно прочитать его бутсектор, а заодно и бутсекторы других разделов. У меня перечисление разделов может выполняться вообще без обращения к их содержимому. Существует вероятность появления двух одинаковых идентификаторов.

Цитата:
Проверки базовой памяти нет. Сначала ввёл, затем отказался от неё.
Что так? Ты же заполняешь базовую память под завязку. А как это сделать, точно не зная границу доступной (базовой) памяти сверху?

Цитата:
Проверки размера файла тоже нет. За ненадобностью.
Не понял. А если у тебя в корне лежит стометровый файл ядра? Как загрузчик его будет грузить?

Цитата:
Я написал, какие именно проблемы решает загрузчик. И проблемы вполне реальные. Вспомни, что ранние версии MS-DOS требовали, чтобы IO.SYS/MSDOS.SYS были первыми именами в корневой директории и IO.SYS располагался непрерывно в начале диска. Более поздние версии сняли ЧАСТЬ ограничений. Это всё от острой нехватки места. Любой, кто пишет загрузчик нулевого уровня так или иначе столкнётся с серьёзными сложностями подобного рода. А ведь гораздо приятней сразу иметь нулевой загрузчик, не имеющий НИКАКИХ ограничений на размещение файла, его имя и положение в корневой директории и не парясь процессом начальной загрузки.
+1

Цитата:
С данным загрузчиком дальнейшую работу с дисками через BIOS по INT13 уже можно и не писать. 608к вполне достаточно, чтобы в них вписать перевод в защищённый режим, часть ядра, драйверы дисков и файловых систем без промежуточных стадий. А в случае мини-систем и вообще целиком грузить всё ядро ОС.
+1. В моей схеме драйвер загрузочного устройства и ФС находится в отдельном файле, который грузится вместе с файлом ядра, поэтому никакие промежуточные стадии не нужны. Этот драйвер является обычным драйвером защищенного режима. Единственное, что следует учитывать, так это то, чтобы в нем обязательно содержался и драйвер загрузочного диска, и драйвер соответствующей ФС, и менеджер разделов (в случае использования разбитого на разделы диска).

Цитата:
Нет-нет, именно не менее! Иными словами, файл не превышающий в размере 608к будет гарантированно загружен целиком. А вот если он больше, то всё зависит от ряда тонкостей.
Теперь понятно, но написано все равно не очень складно - может показаться, что файлы меньшего размера нельзя грузить вообще.

Цитата:
Полностью зависимость убрать малореально. Во-первых, BIOS сам отъедает немалую часть базовой памяти. Во-вторых, сектор устройства документированно может быть до 4к (уже в этом есть неизбежная вариативность!). В третьих ещё минус 1.5к векторов прерываний и переменных BIOS. Ещё нужно место для самого кода, промежуточных данных и т.д. На всё я отвожу максимум 32к. Остальное (640-32) и есть те самые гарантированные 608к, что на самом деле немало. Реальный максимум - 627к для FAT12/16 и 625к для FAT32, но лишние 20к - слабое утешение. Если файл не вписался в 608к уже сейчас, то надёжней будет всё же ввести промежуточный загрузчик или ввести распаковку в ОЗУ, чем закладываться на негарантированный бонус в 20к.
То что "отъедает" BIOS, никак нельзя считать доступной базовой памятью. В случае больших секторов (больше 1 кб; к примеру 2 кб в CD/DVD) ты мог бы кэшировать последний сектор файла в специальном буфере, если он полностью не умещается в оставшемся участке памяти, а находящиеся в нем файловые данные умещаются. Арифметика 640-32 (в идеале) больше похожа на мою. Я не понял, откуда при адресе загрузке 600h у тебя взялись 32 кб? Ты что ли используешь участок в конце базовой памяти? А как же EBDA?

Цитата:
Не вижу связи. Это лишь вопрос выбора адреса, КУДА что кэшировать/писать. База 600h позволяет мини-ОС полней и удобней использовать имеющуюся в распоряжении память.
Сомнительное утверждение. Если почти всю базовую память занимает загруженный образ, то о каком удобстве вообще идет речь. А с загрузчиком дела обстоят еще хуже, ведь у тебя адрес загрузки ядра (600h) лежит ниже адреса загрузки загрузчика (7C00h). Получается, чтобы загрузить ядро размером больше 7C00h-600h, тебе сначала нужно переместить загрузчик.

Цитата:
Вот видите, у вас уже начались какие-то искусственные ограничения :)
Это искусственное ограничение исключительно положительное. Кратность размера файла ядра 1 кб является одним из первичных признаков его корректности (есть еще и сигнатура в конце), который может быть проверен уже на этапе работы первичного загрузчика (я бы и проверку контрольной суммы вынес в первичный загрузчик, но наличие у файла ядра контрольной суммы не описано в загрузочной спецификации).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: OS Boot Tools
СообщениеДобавлено: 15 янв 2012, 15:35 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
phantom-84 писал(а):
Да. Но в отличии от FAT1x в FAT32 обычно с этим нет проблем. В любой винде загрузчик имеет размер минимум 1 кб, а резерв часто делается еще больше. Есть и другие вменяемые способы увеличения размера пространства, доступного загрузчику. Например, у меня для FAT1x используется единый (для обоих типов ФС) расширитель загрузчика, размещаемый в файле bootex.bin размером 512 байт. Можно даже сделать вариативное размещение расширителя либо в файле, либо в резервной области.

Вопрос: а зачем всё это, если удалось всё нормально разместить в 512 байтах?

phantom-84 писал(а):
Я говорил про свой идентификатор раздела. Он передается в dh и является просто "географическим" (сейчас) или каким-либо иным (в перспективе) номером раздела. Выдержки из моей спецификации на эту тему можно найти здесь.

Интересные спецификации. Однако, в свете VolID я рассматриваю это только как потенциальный бонус. Тем более, что после перехода в защищённый режим Int13 перестаёт быть доступным (или же надо делать отдельный Virtual 86 модуль специально для функций BIOS) и что такое Drive 80h - уже остаётся только гадать. VolID в целом более надёжный метод, т.к. предоставляет информацию, не зависящую от BIOS.

phantom-84 писал(а):
Чтобы идентифицировать раздел, нужно прочитать его бутсектор, а заодно и бутсекторы других разделов. У меня перечисление разделов может выполняться вообще без обращения к их содержимому.

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

phantom-84 писал(а):
Существует вероятность появления двух одинаковых идентификаторов.

Существует. Однако 1) она мала и 2) ничто не мешает принудительно разнести совпадающие идентификаторы.

phantom-84 писал(а):
Что так? Ты же заполняешь базовую память под завязку. А как это сделать, точно не зная границу доступной (базовой) памяти сверху?

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

phantom-84 писал(а):
Не понял. А если у тебя в корне лежит стометровый файл ядра? Как загрузчик его будет грузить?

:))) а с чего бы в корне лежал 100-метровый файл ядра, если чётко сказано - 608к? Только если 1) файловая система попорчена или 2) пользователь вышел за рамки спецификаций. И то, и другое - однозначно Achtung!

phantom-84 писал(а):
Теперь понятно, но написано все равно не очень складно - может показаться, что файлы меньшего размера нельзя грузить вообще.

ОК, принято. Сформулирую более внятно в ближайшем же обновлении.

phantom-84 писал(а):
Я не понял, откуда при адресе загрузке 600h у тебя взялись 32 кб? Ты что ли используешь участок в конце базовой памяти? А как же EBDA?

32к сверху. Я релокирую бут-код вверх. А что EBDA? EBDA мне не мешает. Я эту область не трогаю :)

phantom-84 писал(а):
Если почти всю базовую память занимает загруженный образ, то о каком удобстве вообще идет речь.

Если всю, то переходи в защищённый режим и используй остальную память. Если не всю, то и базовую память можно нормально использовать. В любом случае, зачем терять кусок памяти, ниже базы загрузки? Его надо впоследствии криво мапировать, либо накладывать на него какие-то переменные (тоже криво). 600h - это первый реально свободный байт, и то, что туда помещается начало пользовательской ОС, выглядит вполне естественным.

phantom-84 писал(а):
Получается, чтобы загрузить ядро размером больше 7C00h-600h, тебе сначала нужно переместить загрузчик.

Нормально перемещается. Нет проблем.

phantom-84 писал(а):
Это искусственное ограничение исключительно положительное. Кратность размера файла ядра 1 кб является одним из первичных признаков его корректности (есть еще и сигнатура в конце), который может быть проверен уже на этапе работы первичного загрузчика (я бы и проверку контрольной суммы вынес в первичный загрузчик, но наличие у файла ядра контрольной суммы не описано в загрузочной спецификации).

1. Посмотрел на файл NTLDR на одном из дисков. Размер - 297072. Ничему не кратен.
2. Не вижу серьёзной причины для введения кратности. Но если уж так хочется, не пойму, чем база 600h помешала? Да хоть и 123h :)
3. Если кратность размера файла по каким-то необъяснимым причинам завязана с кратностью памяти, то в чём принципиальное отличие кратности 1024 от 512? Магия чисел? А по мне, так лучше 512. В размер сектора.
4. Не дело это первичного загрузчика, проверять кратность и сигнатуры. Его задача - загрузить файл и передать на него управление. В конце концов, ИМХО, лучше будет, если стартап-код в начале образа сам проверить свою контрольную сумму и полноту загрузки.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 351 ]  На страницу 1, 2, 3, 4, 5 ... 36  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB