Пограв трохи з 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 захищає нас від цього? Дуже просто.
Друга небезпека - код в даних, адже майже будь-які послідовності байт це якийсь машинний код, таким чином можна запросто заховати код всередині тексту, а потім виконати перехід на цей текст. Зрозуміло, що володіючи можливістю обмежити переходи, цю проблему вирішити нескладно - розносимо код і дані на різні регістри сегментів і не даємо коду переходити на дані. Тут нічого складного, перший випадок був цікавіше.
Цікаво, що код, який контролює безпеку і реалізує SRPC, вийшов дуже невеликий, в ролику на YouTube розробник говорить то про 6000 рядків, то про 6000 байт. У будь-якому випадку, те й інше - трохи. Там же (в ролику) показували інтерпретатор Ruby, який працює в браузері. Це цікаво, але не більше, цікавіше те, що код на Сі (або там C ++, неважливо) довелося міняти дуже мало, щоб перекомпіліровать його в Google Native Code.
Мені здається, це цікавий проект.
Це не стандарт, а чернетку. У стандарт HTML тег embed, наскільки я знаю, не входив. Це просто черговий пропріетарний нетскейпово / мозілловий ті
VIDEO теж не стандарт, проте, у всіх сучасних браузерах є. Ну як би не дарма є далекі і близькі Джамп. Процесорний кеш теж, думаю не схвалить роззування обсягів коду мало не на порядок.
Як би там не було, сперечатися нема про що, розробники вже озвучили цифри. Ну дивись. майже весь C # код юзабелен в Silverlight. А яка частка C коду працює через NPAPI або SRPC? Мені здається, що все одно доведеться багато всього переписувати під цю нову платформу
В тому-то й сенс, що зміни мінімальні. Це підтверджує, наприклад, Quake для Native Client. Я б все-таки назвав це чутками. Знову ж дивно, що цей слух про Microsoft - єдина подія, де якому згадується IA-128.
Ну, мені все одно. У будь-якому випадку, перехід на 128 біт трапиться, з такими темпами розвитку, в найближчі 5-7 років.