Sergey S. Koval

Ну просто сказочное резюме.

2009-10-13T12:09:35Z

Смотреть тут: http://work.com.ua/jobs/451302/

Обратить внимание на "PS требования". 25000 грн это, примерно, 3000 долларов.

Многопоточность

2009-06-01T19:39:40Z

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

Значит делаем следующее. Вводим микротреды (microthread).

Микротред характеризуется:
1. Текущим состоянием (на низком уровне - набор регистров)
2. Областью памяти под стек. У каждого микротреда свой стек.
3. Стек планировщика (смотри ниже). Тоже локален для конкретного микротреда.

Микротред может иметь три состояния:
1. Активный
2. Ждет выполнения
3. Ждет события

У каждой нити есть простой планировщик, который берет из выполняет задачи из очереди ожидания.

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

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

Рассмотрим пример (псевдокод, для простоты объекты называются A и B):
int A::TestA()
{
return 10;
}

void B::TestB()
{
printf("%d", TestA());
}

1. B::TestB() - точка входа микротреда
2. A::TestA() принадлежит нити 1
3. B::TestB() принадлежит нити 2
4. Вызываем B::TestB(), метод вызывает A::TestA()
5. Шедулер 2 записывает адрес возврата (из стека микротреда) в "стек планировщика".
6. Шедулер 2 понимает что A принадлежит другой нити и добавляет микротред в очередь исполнения шедулера 1
7. Шедулер 1 выполняет A::TestA(), результат попадает в регистры/стек
8. Шедулер 1 видит что в стеке планировщика есть адрес возврата в другую нить
9. Передает микротред во второй шедулер
10.Шедулер успешно завершает микротред.

Что на выходе:
1. Блокировки нужны только на момент передачи управления микротредов.
2. Данные локальны для конкретных объектов и доступ к ним будет выполняться из единственной нити.
3. Микротредов можно (и нужно) плодить пачками - пока один микротред ждет результата, другие микротреды делают полезную работу
4. Если одна нить очень часто выполняет кучи запросов от разных объектов и стала узким горлышком - можно сделать блокировку на уровне микротредов. Т.е. если данный ресурс заблокирован
другой нитью, то обращающийся микротред засыпает и добавляется в очередь блокировки. Как только ресурс освобождается - первый в очереди микротред просыпается и делает то, что ему надо
5. Микротреды могут спать пока не произойдет какое-либо событие, например пока не приехал кусок данных из сети.

Минусы:
1. Сильно возрастают накладные расходы на вызов методов.
2. Нельзя гарантировать порядок выполнения микротредов, разве что вводить какие-либо синхронизационные примитивы, которые будут делить микротреды на категории и запускать категории по

очереди, одна за другой.

Как это все можно сделать, с точки зрения кода... На С++ я бы все виртуальные методы объекта перенаправил на свой proxy метод. Компилятор будет генерить код вызова для оригинальной функции, но в результате вызова оной, попадет вызов не к адресату, а к моему коду. Мой код уже который сохранит состояние стека (с переданными параметрами), определится что делать и выполнит все что ему надо.

Но вот проблемка, насколько я знаю, "правильных" методов получить vtbl и запатчить его нет. См. http://kss.livejournal.com/33491.html
Как вариант - использовать другой язык, но питон не подходит (GIL), у Ruby с нитями еще хуже, Эрланг крутой, но стремный и т.д.
Единственное что пока приходит в голову - допилить напильником GCC что бы он делал то что мне надо, но это уже как-то совсем хардкорно.

Может у кого-то будут какие-либо идеи на сей счет? С точки подхода и с точки реализации?

Хук на виртуальные методы объекта

2009-06-01T18:24:04Z

Значит вопрос знатокам С++.
Есть С++ объект с одним или более виртуальными методами. Хочется захукать их всех. Желательно "относительно" документированными способами. Скажем, пропатчить vtbl не проблема, но хотелось бы знать в compile time/run time что именно патчить - т.е. нужен список.

Есть вариант с кодогенерацией прокси, но данный вариант не подходит.

Что можно сделать?

Мышь

2008-12-14T11:10:10Z

Кризис - странная штука.
Сегодня попал в местный аналог "Метро", магазин "Ашан". Смотрю, в компъютерном отделе, на витрине, лежит мышка Logitech MX Revolution за 522 грн (~$66). Подумал, подумал, купил. Прихожу домой и решил проверить - не переплатил ли.. На сайте самого Logitech, рекомендованая цена $99. В нашем Diawest вообще 1020 грн (~$130).
Скорее всего в магазине забыли произвести переоценку товара с курса 5.05 на курс 7.8, чем я нагло и воспользовался.

Поездка в США, общие впечатления.

2008-10-03T20:04:25Z

И так, у меня завершилась поездка в Штаты. Впечатления под катом.

Общее время проведенное в Штатах - 2 полных месяца и неделя сверху. Первую неделю я был в Хьюстоне (Техас) и чуть-чуть покатался - ездил в Остин который находится в 250 км от Хьюстона.
Первые впечатления я описывал в предыдущем посте.

Остаток времени я провел в Форт Лодердейл (Fort Lauderdale), который во Флориде. Находится тут: http://maps.google.com/?q=fort+lauderdale или всего лишь на 80 км на север от Маями. Город "странный". Очень дорогой, но в котором живут мало-обеспеченные слои населения. Есть свое подобие гетто, куда лучше вообще не приезжать.
Еда очень дорогая. Причем "хорошая" еда еще дороже. Пример: кило пластмассовых помидоров стоит около $1.5. Если помидорчики росли не на химии, то уже $3 за кило и выше. Хотя, химия/не химия понятие относительное, так как они и так все пластмассовые. Скорее всего это общая проблема Американской еды - она массовая. Ее много, но она низкого качества. Салями местного производства есть невозможно - она воняет тухлятиной. Хлеб слишком "воздушный" (читай много разрыхлителя), сыр - среднее между обычным и плавленным, хотя должен быть "нормальным" и с дырками и т.д. Единственное что понравилось - апельсиновый сок в пакетах, который натуральный, а не из концентрата. У нас такого, увы, нет.
Да, я не спорю что хорошая еда есть, но она существенно дороже и ее надо искать. Скажем пиво - оно все массового производства, типа Бадвайзеры всякие, которые совсем даже не пиво. Хорошее пиво или привозное (а его надо искать) или надо искать частные пивоварни которые варят для себя. И того: ширпотреб есть везде и его много, а хорошее надо искать. Прямо как в СССР :-)
Местные говорили что в северных штатах (Висконсин, например), все дешевле. Это как в сообщающихся сосудах: где-то дороже, а где-то дешевле.

Климат очень южный: высокая влажность, часто идут дожди и всегда жарко. Без кондиционера там очень тяжело. Кроме того, 3 месяца в году - сезон ураганов. За время моей поездки было 3 предупреждения: Густав (почти застал, была гроза и сильный ветер), Ханна и Айк, которые пролетели мимо.

За время поездки, получилось чуть чуть поездить по Флориде, был в Орландо (парк Universal Orlando и Kennedy Space Center, который на мысе Канаверал), ездил в Key West: http://maps.google.com/?q=key+west которая самая южная точка США. Еще был в Everglades, который большой заповедник с крокодилами.

Что могу сказать. Universal Orlando - горки прикольные (Duelling Dragons - супер), остальное не очень, на один раз.

