[КТЛ]

ALAKK я не хочу с тобой общаться.
Я тебе не хочу доказывать.
Живи в своем мире ты не достоин пока. 

[КТЛ]

Все прекрасно понимают что можно взломать любую работу и Пентагон тоже.
СAD (САПР-система автоматизированного проектирования )  создана для того чтобы была совместная работа.
По поводу защиты для новичка подойдет   и HideScripts  а для серозной базы только ОДОН и то не каждый.
Я согласен на разработку серьезной базы в которой будет:
1 - 3Д
2 - 2Д
3 – Где можно купить (диван, стол, кухню и т. д.)
4 – Цена изделия
5 – привязка к бухгалтерии и снабжению  (для производителя )
6 – привязка к станкам ЧПУ (для производителя )
Понятно что надо постоянно обновлять .
Вы приставьте какой золотой запас можно собрать
А сколько за такое готовы отдать серьезные предприятия.

[crazyASD]

ALAKK я не хочу с тобой общаться.
Я тебе не хочу доказывать.
Живи в своем мире ты не достоин пока. 

Первое предупреждение - Наврушение правил форума
А товарищ Alakk на сегодняшний день один из самых продвинутых в GDL программировании людей. Говорит тебе дело, т.к., имеет богатый опыт разработки этих самых объектов.
И еще, мое мнение насчет зарабатывания денег. Ты идешь по изначально неверному пути. Продать что-либо у нас конечному потребителю практически нереально. Уж очень жмотлив и мелочен потребитель. Ему легче утащить, или на худой конец самому сделать, чем купить, пусть даже за символические деньги. Не раз встречался с этим.
Мое мнение на этот счет, как и собственно во всем остальном мире - выходить напрямую на производителя, и по его заказу изготавливать требуемые элементы. Тогда все будет на договорной основе, проблем с гонорарами и боязнью плагиата будет практически исключена.

[ufo]

Улудшить защиту GDL средствамиможно, если не тупо Callить на обработку открытия файла, а получать из файла какие либо данные нужные для самой программы (куски кода невозможно значит получить можно какие либо константы только) в самой подпрограмме размещать куски кода из основной програмы.
Проблемма в том что автоматически ты такую защиту не напишеш придется долго парится и ломать голову, весь расчет в такой защите что тот кто ее смотрит устанет проверять и подбирать различные значения.
Лично я бы не стал бы взламывать такую защиту и вычеслять баги вызваные отсутствием констант (особенное если их много), просто бы посмотрел используемые параметры и написал свой скрипт

[deeper]

Народ

можно мне высказать мнение С++ девелопера которые пишет плугины для разных продуктов уже лет десять, таких как Macromedia Director, REALbasic, Revolution, VB, NET, PHP, Ruby, ....

Чтоб решить вашу задачу красиво надо всего лишь чтобы Graphisoft реализовал функцию защиты скрипта, как раз для помощи разработчикам скриптов которые НУ НЕ ХОТЯТ отдавать свой код. Такая фишка есть например в REALbasic.

Так что проще вам люди сходить на Graphisoft и оставить там фиатуре реквест. Потом добавить на нее голосов как можно больше. Поболтать на их форуме чтоб услышали. Сделать им это типа 3-5 человеко дней.

[mr.Mikhail]

Хочу поднять вопрос, как можно реализовать использование объектов на определенном компьютере, но при этом чтобы не было проблем с использованием на нескольких запущенных сеансах архикада на этом компьютере.

Запароленный объект это конечно хорошо, но при этом использовать его можно на любом кол-ве компьютеров.

Из того, что я уже начитал:
1 вар.) Таймер после которого объект выводит сообщение и соответственно выполнение скрипта останавливается.
2 вар.) Собирать определенную уникальную информацию о системе скриптом и формировать какую-то уникальную последовательность символов (опять же автоматически по какому-то алгоритму) и прописывать ее на проверку в объекте. Получится что для каждого пользователя будет свой объект. (поднимать вопросы "как это планируется поддерживать" не нужно, тут все риски и трудозатраты понятны, возможно достаточно сделать через какой-нибудь макрос аля мастер-объект, тогда поддержка будет проще)
Скорее всего без аддона сделать наверно не получится, потому что нужно, чтобы при каждом открытии сеанса архикада происходило считывание информации о системе и формирование уникальной записи и объект уже обращаясь к аддону, или временному файлу генерируемому аддоном на время работы сеанса, делал сравнение записи сохраненной внутри.

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

[Ivanov_Valeriy]

Закажите в Питере ключи с операционкой внутри и либо сами либо к Юре Цепову. Они копейки стоят. Но здесь вы похоже ждете , что кто то всерьез будет вас просвещать как он  реализовал защиту? У меня реализована. И зачем мне кричать об этом на всех ресурсах. Защита это интимное. Личное.   

[mr.Mikhail]

Закажите в Питере ключи с операционкой внутри и либо сами либо к Юре Цепову. Они копейки стоят. Но здесь вы похоже ждете , что кто то всерьез будет вас просвещать как он  реализовал защиту? У меня реализована. И зачем мне кричать об этом на всех ресурсах. Защита это интимное. Личное.   

