Хотя бы потому что на том же Linux за 20 лет толком кроме Valve, никто толком и не двигал прогресс.
переписав современные движки на си fps не изменится ни на кадр
По времени исполнения уйдёт часть рантайма, разница будет, хотя бы в несколько FPS. Собственно автор статьи об этом и упоминает. Культура написания навороченного кода у среднестатистического специалиста Си явно повыше будет.
EAX - просто устаревшее говно мамонта
Ничего подобного. Очевидно человека, который толком не работал с ним и не слышал.
Последние версии, как раз вполне себе в ногу со временем.
Звук старых игр с поддержкой EAX различается с современными играми, где в аудиомикшер всё в кучу навалено.
DirectX Sound
Смысл был в том, что всё это работало на наиболее низком уровне а-ля AMD Mantle. Это не грязные хаки, а возможность работать с железом на более низком уровне. А не целые нагромождения костылей, потому что так захотела Microsoft.
Стандарт де факто сейчас steam audio, Microsoft project acoustics и meta XR
Если на том же Linux до сих пор нет драйверов Creative, Asus XONAR сомневаюсь что эти стандарты применимы. У Вас звуковые карты, являющейся конечной оправной точкой, существуют на одной планете, а user-mode костыли на другой.
ИМХО, проблема здесь во всём сразу, что шикарно начинало работать во времена Windows XP, но пришло в лютую убогость позже.
Во-первых, даже несмотря на более мощные современные процессы, скорость работы игровых движков гораздо медленнее, чем раньше. В современных Windows столько много напихано, что процессор чисто физически 70-90% времени тратит на какой нибудь С++ райтайм, вместо реально обсчёта чего либо.На чистом Си писать разучились уже давно.
Во-вторых, с распространением скриптовых языков типа Lua, Perl, Java разработчики стали писать на них большую часть сценариев. Ранее всё это делалось на куда более низком нативном уровне.
В-третьих, львиная часть бюджета уходит на анимацию и красивую картинку в целом.
Ну и самое главное, такие прорывные технологии в своё время, как Creative EAX (OpenAL), DirectX Sound, PhysX ВНЕЗАПНО оказались за бортом. В итоге, звук в том же Battlefield 4 - 6 откровенный треш VS Battlefield2, Warcraft III, где акустика и реверберация реализованы на нормальном уровне, а не программные user-mode костыли.
только в последствии вносят реальные правки под это решение.
Отчасти понимаю их. Однако, есть важный технический нюанс
и в этот момент хорошо им смягчить переход на новую версию
... прошло 3 года - ничего НЕ выпилили толком. Банально потому:
1) ввиду потока новых изменений, никому нет дела до старых;
2) особо и удалять нечего, кроме разве что DirectX 9, который рассчитан на XP / 2003;
В большой команде очень неэффективно принимать решения и делать крупные изменения в коде за один заход
С профессиональной технической точки зрения, эффективные менеджеры Google уже наступают на свои же технические грабли - размер chrome.dll, который не может расти в бесконечность. А он стабильно растёт всё больше и больше ввиду пункта выше. Инженеры типа представителя Google выше пытаются фиксать эту проблему в ущерб оптимизации убирая __inline. При том, что тащемта такие чудовищные размеры для PE-формата это не очень нормально. Примерно из разряда, накрыть DLL какой нибудь DENUVO и ожидать, что производительность не просядет и не вылезут баги самого нативного лоадера.
полагаю, что при аппаратном ускорении более менее современные видеокарты, даже начиная с архаики AMD HD 77xx / GeForce 9xx могут сами разбираться с этим через свой драйвер напрямую.
js тест рисует какую-то картинку а не падает с эксепшеном, не значит, что вы заставили webgpu работать по нормальному.
Интересно, а какие ещё критерии нужны? Нагрузка CPU / GPU? С чего бы обычный вывод через DirectX 11 (d3d11) стал работать не так, если Вы сами обеспечиваете такую совместимость?
аргументы
Когда ломаешь Ваш Chrome и оно работает (по крайней мере обеспечивает какой-то достаточно высокий уровень фукнциональности путём нехитрых правок) - аргументы говорят сам за себя.
У Вас Windows 8 (8.1), поддерживает всё Вами вышеупомянутое:
DirectX parrarel render output
MFPlat
full user32
shared handle
Process Mitigation (буквально без двух флагов, которые появились в Windows 10) и остальное из kernel32
И тем не менее, всё равно убираете поддержку. Единственное чем это можно аргументировать - гораздо меньше пользователей, чем на Windows 7 даже. Но с технической стороны - ТЕМ БОЛЕЕ никакого смысла в этом нет совсем.
С переходом на Windows 11, возникнет аналогичная ситуация один в один.
За тем, покидаю эту ветку.
Во всяком случае, со своей стороны не прощаюсь, потому что ломать версии Вашего Chrome браузера можно бесконечно.
И никакие палки в колёса, что пытались вставить со 125 здесь не помогут. Ну уже понятно по Вашему (не конкретно Вашему), что поля в PE-header, никак не влияют. Импорт из NTDLL... а Вы здесь за аргументы.
Со своей стороны уже специально подсказываю на DirectX 9 render, чтобы не так стыдно было. С последним хотя бы изменений мегабайт на 15-20 будет в обратную сторону, вместо 5 Мегабайт бинарного кода. Тем более всё равно для совместимости оставляете каждый раз, если отвалятся вышеупомянутые примочки.
Это НЕ настолько фундаментальные вещи, ради которых требуется формально убрать поддержку Windows 7. Понимаю Media Foundation отсутствует на XP/2003, где нет так-же d3d11, здесь всё логично. 7ка, а тем более 8ка - это не серьезно.
Это невозможно, потому что компонент много и выпиливание их долгий и трудоемкий процесс. Тогда бы пришлось забить на все фичи, багфиксы и все-равно отложить выпуск 110 версии, только чтобы уменьшить размер исполняемого файла. Никто так делать не будет. Делают отсечку, отказываются от поддержки и дают добро на отчистку кода.
Да,ещё в первой статье прекрасно расписал абсолютную ущербность Вашей стратегии, которая в сумме даёт замкнутый круг. Вы это не можете признать, равно как и Ваше руководство некомпетентно (с 109 версии). Это лишь подтверждает мои слова, что с профессиональной точки зрения проектирование браузера для архитектуры Windows выглядит ужасным.
Самая первая ломанная версия была 114, прошло три года, уже 141 версия вышла - НИЧЕГО не поменялось. Спокойно бегу и влзамываю 141 версию, потому что ничего не мешает это сделать. Уверен, что когда очередной инкремент условно 1541 версии - НИЧЕГО НЕ поменяется кардинально, потому что Вы и ваша корпорация ходит по замкнутому кругу.
Тут большая разница в том, что разработчикам supremium не надо поддерживать и развивать весь хромиум
Слушайте, с таким уровнем говна, что туда напихали за десятки лет, впору задуматься наоборот почистить его от говконокда и более компанктно струкрутировать/ ОПТИМИЗИРОВАТЬ. Сейчас на дворе НЕ 2000-2010 год, когда всемирная паутина идёт семимильными шагами в развитии. В курсе, что даже сраную "плавную" прокрутку чинили несколько версий подряд.
Да, гугл бы мог нанять еще команду разработчиков делать именно это и не отказываться от старых операционок.
Ключевое слово МОГ БЫ.
И еще много чего мог бы делать, я думаю не вы единственный имеете идеи о том, на что гуглу стоит еще тратить деньги, что лично вам нужно. Но так бизнес не работает.
Вы сами себе противоречите - теперь у Вас бизнес стоит выше интересов пользователей, заявленных ранее.
Никакая организация кода и тестирования не убирает накладные расходы. Тупо все тесты прогонять на еще одной операционке - это одного электиричества и железа надо много
Что за бред... С таким же успехом для Linux нужно тестировать исключительно на Debian, так как зоопарк из всех GNU систем корпорация не может себе позволить с Ваших же слов.
Например, из-за того что MediaFoundation в win7 не умеет нормально в D3D11_RESOURCE_MISC_SHARED_NTHANDLE, нельзя видео из камеры сразу загрузить в текстуру. Поэтому во всех видео энкодерах и рендерерах надо отдельный случай обрабатывать - софтверный фрейм, который надо еще загружать в видео память. Изолированный отдельный компонент чуть подругому себя ведет, и все потребители видео от GPU service, до webrtc с media recorder должны это учитывать.
Да, он не умеет в shared handle, что НЕ помешало мне пропатчить WebGPU для запуска на Windows 7 без shared handle. Потому что базовый оператор if не зависит от типа операционной системы. И этот код Вы всё равно оставите для совместимости, если основная ветка не заработает. Так зачем по итогу убирали формально поддержку Windows 7?? Не увидел ответа.
Нет, не согласен - поддерживать можно ещё долгое время после, если пользователи настойчиво просят (ведь интересы пользователей важнее денег, ведь сами утверждали ранее), причём не сказал что доля мизерная, тем более она даже растёт последние несколько месяцев.
Конкретно:
1) Не вижу там никакого Legacy. Что именно подразумевается под этим? Притянуть разве что d3d9.
2) Стратегия это после объявления прекращения поддержки 7ки выпустить в следующей 110 версии chrome.dll, где уже убраны "ненужные" компоненты, связанные с Windows 7. Размер dll'ки должен уменьшиться. Причём существенно.
На деле - никакой разницы между 109 и 110.
Тривиальный вывод: корпорация Google подошла формально к этому вопросу. Обсуждать больше нечего, это факт!
3) т.е. для разработчика Supermium нет никаких проблем с поддержкой целого зоопарка, а для огромной мегакорпорации, ворочащей миллиардами долларов это представляет невыполнимую задачу. Вот это открытие!
4) Делает разработку легче? Поддержка нескольких платформ - оптимальная организация структуры кода, процесса сборки/тестирования и рабочего окружения. Если этого нет, то даже для одной единственной Windows 11 будет сложно выпускать и тестировать новые сборки.
Если упомянули восьмерку, то ситуацию ещё хуже для Вас - разрыв по фукнционалу между 10 и 8 абсолютно минимальный. Тем не менее даже поддержку восьмёрки зачем то выпилили.
Патчу спокойно все последующие версии после 109 - вижу прекрасно, что меняется мало. Проблемы с разрастанием бинарного кода в chrome.dll пытаются нелепо решить в ущерб оптимизации по скорости. О чём собственно и разговор. Уверен, что оно будет расти до бесконечности и ничего вы с этим не поделаете, если конечно не дойдете по разделению самого chrome.dll на составные части: redner / gpu... Повторите банально мои статьи.
Media Foundation существует на Windows 7, camera тоже на крякнутой 141 прекрасно работает.
Windows Graphics Capture
Что мешает альтернативные реализации через тот-же DirectX использовать на семёрке? Из разряда Microsoft через 20 лет научилась открывать RAR архивы нативно.
dx12
Слышал ещё 3 года назад. Одно и тоже....
hardware acceleration
d3d11 (sm5.0) / d3d9 всё так-же ANGLE использует - какая разница принципиально между 10 и 7??? Чуть менее чем ничем отличается.
Форсится через флаги браузера - в 141 работает даже на древней HD 7770.
ЗВУК
После убийства DirectXSound нечего менять.
Легаси для поддержки
Что поменялось в размере chrome.dll после выхода 110 версии? Н-И-Ч-Е-Г-О, DLL'ка не уменьшилась. Одно из двух: никакого legacy там нет ИЛИ это legacy работает всё так-же на Windows 7 /10.
Меня лишь волнует, почему это "говно" штатноНЕ запускается на Windows 7 (хотя после патчинга/кряка вполне себе нормально работает).
С точки зрения математики/алгоритмов браузер выполнен великолепно.
С профессиональной точки зрения платформы/архитектуры Windows - нубское поделие, о чём рассуждаю на протяжении нескольких статей.
И тот факт, что размер файла только увеличивается после 109 версии, говорит лишь об одном - НИКАКОГО смысла удалять поддержку Windows7НЕ было и НЕТ до сих пор. Ну нет с точки зрения кода, там ничего, что препятствовало бы реально запуску. Особенно актуально на фоне таких приятных новостей.
p.s. Само собой не собираюсь сидеть на 109 версии.
Разница в оптимизации -O3 / -O2 была только между 109 (официально последняя Windows 7) и следующими версиями (114). Крякнутые неофициальные версии работали заметно быстрее на Windows 7.
Самый максимум: из-за невозможности контролировать разрастание кодовой базы этими "гениями" в последних версиях Chrome часть subroutine вместо __inline делается отдельной функцией.
Не совсем правда:EDGE.Patcher для Microsoft EDGE/ Chrome всё таки делали по сигнатурам и это без проблем работает на широком диапазоне версий (кряк для Windows 7). Здесь аналогичная ситуация.
Хотя бы потому что на том же Linux за 20 лет толком кроме Valve, никто толком и не двигал прогресс.
По времени исполнения уйдёт часть рантайма, разница будет, хотя бы в несколько FPS. Собственно автор статьи об этом и упоминает. Культура написания навороченного кода у среднестатистического специалиста Си явно повыше будет.
Ничего подобного. Очевидно человека, который толком не работал с ним и не слышал.
Последние версии, как раз вполне себе в ногу со временем.
Звук старых игр с поддержкой EAX различается с современными играми, где в аудиомикшер всё в кучу навалено.
Смысл был в том, что всё это работало на наиболее низком уровне а-ля AMD Mantle. Это не грязные хаки, а возможность работать с железом на более низком уровне. А не целые нагромождения костылей, потому что так захотела Microsoft.
Если на том же Linux до сих пор нет драйверов Creative, Asus XONAR сомневаюсь что эти стандарты применимы. У Вас звуковые карты, являющейся конечной оправной точкой, существуют на одной планете, а user-mode костыли на другой.
ИМХО, проблема здесь во всём сразу, что шикарно начинало работать во времена Windows XP, но пришло в лютую убогость позже.
Во-первых, даже несмотря на более мощные современные процессы, скорость работы игровых движков гораздо медленнее, чем раньше. В современных Windows столько много напихано, что процессор чисто физически 70-90% времени тратит на какой нибудь С++ райтайм, вместо реально обсчёта чего либо.На чистом Си писать разучились уже давно.
Во-вторых, с распространением скриптовых языков типа Lua, Perl, Java разработчики стали писать на них большую часть сценариев. Ранее всё это делалось на куда более низком нативном уровне.
В-третьих, львиная часть бюджета уходит на анимацию и красивую картинку в целом.
Ну и самое главное, такие прорывные технологии в своё время, как Creative EAX (OpenAL), DirectX Sound, PhysX ВНЕЗАПНО оказались за бортом. В итоге, звук в том же Battlefield 4 - 6 откровенный треш VS Battlefield 2, Warcraft III, где акустика и реверберация реализованы на нормальном уровне, а не программные user-mode костыли.
Отчасти понимаю их. Однако, есть важный технический нюанс
... прошло 3 года - ничего НЕ выпилили толком. Банально потому:
1) ввиду потока новых изменений, никому нет дела до старых;
2) особо и удалять нечего, кроме разве что DirectX 9, который рассчитан на XP / 2003;
С профессиональной технической точки зрения, эффективные менеджеры Google уже наступают на свои же технические грабли - размер chrome.dll, который не может расти в бесконечность. А он стабильно растёт всё больше и больше ввиду пункта выше. Инженеры типа представителя Google выше пытаются фиксать эту проблему в ущерб оптимизации убирая __inline. При том, что тащемта такие чудовищные размеры для PE-формата это не очень нормально. Примерно из разряда, накрыть DLL какой нибудь DENUVO и ожидать, что производительность не просядет и не вылезут баги самого нативного лоадера.
наверное, это если прям вручную всё делать.
полагаю, что при аппаратном ускорении более менее современные видеокарты, даже начиная с архаики AMD HD 77xx / GeForce 9xx могут сами разбираться с этим через свой драйвер напрямую.
Интересно, а какие ещё критерии нужны? Нагрузка CPU / GPU? С чего бы обычный вывод через DirectX 11 (d3d11) стал работать не так, если Вы сами обеспечиваете такую совместимость?
Когда ломаешь Ваш Chrome и оно работает (по крайней мере обеспечивает какой-то достаточно высокий уровень фукнциональности путём нехитрых правок) - аргументы говорят сам за себя.
У Вас Windows 8 (8.1), поддерживает всё Вами вышеупомянутое:
DirectX parrarel render output
MFPlat
full user32
shared handle
Process Mitigation (буквально без двух флагов, которые появились в Windows 10) и остальное из kernel32
И тем не менее, всё равно убираете поддержку. Единственное чем это можно аргументировать - гораздо меньше пользователей, чем на Windows 7 даже. Но с технической стороны - ТЕМ БОЛЕЕ никакого смысла в этом нет совсем.
С переходом на Windows 11, возникнет аналогичная ситуация один в один.
Во всяком случае, со своей стороны не прощаюсь, потому что ломать версии Вашего Chrome браузера можно бесконечно.
И никакие палки в колёса, что пытались вставить со 125 здесь не помогут. Ну уже понятно по Вашему (не конкретно Вашему), что поля в PE-header, никак не влияют. Импорт из NTDLL... а Вы здесь за аргументы.
часть кода MFPlat
DXGI draw out
Вам самим то не смешно?
Со своей стороны уже специально подсказываю на DirectX 9 render, чтобы не так стыдно было. С последним хотя бы изменений мегабайт на 15-20 будет в обратную сторону, вместо 5 Мегабайт бинарного кода. Тем более всё равно для совместимости оставляете каждый раз, если отвалятся вышеупомянутые примочки.
Это НЕ настолько фундаментальные вещи, ради которых требуется формально убрать поддержку Windows 7. Понимаю Media Foundation отсутствует на XP/2003, где нет так-же d3d11, здесь всё логично. 7ка, а тем более 8ка - это не серьезно.
Да,ещё в первой статье прекрасно расписал абсолютную ущербность Вашей стратегии, которая в сумме даёт замкнутый круг. Вы это не можете признать, равно как и Ваше руководство некомпетентно (с 109 версии). Это лишь подтверждает мои слова, что с профессиональной точки зрения проектирование браузера для архитектуры Windows выглядит ужасным.
Самая первая ломанная версия была 114, прошло три года, уже 141 версия вышла - НИЧЕГО не поменялось. Спокойно бегу и влзамываю 141 версию, потому что ничего не мешает это сделать. Уверен, что когда очередной инкремент условно 1541 версии - НИЧЕГО НЕ поменяется кардинально, потому что Вы и ваша корпорация ходит по замкнутому кругу.
Слушайте, с таким уровнем говна, что туда напихали за десятки лет, впору задуматься наоборот почистить его от говконокда и более компанктно струкрутировать/ ОПТИМИЗИРОВАТЬ. Сейчас на дворе НЕ 2000-2010 год, когда всемирная паутина идёт семимильными шагами в развитии. В курсе, что даже сраную "плавную" прокрутку чинили несколько версий подряд.
Ключевое слово МОГ БЫ.
Вы сами себе противоречите - теперь у Вас бизнес стоит выше интересов пользователей, заявленных ранее.
При том, что Google просрал кучу денег на провальные проекты просто так, даже слышать не хочу про бизнес идеи. Это не тот случай.
Что за бред... С таким же успехом для Linux нужно тестировать исключительно на Debian, так как зоопарк из всех GNU систем корпорация не может себе позволить с Ваших же слов.
Да, он не умеет в shared handle, что НЕ помешало мне пропатчить WebGPU для запуска на Windows 7 без shared handle. Потому что базовый оператор if не зависит от типа операционной системы. И этот код Вы всё равно оставите для совместимости, если основная ветка не заработает. Так зачем по итогу убирали формально поддержку Windows 7?? Не увидел ответа.
Нет, не согласен - поддерживать можно ещё долгое время после, если пользователи настойчиво просят (ведь интересы пользователей важнее денег, ведь сами утверждали ранее), причём не сказал что доля мизерная, тем более она даже растёт последние несколько месяцев.
Конкретно:
1) Не вижу там никакого Legacy. Что именно подразумевается под этим? Притянуть разве что d3d9.
2) Стратегия это после объявления прекращения поддержки 7ки выпустить в следующей 110 версии chrome.dll, где уже убраны "ненужные" компоненты, связанные с Windows 7. Размер dll'ки должен уменьшиться. Причём существенно.
На деле - никакой разницы между 109 и 110.
Тривиальный вывод: корпорация Google подошла формально к этому вопросу. Обсуждать больше нечего, это факт!
3) т.е. для разработчика Supermium нет никаких проблем с поддержкой целого зоопарка, а для огромной мегакорпорации, ворочащей миллиардами долларов это представляет невыполнимую задачу. Вот это открытие!
4) Делает разработку легче? Поддержка нескольких платформ - оптимальная организация структуры кода, процесса сборки/тестирования и рабочего окружения. Если этого нет, то даже для одной единственной Windows 11 будет сложно выпускать и тестировать новые сборки.
Будет работать на всех хромоподобных браузерах + CEF.
БОЛЕЕ наглядный вид subroutine
tls_add_message, которую необходимо пропатчить (x64) в отладчике x64dbg:Для x86 асм различаются (так-же нашёл).
Если упомянули восьмерку, то ситуацию ещё хуже для Вас - разрыв по фукнционалу между 10 и 8 абсолютно минимальный. Тем не менее даже поддержку восьмёрки зачем то выпилили.
MFPlat:
Это же обвёртки над интерфейсами, в теории дописать реально - всё равно на DirectX 11 device замыкаются (как и с рендером для отдельного окна).
Ну это же наверное что-то очень древнее должно быть!
Существуют GetFrontBufferData или render в текстуру / GetDisplaySurfaceData.
разве что паралельный рендер с 8ки DirectOut - но людям на семёрке с HD экранами не очень будет заметно по скорости.
3 года одно и тоже. Стоит ли удивляться что даже в WebGPU сделали наоборот.
Патчу спокойно все последующие версии после 109 - вижу прекрасно, что меняется мало. Проблемы с разрастанием бинарного кода в chrome.dll пытаются нелепо решить в ущерб оптимизации по скорости. О чём собственно и разговор. Уверен, что оно будет расти до бесконечности и ничего вы с этим не поделаете, если конечно не дойдете по разделению самого chrome.dll на составные части: redner / gpu... Повторите банально мои статьи.
Даже аппаратное ускорение WebGPU работает на семёрке средствами DirectX 11.
Зачем убирали поддержку 7 - до сих пор сами не можете ответить на этот простой технический вопрос.
Абсолютное большинство даже на виртуалке работает.
Vulkan так-же поддерживается Windows 7 для некоторых видео-карт и заработает в теории.
Не знаете к чему придраться)
p.s. Не хуже Вас знаю как потроха сего поделия работают внутри и где можно пропатчить/улучшить.
SDK можно тоже притянуть за уши.
Аналогично как и WinAPI для Chrome.
Или эмулировать а-ля Wine.
Всё запускается прекрасно до сих пор.
С аппаратным ускорением через native d3d11
Media Foundation существует на Windows 7, camera тоже на крякнутой 141 прекрасно работает.
Что мешает альтернативные реализации через тот-же DirectX использовать на семёрке? Из разряда Microsoft через 20 лет научилась открывать RAR архивы нативно.
Слышал ещё 3 года назад. Одно и тоже....
d3d11 (sm5.0) / d3d9 всё так-же ANGLE использует - какая разница принципиально между 10 и 7??? Чуть менее чем ничем отличается.
Форсится через флаги браузера - в 141 работает даже на древней HD 7770.
После убийства DirectXSound нечего менять.
Что поменялось в размере chrome.dll после выхода 110 версии? Н-И-Ч-Е-Г-О, DLL'ка не уменьшилась. Одно из двух: никакого legacy там нет ИЛИ это legacy работает всё так-же на Windows 7 /10.
Для сравнения Sony Xperia 2013 года до сих пор работает. Батарея менялась всего навсего ОДИН РАЗ при активном использовании (основной смартфон).
@wataru, не нас, а Вас. Это Вас должно волновать разрастание "кодовой базы".
Меня лишь волнует, почему это "говно" штатно НЕ запускается на Windows 7 (хотя после патчинга/кряка вполне себе нормально работает).
С точки зрения математики/алгоритмов браузер выполнен великолепно.
С профессиональной точки зрения платформы/архитектуры Windows - нубское поделие, о чём рассуждаю на протяжении нескольких статей.
И тот факт, что размер файла только увеличивается после
109версии, говорит лишь об одном - НИКАКОГО смысла удалять поддержку Windows 7 НЕ было и НЕТ до сих пор. Ну нет с точки зрения кода, там ничего, что препятствовало бы реально запуску. Особенно актуально на фоне таких приятных новостей.p.s. Само собой не собираюсь сидеть на 109 версии.
Нет, Chrome Windows 7 crack - 3 года патчится без принципиальных изменений.
Разница в оптимизации
-O3/-O2была только между 109 (официально последняя Windows 7) и следующими версиями (114). Крякнутые неофициальные версии работали заметно быстрее на Windows 7.Самый максимум: из-за невозможности контролировать разрастание кодовой базы этими "гениями" в последних версиях Chrome часть subroutine вместо __inline делается отдельной функцией.
Аналогичные нюансы решили ранее: EDGE.Patcher
Дополнительно:
Windows 7 CRACK
подчищает испорченную цифровую подпись файла, чтобы антивир меньше ругался.
Не совсем правда: EDGE.Patcher для Microsoft EDGE/ Chrome всё таки делали по сигнатурам и это без проблем работает на широком диапазоне версий (кряк для Windows 7). Здесь аналогичная ситуация.
Если уважаемые пользователи будут донатить миллиарды, готов бросить основную работу и переключится на системную разработку под Windows 7.
Дурной пример заразителен. В прямом и обратном смыслах.
С Вашего позволения внесу аналогичные коррективы в свой Google Chrome Windows 7 crack:
Заодно и на 7ке будет работать!