Kennedy Space Center - восхитительно. Мне всегда нравилась космонавтика, а тут побывать на стартовых площадках шаттлов... Что тут говорить. Очень интересно, очень много информации, хорошие гиды - все понравилось. Если будет компания, хочу еще раз вернуться, но с лучшей камерой :-)

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

Key West - не доехал до самого Key West, остановился в Key Largo. прикольно, особенно когда ныряли с масками коралловых рифах. Ощущения - как в аквариуме с рыбками плаваешь.

Вобщем, впечатления о Штатах у меня теперь смешанные. Во первых - они испоганили природу. Скажем мангровые (http://en.wikipedia.org/wiki/Mangrove) заросли были вырезаны под корень, что бы песочек был и пляжи всякие. Или что бы просто было больше места под постройки.
Во вторых - очень много банально некультурных людей. Перед тобой едет машина, вроде хорошая - порш там какой-то. Открывается окно, из окна вылетает недоеденная булка вместе с бумажным пакетом. И остается на обочине. Обочины, я извиняюсь, засраны.
В третьих - культура потребления. Они могут не платить по долгам, но при этом ходить в ресторан. Потому что они привыкли так жить. Кстати, это одна из причин текущего кризиса.

Кстати, про кризис - местные забавные истории рассказывали. Мол, был там какой-то сенатор из Мичигана, он пару лет назад провел какой-то там билль, что каждый Американец должен иметь возможность осуществить свою мечту - купить себе дом. В результате, банки обязали выдавать кредиты на жилье не проверяя может ли данный индивидум его оплачивать. Вот и получал народ с доходом в 25 тыс/год (грязными!) кредиты на квартиры за $120,000. Банки просекли фишку и начали этими самыми кредитами торговать, в результате чего кредит мог заключаться с одним банком, а через год он пройдет через 10 банков. Те банки, которые имели голову на плечах - старались давать кредиты, но избавляться от них как можно скорее.
И вот наступил момент. Банки начали терять деньги - люди банально не могли платить даже проценты за свое жилье. Банки начали конфисковать имущество и пытаться его продавать. Так получилось, что предложение стало намного выше спроса и жилье поползло вниз. И произошло следующее: те кто взял кредит и мог его оплачивать, увидел что то жилье которое он купил за $200,000 уже стоит $100,000. Какой им смысл платить лишних 100 тыс? Они тоже начали скидывать жилье. Процесс стал неуправляемый и ипотечные фонды начали закрываться - на руках квартир куча, их никто не покупает и оборотных средств не осталось. Ипотечные фонды начали тянуть за собой банки. Перепуганный народ начал забирать средства из банков, а как известно - банк не хранит все вклады, он деньгами распоряжается как ему хочется и на руках денег почти всегда меньше чем сумма вкладов. Почему забирают деньги из банков? Потому что в Штатах правительство гарантирует только $100,000 в случае банкротства банка. У банков не осталось операционных средств. Они начали валиться тоже. И так далее. Так вот, этот самый сенатор теперь продвигает способ спасения банковской системы - выдать им 700 мрлд. и они должны выплыть. Такие вот дела.

Все фотки лежат тут:
http://www.flickr.com/photos/30473078@N08/

Слева есть альбомы, некоторые фотографии получились, некоторые нет. Кроме того купил себе Canon 40D (спасибо cray_days за советы), так что там смесь Сanon 40D и Canon A520.

Первые впечатления (в основном по машине)

2008-08-03T15:16:41Z

Так уж получилось, что мне повезло попасть в США, причем во второй раз.

В первый раз была Калифорния, в этот раз - Техас. Тогда у меня не было прав и меня катали, в этот раз права есть и была взята арендная машина :-)

У меня дома - Лачик (Chevrolet Lacetti) 1.6 хетч. Когда брал машину в аренду тут (в аеропорту) попросил что-то не очень большое и подешевле. Сказали что - без проблем, будет что-то типа Сонаты. Ага, как же. Прихожу на стоянку и вижу что мне достался Chrysler 300C в комплектации Touring (двигатель 3.2 и 250 лошадок). Из "сложностей" - я на ручке учился ездить, да и два года ездил тоже. Теоретически как рулить на автомате знал, но реально покататься не получалось. Пришлось проверять теорию сразу по получению машины.

Наши пластиковые права в Штатах действительны. Права старого образца, увы - нет. Машину в аренду не дадут если не оформлена полная страховка, что автоматически делает аренду дороже. Арендовать дешевле на 7 дней (неделя) чем на 6. Например: аренда в день стоит $60, а в неделю - $280 (включая все страховки). Да, дорого, но поскольку тут общественный транспорт почти отсутствует как класс и на нем ездят только социально-неблагополучные индивидумы, машину прийдется арендовать. Кстати, если брать машину сразу на месяц, получается что-то типа $900-$1000.

По бензину и его стоимости. Галлон "обычного" стоит $3.75. Обычный, это который аналог нашего 92. Super (95) стоит $3.85. Premium (98) - $3.95. В галлоне - 3.78 литра. И того, за 3.78 литра мы платим $3.85, что примерно равно $1,02 за литр. Когда я сказал что у нас есть 95-обычный, 95-Super, 95-Premium с одинаковым октановым числом - местные сильно удивлялись :-)

С собой я взял свой комуникатор который умеет GPS и на котором стоит iGo. Единственное что мне пришлось сделать - найти карты нужных штатов и подключить их к iGo. Так вот, если в Киеве iGo считает маршрут моментально, вне зависимости от его длины, то в Хьюстоне (где я сейчас) - думает около минуты. Я думаю это из за плотности дорог на один квадратный километр. Кроме того, iGo напрочь сносит крышу с многоэтажными развязками. Например - он предлагает выехать на магистраль на 2м "этаже" а потом "повернуть" с моста направо. Если бы я это мог бы сделать, выглядело это как в Терминаторе 2, когда грузовик в водо-канал прыгает...

Пока буду рассказывать про Хьюстон и поездку в Остин.

Хьюстон (карта - http://maps.google.com/maps?near=Houston,TX ) состоит из двух "колец" и лучей которые как-бы расходятся в разные стороны от центра города.

Кольцо - это скоростная магистраль, 6 полос в одном направлении. На ней нет светофоров.
Лучи - обычно 4 полосы в одном направлении, светофоры отсутствуют. Хоть магистраль и находится в черте города, на ней не действуют скоростные ограничения (можно ехать 120 км/ч, например).
Важная деталь - скоростные трассы все платные. На трассе есть КПП, проезжая через который нужно заплатить некое количество денег ($1.25, в среднем). Платить можно либо наличекой (что требует остановки) либо с помощью специального устройства, который предварительно покупается в магазине. Наличие устройства не требует остановки и даже снижения скорости. Штраф за проезд без оплаты - около $40 за каждое нарушение. Я, естественно, был не в курсе что это такое и проехал через КПП без оплаты. А потом быстро поехал в офис и оплатил проезд пост-фактум, что сработало (пришлось объяснять что мы не местные) :-)