Валерий у Вас же у самого стоит подобная проблема, что ваши объекты которые вы продаете можно использовать на любом компьютере.

Я хочу обсудить вариант самого принципа, а не конкретную реализацию.

[Ivanov_Valeriy]

у меня нет проблемы. Я ее решил давно.

[Vladimir57]

Какова Ваша цель?
Если Вы хотите продавать библиотечные объекты - это одно. Если просто на фирме сохранить зксклюзивность -это другое.
Лично я заказывал и покупал объектов на приличную сумму. И скажу, никогда бы не купил объект привязанный к конкретномку компьютеру - это очень неудобно.
Мне много платных объектов сделали просто под честное слово, без всякой кодировки и я его, слово, ниразу не нарушил и не нарушу.
Если уж очень захотят украсть все равно украдут, но это не стоит затрат.
Но есть возможность, например, просто закодировать по времени использования. Правда, время можно откатить назад и объект опять работает, но начинаются проблемы с почтой, паролями и прочий геморой.
Если вы передаете свою модель другим пользователям, то можно просто сделать, чтобы у объктов отсутствовал интерфейс, тогда объект будет присутствовать везде в модели, включая спецификации, но изменить в нем какие-либо параметры те, кому вы передали модель, не смогут.
Еще можно закодировать объект по номеру лицензии, но это решение для лицензионных пользователей.
Если вы думаете зарабатывать на объектах, то они должны быть какими-то уникальными, а таких специалистов, которые могут их писать очень мало, но они есть.
Решение зависит от стоящих задач.

Хочу поднять вопрос, как можно реализовать использование объектов на определенном компьютере, но при этом чтобы не было проблем с использованием на нескольких запущенных сеансах архикада на этом компьютере.

Запароленный объект это конечно хорошо, но при этом использовать его можно на любом кол-ве компьютеров.

Из того, что я уже начитал:
1 вар.) Таймер после которого объект выводит сообщение и соответственно выполнение скрипта останавливается.
2 вар.) Собирать определенную уникальную информацию о системе скриптом и формировать какую-то уникальную последовательность символов (опять же автоматически по какому-то алгоритму) и прописывать ее на проверку в объекте. Получится что для каждого пользователя будет свой объект. (поднимать вопросы "как это планируется поддерживать" не нужно, тут все риски и трудозатраты понятны, возможно достаточно сделать через какой-нибудь макрос аля мастер-объект, тогда поддержка будет проще)
Скорее всего без аддона сделать наверно не получится, потому что нужно, чтобы при каждом открытии сеанса архикада происходило считывание информации о системе и формирование уникальной записи и объект уже обращаясь к аддону, или временному файлу генерируемому аддоном на время работы сеанса, делал сравнение записи сохраненной внутри.

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

[mr.Mikhail]

Какова Ваша цель?
Если Вы хотите продавать библиотечные объекты - это одно. Если просто на фирме сохранить зксклюзивность -это другое.
Лично я заказывал и покупал объектов на приличную сумму. И скажу, никогда бы не купил объект привязанный к конкретномку компьютеру - это очень неудобно.
Мне много платных объектов сделали просто под честное слово, без всякой кодировки и я его, слово, ниразу не нарушил и не нарушу.
Если уж очень захотят украсть все равно украдут, но это не стоит затрат.
Но есть возможность, например, просто закодировать по времени использования. Правда, время можно откатить назад и объект опять работает, но начинаются проблемы с почтой, паролями и прочий геморой.
Если вы передаете свою модель другим пользователям, то можно просто сделать, чтобы у объктов отсутствовал интерфейс, тогда объект будет присутствовать везде в модели, включая спецификации, но изменить в нем какие-либо параметры те, кому вы передали модель, не смогут.
Еще можно закодировать объект по номеру лицензии, но это решение для лицензионных пользователей.
Если вы думаете зарабатывать на объектах, то они должны быть какими-то уникальными, а таких специалистов, которые могут их писать очень мало, но они есть.
Решение зависит от стоящих задач.

По-моему заказывание объекта у кого-то для себя и создание объектов с целью зарабатывания на них две абсолютно противоположные вещи.
Поводу уникальности согласен, обратились с подобной задачей, стало интересно.
Цель:
Чтобы после продажи библиотеки недобросовестному пользователю, который публикует/раздает/распространяет без договоренностей с разработчиком (аля пиратит) и не купившие библиотеку пользователи не могли использовать её в своих проектах.

По поводу отсутствующего интерфейса не понял. Мне казалось, что это следствие какой-то проверки, что "вот мы установили, что объект использует пират" и поэтому делаем какие-то ограничения.

[bImaginaire]

