говори ник, отсыплю.fog wrote:У кого есть карма на хабре?
Выпуск новостей ReactOS №…
Re: Newsletter
Newsletter 44
ReactOS Newsletter - Newsletter 44 (#44), от Z98, 2008-08-06
Процесс разработки
Снова вернулся интересный баг, проявляющийся при создании хендла. При создании 4100-го хендла, система падает. Этот баг был обнаружен при использовании VLC и был в конечном счёте исправлен Кристофом фон Виттичем. Проблема заключалась в неверных вычислениях, когда код пытался получить доступ к индексу более, чем 4099 в первой таблице. Верные значения - выходят за её границы и предполагается их искать во второй таблице и выше. Теперь система упадёт не раньше создания 4186000 хендла. Этого должно быть достаточно для большинства случаев.
Алексей Брагин работает над добавлением утилиты проверки файловой системы в ReactOS. Учитывая дефицит безопасности FAT, это должно быть весьма полезным дополнением. Утилиты chkdsk, format и autochk - являются лишь обёртками к функциям библиотек для файловых систем, таких как ufat.dl и untfs.dll, которые предоставляют нужные функции для форматирования и проверки дисков. Библиотеки взаимодействуют с их оболочками через fmifs.dll, интерфейс которой хорошо известен.
Кроме этих трёх утилит, Алексей также окончил портирование dosfsck, начатое Стивеном Эдвардсом и Майком Норделлом. Этот порт уже в транке и функционирует, пока Алексей добивается работы autochk и ufat.dll в своей рабочей копии. Видно работа идёт скорее гладко, поскольку мы должны скоро увидеть результаты.
Последнее, но не по важности, Тимо Крейцер работал над исправлением некоторых вычислений с плавающей точкой в ядре Win32. В архитектуре x86 данные при операциях переключения контекста не сохранялись при работе в режиме ядра. Тем не менее, по неким причинам все вычисления с плавающей точкой в win32k были написаны с использованием FPU. Тимо полностью переписал структуры данных для того, чтобы не использовать FPU и почти готов их представить.
_____________________________________________________________
Конвенция Linuxworld
Как ни удивительно, ReactOS на Linuxworld разделяет стенд с разработчиками Haiku, и мы более чем рады, поделиться местом для экспозиции именно с этим проектом. К сожалению, Арт Йеркес (Art Yerkes) - наш единственный разработчик, который там будет присутствовать, так как находится ближе географически и располагает необходимым количеством времени. Так что - уверенно ищите стенд ReactOS и составьте ему компанию.
_____________________________________________________________
Обновление ARM
Команда ARM немало проделала с того момента, как я говорил о них в прошлый раз и теперь я один бьюсь над списком изменений для релизов, я охвачен идеей всё это завершить. Они добавили немалое количество кода, готовящего ReactOS к загрузке на ARM и внесли немало исправлений в процессе. Их работа над менеджером памяти особенно ценна, как над одним из слабых мест в коде ReactOS. На их фоне все мы(остальные) выглядим не очень впечатляюще, учитывая количество исправлений, которые они внесли.
Шаги, предпринятые командой ARM, обеспечили, в первую очередь, уверенность, что код будет компилироваться для ARM. Здесь следует решать проблему фактической загрузки, которая требует модификации Freeloader для запуска на платформе и с процессором ARM. После обнаружения ядра(при загрузке), будет возможно получать вывод по отладочному COM-порту, чтобы можно было видеть, чего не хватает для запуска. На данном этапе, дальнейшее движение без этого невозможно. После применения неких хаков-ухищрений, ARM команда реализовала, как следует, отладку, хотя и не без некоторых жалоб на этом пути.
Для фактического запуска, операционная система нуждается в управлении своими ресурсами, включая процессорное время и память. В основном, весь код, реализующий перехват прерываний и разделение времени должен быть переписан, чтобы ОС могла реально сообщать, когда что-либо произойдёт или когда она должна что-нибудь сделать. Что касается менеджера памяти, они находили одну запутанную ошибку за другой, тайно злорадствуя над этим. Но, так как они исправили их, мы их прощаем.
Сейчас, команда ARM работает над тем, чтобы привести в рабочее состояние свой порт для возможности использовать загрузкочное устройство, другими словами - рамдиск(виртуальный диск в оперативной памяти). Кроме написания нового драйвера для рамдиска и исправлений в CDFS и в собственном FAT драйвере, также они возвращаются к менеджеру памяти, для исправления или расширения функциональности, нужной им для выполнения рамдиска. Ещё несколько новых жалоб, возникших с тех пор, вероятно, означают, что они добиваются прогресса в упрощении и исправлении кода.
Следующим шагом, по которому они уже сделали некоторые предварительные работы, становится пользовательский режим загрузки и работы. Я желаю им удачи и в дальнейшем буду наблюдать за их будущей работой. Даже если это будет означать потерю нескольких часов создания списка их изменений.
_____________________________________________________________
Портирование на 64-разрядную архитектуру
Не буду слишком обнадёживать, так как есть много препятствий, которые нужно пройти перед тем, как можно будет говорить о каких-либо существенных продвижениях. Тимо Крейцер разбирается со средой разработки ROSBE для 64-разрядности некоторое время, как и Самуэль Серафион, теоретически - второй автор выпусков новостей, моя копия. Сэм начал работать над возможностью компиляции и прочего для ядра, freeldr, библиотеки C, нескольких драйверов, нескольких приложений пользовательского режима
и всех заголовочных файлов, от которых зависит компиляция. Для Win32k компиляция не удаётся, поэтому нам есть, куда двигаться. Сейчас, freeldr должен загружать ядро, но всё проваливается на ранних этапах инициализации. Здесь нужна масса кода, который просто отсутствует и мы не можем изменять менеджер памяти для работы в расширенном(x64) режиме. Это, наверняка, будет долгий и трудный путь.
_____________________________________________________________
Больше новых людей
Ну, относительно новых. Стефан Гинсберг бродил по каналу под именем Stefan100. Он крутился рядом несколько месяцев и зарывался в код ядра, докучая разным разработчикам. В процессе, Стефан находил несколько небольших ошибок и даже несколько крупных, обеспечивая к ним заплатки. Ему был предоставлен доступ и он занимается, в основном, исправлением ошибок, где находится область его интересов.
Другая личность, получившая доступ на внесение изменений это Кэмерон Гутман, известный как aircommander на канале. Его доступ на изменение несколько отличается, как доступ к ветке, предназначенной для поиска и исправления проблем в коде реализации сетевого доступа. Иногда он запускает сервер, установленный на ReactOS для проверки стрессоустойчивости, хотя он не выживает и часа, если повезет. Хотя немногие исправления были внесены в транк, они не укладываются в сроки, позволяющие выпуститься в ветке 0.3.6.
В заключение, всё выглядит так, что Самуэль остаётся слишком занятым, чтобы не иметь возможности также заниматься написанием новостей. Как упоминалось выше, он работает над портом x64. Его доступ - также к отдельной ветке, которую он использует для портирования на архитектуру x64. Кто знает, быть может и я присоединюсь ради развлечения и действительно сделаю что-то реально работающее.
***
LRN, моя очередь
Спасибо fog, jedi-to-be, virus126, hto за помощь в коррекции и русификации перевода
Процесс разработки
Снова вернулся интересный баг, проявляющийся при создании хендла. При создании 4100-го хендла, система падает. Этот баг был обнаружен при использовании VLC и был в конечном счёте исправлен Кристофом фон Виттичем. Проблема заключалась в неверных вычислениях, когда код пытался получить доступ к индексу более, чем 4099 в первой таблице. Верные значения - выходят за её границы и предполагается их искать во второй таблице и выше. Теперь система упадёт не раньше создания 4186000 хендла. Этого должно быть достаточно для большинства случаев.
Алексей Брагин работает над добавлением утилиты проверки файловой системы в ReactOS. Учитывая дефицит безопасности FAT, это должно быть весьма полезным дополнением. Утилиты chkdsk, format и autochk - являются лишь обёртками к функциям библиотек для файловых систем, таких как ufat.dl и untfs.dll, которые предоставляют нужные функции для форматирования и проверки дисков. Библиотеки взаимодействуют с их оболочками через fmifs.dll, интерфейс которой хорошо известен.
Кроме этих трёх утилит, Алексей также окончил портирование dosfsck, начатое Стивеном Эдвардсом и Майком Норделлом. Этот порт уже в транке и функционирует, пока Алексей добивается работы autochk и ufat.dll в своей рабочей копии. Видно работа идёт скорее гладко, поскольку мы должны скоро увидеть результаты.
Последнее, но не по важности, Тимо Крейцер работал над исправлением некоторых вычислений с плавающей точкой в ядре Win32. В архитектуре x86 данные при операциях переключения контекста не сохранялись при работе в режиме ядра. Тем не менее, по неким причинам все вычисления с плавающей точкой в win32k были написаны с использованием FPU. Тимо полностью переписал структуры данных для того, чтобы не использовать FPU и почти готов их представить.
_____________________________________________________________
Конвенция Linuxworld
Как ни удивительно, ReactOS на Linuxworld разделяет стенд с разработчиками Haiku, и мы более чем рады, поделиться местом для экспозиции именно с этим проектом. К сожалению, Арт Йеркес (Art Yerkes) - наш единственный разработчик, который там будет присутствовать, так как находится ближе географически и располагает необходимым количеством времени. Так что - уверенно ищите стенд ReactOS и составьте ему компанию.
_____________________________________________________________
Обновление ARM
Команда ARM немало проделала с того момента, как я говорил о них в прошлый раз и теперь я один бьюсь над списком изменений для релизов, я охвачен идеей всё это завершить. Они добавили немалое количество кода, готовящего ReactOS к загрузке на ARM и внесли немало исправлений в процессе. Их работа над менеджером памяти особенно ценна, как над одним из слабых мест в коде ReactOS. На их фоне все мы(остальные) выглядим не очень впечатляюще, учитывая количество исправлений, которые они внесли.
Шаги, предпринятые командой ARM, обеспечили, в первую очередь, уверенность, что код будет компилироваться для ARM. Здесь следует решать проблему фактической загрузки, которая требует модификации Freeloader для запуска на платформе и с процессором ARM. После обнаружения ядра(при загрузке), будет возможно получать вывод по отладочному COM-порту, чтобы можно было видеть, чего не хватает для запуска. На данном этапе, дальнейшее движение без этого невозможно. После применения неких хаков-ухищрений, ARM команда реализовала, как следует, отладку, хотя и не без некоторых жалоб на этом пути.
Для фактического запуска, операционная система нуждается в управлении своими ресурсами, включая процессорное время и память. В основном, весь код, реализующий перехват прерываний и разделение времени должен быть переписан, чтобы ОС могла реально сообщать, когда что-либо произойдёт или когда она должна что-нибудь сделать. Что касается менеджера памяти, они находили одну запутанную ошибку за другой, тайно злорадствуя над этим. Но, так как они исправили их, мы их прощаем.
Сейчас, команда ARM работает над тем, чтобы привести в рабочее состояние свой порт для возможности использовать загрузкочное устройство, другими словами - рамдиск(виртуальный диск в оперативной памяти). Кроме написания нового драйвера для рамдиска и исправлений в CDFS и в собственном FAT драйвере, также они возвращаются к менеджеру памяти, для исправления или расширения функциональности, нужной им для выполнения рамдиска. Ещё несколько новых жалоб, возникших с тех пор, вероятно, означают, что они добиваются прогресса в упрощении и исправлении кода.
Следующим шагом, по которому они уже сделали некоторые предварительные работы, становится пользовательский режим загрузки и работы. Я желаю им удачи и в дальнейшем буду наблюдать за их будущей работой. Даже если это будет означать потерю нескольких часов создания списка их изменений.
_____________________________________________________________
Портирование на 64-разрядную архитектуру
Не буду слишком обнадёживать, так как есть много препятствий, которые нужно пройти перед тем, как можно будет говорить о каких-либо существенных продвижениях. Тимо Крейцер разбирается со средой разработки ROSBE для 64-разрядности некоторое время, как и Самуэль Серафион, теоретически - второй автор выпусков новостей, моя копия. Сэм начал работать над возможностью компиляции и прочего для ядра, freeldr, библиотеки C, нескольких драйверов, нескольких приложений пользовательского режима
и всех заголовочных файлов, от которых зависит компиляция. Для Win32k компиляция не удаётся, поэтому нам есть, куда двигаться. Сейчас, freeldr должен загружать ядро, но всё проваливается на ранних этапах инициализации. Здесь нужна масса кода, который просто отсутствует и мы не можем изменять менеджер памяти для работы в расширенном(x64) режиме. Это, наверняка, будет долгий и трудный путь.
_____________________________________________________________
Больше новых людей
Ну, относительно новых. Стефан Гинсберг бродил по каналу под именем Stefan100. Он крутился рядом несколько месяцев и зарывался в код ядра, докучая разным разработчикам. В процессе, Стефан находил несколько небольших ошибок и даже несколько крупных, обеспечивая к ним заплатки. Ему был предоставлен доступ и он занимается, в основном, исправлением ошибок, где находится область его интересов.
Другая личность, получившая доступ на внесение изменений это Кэмерон Гутман, известный как aircommander на канале. Его доступ на изменение несколько отличается, как доступ к ветке, предназначенной для поиска и исправления проблем в коде реализации сетевого доступа. Иногда он запускает сервер, установленный на ReactOS для проверки стрессоустойчивости, хотя он не выживает и часа, если повезет. Хотя немногие исправления были внесены в транк, они не укладываются в сроки, позволяющие выпуститься в ветке 0.3.6.
В заключение, всё выглядит так, что Самуэль остаётся слишком занятым, чтобы не иметь возможности также заниматься написанием новостей. Как упоминалось выше, он работает над портом x64. Его доступ - также к отдельной ветке, которую он использует для портирования на архитектуру x64. Кто знает, быть может и я присоединюсь ради развлечения и действительно сделаю что-то реально работающее.
***
LRN, моя очередь
Спасибо fog, jedi-to-be, virus126, hto за помощь в коррекции и русификации перевода
Last edited by bz00mmer on Thu Aug 07, 2008 10:38 am, edited 5 times in total.
Re: Newsletter
Процесс разработки
Снова вернулась интересная ошибка, связанная с созданием хендла. Систему роняет появление 4100-го хендла. Эта ошибка была обнаружена при использовании VLC и, в итоге, исправлена Кристофом фон Виттичем (Christoph von Wittich). Проблема заключалась в неверном вычислении индекса, код пытался получить доступ к указателю более, чем 4099 в первой таблице. Правильные значения выходят за её границы и предполагается, что их нужно искать во второй таблице или ещё выше. Теперь система упадёт не раньше создания 4186000 хендла. Этого должно быть покачто достаточно.
Алексей Брагин (Aleksey Bragin) работает над добавлением средств проверки файловой системы в ReactOS. Учитывая слабую надёжность FAT, это должно стать весьма полезным дополнением. Утилиты chkdsk, format и autochk - являются лишь обёртками к функциям библиотек для файловых систем, таких как ufat.dll и untfs.dll, которые и предоставляют нужные функции для форматирования и проверки дисков. Библиотеки взаимодействуют с этими утилитами через fmifs.dll, интерфейс которой хорошо известен.
Кроме этих трёх утилит, Алексей также окончил портирование dosfsck, начатое Стивеном Эдвардсом (Steven Edwards) и Майком Норделлом (Mike Nordell). Этот порт уже в транке и функционирует, а Алексей пытается заставить работать autochk и ufat.dll в своей рабочей копии. Видимо, работа идёт не плохо и мы скоро увидим результаты.
И последняя, но немаловажная, новость. Тимо Крейцер (Timo Kreuzer) занимается исправлением работы некоторых операций с плавающей точкой в ядре Win32. В архитектуре x86, данные операций с плавающей точкой не сохранялись при переключении контекста в режим ядра. Тем не менее, по неким причинам все вычисления с плавающей точкой в win32k были написаны с использованием FPU. Тимо полностью переписал структуры данных для того, чтобы не использовать FPU и почти готов их представить.
Linuxworld'ская конвенция.
Как ни удивительно, ReactOS на Linuxworld разделяет стенд с разработчиками Haiku, и мы более чем рады, поделиться местом для экспозиции именно с этим проектом. К сожалению, Арт Йеркес (Art Yerkes) - наш единственный разработчик, который там будет присутствовать - т.к. находится географически близко и располагает необходимым количеством времени. Так что - уверенно ищите стенд ReactOS и составьте ему компанию.
Обновление ARM
Команда ARM сделала достаточно, с того момента, как я говорил о них в прошлый раз и теперь я один бьюсь над списком изменений для релизов, я охвачен идеей всё это завершить. Они добавили много нового кода, подготавливающего ReactOS к загрузке на ARM и внесли немало исправлений в уже имеющийся код. Их работа над менеджером памяти особенно ценна, так как это одно из слабых мест в коде ReactOS. На их фоне все мы (остальные) выглядим не очень впечатляюще, учитывая количество исправлений, которые они внесли.
Шаги, предпринятые командой ARM, обеспечивают, в первую очередь, компилирование исходного кода для ARM платформы. Теперь следует решить задачу фактической загрузки, которая требует модификации Freeloader (загрузчика) для запуска. После инициализации ядра, будет возможно получить на COM-порт информацию, необходимую для отладки, тем самым найти и устранить неисправности. На данном этапе, продолжение разработки без вышеописанных шагов невозможно. После применения некоторых ухищрений, ARM команда имплементировала систему отладки, хотя и не без "подводных камней".
Для фактического запуска, операционная система нуждается в управлении имеющимися физическими ресурсами (памятью, процессором ит.п.). В основном, весь код, управляющий прерываниями и таймингами должен быть адаптирован для ARM платформы, чтобы ОС могла управлять событиями и делать что либо при их появлении. Что касается менеджера памяти, они нашли и исправили несколько весьма неприятных ошибок.
Сейчас, команда ARM работает над тем, чтобы порт мог использовать загрузочное устройство, например, рамдиск (виртуальный диск в оперативной памяти). Кроме работы над новым драйвером для рамдиска и исправлений в CDFS и FAT (драйвера файловых систе? они также работают над менеджером памяти, для исправления и расширения функциональности, нужной для правильной имплементации рамдиск-драйвера. Изменения исходном коде также позваляют предположить, что команда ARM успешно работает над исправлением и рефракторингом старого кода.
Следующим шагом, является инициализация частей ОС, работающих в пользовательском режиме, хотя и сейчас в этой области замечен прогресс. Я желаю им удачи и в дальнейшем буду наблюдать за их работой. Даже если это будет означать потерю нескольких часов создания списка изменений, которые они внесли за прошедшее время.
Портирование на 64-разрядную архитектуру
Не буду слишком обнадёживать, так как есть много препятствий, которые нужно преодолеть перед тем, как можно будет говорить о каких-либо существенных продвижениях. Тимо Крейцер (Timo Kreuzer) уже некоторое время занимается подготовкой окружения для сборки 64-битного порта ReactOS, он дал мне и Самуэлю Серафион'у (Samuel Serapion), соавтору этого выпуска новостей, копии своих наработок. Сэм сейчас пытается собрать систему, а именно ядро, freeldr, CRT, и небольшого числа необходимых драйверов, и некоторых приложений пользовательского режима, а так же всех заголовочных файлов, от которых зависит компиляция. Не смотря на это компиляция Win32k обрывается на полпути, поэтому нам есть, куда двигаться. На данный момент, freeldr загружает ядро, но его загрузка заканчивается неудачей, в самом начале инициализации. Нам не хватает немного кода, и мы даже не начинали изменять менеджер памяти для работы с длинными (8-ми байтовыми) указателями. Но определённо можно сказать, это будет длинный и тяжёлый путь.
Снова вернулась интересная ошибка, связанная с созданием хендла. Систему роняет появление 4100-го хендла. Эта ошибка была обнаружена при использовании VLC и, в итоге, исправлена Кристофом фон Виттичем (Christoph von Wittich). Проблема заключалась в неверном вычислении индекса, код пытался получить доступ к указателю более, чем 4099 в первой таблице. Правильные значения выходят за её границы и предполагается, что их нужно искать во второй таблице или ещё выше. Теперь система упадёт не раньше создания 4186000 хендла. Этого должно быть покачто достаточно.
Алексей Брагин (Aleksey Bragin) работает над добавлением средств проверки файловой системы в ReactOS. Учитывая слабую надёжность FAT, это должно стать весьма полезным дополнением. Утилиты chkdsk, format и autochk - являются лишь обёртками к функциям библиотек для файловых систем, таких как ufat.dll и untfs.dll, которые и предоставляют нужные функции для форматирования и проверки дисков. Библиотеки взаимодействуют с этими утилитами через fmifs.dll, интерфейс которой хорошо известен.
Кроме этих трёх утилит, Алексей также окончил портирование dosfsck, начатое Стивеном Эдвардсом (Steven Edwards) и Майком Норделлом (Mike Nordell). Этот порт уже в транке и функционирует, а Алексей пытается заставить работать autochk и ufat.dll в своей рабочей копии. Видимо, работа идёт не плохо и мы скоро увидим результаты.
И последняя, но немаловажная, новость. Тимо Крейцер (Timo Kreuzer) занимается исправлением работы некоторых операций с плавающей точкой в ядре Win32. В архитектуре x86, данные операций с плавающей точкой не сохранялись при переключении контекста в режим ядра. Тем не менее, по неким причинам все вычисления с плавающей точкой в win32k были написаны с использованием FPU. Тимо полностью переписал структуры данных для того, чтобы не использовать FPU и почти готов их представить.
Linuxworld'ская конвенция.
Как ни удивительно, ReactOS на Linuxworld разделяет стенд с разработчиками Haiku, и мы более чем рады, поделиться местом для экспозиции именно с этим проектом. К сожалению, Арт Йеркес (Art Yerkes) - наш единственный разработчик, который там будет присутствовать - т.к. находится географически близко и располагает необходимым количеством времени. Так что - уверенно ищите стенд ReactOS и составьте ему компанию.
Обновление ARM
Команда ARM сделала достаточно, с того момента, как я говорил о них в прошлый раз и теперь я один бьюсь над списком изменений для релизов, я охвачен идеей всё это завершить. Они добавили много нового кода, подготавливающего ReactOS к загрузке на ARM и внесли немало исправлений в уже имеющийся код. Их работа над менеджером памяти особенно ценна, так как это одно из слабых мест в коде ReactOS. На их фоне все мы (остальные) выглядим не очень впечатляюще, учитывая количество исправлений, которые они внесли.
Шаги, предпринятые командой ARM, обеспечивают, в первую очередь, компилирование исходного кода для ARM платформы. Теперь следует решить задачу фактической загрузки, которая требует модификации Freeloader (загрузчика) для запуска. После инициализации ядра, будет возможно получить на COM-порт информацию, необходимую для отладки, тем самым найти и устранить неисправности. На данном этапе, продолжение разработки без вышеописанных шагов невозможно. После применения некоторых ухищрений, ARM команда имплементировала систему отладки, хотя и не без "подводных камней".
Для фактического запуска, операционная система нуждается в управлении имеющимися физическими ресурсами (памятью, процессором ит.п.). В основном, весь код, управляющий прерываниями и таймингами должен быть адаптирован для ARM платформы, чтобы ОС могла управлять событиями и делать что либо при их появлении. Что касается менеджера памяти, они нашли и исправили несколько весьма неприятных ошибок.
Сейчас, команда ARM работает над тем, чтобы порт мог использовать загрузочное устройство, например, рамдиск (виртуальный диск в оперативной памяти). Кроме работы над новым драйвером для рамдиска и исправлений в CDFS и FAT (драйвера файловых систе? они также работают над менеджером памяти, для исправления и расширения функциональности, нужной для правильной имплементации рамдиск-драйвера. Изменения исходном коде также позваляют предположить, что команда ARM успешно работает над исправлением и рефракторингом старого кода.
Следующим шагом, является инициализация частей ОС, работающих в пользовательском режиме, хотя и сейчас в этой области замечен прогресс. Я желаю им удачи и в дальнейшем буду наблюдать за их работой. Даже если это будет означать потерю нескольких часов создания списка изменений, которые они внесли за прошедшее время.
Портирование на 64-разрядную архитектуру
Не буду слишком обнадёживать, так как есть много препятствий, которые нужно преодолеть перед тем, как можно будет говорить о каких-либо существенных продвижениях. Тимо Крейцер (Timo Kreuzer) уже некоторое время занимается подготовкой окружения для сборки 64-битного порта ReactOS, он дал мне и Самуэлю Серафион'у (Samuel Serapion), соавтору этого выпуска новостей, копии своих наработок. Сэм сейчас пытается собрать систему, а именно ядро, freeldr, CRT, и небольшого числа необходимых драйверов, и некоторых приложений пользовательского режима, а так же всех заголовочных файлов, от которых зависит компиляция. Не смотря на это компиляция Win32k обрывается на полпути, поэтому нам есть, куда двигаться. На данный момент, freeldr загружает ядро, но его загрузка заканчивается неудачей, в самом начале инициализации. Нам не хватает немного кода, и мы даже не начинали изменять менеджер памяти для работы с длинными (8-ми байтовыми) указателями. Но определённо можно сказать, это будет длинный и тяжёлый путь.
News #45
ReactOS 0.3.6
Новый релиз операционной системы ReactOS
Выпущен ReactOS 0.3.6
Спустя чуть больше месяца после версии 0.3.5 мы аннонсируем релиз ReactOS 0.3.6.
Этот релиз, как и серия 0.3.x, продолжает оставаться в альфа-стадии ПО, а потому, не следует ожидать слишком многого.
Версия ReactOS 0.3.6 это результат концентрации разработчиков на исправлении ошибок, совместимости и стабильности. В этом месяце в репозиторий ReactOS было внесено более тысячи правок.
Обзор изменений
Консолидация всех изменений с подробностями может быть найдена в списке изменений. Резюме наиболее важных изменений:
- Поддержка большего числа архитектур: улучшения версии для ARM, начало поддержки архитектуры x64
- Сокращены требования к памяти FreeLdr для загрузки ReactOS
- Теперь стала возможной выгрузка драйверов
- Многочисленные улучшения и исправления ядра (вопросы передачи в APC, таймеров, большой объём работы над аппаратно-независимой частью менеджера памяти)
- Доступно больше приложений Win32 для выполнения благодаря исправлению реализации кучи в библиотеке RTL (например, программы установки, базирующиеся на InnoSetup, приложения Delphi и т.д.)
- Исправление сетевого стека и исключение утечек памяти
- Улучшения подсистемы Win32, большинство библиотек пользовательского уровня синхронизированы с Wine
Новый релиз операционной системы ReactOS
Выпущен ReactOS 0.3.6
Спустя чуть больше месяца после версии 0.3.5 мы аннонсируем релиз ReactOS 0.3.6.
Этот релиз, как и серия 0.3.x, продолжает оставаться в альфа-стадии ПО, а потому, не следует ожидать слишком многого.
Версия ReactOS 0.3.6 это результат концентрации разработчиков на исправлении ошибок, совместимости и стабильности. В этом месяце в репозиторий ReactOS было внесено более тысячи правок.
Обзор изменений
Консолидация всех изменений с подробностями может быть найдена в списке изменений. Резюме наиболее важных изменений:
- Поддержка большего числа архитектур: улучшения версии для ARM, начало поддержки архитектуры x64
- Сокращены требования к памяти FreeLdr для загрузки ReactOS
- Теперь стала возможной выгрузка драйверов
- Многочисленные улучшения и исправления ядра (вопросы передачи в APC, таймеров, большой объём работы над аппаратно-независимой частью менеджера памяти)
- Доступно больше приложений Win32 для выполнения благодаря исправлению реализации кучи в библиотеке RTL (например, программы установки, базирующиеся на InnoSetup, приложения Delphi и т.д.)
- Исправление сетевого стека и исключение утечек памяти
- Улучшения подсистемы Win32, большинство библиотек пользовательского уровня синхронизированы с Wine
-
- Posts: 706
- Joined: Sun Mar 16, 2008 11:26 am
- Location: Russia, Stavropol
- Contact:
Re: Newsletter
На их фоне остальные из нас (все мы) выглядим не очень впечатляюще, учитывая количество исправлений, которые они отправили (сделали)Вместе с всеми исправлениями, которые они внесли и всему действительно сделанному их отдых смотрится плохо.
Re: News #45
Поискал по словам USB и Sound, но ничего не нашёл. Жаль.bz00mmer wrote:Консолидация всех изменений с подробностями может быть найдена в списке изменений.
А сам Дельфи заработал, нет?bz00mmer wrote:- Доступно больше приложений Win32 для выполнения благодаря исправлению реализации кучи в библиотеке RTL (например, программы установки, базирующиеся на InnoSetup, приложения Delphi и т.д.)
Re: Newsletter 44
Команда ARM проделала немного с того момента, как я говорил о них в прошлый разbz00mmer wrote:Команда ARM проделала немного, как я говорил в прошлый раз
// фигассе, релиз пришёлся прям на мою днюху %)
Last edited by virus126 on Thu Aug 07, 2008 8:58 am, edited 1 time in total.
Re: Newsletter
Надо проверить и написать сюда и сюда...Ozarnik wrote: А сам Дельфи заработал, нет?
The ARM team has done quite a bit since I last mentioned themvirus126 wrote:Команда ARM проделала немного с того момента, как я говорил о них в прошлый разbz00mmer wrote: Команда ARM проделала немного, как я говорил в прошлый раз
Re: Newsletter
словари.яндекс: quite a bit — значительное количествоhto wrote:The ARM team has done quite a bit since I last mentioned them
гугль: quite a bit — совсем немного
кому верить?
-
- Posts: 706
- Joined: Sun Mar 16, 2008 11:26 am
- Location: Russia, Stavropol
- Contact:
Re: Newsletter
Верь Яндексу.
Re: Newsletter
Судя по количеству их коммитов и по тексту ниже - прав Яндекс.
Поправлю, разумеется.
Поправлю, разумеется.
Re: Newsletter
Свежие новости, 45й выпуск
Вкратце о Art Yerkes: побывал на ЛинуксВорлд, пописАл Common Cache, обнаружил проблему в РОС.
Перевод 44х, кстати, по-прежнему отсутствует в русских новостях,
а о релизе uncorr свой перевод писал. Бардак.
зы как и обещал в Vacancies, представлю мануалы на неделе...
Вкратце о Art Yerkes: побывал на ЛинуксВорлд, пописАл Common Cache, обнаружил проблему в РОС.
Перевод 44х, кстати, по-прежнему отсутствует в русских новостях,
а о релизе uncorr свой перевод писал. Бардак.
зы как и обещал в Vacancies, представлю мануалы на неделе...
Перевод Newsletter
http://translated.by/you/reactos-newsletter-46/
Помогайте, критикуйте. Предлагаю публиковать перевод через 24 часа после перевода всех абзацев или трёх вычиток.
Помогайте, критикуйте. Предлагаю публиковать перевод через 24 часа после перевода всех абзацев или трёх вычиток.
Re: Newsletter
№45
Рапорт с LinuxWorld
На пошлой неделе Art Yerkes представлял ReactOS на выставке Linux World в Калифорнии. К сожелению он был единственным членом комьюнити, который смог приехать, но всё прошло достаточно успешно. Во время подготовки к выставке Art'ом была найдена ошибка, которой я займусь позже. Эта непринятнось вынудила его использовать для публичной презентации ReactOS эмулятор QEMU. Можество людей (среди которых были и пользователи ОС Линукс) заинтересовалось ReactOS. Была продемонстрированна работа программ Abiword, Firefox (с html файлами, т.к. отсуствовало интернет подключение на стенде), WinRAR, 7zip, the LMarbles и xemacs.
Art встретил несколько журналистов из Ars Technica и из Alternageek. Результатом стал видеорепортаж, который можно посмотретть тут: http://alternageek.com/linuxworldexpo/a ... orld-2008/ . Так же Art познакомился с Hans Peter Anvin, который заинтересовался нашим winldr загрузчиком, для того чтобы внедрить его в SYSLINUX.
СС (кеш менеджер)
Работа над СС началась давно, как то я уже рассказывал о Алексее Брагине и его NoCc ветке в репозитории. И вот теперь Art Yerkes взялся за эту работу и в основном закончил извлечение СС из Менеджера Памяти. Главной проблемой на данный момент являются общие структуры. Оба модуля работают с этими структурами, но проблема в том, что СС напрямую этого делать не должен. Соответствующее разделение позволит СС модуля опираться в своей работе лишь на интерфейсы предоставляемые ММ (менеджером памяти). Сейчас же СС использует обьекты ММ для построения кеша.
Схема работы кеша, над которой сейчас работает Art, очень проста. Для людей не знакомых с алгоритмами менеджмента памяти "clock" алгоритм это э
For people not familiar with memory management algorithms, the clock algorithm is basically where the entries of the cache are in a list and are walked by a 'hand' whenever the need arises to find a free spot. The entries themselves are marked with a flag that determines whether the hand will evict that entry for use. Every time the clock encounters a marked entry, it will unmark it so that the next time it is encountered the hand gets to free it. This is a simplistic explanation, but should get the idea across. Many variations exist, some with multiple hands and others with varying levels of priority for each entry.
The one Art is implementing is just a one handed clock cache and in this instance the hand also cannot unmark any of the entries. Not surprisingly, this means the system needs to wait for the application to unmark its entry or else the entire system crashes. The hand in this instance only traverses the unmarked entries when looking for a free spot for new entries. The entire cache is described by a bitmap and the unmarked entries are zeroes in the bitmap, which is how the hand knows which entries to go to next.
Однако эта работа сделана и Artу ножно разделить СС и ММ компоненты системы. В данный момент Artу заниается тем, что исследует различные компоненты (включая ММ и драйвера файловых систем) на предмет зависимости от СС модуля. Art уже начал добавлять код в специально выделенную ему ветку в репозитории, следовательно желающие ему помощь уже могут действовать. Но должно пройти немнго времени, прежде чем всё начнёт работать как запланировано.
Причуды установки ReactOS
Проще гопоря, ReactOS при установке ведёт себя неправильно, например не проверяет является ли установочным диском раздел, с которого бдудут скопированы файлы, возврвщаят неправильный раздел для установочного диска, если присувствует ещё один раздел на диске, и использует даже те разделы, которые обозначены, как "в использовании".
Упомянутая выше ошибка связана с неправильным присвоением буквы к диску и выражается в падении истановщика. Именно с этой ошибкой встретился Art при установке на ext2 раздел, когда готовил презентацию к выставке. Описаные проблемы могут возникнуть и в других ситуациях, но если ваша система сконфигурирована подобным образом, это будут первые ошибки с которыми вы столкнётесь. К сожалению, ошибки частично зависиеы друг от друга, по-этому, чтоб исправить вторую ошибку надо хотя бы частично устранить первую. Последняя описаная ошибка проблем с исправлением вызвать не должна.
Рапорт с LinuxWorld
На пошлой неделе Art Yerkes представлял ReactOS на выставке Linux World в Калифорнии. К сожелению он был единственным членом комьюнити, который смог приехать, но всё прошло достаточно успешно. Во время подготовки к выставке Art'ом была найдена ошибка, которой я займусь позже. Эта непринятнось вынудила его использовать для публичной презентации ReactOS эмулятор QEMU. Можество людей (среди которых были и пользователи ОС Линукс) заинтересовалось ReactOS. Была продемонстрированна работа программ Abiword, Firefox (с html файлами, т.к. отсуствовало интернет подключение на стенде), WinRAR, 7zip, the LMarbles и xemacs.
Art встретил несколько журналистов из Ars Technica и из Alternageek. Результатом стал видеорепортаж, который можно посмотретть тут: http://alternageek.com/linuxworldexpo/a ... orld-2008/ . Так же Art познакомился с Hans Peter Anvin, который заинтересовался нашим winldr загрузчиком, для того чтобы внедрить его в SYSLINUX.
СС (кеш менеджер)
Работа над СС началась давно, как то я уже рассказывал о Алексее Брагине и его NoCc ветке в репозитории. И вот теперь Art Yerkes взялся за эту работу и в основном закончил извлечение СС из Менеджера Памяти. Главной проблемой на данный момент являются общие структуры. Оба модуля работают с этими структурами, но проблема в том, что СС напрямую этого делать не должен. Соответствующее разделение позволит СС модуля опираться в своей работе лишь на интерфейсы предоставляемые ММ (менеджером памяти). Сейчас же СС использует обьекты ММ для построения кеша.
Схема работы кеша, над которой сейчас работает Art, очень проста. Для людей не знакомых с алгоритмами менеджмента памяти "clock" алгоритм это э
For people not familiar with memory management algorithms, the clock algorithm is basically where the entries of the cache are in a list and are walked by a 'hand' whenever the need arises to find a free spot. The entries themselves are marked with a flag that determines whether the hand will evict that entry for use. Every time the clock encounters a marked entry, it will unmark it so that the next time it is encountered the hand gets to free it. This is a simplistic explanation, but should get the idea across. Many variations exist, some with multiple hands and others with varying levels of priority for each entry.
The one Art is implementing is just a one handed clock cache and in this instance the hand also cannot unmark any of the entries. Not surprisingly, this means the system needs to wait for the application to unmark its entry or else the entire system crashes. The hand in this instance only traverses the unmarked entries when looking for a free spot for new entries. The entire cache is described by a bitmap and the unmarked entries are zeroes in the bitmap, which is how the hand knows which entries to go to next.
Однако эта работа сделана и Artу ножно разделить СС и ММ компоненты системы. В данный момент Artу заниается тем, что исследует различные компоненты (включая ММ и драйвера файловых систем) на предмет зависимости от СС модуля. Art уже начал добавлять код в специально выделенную ему ветку в репозитории, следовательно желающие ему помощь уже могут действовать. Но должно пройти немнго времени, прежде чем всё начнёт работать как запланировано.
Причуды установки ReactOS
Проще гопоря, ReactOS при установке ведёт себя неправильно, например не проверяет является ли установочным диском раздел, с которого бдудут скопированы файлы, возврвщаят неправильный раздел для установочного диска, если присувствует ещё один раздел на диске, и использует даже те разделы, которые обозначены, как "в использовании".
Упомянутая выше ошибка связана с неправильным присвоением буквы к диску и выражается в падении истановщика. Именно с этой ошибкой встретился Art при установке на ext2 раздел, когда готовил презентацию к выставке. Описаные проблемы могут возникнуть и в других ситуациях, но если ваша система сконфигурирована подобным образом, это будут первые ошибки с которыми вы столкнётесь. К сожалению, ошибки частично зависиеы друг от друга, по-этому, чтоб исправить вторую ошибку надо хотя бы частично устранить первую. Последняя описаная ошибка проблем с исправлением вызвать не должна.
Who is online
Users browsing this forum: No registered users and 14 guests