В США общая система правил дорожного движения, но в каждом штате свои модификации, причем в отдельных городах правила могут отличаться. В Техасе разворот на зеленый разрешен (при отсутствии запрещающего знака). В Далласе, например, запрещен. В Техасе распространены специальные полосы для разворотов (http://en.wikipedia.org/wiki/Texas_U-turn) которые, обычно, расположены перед перекрестком и на них можно делать разворот вне зависимости от состояния светофора и перекрестка.
На дорогах - обилие знаков. На каждом перекрестке, на асфальте и над каждой полосой висит знак (и текст) который показывать что можно делать и что нельзя. Обычно самая левая полоса - только поворот налево (запрещается движение прямо) и самая правая - только для поворота направо.

Разметка дороги бывает двух цветов - белая и желтая. Желтая - менее "жесткая" версия белой. Например, двойную белую сплошную запрещается пересекать вообще. А вот желтую двойную сплошную разрешается пересекать для поворота налево (т.е. запрета нет, но и не рекомендуется).

Полиция тут очень злая. Особенно highway patrol. Могут сесть на хвост, остановить, попросить документы, что-то проверить, а потом сказать спасибо и предупредить что превысил скорость на 1.5 км/ч и пожелать хорошей дороги. Если что-то откопают, выпишут штраф. Три штрафа - надо пересдавать на права. Я не в курсе что произойдет с нашими правами, думаю что просто запретят водить машину на территории штатов.

Про поездку в Остин - что понравилось, так это дороги. Очень часто прямые и минимум поворотов. По сути, за 250 км пути от Хьюстона до Остина я ехал по трем шоссе с минимум 2-мя полосами в каждом направлении. В машине стоит круиз-контроль, так что я включил нужную скорость и спокойно себе рулил в нужном мне направлении, прислушиваясь к подсказкам GPS. Максимальная скорость на highway/interstate - 70 миль/ч или около 110 км/ч. Превышение разрешается только на обгоне. Почему так (при хороших машинах) - я без понятия. Что интересно, на обочине очень часто валяются разорванные покрышки. Тут, в целом, жарко и почти всегда сухая погода, вот их и разрывает. Народ, увы, не сильно дисциплинированный - мусор выбрасывают просто через окно. Но если поймают - будет ОЧЕНЬ больно :-)

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

По стоимости проживания... Еда дешевле чем в Украине. Обычно на 30-50%. Машины и электроника даже не стоит сравнивать. Новый Ford Focus стоит от $14,000. 50" LCD от Samsung (новый!) = $1000.
Жилье - вообще печально. Двухэтажный коттедж (с гаражом на две машины) возле крупного города с небольшим куском земли (садик там или просто backyard) = $180,000. Причем он уже меблированный, с системой раздельного кондиционирования и всей инфраструктурой, типа канализации.
Что заметно - товары дешевые, а вот все услуги дорогие. Скорее всего это потому, что почти все импортируется за бесценок и слишком большая конкуренция, а вот услуги уже идут по местным уровням дохода, что сразу поднимает их стоимость.

Следующая остановка будет во Флориде, возле Маями, так что продолжение следует.

P.S. Фотографии будут позже.

Houston

2008-07-27T10:30:36Z

Я свалил в командировку в Штаты. Сейчас - в Хьюстоне.
Фотки будут позже.

Самая лучшая MMO!

2008-07-19T14:44:56Z

Качать клиент на: http://www.progressquest.com

Если чего, я на сервере Spoltog, звать - Yexyex :-)

Они убивают питонов!

2008-06-23T20:43:10Z

Да уж, странный же народ бывает :-)

http://techfaux.com/2008/06/17/peta-targets-computer-programmers-with-string-of-bizarre-protests/

Апдейт nvphforce

2008-05-28T19:32:10Z

Небольшой апдейт.
Не всегда корректно передавалась строка в приложение которое дебагаем - была непонятка между CreateProcess(), MSDN и мной.
Исправлено, за фикс спасибо __vortex__

Брать тут: http://narod.ru/disk/588801000/nvphforce11b.zip.html

А теперь с банановым вкусом!

2008-05-19T16:50:47Z

Вот новая версия форсилки nvPerfHUD.
Теперь умеет D3D10 и, теоретически, D3D10.1 (хуки стоят, но проверить не на чем).
Спасибо __vortex__ за любезно предоставленную машину с вистой где я его дописывал и отлаживал.
Изменений для D3D9 части почти нет.
Работать будет и в XP (разве что только D3D9 хучит) и в висте - там и D3D9 и D3D10.

Брать тут: http://narod.ru/disk/372305000/nvphforce.zip.html

Пользуясь, соглашаемся что не будем юзать во всяких нехороших целях и все такое.

P.S. Зачем DXUT вызывает D3D10CreateDevice и D3D10CreateDeviceAndSwapChain около 10 раз я так и не понял.

Cистемы контроля версий

2008-05-17T12:40:54Z

Давным давно я использовал CVS, в основном что бы забирать исходники с Sourceforge.
На Очень Большом Проекте (ОБП) мы использовали Subversion. Все было отлично и функциональности оного нам хватало с головой. Другие коллективы использовали всякие разные vcs - от Perforce до ClearCase.
Свои наблюдения я опишу чуть ниже

Perforce. Честно говоря, я не понимаю зачем в системе контроля версий нужно делать exclusive lock для файлов, кроме как для бинарных, которых мерджить принципиально очень сложно или вообще невозможно.
Для двух комманд, физически расположенных в разных городах это слишком накладно - lock делался через Internet и, не дай Бог, кто-то уже залочил файл не в локальном офисе и ушел домой не отдав изменений...
Сама процедура lock'а занимала около 4-6 секунд, что не много, но раздражало когда надо исправить банальную очепятку в комментарии.
Оговорюсь - пробовал я Perforce после Subversion, а по удобности с TortoiseSVN мало кто может поспорить.

ClearCase.. Ужасный монстр, который к тому же еще и очень дорогой. Понятие "атомарность" отсутствует как класс. Очень тормозной (в виду целого багажа legacy кода). Юзер интерфейс ужасен настолько, что вызывает отвращение :-)
Вобщем, советуется избегать данную поделку, тем более что наличие бесплатных альтернатив при стоимости лицензии на одно рабочее место в $3k должно отпугивать само по себе.

Subversion. Отлично справился с задачей хранения и исходников и бинарных данных. Репозиторий у нас был "относительно" небольшой, где-то около 8-9 гигов в сумме на код/данные.
Проблемы, в принципе, стандартные (но мы с ними не столкнулись, повезло):
1. Падает сервер - репозиторий не доступен
2. Ломается HDD на сервере - вся история теряется (бекап спасет)
3. Тяжело работать с ветками - при мердже веток теряется история. Новая бета SVN умеет merge tracking, который собственно и призван решить данную проблему. Мы руками переносили список изменений когда объединяли ветки. Да и вообще, процесс не совсем интуитивен.

Теперь посоветовали (а именно murkt) посмотреть на так называемое третье поколение систем контроля версий. В двух словах - очень понравилось.
Основные претенденты: git, mercurial и bazaar.
Git я отбросил сразу - основная платформа разработки у меня это Windows, а git - linux only с убогими попытками работы под Windows.
Bazaar я сильно не рассматривал, все говорят что Mercurial лучше, так что я поверю им на слово :-)
Буду описывать Mercurial, т.к. большинство пунктов можно перенести и на git и на Bazaar.

Значит так, основные отличия от Subversion/Perforce/etc:
- Вся система представляет собой p2p, т.е. нет центрального репозитория
- Любое изменение создает ветку

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

Рассмотрим процесс получения/отдачи изменений в Subversion.
1. Делаем update - забираем новые изменеия из репозитория
2. Делаем merge, автоматический если конфликтов нет, ручной если они были
3. Делаем commit - отдаем свои локальные изменения в репозиторий.

