Компилируем С\С++ код в WebAssembly

Original author: Alon Zakai
  • Translation
  • Tutorial
WebAssembly — это новый бинарный формат, в который могут быть скомпилированы веб-приложения. Он проектируется и реализуется прямо в тот момент, когда вы читаете эти строки и двигают его вперёд разработчики всех основных браузеров. Всё меняется очень быстро! В этой статье мы покажем текущее состояние проекта с достаточно глубоким погружением в инструментарий по работе с WebAssembly.

Для того, чтобы WebAssembly заработал, нам нужны две основных компоненты: инструменты для сборки кода в бинарник формата WebAssembly и браузеры, способные этот бинарник загрузить и выполнить. И то, и другое ещё не полностью создано и очень сильно зависит от завершения работы на спецификацией WebAssembly, но в общем-то это отдельные компоненты и их развитие идёт параллельно. Это разделение — хорошая вещь, оно позволит компиляторам создавать WebAssembly-приложения, способные работать в любом браузере, а браузерам — запускать WebAssembly-программы не зависимо от того, каким компилятором они были созданы. Другими словами — мы получаем открытую конкуренцию инструментов разработки и браузеров, что непрерывно будет двигать всё это вперёд, принося конечному пользователю отличный выбор. Кроме того, такое разделение позволяет командам разработчиков инструментария и браузеров работать параллельно и независимо.

Новый проект на стороне инструментарий WebAssembly, о котором я хочу сегодня рассказать, называется Binaryen. Binaryen это библиотека для поддержки WebAssembly в компиляторах, написанная на С++. Если вы лично не работаете над компилятором WebAssembly, то вам, вероятно, не нужно напрямую знать что-либо о Binaryen. Если вы используете какой-нибудь компилятор WebAssembly, то он, возможно, под капотом использует Binaryen — мы рассмотрим примеры ниже.


Ядро библиотеки Binaryen предназначено для парсинга и генерации WebAssembly, а также представлении его кода в виде абстрактного синтаксического дерева (AST). На основе этих возможностей созданы следующие полезные утилиты:

  • утилита для командной строки, способная загрузить WebAssembly-модуль, распарсить его и выполнить его код как интерпретатор (произвести действия, вывести результат в консоль). Для загрузки модуля и вывода результата используется временная нотация s-выражений, имеющая суффикс .wast (я напомню, что окончательный формат представления бинарных модулей WebAssembly всё ещё в процессе разработки).
  • asm2wasm — утилита для компиляции asm.js в WebAssembly.
  • wasm2asm — утилита для компиляции WebAssembly в asm.js (ещё разрабатывается)
  • s2wasm, которая компилирует .s-файлы (формат, создаваемый новым бекендом для WebAssembly в LLVM) в WebAssembly.
  • wasm.js — порт Binaryen на JavaScript. Это позволит запускать все вышеуказанные инструменты прямо в браузере.


О Binaryen можно посмотреть вот эти слайды.

Ещё раз напомню, что WebAssembly находится в стадии активного проектирования, а значит входные и выходные форматы Binaryen (.wast, .s) не окончательны. Binaryen постоянно обновляется с обновлением спецификации WebAssembly. Степень кардинальности изменений со временем снижается, но гарантировать какой-либо совместимости никто, конечно, пока не может.

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

Компиляция в WebAssembly с использованием Emscripten

Emscripten может компилировать код на С в asm.js, а Binaryen (с помощью утилиты asm2wasm) может компилировать asm.js в WebAssembly, таким образом связка Emscripten + Binaryen даёт нам полный набор инструментов для компиляции кода на С и С++ в WebAssembly. Вы можете запустить asm2wasm на asm.js коде, но проще позволить Emscripten сделать это за вас, как-то так:

emcc file.cpp -o file.js -s ‘BINARYEN=”path-to-binaryen”’


Emscripten скомпилирует файл file.cpp и на выходе даст вам JavaScript-файл, плюс отдельный файл в формате .wast с WebAssembly. Под капотом Emscripten скомпилирует код в asm.js, сам запустит для него asm2wasm и сохранит результат. Более детально это описано на Вики проекта Emscripten.

