Створення інсталятора, Різне, Програмування, статті

Створену нову версію програми, в принципі, вже можна поширювати серед користувачів. Запакувати ЕХЕ-файл ZlP-архіватором, додати в цей архів readme-файл і файл довідки, і розмістити отриманий ZIP-файл в Інтернеті. Однак для серйозної shareware-програми цього мало. Потрібно створити до свого продукту спеціальну програму установки, або, як її ще називають, інсталятор (“install” – встановлювати)

Чому shareware-програмі необхідний інсталятор? На це є кілька причин:


Деякі автори програм, почавши розповсюдження своїх продуктів на російському ринку і як freeware, звикли до того, що інсталятор до них робити не потрібно. Деякі з розробників навіть з гордістю роблять приписку до опису своєї програми: “Не вимагає інсталяції”. Це з одного боку, виправдано: користувач може бути впевнений, що процес копіювання програми на диск його комп’ютера буде під його контролем системні налаштування будуть відредаговані без його відома або в папку WINDOWS / SYSTEM не буде записано ніяких “лівих” файлів. Правда, все це може бути зроблено вже самою програмою при першому запуску її ЕХЕ-файла. З іншого боку, недовіра до інсталяторам з боку користувачів в основному обумовлено низькою надійністю старих версій Windows (наприклад, 3.х) і поганою якістю програм сторонніх розробників, що з’явилися на ринку в той час, – наприклад, механізм видалення вже встановленої під Windows програми працював малоефективно. Зараз, після дуже великого для індустрії інформаційних технологій періоду часу, ситуація сильно змінилася, і більшість користувачів розглядають інсталятор як помічника в роботі, а не тягар, придуману авторами програм для засмічення жорстких дисків користувачів.

Зі збільшенням обсягу продажів через Інтернет, бумом shareware, скороченням частки “коробкових” продуктів на ринку і перехід деякої їх частини в розряд shareware, інсталятор став грати роль не тільки програми установки, а й “упаковки” програмного продукту, що має велике значення в справі захисту авторських прав.

Справа в тому, що в той час, коли більшість платних продуктів були “коробковими”, тобто продавалися у фірмовій упаковці, ліцензійна угода, в якому правовласник дозволяв використання програми, друкувалося прямо на цій упаковці. Текст ліцензійної угоди обов’язково починався зі слів: “Розкриваючи упаковку даного програмного продукту, Ви підтверджуєте свою згоду з умовами цього ліцензійної угоди “. Ліцензійні угоди навіть стали називати” обгортковими ліцензіями “, т, е. ліцензіями, опублікованими на упаковці.

Після того як все більше програм стало поширюватися по комп’ютерних мережах, в тому числі і через Інтернет, термін “обгорткова ліцензія” став втрачати сенс – адже “обгортки” як такої вже не було! І тоді роль упаковки став грати інсталятор: перед початком процесу установки продукту він демонструє користувачеві текст угоди і вимагає поставити прапорець або перемикач Згоден для продовження установки. А слова “Розкриваючи упаковку даного програмного продукту …” замінилися на “Встановлюючи даний програмний продукт …” Таким чином, ліцензійна угода, оформлена в електронному вигляді, продовжують називати “обгорткового ліцензією”.

Звичайно, не можна не згадати про те, що іноді без інсталятора просто не обійтися – наприклад, коли для нормальної роботи встановлюваної програми потрібно скопіювати в папку WINDOWS / SYSTEM і зареєструвати в системі ActiveX-і DLL-бібліотеки, типи файлів і т. п.

Самостійна підготовка інсталятор – досить проста справа. Існує величезна кількість продуктів незалежних розробників (як безкоштовних, так і shareware і комерційних), що дозволяють створювати про-грами установки. Яку з них віддати перевагу? Давайте подивимося, на які параметри потрібно звернути увагу при виборі програми створення інсталяторів.

Спочатку, економічність. Здавалося б, для будь-якої програми головне – це функціональні можливості, але тут вони відходять на другий план. Перше, на що варто звернути увагу при розгляді програми створення інсталяторів – обсяг файлів, які вона генерує. Адже функції і діалогові вікна інсталятора також вимагають певного простору на диску, в результаті файл інсталятора разом із які в ньому стиснутими файлами програмного продукту виявиться дещо більше, ніж, наприклад, обсяг ZlP-архіву з тими ж файлами всередині.