Рассмотрим процесс получения/отдачи изменений в Mercurial.
Тут commit имеет другое значение: отдать изменения в локальную копию репозитория. Т.е. мы программируем себе, наделали изменений, отдали их в свой репозиторий. Главный репозиторий о них еще не знает.
Теперь представим что таких программистов 5. Каждый делает commit в свою локальную копию. Но ведь им нужно как-то обменяться изменениями..
Процесс выглядит так:
1. Разработчик наделал изменений, сделал commit (один или больше, не имеет значения)
2. Делает pull (по типу update в svn) - забирает текущие изменения из главного репозитория
3. Делает merge (автоматический или ручной, если конфликты)
4. Делает push (по типу commit в svn)

После этого все его изменения будут отданы в главный репозиторий. Собственно процесс от Subversion не сильно отличается, разве что мы свой код отдаем в локальный репозиторий, а когда накопили изменений - отдаем все скопом в главный репозиторий.
Вот пример:

Была 610 ревизия. Автор TK Soh.
611 - 614 ревизии были сделаны тоже им, скорее всего локально.
И тут бравый программист Steve Borho делает мега фикс для ревизии которая у него была, а именно 610. По сути, Steve сделал ветку для себя начиная с 610 ревизии.
В 616 ревизии TK Soh делает мердж ветки Стива в главную ветку.
Дальше начинается веселье с 5 разными ветками для 3х разных разработчиков, в результате оно все мерджится в главную. Примерно так оно и работает. Скриншот взят с TortoiseHg. Почему Hg? Вспоминаем таблицу Менделеева :-)

Кстати, подобная схема позволяет организовать процесс труда следующим образом:
1. Есть главный-главный репозиторий.
2. В главный-главный репозиторий могут отдавать только лиды по направлениям (графика, gameplay, etc)
3. У каждого лида есть свой репозиторий (копия главного-главного)
4. В репозиторий лида могут отдавать только программисты подчиненные лиду
5. Лид делает code review и время от времени синхронизируется с главным-главным репозиторием

Альтернативный подход: лид может забирать изменения у самих разработчиков и мерджить руками (заодно проверяя чего там разработчики наделали). Mercurial поддерживает несколько транспортов: файловая система (включая сетевые диски), http, https, ssh и даже почта.
Забирать совсем вручную не обязательно, достаточно написать скрипт. Понятное дело что забираться будут те изменения, которые разработчик закоммитил в локальный репозиторий, а не текущую локальную рабочую копию разработчика.
Кстати, вариант когда лид закидывает изменения в рабочие копии разработчиков тоже возможен (а не наоборот, когда разработчики забирают изменения из репозитория). Т.е. push/pull просто указывают направление операции и так как все репозитории равнозначны - разделение главный/подчиненный целиком условное.

Такой подход:
а) Автоматически делит проект функционально
б) Каждая команда трудится в своей песочнице
в) Главный репозиторий получает только проверенные изменения

Если сравнить Mercurial с Subversion, то получится примерно так:

Достоинства:
1. Быстрее работает
2. Репозиторий локален, commit очень быстрый
3. Абсолютно условное разделение главный/подчиненный
4. Автоматический бекап репозитория на всех машинах разработчиков. Если что-то упадет, то оно упадет только на его машине, пускай это будет даже главный-главный репозиторий
5. Намного легче работать с ветками чем в svn, т.к. вся идеология на них и построена
6. Очень похожий набор комманд на SVN
7. Возможность импортировать весь репозиторий из/в SVN
8. Возможность написания плагинов, хуки как в SVN присутствуют тоже
9. Trac понимает Mercurial (с плагином)

Недостатки:
1. Т.к. хранится вся история изменений, бинарники которые тяжело diff'ать хранить накладно - на каждой машине будет копия всех ревизий.
2. TortoiseHg сыроват (хоть и работает). Command-line работает отлично.

В целом, сейчас Mozilla живет на Mercurial (уже почти год как) и вроде бы ничего, жалоб нет.
Ах да, еще в Mercurial есть нативная поддержка Patch Queues, оно полезно если часть кода приходит извне в виде патчей (например - для middleware), в результате Mercurial работает с патчами как с нативными изменениями (они показываются в истории, etc).

И напоследок ссылок по теме:
1. http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
2. http://versioncontrolblog.com/2007/06/26/video-bryan-osullivan-mercurial-project/
3. http://wincent.com/a/about/wincent/weblog/archives/2007/10/why_distributed.php
4. http://www.dribin.org/dave/blog/archives/2007/12/30/why_mercurial/
5. http://lucumr.pocoo.org/cogitations/2008/01/28/mercurial-for-subversion-users/
6. http://weblogs.mozillazine.org/preed/2007/04/version_control_system_shootou_1.html
7. http://antonym.org/node/143

Вроде все :-)

Почему С++ хорошо для низкоуровневых приложений

2008-05-13T22:55:38Z

Возникла идея описать как у нас связывается совсем уж низкий уровень с С++.