Но подождите, какой смысл компилировать что-то в WebAssembly, если браузеры его пока не поддерживают? Отличный вопрос! :) Да, мы пока что не сможем запустить этот код ни в одном браузере. Но мы уже можем кое-что потестировать с его помощью. Итак, мы хотим проверить, верный ли бинарник создала связка Emscripten + Binaryen. Как же это сделать? Для этого мы можем использовать wasm.js, который Emscripten интегрировал в выходной .js-файл, полученный командой вызова emcc (см. выше). wasm.js содержить в себе порт Binaryen на Javascript, включая интерпретатор. Если вы запустите file.js (в node.js или в браузере), то вы получите результат выполнение WebAssembly. Это позволяет нам фактически подтвердить, что скомпилированный бинарник WebAssembly работает верно. Вы можете посмотреть на пример такой программы, плюс ещё пару примеров есть в репозитории для тестовых целей.

Конечно же, мы пока ещё не стоим на твёрдой земле со всеми этими инструментами. Тестовое окружение получается странноватое. С++ код компилируется в WebAssembly и затем выполняется в WebAssembly-интерпретаторе, который сам по себе написан на С++, но портирован на JavaScript. И нет пока никаких других способов запустить всё это. Но у нас есть несколько причин верить полученным результатам:

  • Выходной код проходит все тесты Emscripten. Они включают обработку множества реальных кодовых баз (Python, zlib, SQLite) плюс множество «подозрительных» ситуаций в С и С++. По опыту можно сказать, что если тесты Emscripten проходят для всех этих случаев, то и другой код, обработанный Emscripten будет вести себя нормально
  • Интерпретатор Binaryen проходит все внутренние тесты WebAssembly, определяющие правильность выполнения WebAssembly. Другими словами, когда мы получим поддержку WebAssembly в браузерах, они должны будут вести себя тем же образом (ну разве что работать быстрее).
  • Большую часть работы делает Emscripten, который является стабильным компилятором, давно используемым в продакшене и лишь относительно малая часть поверх него делается с помощью Binaryen (его код составляет всего пару тысяч строк). Меньше кода — меньше багов.


Всё это показывает, что мы уже имеем некоторый результат, можем скомпилировать код на С и С++ в WebAssembly и даже как-то его запустить.

Заметьте, что WebAssembly — всего лишь ещё одна новая фича, и, отвлёкшись от неё, всё остальное в Emscripten работает по-прежнему: Emscripten позволяет использовать libc и syscalls, OpenGL/WebGL код, интеграцию с браузерами, интеграцию с node.js и т.д. В результате проекты, которые уже используют Emscripten, смогут переключиться на WebAssembly просто добавлением нового параметра командной строки. И это позволит С++ проектам быть скомпилированным в WebAssembly и работать в браузерах без всяких усилий.

Использование нового экспериментального бекенда к LLVM для WebAssembly с Emscripten

Мы только что увидели новый важный этап в развитии Emscripten, который дал ему возможность создавать WebAssembly-модули и даже тестировать их работу. Но на этом работа не останавливается: это было всего-лишь использование текущего компилятора asm.js, вместе с утилитой asm2wasm. Есть новый бекенд к LLVM для WebAssembly (вернее пока ещё нет, но активно пишется) — прямо в основной ветке разработки LLVM. И, хотя он ещё и не готов для реального применения, со временем он станет очень важным инструментом. Binaryen поддерживает формат его выходных данных.

LLVM-бекенд для WebAssembly, как и большинство LLVM-бекендов, создаёт ассемблерный код, в данном случае в специальном .s-формате. Этот формат близок к WebAssembly, но не прямо идентичен ему — он скорее похож на вывод компилятора С (линейный список инструкций, одна инструкция на строку), чем на абстрактное синтаксическое дерево WebAssembly. Данный .s-файл может быть преобразован в WebAssembly достаточно тривиальным способом (в общем-то, Binaryen включает утилиту s2wasm, которая именно это и делает — посмотрите насколько она проста). Вы можете запустить её саму по себе, или использовать для этого Emscripten, который теперь поддерживает новую опцию WASM_BACKEND, которую вы можете использовать вот так:

emcc file.cpp -o file.js -s ‘BINARYEN=”path-to-binaryen”’ -s WASM_BACKEND=1


Обратите внимание, что вам также нужно использовать опцию BINARYEN, поскольку s2wasm это часть Binaryen. Когда все эти опции указаны, Emscripten использует новый бекенд для WebAssembly вместо использования компилятора asm.js. После вызова бекенда и получения от него файла в .s-формате Emscripten вызовет s2wasm для конвертации в WebAssembly. Несколько примеров программ, которые вы уже можете собрать подобным способом, вы можете найти на Вики проекта Emscripten.

Таким образом, у нас есть два способа собрать WebAssembly-модуль с использованием Binaryen:
  1. Emscripten + asm.js backend + asm2wasm, что работает уже прямо сейчас и должно быть относительно простым и приемлимым вариантом
  2. Emscripten + новый бекенд для WebAssembly + s2wasm, который пока не полностью рабочий вариант, но с развитием бекенда для WebAssembly будет выходить на первый план.


Цель на данный момент — сделать переход от первого способа ко второму как можно менее сложной. В идеале всё должно свестить к замене одного аргумента в командной строке.

Таким образом у нас формируется чёткий план:

  1. Используем Emscripten для генерации asm.js кода (уже сегодня)
  2. Переходим на генерацию WebAssembly через asm2wasm (уже можно, но ещё не готовы браузеры)
  3. Переходим на генерацию WebAssembly через новый LLVM бекенд (как только он будет готов)


Каждый шаг даёт новые преимущества пользователям (скорость!) и практически не вызывает сложностей у разработчиков.

