Danny Arty, попробуйте поиграться с заголовками с сервера и атрибутом download на ссылке. Но учтите, что результат может отличаться даже в разных версиях одного браузера.
xmoonlight, задачи, решения которых нет вовсе (типа быстрого пересчета криптографии, построенной именно на сложности вычислений) я в качестве вариантов просто не рассматривал.
Поскольку решение чудовищно велико, очевидно, что на самом деле оно не требуется. Просто неверно поставлена задача. Скорее всего, решение - какой-нибудь банальный рюкзак, просто ТС о нем не слышал.
Moris Bourbon, вы же сами продемонстрировали, что текст ошибки сохраняется независимо от того, включен ли тот пункт, на который она указывает.
Возможно, сама система, которую вы устанавливаете в виртуалку, требует виртуализации? Это Win7 x32, точно? Попробуйте на начальных этапах создания виртуалки выбрать Linux x32 и проверить, будет ли VB на нее ругаться.
Brendan Castaneda, то, что вы делаете на стороне клиента, не имеет к борьбе с уязвимостями никакого отношения.
Бот, который зашлет вам эксплойт, даже не знает, что такое браузер.
После покупки продукта припев меняется на рекламу сертифицированных специалистов, которые готовы дорого разгребать тот геморрой, который вы себе дорого прикупили, наслушавшись того маркетинга.
Brendan Castaneda, это классическая ошибка: вы считаете, что есть опасные символы, которые надо экранировать, вместо определения места, где нужно предупреждать конкретные уязвимости. В результате у вас потом где-нибудь будет двоиться апостроф или вылезать html-код с дважды обезвреженным амперсендом.
profesor08, а вы что именно нюхаете? Если приведенный мной код - рекомендую проверить обоняние. Он минимально отличается от приведенного тут, например.
Раскопал причину разного количества вызовов: разница в std::sort, где по стандарту сохранение порядка "равных" элементов не гарантируется, но MS-компилятор использует алгоритм, который его сохраняет, а GCC - нет.
В результате узлы в виндах шли в перебор отсортированными по фактору перспективности, а потом - по порядку, а в Линуксе - слегка перемешанными, и это для тестового набора данных оказалось менее эффективно, добавляя итераций перебора. В общем случае - не факт, так что никаких особых открытий не случилось.
Привел сортировку к строго одинаковому порядку, замеряю.
Общее время перебора оказалось примерно одинаковым, в виндах чуть больше, зато внутренние функции показывают втрое меньше времени.
Убрал вызовы профайлера, замеряю общее время снова.
Линукс крутит перебор в шесть раз дольше!
Внутренний цикл в виндах отрабатывает примерно тысячу раз за миллисекунду, верить профайлеру приходится с оглядкой. Учитывая разницу в результатах с профайлером и без - он вообще теряет смысл.
gbg, еще раз: я переделал этот код, он больше не использует вектор, он заполняет статический буфер, который потом, позже, присваивается вектору, который уже сохраняется в стеке вариантов. Но все равно именно на этом куске кода, суммируя разницу в миллисекундах, Линукс насчитывает 68 секунд из 100, затраченных на весь перебор, а Винды - 3 из 75. Стабильно. На одних и тех же данных.
Собственно, сейчас мне статистика показывает, что Винды обычно вызывают этот кусок кода реже - правда, не в 20 раз, а примерно в 4, но все же. Возможно, где-то выше неверно отрабатывает отсечение тупиковых ветвей.
