Судя по числу минусов, которые получил этот пост, Хабр проверку на адекват прошел. Что не может не радовать.

Возражу Вам. Sega имела историю нескольких подряд убыточных консолей. Сначала они пытались пролонгировать жизнь Genesis / Megadrive различными дополнениями вроде Sega CD и 32x, далее Sega Dreamcast и Saturn. Также из игровых козырей у них по сути был только Sonic. Компания была почти банкротом, чего нельзя сказать о Nintendo. 3DS является самой продаваемой портативной консолью, а Wii была одной из самых успешных домашних консолей. Проблема Nintendo на мой взгляд как раз в закрытости, а также они слегка промахнулись с Wii U, поскольку она почти ничем не отличается от своей предшественницы кроме усовершенствованного контроллера, с которым никто не знает что делать.

1. DLL без ASLR
2. Memory Leak
3. Использование других путей (типа JRE), что «обходом» ASLR можно назвать с натяжкой.

Учитывая то, что в последних офисе и JRE dll-ки уже обновили, что делает метод, основанный на DLL без ASLR несколько затруднительным, можно у Вас поинтересоваться, много Вы знаете хороших memory leak сплойтов, которые позволят узнать местоположение в памяти и не «уронить» атакуемую программу и в дальнейшем использовать полученную информацию в самом эксплойте?

А под словом «атакуемую программу» я имею в виду браузер или плагин, ибо большинство малвари распространяется через drive-by-download (имеется в виду не считая социальной инжинерии).

Не забудьте прибавить и Kido/Conficker/Downadup к этому списку :)

Зачем? Клиенты-то причем? Бизнес каждый делает так как может. Не нравится поведение есета, так нужно их на место ставить рыночными методами. Создайте свой алгоритм обнаружения вирусов и утрите им нос :)

Объясняю: каждому узлу соответствует определенная стоимость пути до него (f), которая складывается из эвристики (h) и счета узла (g). Счет узла это стоимость перемещения от начального узла к данному узлу, следуя найденному к нему пути, где расстояние до вертикального или горизонтального соседнего узла равно 10, а до диагонального — 14. Счет каждого следующего узла на пути складывается из счета родительского узла и расстояния от родительского узла до текущего. Эвристика же это оценка стоимости пути от данного узла до конечного (как считается эвристика см. выше).
По поводу «можно в личку или статью»: можно, конечно, но создание такой статьи дело не одного дня, у меня свои дела и запланирована статья по другой теме. Если Вам интересно разобраться в этом алгоритме, то прочтите великолепную и очень подробную статью о нем:
www.policyalmanac.org/games/aStarTutorial_rus.htm, а вот если у Вас возникнут трудности в реализации алгоритма на каком-то конкретном языке или вопросы по самому алгоритму, то Вы можете написать мне в личку и посоветоваться, я с радостью помогу, только просьба задавать конкретные вопросы.

Данный компонент предназначен именно для того чтобы не разбираясь в алгоритме использовать его в своих приложениях.

Нет, 10 это расстояние от одного узла до другого, смежного с ним, а 14 — расстояние от узла до другого, расположенного по-диагонали от него. На самом деле расстояния равны 1 и 1.4 (это есть расстояние до узла по диагонали вычисленное по теореме Пифагора), но т.к. правила оптимизации программ диктуют нам избегать где это возможно операций с числами с плавающей точкой, то данные значения умножаются на 10, отсюда 10 и 14

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

zloe_zlo
Волновой алгоритм отличается от А* тем что последний осуществляет направленный поиск. У меня поиск именно такой. Рассчитывается эвристика, с помощью которой определяется направление пути и поиск не среди всех клеток, а только тех, что лежат вдоль оптимального пути. Поэтому данный алгоритм именно А*, а не волновой алгоритм.

200 на 100 узлов это максимум на котором я прогонял компонент. Более высокие разрешения заставляют скрипт работать более 15 секунд, причем не на этапе поиска самого, а на этапе создания массива объектов (кстати скорость поиска при 200 на 100 все равно высокая). Что касается способа вычисления оптимального пути то он прост — его стоимость как это водится в данном алгоритме, складывается из эвристики и суммы счета каждого узла, посещенного вдоль пути к текущему узлу. Эвристика же считается по простой формуле:
xDistance = abs(currentX-targetX)
yDistance = abs(currentY-targetY)
if xDistance > yDistance
H = 14*yDistance + 10*(xDistance-yDistance)
else
H = 14*xDistance + 10*(yDistance-xDistance)
end if

я ответил на Ваш вопрос или Вы что-то другое имели ввиду?

Я могу ошибаться, но источники в Интернете (http://en.wikipedia.org/wiki/A*_search_algorithm, и ссылки в этой статье), а также книга Рассела и Норвига «Искусственный Интеллект: современный подход» говорят о том, что это А*. Интернет, конечно может врать, но зарекомендовавшая себя книга выдающихся ученых, осмелюсь предположить, — нет.