Я неоднократно слышал что для всего низкоуровневого - обязательно чистый С, С++ путь туда заказан и тому подобное. Категорически с этим не согласен.
Следует разделять что конкретно используется - куча сторонних либ или С++ как язык программирования. Да, STL использовать для чего-либо специфического не получится, но не сильно и надо.
Вобщем, подробности. Сейчас пишется и тестируется х86 эмулятор который состоит из двух частей - первая переводит х86 код в псевдокод, вторая его исполняет. Что то типа CodeVirtualizer (http://www.oreans.com/codevirtualizer.php) или VM внутри старфорса, разве что свое.
У процессора есть регистр флагов. Каждый бит что-то означает. Мол там последняя операция дала нулевой результат. Или переполнение регистра было, etc. Флаги нужно эмулировать - при выполнении арифметических (и не только) операций нужно выставлять/убирать биты из регистра флагов (или переменной которая играет регистр флагов в эмуляторе).
Почти каждая инструкция ставит их по своему. Флагов значительных всего 6, минимальный набор инструкций который надо поддержать - не менее 20 (все арифметические и логические операции).
Берем пример на С (жертва - DosBox):

/* CF     Carry Flag -- Set on high-order bit carry or borrow; cleared
          otherwise.
*/
Bitu get_CF(void) {

    switch (lflags.type) {
    case t_ADDb:    
        return (lf_resb<lf_var1b);
    case t_ADDw:    
        return (lf_resw<lf_var1w);
    case t_ADDd:
        return (lf_resd<lf_var1d); 
...
}

_Winnie C++ Colorizer

Т.е. на каждый флаг, на каждый тип команды, на каждый размер операнда (1, 2 и 4 байта) по отдельному case. Оно, да, работает. Вопрос - быстро ли?
Смотрим Bochs:

bx_bool BX_CPU_C::get_CFLazy(void)
{
  unsigned cf;

  switch (BX_CPU_THIS_PTR oszapc.instr) {
    case BX_LF_INSTR_ADD8:
    case BX_LF_INSTR_ADD16:
    case BX_LF_INSTR_ADD32:
      cf = (result_32 < op1_32);
      break;
    // used only if CF = 1 when executing ADC instruction
    case BX_LF_INSTR_ADC8:
    case BX_LF_INSTR_ADC16:
    case BX_LF_INSTR_ADC32:
      cf = (result_32 <= op1_32);
      break;
...
}

_Winnie C++ Colorizer

Лучше, да. Они если могут лишних case не плодят. Но идея та же. Кстати, Bochs компилируется С++ компилятором, но вот подход к многим вещам все еще Си'шный.

А как это можно сделать "по нормальному" в С++:
1. На шаблонах
2. Через перегрузку функций

Скажем у нас есть операция ADD. Делаем что-то вида:

enum    OpTypes
{
    OpAdd
}

template<typename T, OpTypes op>
struct  CheckCF
{
    inline  bool    operator()(T v1, T v2, T r, esDword oldFlag)
    {
        return false;
    }
};

template<typename T>
struct  CheckCF<T, OpAdd>
{
    inline  bool    operator()(T v1, T v2, T r, esDword oldFlag)
    {
        return r < v1;
    }
};

_Winnie C++ Colorizer

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

Правка: Чтобы не быть голословным, вот во что преобразуется проверка CF флага для операции ADD (пример выше) Microsoft Visual Studio 2005:


                 add     eax, esi
                 cmp     eax, esi
                 sbb     eax, eax
                 neg     eax

Intel C++ Compiler делает так:


                 add     eax, edi
                 cmp     eax, edi
                 mov     eax, 0
                 adc     eax, 0

Простая проверка - мало кода. Проверка посложнее (например AF) дает больше кода, но все равно, суммарно проверка на все флаги меньше 50 инструкций суммарно (читай около 150 байт кода на поддерживаемую инструкцию).

Вот небольшой пример, который на С просто невозможно написать, разве что вручную сделать все 6*20 (минимум) комбинаций для каждой команды или написать препроцессор который это сделает. Последний вариант, насколько я знаю, и используется когда надо сделать что-то подобное. Получается что надо потратить время и на препроцессор и на изменение процесса сборки.

В драйверах С++ тоже хорошо живется. Метапрограммирование местами может серьезно выручить (в основном экономит время на monkey coding). Не хочется ООП - кто ж заставляет, все можно писать в Си-стиле и по возможности автоматизировать свой труд.

Такие вот пироги.

Основные отличия винды Win64 от Win32

2008-04-25T10:49:45Z

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

Начнем, наверное, с общих архитектурных различий x86 и x64.
Регистров стало в два раза больше, что приятно. Набор инструкций остался такой же, разве что убрали однобайтовые dec/inc reg (increment/decrement register) в пользу специальных префиксов нужных только в х64.
Кстати, inc/dec убрали специально - у них был баг, когда ZF (Zero Flag, ставится в 1 когда результат операции равен 0) не меняется при inc reg. Это старая ошибка, еще с 8086 и ее в целях совместимости "пронесли через века". Аналогичная операция add/sub reg, 1 работает правильно.
Размер регистр соответственно стал 64 бита. Причем осталась возможность обращаться к 32, 16 и 8 битной частям.
Памяти стало можно адресовать аж 2^64 чего должно хватить на несколько поколений вперед. На x86 - до 16 ГБ, с PAE.
Еще там были изменения в работе с селекторами и т.д., но это уже не интересно.
Появилась возможность работы с RIP напрямую. Т.е. относительная адресация относительно RIP (Instruction Pointer). В результате можно писать код не привязанный к адресу загрузки. Внешнее проявление для x64 для одного и того же кода - таблица relocation уменьшилась в несколько раз по сравнению с Win32 версией.

Теперь о Win64 (будь то Windows XP 64, Windows 2003 64 bit edition или Vista 64):
a) Изменена система работы с per-thread exception'ами.
Раньше все делалось через SEH - по адресу fs:[0] лежит указатель на голову списка обработчиков exception'ов. Первым элементом в списке находится базовый обработчик, который показывает окошко "Приложение допустило ошибку и будет закрыто". Или типа того.
Установка handler'ов делается при входе в функцию, элемент создается в стеке (там два поля - адрес обработчика и next) и указатель на элемент записывается в fs:[0]. Соответственно при глубокой рекурсии, длина списка обработчиков exception'ов будет равна глубине рекурсии.
Теперь посмотрим что происходит когда обрабатывается exception:
1. Обработчик решил "обработать" exception
1.1. Нужно сделать stack unwinding, а именно - откатить стек к исходному состоянию (к стек фрейму обработчика)
1.2. Для С++ вызвать деструкторы всех объектов созданных на стеке.
В х86 этим занимается код приложения - система дергает обработчики по цепочке с флагом unwind и те, соответственно откатывают свой стек.

В Win64 не сильно думали и перенесли код из версии винды для Itanium (а туда из версии для Alpha).
Идея состоит в следующем:
1. В каждом (!) запускаемом/загружаемом модуле (EXE/DLL) содержится специальная табличка. Табличка содержит смещения и длину всех функций внутри данного модуля, а так же набор неких п-кодов нужных для "размотки" стека.
2. Когда происходит exception, система смотрит где он произошел и ищет структурку из таблички отвечающую за эту функцию.
3. Используя п-код отматывает стек и вызывает exception handler, который представляет само приложение (адрес записан в той же структурке), что бы тот дергнул деструкторы локальных объектов
4. По цепочке отматывает до нужного фрейма

В результате:
1. Накладных расходов в runtime на включение exception handling для х64 проектов нет, тем более что exception структурки для х64 должны создаваться _всегда_.
2. Если exception произошел в функции, для которой нет структуры (ошибка компилятора собравшего программу, например) - приложение падает с ошибкой. Помочь может только SetUnhandledExceptionHandler(). Не имеет значения где упало - в своем приложении или в third party DLL, падает всегда приложение.

b) Приложения Win32 работают под эмулятором.
Идеология эмулятора переехала из Itanium версии, разве что ее переписали под реалии x64, который умеет запускать x86 код нативно.
Например некоторое время не было "нормального" метода для вин32 приложений для перебора DLL'ек внутри Win64 процесса.
Эмулятор работает в user mode и относительно "бесплатен". Во всяком случае нет тяжелых операций переключения из ring 3 в ring 0, кроме как для исполнения самих системных вызовов.
Если перебрать DLL для x86 процесса, будут видны только системные DLL нужные для работы эмулятора.

c) Изменили call convention. STDCALL no more.
4 первых параметра передаются через регистры. Остальные через стек. Стек очищает тот кто передает параметры (а-ля C calling convention).
Из приколов - хоть 4 параметра и в регистрах, но вызывающий должен зарезервировать стек, если вызываемая функция захочет их временно сохранить в стеке.

Пока вроде все чего хотел написать. Если еще чего вспомню - отдельным постом.

Microsoft зажигает...

2008-04-22T09:30:02Z

http://www.microsoft.com/about/diversity/programs/dac/gleam.mspx

KeeLoq сломали.

2008-04-06T09:06:38Z

Я понимаю что уже давно подобрали к разным сигнализациям мастер ключи, но теперь нашли способ провести атаку не зная вообще ничего о сигнализации, кроме того что она использует KeeLoq.

http://www.uinc.ru/news/sn9808.html

Мерцание LCD

2008-03-28T14:26:45Z

Может я и отстал от жизни, но оказывается что большинство LCD мониторов мерцает.
Дело вот в чем: яркость можно регулировать двумя способами: током и ШИМ (широтно-импульсная модуляция).
Первый способ сильного распространения не получил - тяжело постоянно поддерживать яркость постоянной, в результате чего она "плавает".
Второй способ простой - с большой частотой включаем/выключаем лампы подсветки. Параметр яркости монитора определяет сколько лампы будут включены и сколько выключены. В большинстве случаев, частота ШИМ - 300 Гц.
Для более подробной информации с графиками (вордовский документ):
http://www.doesitmatter.ru/lcdpuls.doc