В заключение хочу сказать, что хотя данная статья и написана о Binaryen в контексте его применения с Emscripten, это всё-ещё отдельная библиотека для WebAssembly общего применения. Если у вас есть идеи создания некоторых инструментов для работы с WebAssembly — вы можете взять библиотеку Binaryen и работать с ней, не оглядываясь на Emscripten, LLVM или что-то ещё.
Инфопульс Украина
Creating Value, Delivering Excellence
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 58

    0
    Интересно, получится ли современные js движки и рендеры html просто превратить в обычные библиотеки с wasm кодом для совместимости с существующим кодом, а новые веб приложения делать каким угодно образом?
      0
      Конечно, для того всё и затевалось. Всякие там ангуляры и jQuery не имеет никакого смысла парсить и выполнять как Javascript — это должен быть бинарный код, быстрый и эффективный, но в то же время не встроенный в браузер, чтобы была возможность оперативно его обновить.
      0
      Из новостей про реализацию в движках: неделю назад поддержка wasm была включена в v8 без флага компилятора, с рантайм-флагом --enable-wasm, но коммит оказался плохим, и на следующий день его откатили, поэтому пока v8 надо собирать самому. Чуть раньше какая-то поддержка прототипа появилась в jsc. Подозреваю, что скоро уже можно будет попробовать первую реализацию.
        +2
        Пожалуйста покажите исходный код Hello World которое можно было-бы запустить в браузере.Так же смогу ли я из С++ приложения манипулировать DOM — т.е. не значит ли это что скоро всякие Ангулары и JQuery уйдут прошлое и появится новое поколение более простых и удобных фреймворков.

        Плюс такой вопрос — есть ли шансы, что скоро вместо HTML можно будет QML использовать?
          +2
          1. Это переводная статья, и переводчики никому ничего не должны показывать :-)

          2. Да, сможете делать в том числе и это, при должной поддержке разработчиками компиляторов. WebAssembly разрабатывается именно как целевая платформа для компиляции, т.е. разработчики LLVM или backend GCC должны будут поддерживать WebAssembly как еще одну платформу.

          3. Вы какой именно QML имели в виду..?
            0
            видимо от Qt))
            0
            urho3d.github.io/HTML5-samples.html (чтобы мышь захватывалась примеры нужно развернуть на весь экран)
            Исходный код: github.com/urho3d/Urho3D
              0
              Пожалуйста покажите исходный код Hello World

              Самый обычный Hello World, ничего лишнего. Только браузера подходящего пока нет :)
              –7
              Flash умер, да здравствует кусок бинарного говна Flash!

              И до вэба проклятые ироды добрались.
                +5
                Не-не, флеш был закрытый, внешний по отношению к браузеру и неконтролируемый. А WebAssembly — бегает внутри браузера (быстро), безопасный, работает с тем же HTML5, а не строит свои велосипеды.
                  –5
                  Дело совершенно не в том, закрытый или открытый по отношению к браузеру. А в том, что эта хрень будет закрыта по отношению к пользователю.

                  Попробуйте-ка из бинаря рекламу вырезать, например.
                    0
                    С чего бы это? Она будет строить DOM-дерево, которое можно проинспектировать или изменить инструментами разработчика в браузере. Более того, разработчики браузеров вполне могут дать и возможность отладки WebAssembly (точки останова, трейсы, пошаговое выполнение). Что им мешает? Формат же полностью открыт и именно браузер его выполняет.
                      –1
                      Ассемблер и бинарный формат инструкций процессора тоже ни для кого не секрет. Однако попробуйте пореверсить какой-нибудь более менее большой проект.

                      Всё делается ради того, чтобы закрыть свой код от посторонних глаз. А аргументы могут быть самые разные: скорость, безопасность и так далее.
                        +1
                        Ну мне кажется популярные вещи (типа jQuery и Angular) сразу выпустят бинарники своих либ с исходниками и файлами символов, что сделает отладку тривиальной. Что касается остальных — хм… я даже не знаю, а какой-такой хитрый закрытый код может бежать в браузере, учитывая что всё, что он может — менять UI на страничке правками DOM-дерева?
                          0
                          А вам лично чем это поможет, что вы так за эту технологию обрадовались? Скорость, как правильно пишут ниже, не особо изменится. Затык в другом месте. Отладка пусть чуть-чуть, но станет геморнее (надо добывать дебаг символы теперь). Где профит-то?
                            0
                            А их и сейчас надо добавлять для отладки минифицированного JS-кода, браузеры это уже умеют. Профита нет, но и убытка тоже нет.
                              –1
                              Нет повода не выпить, однако!
                            +3
                            Серьёзно? А скажите мне, как соотносится с DOM набор пикселей внутри canvas? Или видео/звук из media?
                            И это всё не упоминая о привычке разработчиков считать своё приложение уникальным и единственным, и претендовать на 100% ресурсов пользователя. После чего рушить браузер при 50 открытых вкладках.
                              0
                              ничего не мешает повесить браузер/вкладку из javascript while (true) {} и вперед, в чем проблема?
                              для webAssebly сразу делаю восстанавливалку кода из бинарного формата
                                +1
                                Как я и говорил — у WebAssembley будут те же права и возможности, что и у javaScript, просто работать он будет быстрее. Как в JS вы можете работать с DOM или рисовать по canvas — так и там сможете, просто отрисовка какой-нибудь HD-сцены из пары текстур уже сможет работать на 50 fps, а не на 10 fps.
                          +2
                          Я не вижу принципиальной разницы между WebAssembly и минифицированным JS. Оба закрыты на одном уровне, из обоих одинаково сложно вырезать рекламу. И вырезать её всё равно будут не из них, а из построенного ими DOM.
                            +6
                            Смотрите на два шага вперед. Сначала вам сделают бинарный JS. Потом скажут: а нафига эта свистопляска с DOM? Пусть браузер тупо исполняет код и рисует в экран. Жаба-аплеты помните? То, что не удалось тогда Sun, потому что у них не было своего браузера, сейчас на ваших глазах сделает Google сотоварищи. Только следите за руками.
                              0
                              Свистопляска с DOM нужна пока, чтобы кормить миллионы дизайнеров и верстальщиков :) А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее. А вот провалидировать ввод регэксиком, сделать HTTP-запрос, распарсить JSON, как-то данные эффективно в памяти разложить и быстро искать — на С++ будет реактивно и приятно.
                                0
                                А в чем тогда преимущество по скорости? Ведь в браузере уже давным давно тормозит не JS, а DOM. Какая разница чем вы будете манипулировать DOM (хоть Ассемблером), ведь он сам является узким местом.
                                  0
                                  Цель wasm — не новый фреймворк вроде java и прочих, а для того, чтобы 1. тяжёлую логику сделать компилируемой, 2. позволить компиляцию из любых языков. Кстати в десктоп-приложениях проблема такого количечтва элементов, как требуется от DOM, тоже не решена никак, его не на что заменить.
                                    +2
                                    Декларируемая цель — да. А так: посмотрите, во что превратился ACPI из декларируемой цели сделать управление питанием простым и легким. Понимаю, что это далеко от вэб-разботки и гораздо ниже уровнем, но аналогия, как мне кажется, очень хорошая и показательная.

                                    Кроме того, ответ на вопрос предыдущего оратора в чем преимущество по скорости так и не дан. А если не скорость, то ради чего это всё?
                                      +2
                                      Ну представьте какую-нибудь игрушку в браузере. У неё некоторая часть нагрузки — это физический движок, который до этого надо было писать на Javascript и он тормозил, к примеру, для рассчета какого-нибудь там взрыва\дыма\блика\дождя. Теперь код рассчёта физики будет можно написать на С++, ну а отрисовывать как раньше — по канвасу (который тоже уже через DirectX рисуется с ускорением). Прикиньте — какое-нибудь там GTA в браузере будет работать, ну потому что нет никаких больше причин, почему бы оно не работало.
                                        0
                                        Вы либо путаете тёплое с мягким, либо путаетесь в показаниях.

                                        Если речь идет о неком бинарном intermediate language, чем мне представляется WebAssembly из того, что я прочитал, то там должно быть всё равно на чём писать. Вы будуте ограничены наименьшим из возможностей языка и возможностей WebAssembly. Таким образом, никаких преимуществ кроме вкусовщины вы не получите.
                                          –1
                                          Там и есть всё-равно на чём писать, просто писать будут на С\С++ :) Преимущества получаются от того, что это будет бинарный код, уже собранный под нужную архитектуру проца. И не надо тратить время на парсинг и интерпретацию javascript. Плюс можно делать такие прикольные штуки как реалтайм обработка видео, таймеры с точностью до сотен наносекунд, какой-нибудь массивчик на миллиард элементов в словаре и т.д. — попробуйте это на javascript написать.
                                            0
                                            Я ничего не понимаю. С какого рожна вэб-разрабы вдруг возьмуться за C++? А главное зачем, если то же самое можно написать на знакомом им JS, скомпилировать и вперде?

                                            Нет абсолютно никакого спроса на разработку вэб-логики на C++. Если оставаться в рамках вэб-логики.
                                              +3
                                              Так они и будут писать на «знакомом JS» — в смысле всякие «обычные» сайты. Просто те библиотеки, которые они сейчас используют (jQuery, Angular) будут переписаны на WebAssembly и начнут работать в разы больше. Но интерфейс у них останется тот же. Плюс добавляется возможность написать и «необычный сайт» — игрушку типа флешевой, презентацию, веб-редактор видео и т.д. — массивная логика больше не будет тормозить из-за неэффективности Javascript.
                                                +2
                                                А разве сейчас для JS не применяются JIT-компиляторы? А если они применяются, то есть какие-то общедоступные результаты профилирования, которые подтверждают, что проблема именно в JS?
                                              0
                                              Прочитал ваш измененный камент. Скажите, а вы сами разработчик? Как у вас в одном абзаце уживаются слова: «Там и есть всё-равно на чём писать» и «попробуйте это на javascript написать»?
                                                +2
                                                «Там и есть всё-равно на чём писать»

                                                Код можно будет написать на любом языке, для которого будет создан компилятор в WebAssembly. Первым появится компилятор для С\С++ (потому что LLVM его уже пилят), но потом, возможно, будут и другие.

                                                попробуйте это на javascript написать

                                                Имелось в виду «попробуйте это написать сейчас на javascript, выполняющемся в браузере без WebAssembly» — работать будет очень медленно.
                                                  0
                                                  Код можно будет написать на любом языке, для которого будет создан компилятор в WebAssembly. Первым появится компилятор для С\С++ (потому что LLVM его уже пилят), но потом, возможно, будут и другие.
                                                  Вообще как я понял emscripten занимается не компиляцией C/C++ в JS. Он занимается трансляцией LLVM биткода в JS, соответственно в WebAssembly можно скомпилировать любой язык, поддерживаемый LLVM. Уже можно. Но в статье почему‐то говорится только о C/C++.

                                                  Если я прав, то, соответственно, писать компиляторы в WebAssembly практически не будут. Будут в первую очередь писать компиляторы в LLVM биткод.
                                                    +2
                                                    Такой длинный спор и в качестве профита — пример в виде переписанного jQuery / Angular. Ну перепишут (ли? — прямо таки огромным «ли?») и будет работать на миллисекунду в секунду быстрее, но тормозить же все равно будет отрисовка. В большинстве случаев проблема в неэффективном использовании операций работы с DOM, что вызывают лишние перерисовки, перерасчеты размеров, положения элементов на странице и т.п., а не скорость работы с JS. Вот работа с аудио, видео, игродев и прочее — вот здесь профит может быть куда ощутимее.
                                                      0
                                                      Так о том и речь, что под видом мнимой производительности юзеры получат анальный зонд.
                                      0
                                      А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее.


                                      Дооо! Видимо от того, как быстро, гибко и красиво можно наструячить под HTML+CSS к каждому первому большому сайту теперь есть свой апп под iOS и Android. Следующий ход: сделать апп под браузер. Следующий ход избавится от отдельных аппов под мобильные платформы, превратив вэб в сплошные закрытые аппы.
                                        +1
                                        А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее.
                                        Почему быстрее не получится, расскажите?
                                          0
                                          Потому, что многие штуки из HTML+CSS просто не реализованы пока достаточно хорошо даже в мощных UI-фреймворках типа Qt и их придётся писать руками. А даже если реализованы — вы программистов на таком уровне знающих QML и всякие кутешные стили не найдёте даже 1% от количества дизайнеров и верстальщиков, знающих HTML+CSS.
                                            0
                                            Потому, что многие штуки из HTML+CSS просто не реализованы пока достаточно хорошо даже в мощных UI-фреймворках типа Qt и их придётся писать руками.
                                            Какие штуки? Можно хоть пару примеров?

                                            А даже если реализованы — вы программистов на таком уровне знающих QML и всякие кутешные стили не найдёте даже 1% от количества дизайнеров и верстальщиков, знающих HTML+CSS.
                                            Там для качественной верстки порог вхождения на порядок ниже, так что вопрос с количеством решится очень быстро, тем более что логика в QML и так пишется на JS.
                                        0
                                        Потом скажут: а нафига эта свистопляска с DOM? Пусть браузер тупо исполняет код и рисует в экран.
                                        И это будет просто шикарно, это я вам как QML разработчик говорю. Нельзя вырезать рекламу? Ну из мобильных приложений тоже нельзя, живем же как-то.
                                          0
                                          Шикарно? Ну сиюминутную выгоду в том, что вы, я и ещё 100 тысяч девелоперов внезапно станут востребованными на рынке вэб-разработки, получим. Но как быть с тем, что 7 млдр. людей (в том числе и мы с вами) получат очередной анальный зонд?
                                            0
                                            Мне кажется, вы неправильно трактуете термин «зонд». Еще раз: проблема только в том, что рекламу нельзя вырезать, верно?
                                              0
                                              Нет, реклама — это только самое первое и самое безобидное, что приходит на ум. В перспективе вы получите андроид или айос. Да, будет умерено безопасный браузер. Да, будут приложения с разными правами и браузер будет контролировать, чтобы они эти права не превышали. Но будет юзер, который будет собственноручно и слепо выдавать права приложениям, не имея в сущности возможности проверить на сколько добросовестно приложение этими правами пользуется. И только не надо в этом месте рассказывать про юзера, который сам себе злобный буратино, потому что у него не будет другой альтернативы.
                                                0
                                                Какие права? Как была песочница в браузере, так и останется.
                                                  +1
                                                  Это то, что вам сейчас обещают. Так было в своё время с ACPI, когда всем сунули открытую спецификацию и сказали: нафига ОС знать много подробностей об управлении питанием? Давайте сделаем AML, который будет хранится в BIOS, а в ОС будет интерпретатором этого кода.

                                                  Что имеем теперь? Теперь в каждом PC процессор иногда входит в System Management Mode. Ни ОС, ни кто-либо другой не может ни предсказать, когда это случается, ни посмотреть что за код исполняется в этот момент, потому что этот код закрыт даже от ОС (даже в бинарном виде). Потом к этому добавили UEFI и Management Engine, который также связан с этой фигней. Его работа является одним из самым больших секретов корпорации Intel (у AMD свой не менее секретный аналог). Даже разработчики BIOS'ов получают от Intel кусок бинарного говна, который они обязаны включить в свой BIOS и всё. Никаких сведений.

                                                  А всё начиналось так безобидно.
                                                    –1
                                                    Не могу согласиться с этой аналогией, она тут совершенно не применима.
                                                      0
                                                      Время нас рассудит.
                                                  +2
                                                  Приложения, работающие на WebAssembly будут иметь те же права, которые сейчас имеет javascript в браузере. И так же, как javascript, их выполнение можно будет отключить. Ничего с этой точки зрения не поменяется.
                                                    0
                                                    Вы сейчас нам рассказываете про то, с чем WebAssembly предстанет пред ясные очи общественности в первой версии. Мы же в этом треде обсуждаем скорее перспективы его развития.
                                                      –2
                                                      А, ну так захватит браузер и будет за всеми следить, конечно же :) Сейчас все так делают.
                                  0
                                  Это конечно все круто и быстро. У меня только один вопрос на сколько это будет безопасно?
                                  Давайте так я пишу на C++ под браузер, у меня есть указатель на адрес в памяти и я могу в теории, обратится к любому участку памяти текущего процесса, я бы не считал это особо безопасным. Можно таких дел натворить.
                                    0
                                    Вы и сейчас можете писать на C++ под браузер и переводить это через emscripten в asm.js. Это безопасно?

                                    WebAssembly исполняется в виртуальной машине. Он будет ровно настолько безопасным, насколько безопасной будет виртуальная машина: т.е. никаких отличий от текущего статуса с JavaScript, за исключением новизны и, как следствие, наличия пока не обнаруженных ошибок. От используемого языка безопасность не зависит совершенно; хотя на C++ вы будете иметь все шансы обратиться куда‐то не туда, это «куда‐то» может вести только в память машины.

                                    И, кстати, про безопасность написано прямо в README WebAssembly:
                                    WebAssembly is safe: WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.
                                      0
                                      Спасибо за объяснение.
                                      Код компилируется более предсказуемо с точки зрения безопасности из js нежели из c++. И всяких дыр там будет хватать, ладно пока в действии не увидишь, не узнаем, но будущие туманно.
                                        +1
                                        А как-будто js-код после интерпретации не превращается в машинный код, который байтики туда-сюда по памяти гоняет и инструкции на процессоре выполняет. А всяких там выходов за границы и переполнений не случается просто потому, что код интерпретатора хорошо отлажен. Вот и WebAssembly отладят.
                                          0
                                          В этом разница, что js проще контролировать, чем выполнение кода с возможностью прямого обращения к памяти. И отладить это все до надлежащего уровня будет ой как не просто.
                                            0
                                            а вы простите каким браузером пользуетесь?

                                  Only users with full accounts can post comments. Log in, please.