Ця різниця між “звичайною” архівом і інсталятором існує і при використанні різних програм може виявитися дуже значною. Наприклад, відомий пакет InstallShield (Полегшені версії якого, до речі, входять у комплекти поставки багатьох систем розробки додатків), “додає” до дистрибутива програми більш мегабайта! Звичайно, ис-пользовать InstallShield можна хіба що в тому випадку, якщо готову програму планується поширювати не через Іптернет, де у більш компактних програм є більше шансів залучити до себе увагу користувачів. Тим не менш, деякі shareware-розробники все одно застосовують InstallShield. Наприклад, я іноді питаю авторів, надсилають мені заявки на публікацію своїх програм в каталозі SoftList: “Чому Ваша програма, будучи начебто невеликий утилітою, має архів розміром майже 2 Мбайта? “” Та не турбуйтеся, – чую я у відповідь, – сама програма займає всього 500 Кбайт, а все інше – інсталятор! “Ні, програма установки,” з’їдає “втричі більший обсяг, ніж безпосередньо “Основний” продукт – надто велика розкіш для shareware. Отже, як я вже згадував, InstallShield, На мій погляд, розумно використовувати для “обгортки” до програм, які не планується поширювати по комп’ютерних мережах – наприклад, написаних під конкретне замовлення або розрахованих на публікацію на CD-ROM і йому подібних носіях.

Інші програми по створенню інсталяторів набагато більш помірні у своїх апетитах. Власне, громіздкість InstallShield стала своєрідним каталізатором появи аналогічних, але більш компактних продуктів: shareware-розробники, яким для розповсюдження своїх продуктів через Інтернет був потрібний більш економічний інсталятор, писали власні генератори програм установки, а потім деякі з них, в свою чергу, були оформлені як самостійні shareware-продукти.