Варианты решения:
1. Забить если устраивает
2. Выкрутить яркость на 100% и понизить значения контрастности и RGB каналов.

Xploding Plastix

2008-03-15T21:25:15Z

Вот нашел случайно в Last.fm сабжевых "ребят".
По категориям Last.fm играют big beat с примесью джаза.
Я бы охарактеризовал как: шпионские фильмы + Fat Boy Slim + Amon Tobin + джаз.
Однозначно разрывная штука.

Послушать треки можно на http://www.xplodingplastix.com/
Советую начать с "Treat me mean, I need the reputation" (номер 9 на их сайте).

О рефакторинге...

2008-03-01T12:47:03Z

Мы продолжаем раскрывать всему прогрессивному человечеству тайны и секреты IT-индустрии. Причем продолжаем делать это в нагрузку к основному содержанию, т. е. совершенно безвозмездно.

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

Чтобы ничего не делать, но завоевывать уважение и получать много денег, в программировании надо знать следующие термины и их сакральные смыслы: рефакторинг, паттерны и лучшие практики. Из аксессуаров нужен портрет Джоэля Спольски в розовой рамочке в форме сердечка и любая очень толстая книга на любом иностранном языке со словами Software Engineering на обложке. Чем больше портрет Спольски, толще книга и иностраннее язык – тем лучше.

Итак, вы все заготовили, начнем изучать сакральные смыслы.

Рефакторинг. Это занятие. Вы должны понимать, что можно заниматься рефакторингом на людях, в одиночку и даже при дамах – это не зазорно. Зазорно же не заниматься рефакторингом вообще. Суть рефакторинга проста. Предположим, у вас есть два Больших Куска Железа С Дырками, из которых вы хотите с помощью винтиков, болтиков и шайбочек скрутить Великое, От Чего Содрогнется. Вы можете скручивать его так: надевать на винтик шайбочку, вставлять винтик в дырку, надевать еще одну шайбочку и только потом накручивать гайку. И это хорошо. А еще вы можете делать так – надевать на винтик шайбочку, вставлять винтик в дырку, накручивать гайку и еще одну гайку – контргайку. И это тоже хорошо. А еще вы можете начистить винтик перед скручиванием наждачкой-нулевкой. Чтобы было красиво. И даже отполировать его пастой ГОИ. Чтобы совсем прекрасно было. Вот это стремление к красоте и фэншую в закручивании винтиков и гаек и есть рефакторинг. А так как красота спасет мир, надо ее насаждать всеми силами, не обращая внимания на писк жертв.

Теперь паттерны. Это те самые Большие Куски Железа С Дырками. Вы их никогда не найдете самостоятельно, потому что там, где их можно найти, – на свалках, в отходах производства – их всегда находят другие люди. И пишут о них книги. Хорошие паттерны, как хороший сыр, должны быть дырчатыми и мягкими. Потому что из паттернов, в которых мало дырок и которые не гнутся о коленку, скрутить Великое, От Чего Содрогнется, трудно, если вообще не невозможно (правда, если у вас много сил и очень крепкие колени…).

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

Вот, собственно, и все сакральные смыслы. Применяйте полученные знания с умом, требуйте от всех рефакторинга во имя спасения мира, ищите в книгах самые дырчатые и мягкие Большие Куски Железа С Дырками, старайтесь сделать так, чтобы именно чужие колени болели от лучших практик, чаще смотрите на потрет Спольски в розовой рамочке и никогда, запомните, никогда не выходите из кабинета без толстой книги Software Engineering на иностранном языке в руках!

Взято с http://dpk.com.ua/blog/14954.html

Работа

2008-02-18T15:20:56Z

Относительно определился: http://www.in-square.net/
Добро пожаловать :-)

Апгрейд монитора

2007-11-01T19:49:32Z

После относительно долгого использования Samsung 172X решил "проапгрейдиться". Хотелось всего и побольше, но за относительно небольшие деньги.

Скажем так, много для меня это от 22", а небольшие деньги - меньше $700. Выбор пал на Samsung 245B который и был приобретен.

Из технических характеристик: матрица TN (что сказывается на цветопередаче, но я не эстет, к сожалению, на посмотреть фото - с головой), 1920x1200, заявленных 5 мс отклика и 24".

