> sniknik ©   (05.03.16 21:56) [47]
> > Если работаем без bpl, то придется перекомпилить всю эту
> ватагу из exe и dll. В противном случае - компилим только
> один bpl и отдаем его заказчику...
> часто слышал такие объяснения, и ни разу не видел это реально
> работающим... не, может мне просто не везло, но обычно это
> выглядит так, с точки зрения заказчика -
> - мы тут кое чего исправили, замените файл.
> - заменили, вообще запускаться перестало с ошибкой ...
> - хм. тут наверное еще вот этот модуль нужен.
> - не получилось.

Да не, работает... Есть нюансы, конечно, но работает. Клиентов много, но они все корпоративные... Ибо продукт рассчитан на них. Не для одиноких домохозяек, скажем так...

> в сетапе должно быть все, вместе с модулями, без необходимости
> "кусочно-апдейта".

А, ну да... Скажи это МС, чтоб они тебе на каждый виндовый хот-фикс полный дистрибутив винды высылали. С необходимостью полной установки... :)

> само собой, откуда тестирование в логике "компилим только
> один bpl и отдаем его заказчику..."?

Это, как "само-собой" разумеющееся. Процесс "отдаем заказчику" не такой простой, как тебе кажется... Там, как минимум, два уровня тестирования - наш и заказчика. Бывает и третий - интегратора...

Но, есть и недостатки...
Например, сейчас столкнулись с полной опой... Есть известный баг в Controls.pas, связанный с RegisterWindowMessage... Лечится правкой этого самого Controls.pas. Но, в случае работы с BPL, не лечится никак, ибо надо перекомпилить дельфишную vcl60.bpl (у нас Д6, если че :) ). А как? Сырцов то полных нету...

Я поддерживал программу с двумя миллионами клиентов.


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

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

и есть рантайм пакеты. и ничего не взрывается, и релиз-билдов за 17 лет третья сотня пошла.

> asail ©   (06.03.16 06:06) [61]
>
> Но, есть и недостатки...
> Например, сейчас столкнулись с полной опой... Есть известный
> баг в Controls.pas, связанный с RegisterWindowMessage...
>  Лечится правкой этого самого Controls.pas. Но, в случае
> работы с BPL, не лечится никак, ибо надо перекомпилить дельфишную
> vcl60.bpl (у нас Д6, если че :) ). А как? Сырцов то полных
> нету...

Сырцы-то полные есть. Нет только исходников самих пакетов RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что это не полная опа.

> Германн ©   (07.03.16 00:30) [63]

> Сырцы-то полные есть. Нет только исходников самих пакетов
> RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что это
> не полная опа.

А толку от оных сырцов без этих dpk? Подозреваю, что там помимо имеющихся юнитов, требуются еще всякие RES и OBJ... Да и где гарантия, что имеющиеся сырцы идентичны тем, которые использовались Борландом для компиляции своих BPL?
Есть идеи, насчет не полной опы? Был бы весьма признателен!

> Германн ©   (07.03.16 00:30) [63]

> Сырцы-то полные есть. Нет только исходников самих пакетов
> RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что это
> не полная опа.

А толку от оных сырцов без этих dpk? Подозреваю, что там помимо имеющихся юнитов, требуются еще всякие RES и OBJ... Да и где гарантия, что имеющиеся сырцы идентичны тем, которые использовались Борландом для компиляции своих BPL?
Есть идеи, насчет не полной опы? Был бы весьма признателен!

> Rouse_ ©   (05.03.16 16:28) [34]
> Приложение 32 бита, сложно собрать и подгрузить 64 битную библиотеку в 32 битное приложение.
> Все работает и не первый год :)

Я понимаю, что пои примеры вас не убедят, т.к. вы будете уверены, что "вас это не касается". Но взгляните на эти примеры шире. Тем более, что рано или поздно вы будете переезжать на x64 как минимум.
Я не про плагины в явном виде, я про разного рода API, ну и код, который работает на разных машинах и взаимодействует по сети.

Первый раз серьёзно пришлось попотеть, когда часть C++ кода потребовалось перенести на iOS. После повторился цирк с Андроид.
Считаю проблема в том, что из iOS не вынесли уроки как раз вот с типами и выравниванием. Т.е. вместо того, чтобы поправить общий код так, чтобы он однозначно компилировался на разных платформах (в частности, это касалось размеров данных и выравниваний), решили "и так пойдёт". Соответственно, с Андроид'ом занимались сексом по второму кругу в полном объёме ровно с тем же кодом.

А потом "просто перекомпилировали" под новой какой-то версией iOS - и всё прошло совершенно гладко! счастью не было предела.
Разумеется, у клиентов всё тут же "совершенно неожиданно" навернулось, кто бы сомневался.
А всего-то платформа стала 64-разрядной вместо 32 оразрядной, ну и пара безалаберностей в коде про которые все уже давно забыли так вот печально выстрелили. (если напишу предметнее - каждый, уверен, скажет "ну я так-то так никогда не сделаю! это же азбука!" хо-хо, скажу я на это)

Я для себя вынес урок:

1) В API - только типы явно указанного размера! причем для Win-платформы лично я бы использовал только типы из WinAPI, по-моему, это правильнее, хотя это только моё мнение.

2) Обязательно явно указывать размер упаковки структур!
Не, можно, конечно, заморачиваться и при разработке интерфейсных структур очень включать голову, чтобы при любом выравнивании было одинаково, но зачем?? не понимаю. Да и потом это "тайное знание" непременно забудется, придут новые необстрелянные люди - какой смысл оставлять грабли.

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

> asail ©   (07.03.16 10:23) [64]
>
>
> > Германн ©   (07.03.16 00:30) [63]
>
> > Сырцы-то полные есть. Нет только исходников самих пакетов
> > RTLxxx.dpk и VCLxxx.dpk. Но почему-то мне кажется что
> это
> > не полная опа.
>
> А толку от оных сырцов без этих dpk? Подозреваю, что там
> помимо имеющихся юнитов, требуются еще всякие RES и OBJ.
> .. Да и где гарантия, что имеющиеся сырцы идентичны тем,
>  которые использовались Борландом для компиляции своих BPL?
>  

Ну вообще-то Борланд такие гарантии даёт. Но предупреждает, что сырцы могут быть не совсем точными для данной сборки дистрибутива. Ну по крайней мере раньше предупреждал.
"Всякие RES и OBJ" в сырцах присутствуют.
Ну и лично сам пробовал менять исходник System.pas с целью проверить, что сырцы рабочие.