Решение довольно простое. Все библ. элементы надо запаролить. Также все элементы должны содержать в скрипте параметров HIDEPARAMETERS ALL (и дальше список тех, которые все-таки показывать - например A, B, ZZYZX). Потом у каждого объекта должен быть UI (интерфейс). А также некий макрос, который проверяет номер лицензии из списка - скажем у компании 10 лицензий - все десять номеров записываются в массив переменной. Перед выполнением скрипта интерфейса программа обращается в макрос - там скрипт сопоставляет эти номера и выдает 1 или 0 и возвращает значение в основной объект. Если ноль - интерфейс блокируется и пишется что-то вроде "это не лицензионная версия библиотеки, модификация элемента заблокирована". Можно также заблокировать движущие точки (editable hotspots).
А насчет того, что это не будет работать на пиратской версии ArchiCAD, так как она будет всегда возвращать номер лценции ноль - ну так ребята, не используйте пиратский софт. Желание работать на пиратском Архикаде и в тоже самое время пытаться защитить лицензией библиотечные элементы от пиратства выглядит как то странно.

Еще один нюанс. Как так Графисофт перешел от физических ключей защиты к закодированным файлам, надо использовать 
n=REQUEST ("Configuration_number", "", ...) - это "string" который начинается с SW... и длинным номером
Если все-таки компания использует физический ключ, тогда надо запрашивать его номер через:
REQ("Serial_number")

Нельзя запрашивать серийный номер ключа, если он не физический. У софт-ключа тоже есть серийный номер, но он меняется каждый раз когда файл лицензии загружается на компьютер (например надо загружать на сервер и обратно в компьютер ключ после серьезных обновлений операционной системы).  

Скрипт может выгладить как-то так:

Макрос:
licenseConfNum[n][2] - массив в параметрах элемента, который хранит номера лицензий

Скажем где в два столбца будет записываться:
Номер лицензии   Описание
SW00001234   Мой компьютер
SW00012345   Компьютер кого-то
SW00123456   Компьютер еще кого-то


Мастер скрипт:
IF GLOB_SCRIPT_TYPE<>5 THEN
   n=REQUEST ("Configuration_number", "", stConfigurationNumber)
   mylicense=0
   IF n THEN
      FOR i=1 TO VARDIM1(licenseConfNum)
         IF licenseConfNum[1]=stConfigurationNumber THEN mylicense=1
      NEXT i
   ENDIF
ENDIF

2Д скрипт:
END mylicense

3Д скрипт:
END mylicense

UI скрипт:
IF NOT(mylicense) THEN
   UI_DIALOG "ЛИЦЕНЗИЯ НЕ НАЙДЕНА!", 444, 296
   
   UI_STYLE 2,1
   
   UI_OUTFIELD   "Это лицензионная версия библиотеки", 35, 5
   UI_OUTFIELD   "Все параметры заблокированы.", 35, 20
   UI_OUTFIELD   "Обратитесь к разработчикам за лицензией:", 35, 35
   
   UI_BUTTON UI_LINK, "mymail@mail.com", 100, 150, 250, 30, 0, "mailto:mymail@mail.com?Subject=ArchiCAD%20Library%20License"
ENDIF
END mylicense

В основном объекте мастер скрипт начать так:
CALL "LicenseMacro" PARAMETERS RETURNED_PARAMETERS mylicense

И UI начать так:
IF NOT(mylicense) THEN END

Вот и все, что я могу сказать про Вьетнам.

[ufo]

bImaginaire,
Какой-то неправильный линейный подход, получается для каждого нового пользователя вам нужно разработать свой новый библиотечный элемент,  к тому-же как наберется пару тысяч ключей не будет ли такой элемент подтормаживать? Имхо должно быть реализовано через ключ,  который генерируется по запросу от пользователя на основании серийного номера,  в библиотечном элементе должен быть обратный алгоритм который из ключа генерирует серийный номер и сравнивает его с серийным номером. По идее при генерирование ключа должно быть что то вроде хеш-таблицы чтобы на основании 1 пары значений ключ-серийник , нельзя было вычислить все остальные, учитывая что ответную часть писать на GDL дело не простое.

[bImaginaire]

что-то вы тут неправильно поняли. Совершенно не нужно создавать новый объект для нового пользователя - номера ключей защиты прописываются в одном массиве. Скрипт сверяет ключ защиты ArchiCAD с номером, прописанном в параметрах макро-объекта. Все элементы библиотеки обращаются к одному макро-объекту, запрашивая информацию - совпадают ли номера ключа защиты.

Скажем, это большая компания на 50 компьютеров - а это на самом деле большая компания. В этом случае массив будет иметь 50 переменных - что не будет никак тормозить.

[ufo]

что-то вы тут неправильно поняли. Совершенно не нужно создавать новый объект для нового пользователя - номера ключей защиты прописываются в одном массиве. Скрипт сверяет ключ защиты ArchiCAD с номером, прописанном в параметрах макро-объекта. Все элементы библиотеки обращаются к одному макро-объекту, запрашивая информацию - совпадают ли номера ключа защиты.

Скажем, это большая компания на 50 компьютеров - а это на самом деле большая компания. В этом случае массив будет иметь 50 переменных - что не будет никак тормозить.

На практике будет все наоборот будет 50 заказов от разных организаций, в разное время и вам постоянно надо будет добавлять новые серийники в элемент.