Буквально на днях в своем приложении на маркете тоже сделал вызовы Java из C++, но по другой причине (не хотел лишние библиотеки полключать для работы со шрифтами и картинками), проверил все на своих устройствах, на куче виртуальных андроидов всех версий.
Но в итоге сложилось все плохо — этот механизм нестабильный, у приложения рухнул рейтинг поскольку нашлось немало пользователей у которых все это дело падало, причем на ровном месте судя по краш-репортам.
Чуть ниже я уже написал, что не прав, автор действительно имел ввиду, то что написал.
Лисп построен исходя из математических моделей (как в общем-то и любой другой язык — теория компиляторов и все такое), но эти модели все равно ориентированны на архитектуру, т.е. делали так, чтобы язык максимально эффективно исполнялся на цифровых вычислительных машинах.
Имхо, тут как с курицей и яйцом, можно спорить бесконечно и правых не будет.
Перечитал статью внимательно и да — действительно, автор имел ввиду, то что имел ввиду. Я не прав — нет ошибок в изложении материала.
Но… Лисп — брал начало из математики, а фортран из архитектуры машин? Бог ты мой — откуда такие категоричные выводы?
1) Если подходить формально — все это математематика и архитектура — в программировании они всегда связанны.
2) Один простой факт о лиспе говорит что он машинно ориентированный — а именно польская запись всех выражений — зачем так сделали? говорят для скорости — так быстрей происходит разбор машиной выражений — это правда, и где тут математика? Все сделано в угоду машины, но не человека.
3) Фортран имел наиболее мощную математическую библиотеку в свое время, даже втроенный тип для комплексных чисел, огромное число математических вычислений проводилось именно на фортране. И все было сделано для людей, а не в угоду машине.
ПС. Короче, с автором статьи можно как минимум поспорить, не все тут однозначно.
Вы писали на лиспе и фортране? Лисп-машины вам о чем нибудь говорят? А то что на фортран математически ориентированный язык — это знал любой школьник в мое время. Я писал на обоих языках, и поэтому обратил внимание на ошибку в подаче материала, которая может ввести в заблуждение людей которые на застали данные языки.
Lisp и Fortran были ветвями двух различных древ эволюции. Один брал свое начало из математики, а второй – из архитектуры машин.
Я вот например понимаю, что из математики брал начало Fortran, а из архитектуры Lisp, но все же многие могут понять с точностью до наоборот, поскольку порядок изложения не совпадает в первом и втором предложении.
Я не про UPX, который кстати вообще не для этого предназначен — сжатые экзешники делались еще под RiscOS в конце 80-х и распаковывались без всяких проблем, надо быть полным чайником, чтобы такую защиту не снять.
Никто никому ничего не навязывает, кроме вас, просто получился неплохой вариант, решили поделиться, к чему эти нападки?
Если читали статью — цель — защитить от дурака с hex-редактором подмену оригинальных строк — не больше не меньше.
1) За минуту ни у кого не получится, как минимум придется найти участок где код выводится, написать патч для программы, чтобы подменить оригинал на что-то свое, поскольку в случае с открытым и закрытым ключем не выйдет просто поменять данные зная алгоритм шифрования. Да это легко ломается — если умеешь, строго говоря любая защита ломается, все зависит от оправданности взлома.
2) И что? Почему это должно считаться аргументом в пользу запрета на подобные решения в тех местах где они достаточны?
3) Все это лирика, а PVS-студию я не разрабатываю, но думаю прожует и не подавится.
По поводу всего остального — никто не заставляет пользоваться такими методами, и ни кто не спорит, что специальные инструменты эффективней, но вот только не надо говорить, что при малейшей мысли о защите от мелких хулиганов нужно хвататься за гранатомет.
1..2) На весь код влияет упаковщик, и уж точно не показанный пример в статье.
3) У вас вылезла портянка в указанном примере? Что там хитроумного? По вашей логике — вообще нельзя использовать шаблоны, макросы — вообще ничего, может вы язык не тот используете?
Видимо кто-то тут разрабатывает обфускаторы и очень неуютно начинает себя чувствовать в свете новых возможностей языка и начинает агрессивно втыкать, что так делать ни в коем разе нельзя. Все ваши доводы абсолютно надуманные — хоть сто минусов мне наставьте.
Все это надуманно, но отвечу:
1) Если есть новый стандарт и он имеет практическую пользу, его нужно внедрять, а не уповать на сторонние решения, требующие еще и капиталовложений, чем больше будет решений на его базе — тем быстрее подтянутся разработчики компиляторов.
2) Если для программиста какой-то там велосипед в коде (в виде одного единственного макроса) — есть проблема, тогда стоит задуматься о его компетентности.
3) Зачем о нем помнить, и что должен о нем подсказывать компилятор?
Кроме того внешние обфускаторы вносят в код не мало тормозов и местами их даже требуется отключать. Подделкой копирайтов, например, занимается обычно школота, которая хочет потроллить бесплатный, но закрытый в плане кода проект — там не нужен профессиональный инструмент, и тем более нет желания за него платить в бесплатном продукте. Лишний build step — как правильно сказанно — лишний.
Вроде про студентов с лабами речь? Там ничего невозможного в плане просмотра машинного кода нет, курсовой еще соглашусь. А за 1-20 лабораторной работы — ну это должен быть очень крутой студент, чтобы столько наваять, но в таком случае он наверное уже и опытный должен быть…
Если все работает, он и сообщения анализатора проверять не будет. А с анализатором и в дизассемблер не полезет — зачем — починил — все ОК, ради чего вдаваться в подробности?
Понятное дело — можно пользоваться анализаторами и отдельно курс про ошибки пройти с детальным рассмотрением. Но теория обычно плохо усваивается.
Если надо готовить не системных программистов, а прикладников, то С++ уже не вариант и проблем таких не будет.
Но даже в упомянутом случае, если студент от безысходности полезет в дизассемблер — это ему только в плюс пойдет. Хотя как вариант в случае безысходности, можно и к анализатору прибегнуть.
Обходя аккуратно разложенные грабли, мы теряем ценный опыт.
Не за что! :) У меня та же история была — продали консоль со всеми дисками и купили ПК (на базе P-200MMX). потом спустя пять лет я купил несколько 3DO для экспериментов и занялся эмуляцией.
Но в итоге сложилось все плохо — этот механизм нестабильный, у приложения рухнул рейтинг поскольку нашлось немало пользователей у которых все это дело падало, причем на ровном месте судя по краш-репортам.
Имхо — плохая идея, на своей шкуре убедился =)
Это Borland Builder мусорит. Хотя использовать его сейчас как-то странно и нелепо.
Лисп построен исходя из математических моделей (как в общем-то и любой другой язык — теория компиляторов и все такое), но эти модели все равно ориентированны на архитектуру, т.е. делали так, чтобы язык максимально эффективно исполнялся на цифровых вычислительных машинах.
Имхо, тут как с курицей и яйцом, можно спорить бесконечно и правых не будет.
Но… Лисп — брал начало из математики, а фортран из архитектуры машин? Бог ты мой — откуда такие категоричные выводы?
1) Если подходить формально — все это математематика и архитектура — в программировании они всегда связанны.
2) Один простой факт о лиспе говорит что он машинно ориентированный — а именно польская запись всех выражений — зачем так сделали? говорят для скорости — так быстрей происходит разбор машиной выражений — это правда, и где тут математика? Все сделано в угоду машины, но не человека.
3) Фортран имел наиболее мощную математическую библиотеку в свое время, даже втроенный тип для комплексных чисел, огромное число математических вычислений проводилось именно на фортране. И все было сделано для людей, а не в угоду машине.
ПС. Короче, с автором статьи можно как минимум поспорить, не все тут однозначно.
Я вот например понимаю, что из математики брал начало Fortran, а из архитектуры Lisp, но все же многие могут понять с точностью до наоборот, поскольку порядок изложения не совпадает в первом и втором предложении.
Этого делать не нужно, а вот minSdkVersion должен быть доступен в NDK.
Никто никому ничего не навязывает, кроме вас, просто получился неплохой вариант, решили поделиться, к чему эти нападки?
1) За минуту ни у кого не получится, как минимум придется найти участок где код выводится, написать патч для программы, чтобы подменить оригинал на что-то свое, поскольку в случае с открытым и закрытым ключем не выйдет просто поменять данные зная алгоритм шифрования. Да это легко ломается — если умеешь, строго говоря любая защита ломается, все зависит от оправданности взлома.
2) И что? Почему это должно считаться аргументом в пользу запрета на подобные решения в тех местах где они достаточны?
3) Все это лирика, а PVS-студию я не разрабатываю, но думаю прожует и не подавится.
По поводу всего остального — никто не заставляет пользоваться такими методами, и ни кто не спорит, что специальные инструменты эффективней, но вот только не надо говорить, что при малейшей мысли о защите от мелких хулиганов нужно хвататься за гранатомет.
3) У вас вылезла портянка в указанном примере? Что там хитроумного? По вашей логике — вообще нельзя использовать шаблоны, макросы — вообще ничего, может вы язык не тот используете?
Видимо кто-то тут разрабатывает обфускаторы и очень неуютно начинает себя чувствовать в свете новых возможностей языка и начинает агрессивно втыкать, что так делать ни в коем разе нельзя. Все ваши доводы абсолютно надуманные — хоть сто минусов мне наставьте.
1) Если есть новый стандарт и он имеет практическую пользу, его нужно внедрять, а не уповать на сторонние решения, требующие еще и капиталовложений, чем больше будет решений на его базе — тем быстрее подтянутся разработчики компиляторов.
2) Если для программиста какой-то там велосипед в коде (в виде одного единственного макроса) — есть проблема, тогда стоит задуматься о его компетентности.
3) Зачем о нем помнить, и что должен о нем подсказывать компилятор?
Кроме того внешние обфускаторы вносят в код не мало тормозов и местами их даже требуется отключать. Подделкой копирайтов, например, занимается обычно школота, которая хочет потроллить бесплатный, но закрытый в плане кода проект — там не нужен профессиональный инструмент, и тем более нет желания за него платить в бесплатном продукте. Лишний build step — как правильно сказанно — лишний.
Оптимизация сыграла злую шутку — сейчас поправим…
Понятное дело — можно пользоваться анализаторами и отдельно курс про ошибки пройти с детальным рассмотрением. Но теория обычно плохо усваивается.
Но даже в упомянутом случае, если студент от безысходности полезет в дизассемблер — это ему только в плюс пойдет. Хотя как вариант в случае безысходности, можно и к анализатору прибегнуть.
Обходя аккуратно разложенные грабли, мы теряем ценный опыт.