Одним з найпопулярніших серед розробників shareware-програм є пакет Installer Wise (Http://www.mindvision.com). Крім широких можливостей, про які ви прочитаєте нижче, він створює досить компактні програми установки: різниця між ZIP-архівом з файлами програми і інсталятором буде всього близько 180 Кбайт. Createlnstall 2000 російської фірми Gentee (http://www.gentee.com) ще більш економічний – після його роботи дистрибутив програми збільшується всього лише на 40 Кбайт. Є, звичайно, ще чимало програм для генерації інсталяторів, але більшість з них створюють відносно компактні настановні програми – в межах 200 Кбайт. Більш “ненажерливі” аналоги практично не мають шансів вижити на ринку shareware (той же InstallShield, Наприклад, в основному застосовується при оформленні великих комерційних продуктів), а їх поява в дистрибутивах shareware-програм обумовлено в основному недосвідченістю автора відповідної програми.

Другим за значенням чинником вибору програми для створення інсталяторів є набір функціональних можливостей, який вона надає розробнику. Природно, за цим параметром різні продукти у цій категорії різняться, і часом дуже сильно. Чи є можливості тієї чи іншої програми достатніми – залежить в основному від особливостей цієї програми.

Для багатьох програм цілком підходить нескладний процес установки, що складається з невеликого числа стадій: показ ліцензійної угоди, пропозиція обрати папку для установки, вибір групи в секції Програми меню Пуск і безпосередньо сам процес копіювання файлів і створення ярликів в Головному меню. У цьому випадку підійде практично будь-яка програма для генерації інсталяторів, в тому числі і з категорії безкоштовних продуктів. Правда, серед останніх дійсно хорошу програму доведеться пошукати: багато програм з цієї групи мають дратівливі недоліки начебто незручного інтерфейсу або відсутності можливості перевизначити зовнішній вигляд інсталятора.

Якщо ж в процесі установки потрібно ще і реєструвати DLL-бібліотеки і ActiveX, надавати користувачеві вибір мови інтерфейсу або встановлюються компонентів програми, виводити визначаються автором програми діалогові вікна і обробляти результат дій користувача, змінювати асоціації файлів, робити записи в реєстрі, перевантажувати комп’ютер після закінчення встановлення і т. п., потрібно більш просунутий генератор інсталяції. Це вже згадані мною Installer Wise, Create Install та ін

І нарешті, важливим питанням при виборі програми створення інсталяторів є зручність роботи з нею. Частина програм цього типу (на щастя, невелика), наприклад вже згадуваний вище InstallShield, A також InnoSetup (Http://www.doniain.com), для опису інсталятора (вид діалогових вікон, обробка подій і т. д.) використовують спеціальні скриптові мови, внаслідок чого освоєння такого продукту сповільнюється. Для подолання цієї проблеми іншими авторами написані спеціальні візуальні конструктори, генеруючі текст скриптів за параметрами, вказаними користувачем в діалоговому режимі – наприклад, ISTool (Http://www.bhenden.org/istool), що створює скрипти для InnoSetup.

Втім, чи є скрипти недоліком чи ні – залежить від поглядів і уподобань самого shareware-розроблювача. Деяким авторам програм більше подобаються саме працювати зі скриптами, до того ж в цьому випадку часто є можливість більш тонко налаштувати параметри інсталятора, ніж при використанні діалогових вікон.

Основна частина програм для створення інсталяторів працюють з користувачем в діалоговому режимі, дозволяючи візуально конструювати майбутній інсталятор: вибирати стадії процесу установки, описувати вид діалогових вікон, визначати інші параметри – імена встановлюваних файлів. реєстровані розширення файлів, назви і шляхи до створюваних ярликів і т. д..

Працювати з такими програмами, звичайно, набагато простіше, ніж з тими, які використовують скрипти.

Яким же повинен бути “правильний” інсталятор? Разом з більшістю програм для їх створення поставляються приклади готових проектів настановних програм, крім того, в якості наочного прикладу можна посмотреть інсталятори відомих і популярних продуктів. Але я б хотів звернути увагу на деякі важливі деталі, якими нехтують деякі розробники.


Демонстрація тексту ліцензійної угоди

Як вже говорилося вище, згоду з умовами ліцензійної угоди – це умова, при якому інсталяція програми може бути продовжена. У цьому – суть ліцензійної угоди як “обгорткового” ліцензії. Значить в інсталятор потрібно не забути включити вікно з текстом License Agreement, щоб користувач міг продовжити установку, тільки натиснувши кнопку Згоден або встановивши відповідний прапорець (перемикач).

Папка для установки за замовчуванням

Мені до цих пір трапляються програми, інсталятори яких пропонують створити папку програми для копіювання файлів не в папці C: Program Files, а в кореневому каталозі диска С:. Звичайно, в більшості випадків можна вибрати для установки будь-яку іншу папку, в тому числі і Program Files, але, по-перше, це дратує, тому що доводиться здійснювати зайві операції, а по-друге, доводиться все одно встановлювати таку програму в каталозі С:, т. до, ніколи не можна бути впевненим в тому, що програма буде нормально працювати в папці Program Files – наприклад, через проблеми з довгими іменами файлів. Хтось може здивуватися тому, що в наш час, коли на ринку панують 32-розрядні операційні системи, якісь програми “не розуміють” довгі імена файлів, але насправді такі програми зустрічаються, і я б не сказав, що дуже рідко.

Створення ярликів в Головному меню

Я вже говорив “Не чіпайте системні файли і настройки” про те, що група з ярликами для встановленої програми повинна знаходитися виключно в папці Програми Головного меню, а не в його першому рівні або десь ще. Якщо ж ви вважаєте, що ярлик до вашій програмі знадобиться користувачеві і на Робочому столі або, наприклад, у першому рівні Головного меню, то інсталятор програми повинен створювати такі ярлики тільки з дозволу користувача.

Якщо ярлик програми міститься не у власну групу в меню Про-грами, А в одну зі стандартних груп – наприклад, Автозавантаження або Стан-дротяні, То потрібно враховувати, що в локалізованих версіях Windows їх назви різняться, і не повторювати помилок розробників пакета утиліт Microsoft PowerToys, в процесі установки яких навіть під російською версією Windows ярлики створюються в групах “Accessories” і “Startup”, які, звичайно, в даній локалізації Windows ігноруються.

Крім установки, програма повинна мати можливість деінсталяції, тобто видалення себе з системи. Програма, яка виробляє цю операцію –

дєїнсталлятор, – як правило, генерується тією ж програмою, яка використовувалася для створення інсталяторів. Хоча більшість програм для генерації інсталяторів надають розробникові самому вирішити, чи потрібен його програмі дєїнсталлятор, насправді він фактично є обов’язковим для будь-якого серйозного програмного продукту.

Деінсталяція – це не просто видалення файлів з комп’ютера, яке, в общем-то, може призвести будь-який користувач вручну. Деінсталяція увазі видалення всіх слідів перебування програми в системі (Записів в реєстрі і інших системних файлах, DLL-бібліотек в папці WINDOWS / SYSTEM і т. п). Якщо ж вся ця інформація залишається в системі, то вона в міру установки на комп’ютер все нових і нових додатків накопичується, що негативно позначається на стабільності роботи операційної системи.

Та й видалення файлів дєїнсталлятором не такий вже й простий процес. Справа в тому, що за замовчуванням дєїнсталлятор налаштовується так, щоб видалити тільки ті файли, які були встановлені раніше. Якщо при видаленні – файлів програми дєїнсталлятор виявляє в її папці файли, які не були туди встановлені інсталятором, то він пропускає їх, а іноді (це залежить від того, якою програмою був створений дєїнсталлятор) взагалі припиняє свою роботу, щоб не видалити важливі файли, наприклад документи, створені користувачем. Але на практиці не все “нові” файли можуть дійсно бути документами користувача: цілком можливо, що це файли, створені операційною системою у зв’язку з роботою даної програми на цьому комп’ютері.

Наприклад, якщо довідкова система продукту виконана у форматі WinHelp, то зазвичай програма установки копіює на диск комп’ютера файли з розширенням hip і cnt (основний файл і файл зі змістом Довідки). Але варто користувачеві хоч один раз подивитися довідкову систему, як на диску буде створений файл з розширенням gid, а якщо користувач проведе розширений пошук-створюються файли FTS і FTG (див. табл. 7.1). Тому файли з цим розширенням також потрібно включити в налаштування програми дєїнсталлятора.

Те ж саме відноситься і до ключів в системному реєстрі з настройками програми. Часто ці ключі створюються не інсталятором, а самою програмою, в процесі роботи користувача з нею. В результаті ці записи не видаляються дєїнсталлятором і залишаються в реєстрі, збільшуючи його обсяг і погіршуючи швидкість роботи Windows. Внаслідок цього потрібно налаштувати дєїнсталлятор на видалення всіх ключів, які можуть бути створені програмою в процесі її використання.

Як відомо, дєїнсталлятор програми для Windows може бути запущений двома способами: за допомогою вибору відповідного пункту в групі з ярликами програми в меню Пуск і за допомогою аплету “Установка і видалення програм “панелі керування Windows. Деякі програми генерації інсталяторів, наприклад вже згадуваний InstallWise, надають користувачеві можливість при видаленні програми скористатися будь-яким з цих способів на свій вибір: відповідні пункти присутні як в меню Пуск, так і в аплеті “Установка і видалення програм” панелі керування. Однак деякі shareware-продукти можна видалити тільки одним способом. Не можна сказати, що це вдалий хід, з точки зору зручності роботи з програмою. Можна випробувати сильно, роздратування, наприклад, послідовно викликавши Панель управління, аплет “Установка і видалення програм “, прокрутити довгий список і не знайти ту програму, яка вам потрібна, прокрутити цей список більш повільно, ретельно вчитуючись у назви продуктів, щоб не пропустити цікаву програму, задуматися, як же все-таки видалити цю злощасну програму і т. д.

Нарешті, коли інсталятор і дєїнсталлятор створені, потрібно обов’язково протестувати їх роботу: наскільки добре продукт встановлюється на комп’ютер і видаляється з нього. Хтось із читачів вважає це зауваження не потрібним – адже необхідність тестування будь-якої програми здається само собою зрозумілою річчю, проте мені час від часу зустрічаються програмні продукти, після інсталяції яких не працюють навіть ярлики в меню Пуск, не кажучи вже про більш серйозні помилки при проектуванні програм установки. При цьому потрібно постаратися знайти можливість протестувати роботу інсталятора та дєїнсталлятора на комп’ютерах з різними версіями Windows, в тому числі і з різними локалізаціями.

Підготовка дистрибутива

Отже, інсталятор програмного продукту готовий: файл setup.exe лежить в папці вашого shareware-проекту. В принципі, цей файл вже є дистрибутивом програми, і його можна сміливо поширювати через Інтернет. Багато авторів так і роблять: перейменовують файл setup.exe так, щоб його назва була співзвучна назві програми, і розміщують його на Web-Сернері.

Це поширений, але не зовсім правильний підхід до вибору варіанта оформлення дистрибутива. Найкраще – упакувати ЕХЕ-файл інсталятора ZIP-архіватором. Крім файлу setup.exe, в архів потрібно включити ще й файл readme.txt, що містить найбільш важливу інформацію про програму і се поточної версії, а також файл file_id.diz, в який записується назва програми, її версія і короткий (10-20 слів) опис.

Головний недолік розповсюдження “голого” файлу setup.exe, без його “обертання” архіватором, полягає в тому, що користувач може дізнатися, яку саме програму містить дистрибутив, тільки встановивши її. Хоча автори зазвичай дають файлу дистрибутива ім’я, похідне від назви програми, воно нерідко абсолютно нічого не говорить користувачеві, тому що виглядає як абревіатура і номер версії – наприклад, ср32е45.ехе: спробуйте здогадайтеся, що за цим малозрозумілим набором букв ховається Netscape Communicator версії 4.5 для Windows 9.X/NT/2000.

Якщо ж інсталятор упакований архіватором, а в архіві знаходиться і файл readme.txt, то користувач може дізнатися, яка саме програма представлена ​​даними дистрибутивом без її безпосередньої установки, а також отримати багато додаткової інформації про неї (що нового з’явилося в цій версії, які існують системні вимоги і т. п).

Деякі читачі, можливо, запитають: “А навіщо в архів потрібно ще включати і файл file_id.diz? Адже багато інформації вже є в readme.txt?” Це дійсно гак, проте file_id.diz більш зручний для читання, якщо користувачеві потрібно лише дізнатися назву програми та її версію. Але найголовніше – багато архіватори, файлові менеджери, каталогізатори автоматично витягають з архівів файли file_id.diz (традиція постачати дистрибутиви файлами file_id.diz йде ще з часів DOS) і показують (або обробляють іншим чином) їх вміст. В результаті користувач отримує опису упакованих файлів з таких архівів без необхідності відкривати їх вручну і самостійно читати файли readme.txt. Не випадково текст у файлі file_id.diz прийнято записувати невеликими по довжині рядками, щоб опис поміщалося в інформаційні вікна відповідних програм.

За свідченням тих shareware-розробників, які розміщують на своїх Web-сайтах програми відразу в двох варіантах – ехе і zip, обидва варіанти скачують приблизно рівну кількість користувачів. Тим не Проте, з ZIP-архівами працювати зручніше, що підтверджують листи від відвідувачів архіву SoftList: в деяких з них містяться досить емоційні прохання публікувати на сайті тільки програми, дистрибутиви яких оформлені у вигляді ZIP-файлів, і навіть зобов’язати авторів програм поширювати свої програми тільки упакованими в архів. Звичайно, виконати такі прохання з різних причин неможливо, але сам по собі факт наявності подібних прохань з боку користувачів показовий, тим більше, що прохань викорінити формат ZIP в області поширення дистрибутиві програм не надходило.

Читачі, напевно, звернули увагу на те, що, говорячи про використання архіватора, я весь час згадую про один форматі – ZIP. Адже існує безліч інших архівних форматів, деякі з яких більш ефективні, ніж ZIP – наприклад, широко поширений в Росії RAR Євгена Рошаля (http://www.rarsoft.com). Справа в тому, що ZIP є стандартом де-факто для розповсюдження файлів в Інтернеті, чого про інших архівних форматах не скажеш. Звичайно, існують винятки, зумовлені, зокрема, специфікою платформи, для якої призначений файл: наприклад, програми для Linux традиційно упаковуються в архіви tar.gz. Але коли мова йде про розповсюдження через Інтернет програмного забезпечення для Windows, тут вибору немає: тільки ZIP, і ніякий інший архіватор.

Велике значення для поширення програм серед закордонних користувачів має і той факт, що існує велика кількість безкоштовних ZIP-архіваторів, а ось той же RAR (як його версія для Windows- WinRAR) – shareware-продукт, за використання якого (в даному випадку – лише для того, щоб розпакувати чужу програму) потрібно платити. І, хоча в комплект поставки RAR входить безкоштовна утиліта UnRar, яка призначена тільки для розпакування файлів, більшість користувачів про неї нічого не знають, тому що автором RAR вона не особливо рекламується. Виходить, що автор shareware-продукту, упакованої RAR (або іншим небезкоштовно архіватором), змушує користувача заплатити гроші тільки за право розархівувати програму. Один з російських shareware-розробників розповідав, що в той час, коли він користувався архіватором RAR для упаковки дистрибутива своїх програм, він якось навіть отримав листа з докором. “Щоб запустити Вашу програму, я повинен зареєструвати RAR!” – Писав користувач.

Примітка

Сподіваюся, мої слова будуть зрозумілі правильно: критикується, звичайно ж, не те, що за користування архіватора потрібно платити, а те, що в даному випадку користувача змушують платити за програму, яка йому фактично не потрібна.

Мабуть, єдиний тип програм, дистрибутивів яких протипоказана упаковка будь-яким архіватором і які повинні поширюватися тільки у вигляді виконуваного файлу (“голий” інсталятор або саморозпаковується архів), – це … ZIP-архіватори. Дуже часто користувач викачує з Інтернету дистрибутив, однією з таких програм як раз для того, щоб розархівувати інші ZIP-файли, і тому йому, швидше за все, буде просто нічим розпакувати дистрибутив, стиснений ZIP-архівом.

Нарешті останнє питання, яке мені хотілося б розглянути в даному розділі, – це питання про те, яке ім’я повинен мати готовий файл дистрибутива, тобто файл, який користувачі будуть качати з Інтернету. Є три можливих варіанти: залишити йому стандартне ім’я начебто setup.zip, дати ім’я на основі назви програми (припустимо, abc.zip) і додати до другого варіанту номер версії – наприклад, abc20.zip означатиме вер-сію 2.0.

Перший варіант, звичайно, відпадає: ім’я файлу setup.zip нічого не скаже користувачеві про назву програми, коли він завантажить цей файл, а через деякий час (наприклад, наводячи порядок на жорсткому диску) вирішить з’ясувати, що ж він містить.

Останній, третій за рахунком варіант представляється ідеальним: в імені файлу міститься вказівка ​​не тільки на назву програми, а й на номер її версії. Користувач, ледь поглянувши на ім’я файлу, може зробити висновок про призначення цього дистрибутива. Крім того, при такому методі найменування файлів відповідний дистрибутив – потрібної програми і потрібної версії – легко знайти на спеціалізованих файлових пошукових системах на кшталт www.filesearch.ru.

Однак, при всіх перевагах, цей спосіб має великий недолік. Після випуску чергової версії програми посилання на її файл швидко розповзаються по всьому Інтернету: автор реєструє програму в різних online-архівах, а деякі архіви самі додають цю програму в свої бази даних. Але після того, як в світ виходить нова версія програми, ім’я файлу змінюється: адже версія програми теж змінилася. В результаті всі посилання, які стоять на файл програми на сторінках інтернет-каталогів програмного забезпечення, комп’ютерних оглядів та інших інформаційних ресурсів, перестають працювати, і відповідно відвідувачі не можуть завантажити програму за цим посиланням. За допомогою невеликої настройки Web-сервера цю проблему можна вирішити, але не всі автори shareware-програм мають можливість зробити таку настройку. Щоб хоч якось поправити становище, розробнику доводиться писати листи адміністраторам відповідних архівів або заповнювати Web-форми з проханням змінити посилання на файл програми. Біда в тому, що великі архіви, як уже згадувалося (див. розд. “Періодичність випуску” даної глави), можуть оновити інформацію про програму в своїх базах даних через тижні і навіть місяці після того, як отримають відповідні запити, і весь цей час файл програми не буде доступний для відвідувачів даних сайтів. І ніхто не знає, скільки зареєстрованих користувачів через це недорахується програма. Враховуючи сказане вище, мені найбільш оптимальним видається варіант номер два: ім’я файлу включає тільки назву (або його абревіатуру) програми, без номера версії. В такому випадку назва залишається більш-менш зрозумілим, а зовнішні посилання на файл програми залишаються робочими при виході нових версій програми. Правда, при пошуку в файлових системах важко буде знайти конкретну версію цієї програми. Однак цим варто пожертвувати заради того, щоб зовнішні посилання на файл програми зберігали свою працездатність після виходу її нової версії: це виявиться набагато більш вигідним у плані збільшення числа зареєстрованих користувачів.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*