Поиграл в разные игры в родном разрешении - артефактов матрицы не заметил. Поиграл не в родном разрешении (720p с XBOX'са) - красотень! К сожалению, у меня хуящик подключен через VGA-box, который не умеет разрешений выше 1600x1200. Потому и 720p.
Цвето-передача, на мой субьективный взгляд, по сравнению с 172X не сильно изменилась. Хотя, может я и не сильно присматривался.

Текста стало помещаться очень много одновременно. Скажем так, почти в два раза больше, в виду широкоформатности и существенно увеличенного разрешения.

В целом, доволен покупкой, да.

Турция

2007-10-07T19:23:44Z

Слетал в Турцию, на недельку.
В планах было отдохнуть на Средиземном море (а не на Черном), в хорошем отеле. Остановились, по совету тур.компании на Antedon Deluxe который в Бельдиби, Анталия.
Проблем с перелетом туда и обратно, к счастью, не было. Как и не было проблем с трансфером. Задержки в 10-15 минут не в счет.

Не буду писать про отель - он соответствует своему уровню. Единственное замечание было по работе системы кондиционирования воздуха, но я думаю они это к следующему сезону решат.
Писать я буду о Турции.
Когда мы ехали в отель, я посматривал по сторонам в Анталии. По ощущениям, это смесь Штатов с нашей ментальностью. От штатов - ухоженность, хорошие дороги, кучи магазинов. От нас - если на участке нет ничего, там свалка.
В течении отдыха ездили на три экскурсии. Одна вводная по Анталии (бесплатная, разве что за обед надо заплатить - 10 у.е.) и две платные по 50 у.е. на человека: ловля рыбы и тур в разрушеный город Хиераполис и экскурсия по травертинам, которые возле Памуккале.
Первая поездка, обзорная, оказалась полным разводом. Нас повозили часа 2 по Анталии (интересная часть), а потом сделали "шоппинг тур" на 6 часов, в течении которого пытались продать всякую муть за баснословные деньги. А продавали вот что: драгоценности, кожу и текстиль (тряпки). Драгоценности, как выразился гид, будут "по европейским ценам, но очень хорошего качества". На самом деле - обычные ювелирные изделия, но при этом в два-три раза дороже чем в Киеве. Следующая остановка - "салон кожы Крыссида", что вызвало несколько смешков в автобусе. Собственно идея та же - пропихнуть за кучу денег товар сомнительного качества. Скажем за обычную кожанную куртку без утеплителя, хотели около $2000. Третья остановка - обычный магазин Colins, только цены снова завышены. Вывод - ну его в баню бесплатные путевки. Потеряли 2/3 дня на какую то фигню. Ах да, они делают скидки. Можно "выторговать" до 75% скидки. Только все равно смысла нет, ибо у нас их товары - дешевле.
Вторая поездка - ловили рыбу в горной реке. На самом деле - ребята хорошо организовали бизнес. Взяли горную реку, оградили плотинами, запустили голодную рыбу (форель) и кучу туристов. И им хорошо - туристы платят деньги и ловят рыбу которую туристы же и сьедят (ее жарят на гриле). И туристам хорошо - какое ни какое подобие рыбалки с неплохим клевом. Вобщем, более-менее.
Самое интересное - третья поездка. Начнем с того, что тон поездке задал гид. Очень образованная женщина, местная, но отлично говорит по русски. Всю экскурсию рассказывала про Турцию, про ее историю, про то как они жили и живут сейчас. Сама экскурсия тоже оказалась весьма занимательной.
В начале мы посетили фабрику по производству ковров. Первое отличие от обзорной экскурсии - тут было действительно интересно. Показали как работают ткачихи (как их правильно назвать?) - адский труд. Почти все к 30 годам сильно садят свое зрение и спину. Как объяснили на фабрике, цена ковра не определяется его размером, а определяется количеством нитей на один квадратный сантиметр. Скажем шерстяной ковер может иметь 36 нитей (6х6), а качественный шелковый ковер - 400 (20x20). Отдельно про шелковый ковер - это чудо. Меняет свой цвет в зависимости от того, как на него падает свет. Обычно небольшого размера и стоят от $3000 за ковер размером 50х50 см. А все дело в том, что его делает один человек от года и больше.
Вторая остановка была уже в Памуккале. Побродили по археологическим раскопкам Хиераполиса, потом полазили по травертинам - красиво.
На обратном пути заехали в местный винный погреб, похлебали вина и поехали домой.
Из того, что заметилось: Турки свою страну любят. Мустафа Кемаль "Ататюрк" у них вообще статус национального героя получил. Оно и не странно - объединить разваленную Османскую империю и сделать республику в 1923 году это не хухры мухры. Кстати, он же и ввел латинский алфавит в то же время. До 2002 года в Турции была полная торба. Бешенная инфляция (лиры шли на счет миллионами), верхушка ничего не делала, социальные службы почти не работали и тому подобное. У них, как и у нас сейчас, президент не имеет всех полномочий и, по сути, премьер руководит страной. Как сказала наш гид, на посту премьера сидел очень старый и больной человек, который уже вообще ничего не мог делать - служил марионеткой для "правящей" элиты. Коалиции в парламенте достали всех и люди сильно ждали перемен. Они наступили в 2002 году, когда мер Истанбула (он себя на этом посту очень хорошо себя зарекомендовал) решил создать свою партию. Ему, правда, привесили какое то нелепое обвинение (читал революционные стихи во время какой то там демонстрации) и посадили на 2 месяца. Народу это откровенное не понравилось и его выпустили раньше срока. Через суд он добился что бы с него сняли судимость и на выборал получил место премьера. После этого он делает ряд серьезных реформ почти во всех сферах деятельности: вводит новую лиру, увеличивает зарплаты гос. служащим, существенно снижает стоимость комунальных услуг за счет потребителей, которые банально воровали электроэнергию, делает реформу в образовании и в медицине. Ну и так далее. За 5 лет такой политики Турция действительно становится на ноги.
Например в городе Анталии, поставили нового мера от этой же партии. Гид рассказывала что по некоторым улицам в жаркий день невозможно было проехать - из за неработающей канализации стояла жуткая вонь. Ничего, пришел правильный человек к власти и навел порядок. Тоже самое и с премьером - кадры решают все.
Вот так вот. Однозначно могу сказать, что Турки сейчас намного ближе к Европе, чем мы. У нас, к сожалению, распи...йство непобедимо. В Анталии я багаж с самолета вообще не ждал - подошел к конвееру и сразу его забрал. У нас - ждал у конвеера 50 минут.

P.S. Ах да, как мне иногда было стыдно за "наших" туристов. Наших - в смысле русскоговорящих. Так и хотелось отойти подальше и делать вид что я не с ними.

Смена работы.

2007-09-06T10:18:17Z

Ну что ж, закончился очередной этап жизни.
Решил что стоит попробовать деньги зарабатывать на себя и для себя и самим же собой.
Посмотрим что из этого выйдет :-)

Rainford Electronics

2007-08-31T12:53:10Z

Есть тут у нас такая мега компания, которая из готовых деталей собирает бытовую технику.
Ну, типа, телевизоры, холодильники и все такое. Вот нашелся сайт оной: http://www.rainford-tv.com.ua/
Дизайн, конечно, очень функциональный. И мигает если смотреть не в IE.
Но меня очень порадовал скрытый баннер, который почему то ссылается на http://www.xxxsexsearch.co.uk
К чему бы это?
Вобщем, чую и техника у них аналогичного качества, не смотря на относительно приятную рекламную компанию.

Читы

2007-05-20T23:53:12Z

Так уж получилось, что я в свое время увлекался созданием читов для всяких игрушек. В основном мультиплеерных шутеров, но и mmorpg досталось тоже...
Дальше под катом.

Читы для меня были интересны сугубо с технической точки зрения - обойти античит, поковыряться во внутренностях движка и так далее.
Начну я, наверное, с Half Life.
Многие слышали про засилье мультиплеерных читов для HL, например о OGC. Как оно работает и что оно делает?
Вводная часть:
HL состоит из трех частей.
Первая: ядро. Состоит из рендера, сетевого кода, работы с устройствами ввода и так далее.
Вторая: клиентская часть мода
Третья: серверная часть мода.

По сути, игра в понимании HL это комплект из двух DLL (серверной и клиенской части мода) + данные для них.
Ядро "общается" с клиентской (и серверной частью) через два интерфейса: интерфейс ядра и интерфейс модуля.
Интерфейс ядра предоставляет всякие разные функции для работы с рендерингом и т.д. Интерфейс модуля используется как таблица callback, когда что то происходит. Например - начинает рендериться кадр. Тоже самое для серверной части, разве что интерфейсы отличаются.
Если не касаться статики и BSP, то основным игровым объектом является entity. Все entity синхронизируются между клиентами в мультиплеерной игре. Для уменьшения нагрузки на канал, апдейтятся только те entity, которых можно видеть (проверка по порталам).

Что делает чит? Он перехватывает необходимые функции из интерфейса клиентского модуля и получает доступ к интерфейсу ядра и делает что хочет. Например - рисует квадратик в screen space с именем игрока. Поскольку игрок может сидеть за дверью (а дверь не учитывается как закрытая нода портала), то точно станет ясно что за дверью кто то сидит. Второй вариант, он же wallhack - отключаем Z test для моделек игроков (можно контролировать флаги с которыми будут рисоваться entity). Ну и тому подобное - можно делать все, что позволяет движок.

Следующее что придумали - а почему бы и не прицеливаться автоматически? Высчитать view angle зная две точки (где мы и куда надо смотреть) совсем не сложно. Сделали. Эволюция метода - использование скелета модельки для определения куда надо целиться + нелинейное предсказание (учитывая ускорение и скорость) для компенсации лага и предсказания траектории движения. Вот и получались 95% headshot'ы при хорошем пинге.
Counter Strike, например, позволял стрелять сквозь стены. Сделано было достаточно просто - если материал стены "позволял" простреливать сквозь, то в зависимости от типа оружия определялось какое количество "стен" пуля может пройти. Стена в данном случае - полигон. Так что теперь стало возможно прицельно стрелять сквозь стены.

Были, конечно, и извраты - серия читов XQZ, где кто то сделал враппер над opengl32.dll и считал количество вертексов на модельку. По количеству вертексов определял что это рисуется и соответственно изменял флажки рендеринга. Понятное дело что такая штука ломалась когда выходили патчи для моделек. Aimbot тут работал просто - проецировали одну из вершин и делали SetCursorPos.
Тут начинается самое интересное. Понятное дело, что с читами мириться никто не хотел, особенно игроки которые чит не смогли достать, либо не поняли как им пользоваться. Начинают появляться античиты.

