Выпуск новостей ReactOS #50 |
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translation complete.
If you do not want to register an account, you can sign in with OpenID.
ReactOS Newsletter #50 | ||
The Perils of PSEH2 | ||
While KJK did get PSEH2 out in record time, this meant that it was relatively untested when he committed it and developers began using it. Currently PSEH seems to be corrupting data when exceptions get thrown, which then cascades down and causes functions to assert and crash, something that it was supposed to prevent. Michael Martin's theory about what is happening is that PSEH is clobbering local variables that are being held in registers, though KJK attributes it to an issue of not using setjmp. The rest of the details are, in his words, "complicated." KJK has committed fixes for the variable corruption problem, but he expects more problems to show up. On the other hand, this spat of issues has prompted KJK to begin writing a test suite for SEH. He has about 70 tests so far and will commit it to trunk soon, with more following. | В связи с тем, что KJK завершил PSEH2 в рекордные сроки, новый код был относительно мало протестирован на тот момент, когда разработчики начали его использовать. Сейчас, похоже, PSEH портит данные во время возникновения исключений, в результате чего вызываемые ниже (по стеку) функции могут не проходить проверку входных данных и аварийно завершаться, от чего PSEH должна была защитить. Майкл Мартин(Michael Martin) предполагает, что это может происходить из-за того, что PSEH портит локальные переменные, находящиеся в регистрах, хотя KJK указывает причиной неиспользование setjmp. Остальные подробности, по его словам, "весьма сложны". KJK внёс исправления для проблемы с порчей локальных переменных, но он ожидает проявления и других проблем. С другой стороны, этот спор о проблеме подтолкнул KJK к написанию набора тестов для SEH. Пока в нём около 70 тестов, которые вскоре будут внесены в транк, со многими другими. | |
One of the more serious issues that cropped up was when ReactOS gets to the login, the system actually had not loaded the components for reading input from the keyboard. This predictably resulted in not being able to get past the login and a great deal of frustration on the part of testers. Unfortunately, even with KJK's most recent fixes, the issue has still not been fully resolved. | Одна из наиболее серьезных проблем возникает во время входа в систему ReactOS, система фактически не загружает компонент для чтения ввода с клавиатуры. Это предсказуемо приводит к тому, что не удаётся загрузиться дальше входа в систему и к большим разочарованиям со стороны тестеров. К сожалению, даже с самыми последними исправлениями KJK, проблема до сих пор не была полностью решена. | |
MSVCRT | ||
The MS Visual C++ Runtime library provides most of the basic services a C++ program may require, though MSVCRT technically is only for programs developed using Visual C++ versions 4.2 through 6 and certain internal components. Newer programs are not supposed to link directly to it, though for the sake of backwards compatibility the Windows SDK still allows you to do it. Interestingly, it was the poor handling of MSVCRT in the 9x family that contributed to most of the DLL hell that people experienced. ReactOS also has its own copy of MSVCRT, though it was cobbled together from a variety of sources in order to provide the various functionalities needed. This created a a lot of problems that Gregor Schneider has been working through to get the ROS MSVCRT to pass more Winetests. He's made good progress, with the unit tests for dir, cpp, printf, and string basically done. Most of the work involved eliminating duplicate or incorrect code and updating to Wine's versions now that their implementation has matured. | Библиотека времени выполнения MS Visual С/C++ предоставляет большую часть базовых служб, которые могут требоваться для любой программы, написанной на С/C++, хотя технически MSVCRT была предназначена только для программ, разработанных с помощью Visual C/C++ версий с 4.2 по 6 и для некоторых внутренних компонент. Более новые программы не предполагалось связывать с ней напрямую, хотя для обратной совместимости Windows SDK по-прежнему позволяет это сделать. Что интересно, именно неправильное обращение с MSVCRT в семействе 9x внесло наибольший вклад в обрушившийся на людей DLL Hell (когда различные версии библиотеки не имели между собой совместимости). У ReactOS также есть своя версия MSVCRT, которую создавали с учётом нескольких исходных версий, чтобы удовлетворить различным функциональным требованиям. Это создавало много проблем, с которыми разбирался Грегор Шнейдер(Gregor Schneider), чтобы заставить ROS MSVCRT проходить большее число тестов от Wine. Он далеко продвинулся, практически полностью написав тесты модулей для dir, cpp, printf и string. Большая часть работы заключается в удалении дублирующего и неверного кода и обновлении до версий Wine, реализации которого достаточно стабильны. | — ...только начал, потом завершу. — bz00mmer |
— ничего, что я упрощу? ЗЫ К чему столько технических подробностей? ЗЗЫ А Z98 - программист, хоть на 0,5%? — bz00mmer
— Меня всё ещё коробят громоздкие переводы "commit" и "trunk". "Assert" по-моему вообще не переводится. — LRN
More 4 comments
— С "транком" соглашусь, можно сказать, что непереводимое, но commit имеет вполне удобоваримый перевод. — bz00mmer
Вопрос в том, насколько зрелая аудитория тех, кто новости читает. — bz00mmer
— Я считаю, что (стараться) переводить нужно ВСЁ. И рассчитывать на широкую аудиторию. А ежель кто думает, что есть что-то непереводимое, пусть глянет <http://arno1251.livejournal.com/30142... — Anonymous
— О какой широкой аудитории может идти речь, если мы говорим о регистрах, setjmp и стэке функций? Аудитории может быть только две - академические и неакадемические программисты. Неакадемические знают, что такое "транк", "коммит", "ассерт", "эксэпшн". Академические - могут не знать, у них почти для всех терминов есть перевобы (обычно - громоздкие). Не-программисты не поймут в любом случае. Хотя с другой стороны, программисты обычно английский знают, так что переводы - явно не на них нацелены. В общем, я так чувствую, что мне лучше поменьше участвовать в переводах, а то совсем озверею от безысходности. Хочется точно передать смысл текста, а не сделать красивый перевод, но - нельзя... — LRN
— Речь идёт о "максимально широкой" аудитории - не ограничивать искуственно. У переводчиков древних текстов причин для безысходности и озверения гораздо больше. :) Трудности, я смотрю, тут с переводом смысла и с качеством русского языка. — Anonymous