Забавная была игрушка «Wolf5K». Это игра на JavaScript, занимающая пять килобайт (!). Был такой конкурс когда-то — «The 5K», цель — уместить что-нибудь толковое в 5 килобайт.

Ребята произвели фурор тогда, они уместили в этот размер небольшую псевдотрёхмерную бродилку. Никаких CANVAS! Хитрость в том, что вся графика (кроме кровищи) делается в формате XBM и передаётся тегу IMG через схему «javascript». Игрушка работала в IE5, IE6, Mozilla 1.1+ и Netscape 4.77 для Мака.

Формат XBM — это текстовый формат чёрно-белых картинок (я даже когда-то делал библиотеку для PHP Image::XBM). Его удалили из IE в SP2, работает ли это до сих пор в Gecko-браузерах я не знаю (у меня сейчас не установлен FF, а ставить лень), а «Опера» не читает графику через схему «javascript», так как никогда не делает попыток угадать контент по содержанию. Только по MIME-типу.

В общем, захотелось мне почему-то вспомнить эту игрушку, а она у меня не работает. Ну, делов-то. Заменить схему «javascript» на чуть доработанную «data». Вот патч, нужно открыть окно игры, скопировать его в строку браузера и нажать «Enter»:

javascript:void(eval(X.toString().replace(/"j.*?;"/, '"data:image/x-xbitmap," + encodeURI(im)')))

В IE по-прежнему работать не будет (в нём нет XBM), в «Хроме» тоже не должно, в «Опере» — заработает. Если у кого-нибудь установлено что-то ещё, попробуйте и скажите получилось ли.

Добавлено утром: читатели сообщают, что в «Сафари» тоже работает.

Существуют эмуляторы на JavaScript следующих платформ: GameBoy, ZX Spectrum, Радио-86РК (мой первый компьютер, между прочим), Nintendo NES, Commodore 64.

Естественно, нужен какой-нибудь хороший браузер, например, «Хром» или «Опера» 10.60 и выше.

Есть где поностальгировать. Думаю, лет через 5—10 появится эмулятор PSP на JavaScript с использованием WebGL, мощностей как раз хватит.

Поиграл немного с Google Native Client — это плагин для браузера (поддерживаются Firefox, «Опера», «Сафари» и «Хром» и платформы Windows, Mac и Linux на x86, x86-64 и ARM).

Это плагин, который умеет исполнять скомпилированный бинарный (!) код в браузере. В каком-то смысле это напоминает ActiveX. Вы пишете бинарный код, компилируете его в специальной версии gcc, а потом просто встраиваете в браузер тегом EMBED.

Меня интересовало как тут соблюдается безопасность. Коду многое запрещено (по сути, всё, что разрешено — это эффективное использование процессорного времени, за остальным нужно обращаться в браузер через NPAPI или SRPC (Simple RPC)), но разработчики много говорят о том, что допускаются ассемблерные вставки.

Как так?

Ларчик, как оказывается, открывается просто и достаточно остроумно. Во-первых, разработчику запрещается использовать некоторые конструкции, например INT (вызов прерывания) и некоторые другие. Во-вторых, команды переходов модифицированы и это самое интересное.

Не знаю как там в процессорах ARM, а в x86 команды могут иметь разную длину, какая-нибудь «PUSH AX» занимает байт, «MOV AL,41» — два, « MOV AX,[BP+8]» — три и так далее. Если сделать переход не на первый байт команды (а, например, на второй байт команды «MOV AL, 41»), то окажется, что оставшаяся последовательность (возможно с байтами, которые идут дальше) тоже что-то означает (в случае «MOV AL, 41» второй байт будет «41», это команда «INC CX»).

Это даёт возможность замаскировать внутри команды любую запрещённую команду и выполнить её, сделав переход не на первый байт. Как Google Native Client защищает нас от этого? Очень просто.

В Ассемблере есть специальная команда — «NOP» (в x86 занимает один байт, её код — «90»), она не делает ничего. Все команды вашей программы выравниваются до 16 байт этой командой. То есть «MOV AL,41» будет дополнена 14-ю командами «NOP», а все переходы разрешаются только на границу этих 16-ти байт. Для этого у адреса перехода всегда отрезаются несколько младших бит.

Вторая опасность — код в данных, ведь почти любые последовательности байт это какой-то машинный код, таким образом можно запросто спрятать код внутри текста, а потом выполнить переход на этот текст. Понятно, что обладая возможностью ограничить переходы, эту проблему решить несложно — разносим код и данные на разные регистры сегментов и не даём коду переходить на данные. Тут ничего сложного, первый случай был интереснее.

Интересно, что код, контролирующий безопасность и реализующий SRPC, получился очень небольшой, в ролике на YouTube разработчик говорит то о 6000 строк, то о 6000 байт. В любом случае, то и другое — немного. Там же (в ролике) показывали интерпретатор Ruby, работающий в браузере. Это интересно, но не более, интереснее то, что код на Си (или там C++, неважно) пришлось менять очень мало, чтобы перекомпилировать его в Google Native Code.

Мне кажется, это интересный проект.

В Mail.Ru потихоньку рождается новый термин? «Микроболк». Чувствую себя Доктором Зло.