Первый самый популярный античит (эх, забыл название), был сугубо на серверной стороне.
Обладал следующими свойствами:
1. Мог проверять переменные клиента (cvar). Обычно читы в них хранили свои настройки.
2. Жестко трейсил лучи на сервере и принудительно выключал модельки невидимых персонажей, чем серьезно грузил машину на которой он стоят.
Первое обошли очень просто:
1. Добавили уникальный префикс к cvar переменным (хитрость в том, что сервер не может перебрать все переменные клиента, а может только запросить значение переменной по имени). Альтернатива - вообще убрали cvar переменные и сделали свою встроенную консоль в чите.
2. Тут хитро. Я придумал следующую штуку (которая потом в OGC попала): у HL очень мощная звуковая система, с учетом разных материалов, с позиционированием звука и так далее. К счастью (или сожалению), при проигрывании звука передается ID entity которая его произвела. Пример: идет кто то за стеночкой, клацает ботинками. Позиция звука известна, кто издал известно - почему бы не использовать. Целиться на звук, увы, сложно, так как апдейт не очень частый. Дополнительный плюс метода - теперь порталы стали не помеха, если я нахожусь в зоне получения звука. А зона эта достаточно большая.
Вобщем, этот античит долго не просуществовал.

Второй достаточно известный античит - Cheating Death. По сути работал как чит - хукал интерфейсы и проверял что бы ничего лишнего не было (адреса функцией в интерфейсах принадлежали HL и т.д.). Содержал клиентскую и серверную части. Серверная ждала определенного хендшейка от клиентской и если его не было, кикала игрока. Клиентская часть была защищена весьма неплохо и малейшее вмешательство воспринимала как чит. К сожалению, у CD оказалась одна бооольшая дырка - серверная часть под Linux содержала debug info. Просто забыли strip'нуть .so'шку. В результате, алгоритм хендшейка быстренько разобрали на части и просто начали фальсифицировать. Началась возня с версиями, когда новая версия CD была не совместимой с предидущей (поменяли хендшейк), в тот же день выходил апдейт к читу с поддержкой нового CD и так далее. Продолжалось это все около года, пока разработчики CD наконец не поняли где собака порылась. А может и не поняли, а тому кто делал читы надоело, я не знаю.

Самое интересное началось с появлением VAC - Valve Anti Cheat. Есть подозрение что его писал кто то из Львова. Подозрение простое - была своя "тусовка", технический форум где обсуждались аспекты программирования читов. Админ (как потом оказалось - из Львова) высказал идею как бы он сделал античит. Как оказалось, VAC работает по той самой схеме как описал данный мсье. Это только предположения, но кто знает.
VAC работает почти как CD, только теперь оффициально от Valve. Есть серверная часть, есть клиентская. Серверная часть скачивается самим сервером с некого защищенного хоста Valve. Клиентская часть скачивается при коннекте с защищенному серверу. Файлы на диск не сохраняются, и сервер и клиент содержат свой loader. Если сдампить что пришло, получается какой то свой формат, который получен из исходной .DLL'ки. (Кстати, в HL2 систему упростили - качается .DLL'ка в temp папку и оттуда грузится. Видимо решили что коль для HL сделали дампилку этих .DLL, то смысла нет дергаться). Клиентская часть работала как и CD - следила что с клиентом и время от времени рапортовала серверной части.
Интересная особенность клиентской части - большой интерпритатор. По сути, что бы понять что оно сейчас делает надо было написать декомпилятор для скриптов. Банальный дизассемблированный код ничего не показывал. Серверная часть для Windows была тоже зашифрована, протокол работы античита тяжело было расковырять. Linux версия VAC сохранялась в .so'шку и оттуда грузилась. В принципе, в начале она даже debug info содержала, потом, правда, прикрыли лавочку.

Первая проблема, которая появилась с античитом - при коннекте к серверу скачивался клиентский модуль. Модуль, как уже говорил, был в определенном формате и получался путем конвертирования DLL'ки. Как оказалось, модуль оказался неподписанным. Результат: подправляем .so файл для Linux сервера и начинаем рассылать троянцев для всех, кто к нам в гости на сервер пожалует. Месяцев через 6 дыру прикрыли, начали подписывать.
Вторая проблема - за найденный чит начали банить. 40 у.е. терять как то не хотелось, начали придумывать способы обхода античита.
Самый простой способ - спрятаться.

Первые версии VAC достаточно легко обходились. Например, была у него проверка - все функции из интерфейса ядра должны указывать на адресное пространство HL.exe, а не какой то левой .dll, что логично. "Фиксили" просто - находили неиспользуемую область и делали там jump gate - в эту область памяти писали JMP myHandler, в интерфейсе ядра указывали на эту область. Тоже самое и с интерфейсом клиентского модуля.
Ну и так далее.

В тот момент у меня появилась мега идея как можно достаточно эффективно скрыть вообще наличие каких либо патчей.
Как известно, у x86 есть система защиты памяти. На каждую страницу (4кб) есть три флага: можно читать, можно писать, можно запускать. К сожалению, можно читать и можно запускать это один флаг. Почему к сожалению - объясню позже.
Так вот, идея - читаем кусок памяти, который мы собираемся патчить. Патчим память. И снимаем флаг "можно читать" со страницы.
Как только кто то попытается прочитать что то по указанному адресу, выскочит exception, который мы словим и сделаем следующее:
1. Восстанавливаем полномочия доступа к странице (с проверкой наш ли это вообще exception)
2. Проверим откуда произошла попытка "читать".
3. Если из ядра или клиентского модуля - ничего не делаем.
4. Если откуда то еще - восстанавливаем из бекапа оригинальные данные.
5. Включаем флаг трассировки. В смысле для процессора, при выполнении каждой комманды будет происходить exception.

Как только сработал exception по трассировке:
1. Убираем флаг трассировки
2. Восстанавливаем патч
3. Снова убираем флаги доступа к странице.

При таком раскладе, обойти такую защиту можно было только снятием защиты со страницы памяти. Что решалось хуком на всякие там функции VirtualProtect и эмуляцией когда пытались нашу страницу поломать. Второй вариант - глобально перехватить мой хендлер эксепшенов. И пытаться понять что же там такое со страницей памяти происходит. Это можно было полечить захукав NtDispatchException (или что то типа такого, забыл уже).
Недостаток простой был - на каждый exception теряется очень много тактов CPU. В результате, проседал FPS. Но даже на Athlon 1 GHz ниже 40 не опускался в Counter Strike. Так что было вполне приемлимо.
А теперь о проблемах x86. Поскольку флаг читать/запускать один, то нельзя защищать таким образом код, ибо получались жуткие тормоза, ибо каждая инструкция давала 2 exception.
Вобщем, было весело.

Что могу сказать про Quake 3. Q3 содержит VM, которая интерпретирует скрипты. Причем для x86 они даже написали JIT. Идея та же что и в HL (или наоборот), разве что модуля стало 3. UI почему то вынесли отдельно. Для вызова функций в/из скриптов существует мега функция, которая принимает н-цать параметров и по ID функции вызывает ее. Вобщем, хукаем эту функцию и повторяем все для HL.

Все остальные игрушки на базе движка Q3 ломаются аналогично, разве что ID функций другие. Я точно ковырялся в JK2 и Wolf:ET - никаких проблем.

Про mmorpg уже отдельным постом :-)