блин ну и умучался я с этой Вашей bds 2006 ))

← →
xayam © (2007-01-09 19:24) [0]

)) Хотел спросить. Может ли из человека (ну вроде меня)) выйти программист, если не вышел философ? Или вышел? ))
Вообще другое интересно, кто-нибудь большой проект делал на делфи с плагинами. Вот у Java есть eclipse, а что есть у делфи... Bpl это конечно круто, но одного этого, как я понял маловато; начал с MDI, дочерние окна в bpl, не понравилось, пробовал фреймы в пакеты запихивать, вроде лучше. Ваше мнение, желательно основанное на опыте разработки расширяемых приложений.

← →
Ega23 © (2007-01-09 19:27) [1]

Из тебя выйдет толк.
А вот дурь, к сожалению, останется...

Шучу.
По сабжу: может, всё-таки, имеет смысл с чего попроще начать?

← →
Mumuka (2007-01-09 19:31) [2]

> )) Хотел спросить. Может ли из человека (ну вроде меня))
> выйти программист, если не вышел философ?

Не выйдет. Если не получился философ - программистом тебе не быть. Все программисты философы. :-)))

← →
Юрий Зотов © (2007-01-09 19:32) [3]

> xayam © (09.01.07 19:24)

А что конкретно интересует? В BPL ведь можно запихать что угодно.

← →
kaZaNoVa © (2007-01-09 19:34) [4]

Делфи 7 рулит. нереально. всегда юзаю)

← →
$Pl@Sh © (2007-01-09 19:34) [5]

> Mumuka (09.01.07 19:31) [2]

Чё за ник такой :)

Полностью согласен, программисты философски относятся к "заработает, не заработает"

← →
Anatoly Podgoretsky © (2007-01-09 19:35) [6]

> Mumuka (09.01.2007 19:31:02) [2]

А все програмисты в первую очередь пофигисты и фантазеры.

← →
Gydvin © (2007-01-09 19:36) [7]

да ну ее, брось

← →
Mumuka (2007-01-09 19:37) [8]

> Anatoly Podgoretsky © (09.01.07 19:35) [6]

фантазируют о том, что их прога будет работать так как надо :-)

← →
xayam © (2007-01-09 19:39) [9]

> Ega23 © (09.01.07 19:27) [1]
> Из тебя выйдет толк.
> А вот дурь, к сожалению, останется...

будем выгонять))

> По сабжу: может, всё-таки, имеет смысл с чего попроще начать?

типа "привет мир" )) да нет такое уже не надо, я же не совсем чайник (сказал он, подумав, что совсем не чайник))

> Юрий Зотов © (09.01.07 19:32) [3]
> > xayam © (09.01.07 19:24)
> А что конкретно интересует? В BPL ведь можно запихать что
> угодно.

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

← →
xayam © (2007-01-09 19:49) [10]

В принципе на sf нашел такой проект -
http://sourceforge.net/projects/rd-dpf/
"DPF(Delphi Plugin Framework) is a general-purpose plugin framework intended to help building scalable, extendable Delphi applications with low cost of maintenance. The framework is specially designed to be easily included into Delphi project of any kind."
Но в исходниках по-моему разобраться не реально... хотя будет время попробую. Кто-нибудь пользовался? Может есть еще подобные проекты?

← →
Юрий Зотов © (2007-01-09 19:51) [11]

> xayam © (09.01.07 19:39) [9]

Например - описываете нужные интерфейсы и организуете взаимодействие через них.

← →
xayam © (2007-01-09 19:57) [12]

> Юрий Зотов © (09.01.07 19:51) [11]
> > xayam © (09.01.07 19:39) [9]
> Например - описываете нужные интерфейсы и организуете взаимодействие
> через них.

да вот кстати, это принципиально через интерфейсы нужно делать или через классы организовывать взаимодействия тоже можно?

← →
Аноним (2007-01-09 20:05) [13]

> xayam ©

> или через классы организовывать взаимодействия тоже можно?

Если брать за основу bpl, то можно. Но, имхо, вариант с интерфейсами предпочтительнее - гибче, вплоть до языковой независимости

← →
xayam © (2007-01-09 20:48) [14]

> Аноним (09.01.07 20:05) [13]

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

← →
xayam © (2007-01-09 21:35) [15]

> Юрий Зотов © (09.01.07 19:51) [11]

дядь Юр, не бросайте нас, без Вас не разобраться))

← →
API © (2007-01-09 21:57) [16]

А наследовать плагин от какого класса. Учитывая что плагины находятся в пакетах мне показалось удобнее от фреймов

Это смотря что плагины делать будут. Но если реализовывать через интерфейсы, то там совершенно все равно, от чего наследовать. Более того, будет уже все равно, что это, - фрейм или что-либо другое, в любом случае для контролов придется окно на родительское окно через ВинАПИ "сажать".

← →
iZEN © (2007-01-09 22:14) [17]

> Юрий Зотов © (09.01.07 19:32) [3]
>
> > xayam © (09.01.07 19:24)
>
> А что конкретно интересует? В BPL ведь можно запихать что
> угодно.

Например? Можно запихать исходники, чтобы распространять компоненты в одном файле библиотеки bpl? Низя. Вернее, можно в виде ресурсов, но Delphi всё равно не сможет встроить их в свою палитру без распаковки сторонними средствами.

Так што... BPL -- это только DLL.

← →
xayam © (2007-01-09 22:17) [18]

> API © (09.01.07 21:57) [16]
> А наследовать плагин от какого класса. Учитывая что плагины
> находятся в пакетах мне показалось удобнее от фреймов
> Это смотря что плагины делать будут

ну в общем это на самом деле плагин будет страницей TPageControl"а, плюс регистрация в меню, плюс на спец. панели и т.д.
Но вот еще такая проблема, как в основной форме узнать как называется тип плагина, чтобы его создать. Прописывать статически не хочется, тогда придется перекомпилировать для каждого плагина, а программно как узнать? Чтобы на автомате можно было загрузить (это уже сделал) из определенных директорий, и создать экземпляр плагина по запросу (тут приходится писать что-то типа
PluginForm:= TFramePlugin.Create(MainForm);
а как узнать выделенное динамически незнаю). Или заморочился и все проще.

← →
vlad-mal © (2007-01-10 01:15) [19]

Программисты (некоторые: я например ;) ) лентяи.

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

← →
Германн © (2007-01-10 01:34) [20]

> Anatoly Podgoretsky © (09.01.07 19:35) [6]
>
> > Mumuka (09.01.2007 19:31:02) [2]
>
> А все програмисты в первую очередь пофигисты и фантазеры.
>
>

Не только программисты. И я тоже такой :)

← →
Чапаев © (2007-01-10 11:07) [21]

> если не вышел философ? Или вышел? ))
Весь вышел.

> По сабжу: может, всё-таки, имеет смысл с чего попроще начать?
Как высказался один мой заочно-знакомый, "с математикой я не очень дружу, потому решил начать с чего попроще, с баз данных".

← →
zdm © (2007-01-10 11:27) [22]

> Чапаев © (10.01.07 11:07) [21]
> > если не вышел философ? Или вышел? ))Весь вышел.> По сабжу:
> может, всё-таки, имеет смысл с чего попроще начать?Как
> высказался один мой заочно-знакомый, "с математикой я не
> очень дружу, потому решил начать с чего попроще, с баз данных".
>

Извините, что повторяюсь. но..
vog> ищу в электронном виде "Написание KERNEL-драйверов под win32 для чайников"
alekzander> win32 уже и на чайниках появилось?

← →
Anatoly Podgoretsky © (2007-01-10 13:00) [23]

> Германн (10.01.2007 01:34:20) [20]

> Не только программисты. И я тоже такой :)

Ты латентный программист

← →
Юрий Зотов © (2007-01-10 14:08) [24]

> iZEN © (09.01.07 22:14) [17]

Все смешалось в доме Облонских....

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

2. BPL - это DLL (правда, не совсем обычная), причем никто никогда этого и не скрывал. Что не мешает ей содержать вполне полновесные плагины.

3. Какое отношение все это имеет к сабжу?

> API © (09.01.07 21:57) [16]

> в любом случае для контролов придется окно на родительское окно через
> ВинАПИ "сажать".

Не обязательно. Например, плагин может реализовывать интерфейс, который имеет метод, возвращающий TControl - и тогда ничто не мешает посадить этот TControl на родительское окно средствами VCL. Тут все зависит от нашего желания - хотим ли мы, чтобы плагины могли разрабатываться на любом языке (и тогда, конечно, их надо юзать через API), или нам достаточно, чтобы они разрабатывались только на Delphi (и тогда можно юзать механизмы VCL).

xayam © (09.01.07 22:17) [18]

> наследовать плагин от какого класса.

От того, который ближе всех по функциональности. Если плагин визуальный, несет на себе контролы, а сам сидит на закладке PageControl, то он может быть TabSheet"ом, фреймом, панелью, GroupBox"ом, да и вообще любым наследником TWinControl.

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

Это уже вопрос не Delphi, а проектирования. На чем бы Вы ни реализовавали Ваше любимое слово, его все равно придется решать. Можно потребовать, чтобы все плагины наследовались от одного базового класса - и тогда EXE будет знать этот класс заранее (а конкретный класс плагина абсолютно неважен). Можно потребовать, чтобы BPL содержала функцию наподобие типа GetPluginClass или GetPluginInstance. И т.д.

Я бы делал так.

1. Все BPL сидят в заранее известном каталоге. Там я их ищу, оттуда их гружу и, если надо, регистрирую в каком-то своем внутреннем списке для дальнейшей работы с ними.

2. Каждый плагин обязан реализовывать некий предопределенный мною интерфейс IPuginInterface. Этот интерфейс содержит все, что нужно EXE от плагина. Конечно, он может содержать и ссылки на другие интерфейсы - это позволяет не валить весь функционал в одну кучу, а разложить его по полочкам.

3. EXE тоже реализует некий предопределенный мною интерфейс IExeInterface. Этот интерфейс содержит все, что может потребоваться плагину от EXE.

4. Каждая BPL обязана содержать функцию GetPuginInterface, принимающую параметром ссылку на IExeInterface, а взамен возвращающую ссылку на IPuginInterface. Как конкретно она это сделает, экземпляр какого класса при этом создаст (или не создаст) и пр. - все это меня абсолютно не интересует. Что она сделает с переданной ей ссылкой - это мне тоже по барабану (но предполагается, что запомнит внутри плагина для дальнейшего использования в нем).

Вот и вся столь любимая Вами структура. Теперь плагин и EXE могут через имеющиеся у них ссылки на интерфейсы работать друг с другом как угодно. И заметьте, что слово Delphi в этой структуре не прозвучало ни разу - потому что и не должно было звучать. К Delphi это не относится.

← →
isasa © (2007-01-10 14:12) [25]

А почему никто не вспоминает про COM + Events или ActiveX ?

← →
Германн © (2007-01-10 17:40) [26]

> Anatoly Podgoretsky © (10.01.07 13:00) [23]
>
> > Германн (10.01.2007 01:34:20) [20]
>
> > Не только программисты. И я тоже такой :)
>
> Ты латентный программист
>

Прошу не называть меня "земляным червяком"!
Я Пофигист Широкого Профиля :)

← →
iZEN © (2007-01-11 01:21) [27]

> Юрий Зотов © (10.01.07 14:08) [24]
>
> > iZEN © (09.01.07 22:14) [17]
>
> Все смешалось в доме Облонских....
>
> 1. При чем тут сырцы и зачем их вообще куда-то там запихивать,
> если все (включая компоненты) можно спокойно распространять
> и без них?

Чтобы распространять delphi-библиотеки вместе с исходным кодом, который можно импортировать в другие проекты. Так как без исходников BPL годны лишь "на посмотреть" интерфейсы. Для разработки они ценности не представляют.

Далее вы описали механизм динамической подгрузки кода во время работы приложения. Зачем? Плагинная архитектура изобретена до вас и описана в образцах проектирования. Это легко делается, но далеко не все delphi-програмисты это делают, вернее — почти никто этим не занимается для BPL.

Да и статическую линковку никто не отменял, но как её провести, если есть только BPL, а исходников нет/потеряли исходники? НИКАК! Реверс-инжиниринг по двоичному коду, а больше ничего нельзя сделать.

О встраивании компонентов в среду разработки (палитру компонентов), имея на руках только BPL, без исходников, не представляется возможным.

← →
isasa © (2007-01-11 01:28) [28]

iZEN © (11.01.07 01:21) [27]
Ты это, не темни, сразу про Java рассказывай ...

← →
ferr © (2007-01-11 01:29) [29]

> Ты это, не темни, сразу про Java рассказывай ...

:)) В .net покруче будет)

← →
Anatoly Podgoretsky © (2007-01-11 02:37) [30]

> isasa (11.01.2007 01:28:28) [28]

> Ты это, не темни, сразу про Java рассказывай ...

:-)

← →
iZEN © (2007-01-11 03:06) [31]

> ferr © (11.01.07 01:29) [29]
>
> > Ты это, не темни, сразу про Java рассказывай ...
>
> :)) В .net покруче будет)

(-:

← →
Юрий Зотов © (2007-01-11 12:46) [32]

> iZEN © (11.01.07 01:21) [27]

> без исходников BPL годны лишь "на посмотреть" интерфейсы. Для
> разработки они ценности не представляют.

> статическую линковку никто не отменял, но как её провести, если есть
> только BPL, а исходников нет/потеряли исходники? НИКАК! Реверс-
> инжиниринг по двоичному коду, а больше ничего нельзя сделать.

> О встраивании компонентов в среду разработки (палитру компонентов),
> имея на руках только BPL, без исходников, не представляется
> возможным.

http://literatura.iatp.ge/targmanebi/krilovi/originali/martishka_i_ochki.htm
"Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит".
(c) И.А. Крылов.

"Ты просто не умеешь их готовить".
(с) Реклама.

> Далее вы описали механизм динамической подгрузки кода во время
> работы приложения. Зачем?

Вообще-то, это был ответ на сабж.

← →
Игорь Шевченко © (2007-01-11 13:10) [33]

iZEN © (11.01.07 01:21) [27]

> Так как без исходников BPL годны лишь "на посмотреть" интерфейсы.
> Для разработки они ценности не представляют.

Ты бредишь

> О встраивании компонентов в среду разработки (палитру компонентов),
> имея на руках только BPL, без исходников, не представляется
> возможным.

Ты бредишь.

← →
DiamondShark © (2007-01-11 13:17) [34]

Не, в среду они встроятся. Но вот без dcu/dcp ничего не откомпилируется.
Это, конечно, не исходники, но тем не менее...

← →
Юрий Зотов © (2007-01-11 13:38) [35]

> DiamondShark © (11.01.07 13:17) [34]

Естественно. И в справке описано. Стандартная поставка без исходников: BPL, DCP, DCU (плюс документация, если она нужна).

И все встраивается, и все компилируется, и все работает, и без всяких исходников.

Что вовсе не новость (казалось бы).
:о)

← →
iZEN © (2007-01-11 20:03) [36]

> Юрий Зотов © (11.01.07 13:38) [35]

Ну вот вы и сами признали, что одна BPL бесполезна. Нужны по крайней мере DCP и DCU. Да, без исходников можно обойтись, но в разработке одна лишь BPL бесполезна!! Это факт. ;-)

С другой стороны есть ведь OCX-библиотеки -- изобретение MS, которые способны предоставить полную информацию о компонентах, содержащихся в них, даже самой Delphi. Совершенно не нужны сторонние файлы -- если надо, то "сопутствующие" исходники генерируются из OCX в самой Delphi.
Так что распространять вместе с BPL, ещё и какие-то файлы DCU и DCP, код которых фактически УЖЕ содержится в BPL, -- следствие непродуманной архитектуры IDE.

> Юрий Зотов © (09.01.07 19:32) [3]
> > xayam © (09.01.07 19:24)
> А что конкретно интересует? В BPL ведь можно запихать что
> угодно.

Оказалось, что далеко не всё. Она есть вариант реализации DLL, и больше ничего. Контейнер двоичного кода. Называется: нет сторонних файлов, с одной лишь BPL обломись по-полной.

> Игорь Шевченко © (11.01.07 13:10) [33]
>
> iZEN © (11.01.07 01:21) [27]
>
>
> > Так как без исходников BPL годны лишь "на посмотреть"
> интерфейсы.
> > Для разработки они ценности не представляют.
>
>
> Ты бредишь

Да не. Вроде выспался. ;)

Кстати, эта тема уже была и обсуждалась. Я приводил те же самые аргументы по ущербности BPL.

Угу. С исходниками облом вышел - значит, надо что-то новенькое придумать. Типа - а почему не зеленое? Зеленое должно быть. Обязано.

Хорошо, объясняю. Но в последний ра, бо уже надоело.

1. Для работы приложения, собранного без run-time пакетов не нужно вообще ничего.

2. Для работы приложения, собранного с run-time пакетами нужны BPL этих пакетов и больше ничего.

3. Для сборки пакетов и приложений, зависящих от какого-либо пакета нужны DCP и DCU этого пакета.

4. В сабже речь идет о п.2. К чему Вы, извините, приплели сюда п.3 - непонятно.

5. Ваше заявление "распространять вместе с BPL, ещё и какие-то файлы DCU и DCP, код которых фактически УЖЕ содержится в BPL, -- следствие непродуманной архитектуры IDE" свидетельствует лишь о том, что Вы не знаете (и/или не понимаете), как формируется исполнимый код, чем он отличается от объектного, что такое линковщик и зачем он нужен.

> iZEN © (11.01.07 20:07) [37]
> Кстати, эта тема уже была и обсуждалась. Я приводил те же
> самые аргументы по ущербности BPL.

ну а для пользователя больше от программы ничего и не надо. Чтобы работала достаточно bpl"ек )) И в чем ущербность не очень понял. Если рассуждать также как ты, то можно продолжить аналогию на exe"ик. Какой от него толк? Только без него не стоит и начинать программировать )) нечего запускать то будет ))

> xayam © (11.01.07 22:39) [39]
> Если рассуждать также как ты, то можно продолжить
> аналогию на exe"ик. Какой от него толк? Только без него
> не стоит и начинать программировать )) нечего запускать
> то будет ))

Если рассуждать так, как я, то техника BPL в Delphi ненужна СОВСЕМ. Если она нужна, в том виде, в котором её представляют BPL, то лучше было бы использовать DLL, не меняя расширение -- так по крайней мере честнее для пользователей других средств разработки.

Достаточно просто подключать OCX и, надеюсь, не нужно объяснять, в чём их преимущества перед BPL/DLL? (А то, блин, второго круга не избежать)

> Юрий Зотов © (11.01.07 22:02) [38]
>
> Угу. С исходниками облом вышел - значит, надо что-то новенькое
> придумать. Типа - а почему не зеленое? Зеленое должно быть.
> Обязано.

Я же говорю: не пудрите людям мозги насчёт всеуниверсальности BPL.

> Юрий Зотов © (11.01.07 22:02) [38]
>
> Хорошо, объясняю. Но в последний ра, бо уже надоело.
>
> 1. Для работы приложения, собранного без run-time пакетов
> не нужно вообще ничего.

Это факт, я не спорю. В настройках компилятора даже флаг такой есть.

> Юрий Зотов © (11.01.07 22:02) [38]
>
> 2. Для работы приложения, собранного с run-time пакетами
> нужны BPL этих пакетов и больше ничего.

Следствие вытекает из п.1.

> Юрий Зотов © (11.01.07 22:02) [38]
>
> 3. Для сборки пакетов и приложений, зависящих от какого-
> либо пакета нужны DCP и DCU этого пакета.

Воооооот.

> Юрий Зотов © (11.01.07 22:02) [38]
>
> 4. В сабже речь идет о п.2. К чему Вы, извините, приплели
> сюда п.3 - непонятно.

Я думал, человек хочет выяснить степень универсальности BPL в контексте расширяемости. Он УЖЕ сделал проект с плагинами (MDI-формы в BPL), но ему показалось этого МАЛО. Расширяемости ему, видите ли не хватает.
Я привёл аргументы в ущербности BPL, в том числе в способе распространения кода для разработки (BPL сама по себе ничего не представляет без исходников/DCU/DCP). Потом обратил внимание на технологию OCX, которая совмещает в себе механизм интроспекции и динамического вызова кода, полученного через этот механизм интроспекции. В Delphi возможен вызов этого кода в статическом связывании (в этом случае использование OCX в проекте равносильно использованию DLL/BPL), так и динамическое связывание во время выполнения приложения (аналог контейнера OLE, COM/DCOM).

> Юрий Зотов © (11.01.07 22:02) [38]
> 5. Ваше заявление "распространять вместе с BPL, ещё и какие-
> то файлы DCU и DCP, код которых фактически УЖЕ содержится
> в BPL, -- следствие непродуманной архитектуры IDE" свидетельствует
> лишь о том, что Вы не знаете (и/или не понимаете), как формируется
> исполнимый код, чем он отличается от объектного, что такое
> линковщик и зачем он нужен.

Может наоборот, я понимаю гораздо больше, чем разработчики Borland, и вижу их ошибки? А?

Использование OCX было бы универсальным решением на все случаи жизни, вы будете спорить?

> вы будете спорить?

Нет, конечно. Разве я, не разработавший ни одного промышленного компилятора, могу спорить с человеком, который "понимает гораздо больше, чем разработчики Borland и видит их ошибки".

Так что распространять вместе с BPL, ещё и какие-то файлы DCU и DCP, код которых фактически УЖЕ содержится в BPL, -- следствие непродуманной архитектуры IDE.

А в С вообще беда, там какие-то странные header-файлы? Что, естественно, свидетельствует о непродуманности архитектуры всей линейки языков, и как следствие - вызывает глючность Windows, так что лучше писать на Java под Linux. А лучше просто пойти и удариться головой о стену. Летальный исход не обязателен, но приветствуется.

>
> 3. Для сборки пакетов и приложений, зависящих от какого-
> либо пакета нужны DCP и DCU этого пакета.

DCU не нужны

> [41] iZEN © (12.01.07 00:09)
> Использование OCX было бы универсальным решением на все
> случаи жизни, вы будете спорить?

А их разве можно статически линковать? AFAIK это все те же DLL.

> [43] API © (12.01.07 02:45)

Почему под Линукс? Он же тоже на С писан.

> Vga © (13.01.07 08:46) [47]
>
> > [41] iZEN © (12.01.07 00:09)
> > Использование OCX было бы универсальным решением на все
> > случаи жизни, вы будете спорить?
>
> А их разве можно статически линковать? AFAIK это все те
> же DLL.

"Псевдостатически", если уместно это слово, -- можно, они будут грузится как DLL. Любой OCX можно импортировать в среду Delphi, в проект. При этом создаются заглушки для ActiveX-объектов, не всегда со всей информацией -- зависит от переваривания полченного кода pascal-компилятором, иногда требуется ручная правка кода заглушек. Через эти заглушки и осуществляется взаимодействие с ActiveX-объектами. Получается, что компилятор проверяет все вызовы на этапе компиляции кода заглушек с прикладным кодом.

Другой способ -- использование интерфейса IDispatch и вызов методов/работа со свойствами по именам (тип данных Variant). Импортирование OCX в среду/проект не требуется. Названия методом и свойств узнаются с помощью любых TypeInfo-эксплореров. Способ более затратный в плане производительности, так как вручную придётся инстанцировать экземпляр объекта (что, в случае заглушек, делается автоматически в сгенерированном коде), при вызовах приводить данные к нужному типу и следить за правильностью приведения во время выполнения (нетипобезопасный способ).

Библиотека OCX, в любом случае, должна распространяться вместе с EXE и регистрироваться в реестре перед использованием.

← →
нечитатель (2007-01-13 14:49) [49]

> А их разве можно статически линковать? AFAIK это все те
> же DLL.
/
iZen использует необычную терминологию. Конечно, статически линковать их нельзя.

> В Delphi возможен вызов этого кода в статическом связывании
> (в этом случае использование OCX в проекте равносильно использованию
> DLL/BPL), так и динамическое связывание во время выполнения
> приложения (аналог контейнера OLE, COM/DCOM).

OCX - старое название ActiveX-компонент, MS отказалась от использования этой аббревиатуры лет 8 назад.

Так называемые "статическое/динамическое связывание" принято называть ранним/поздним связванием.

← →
нечитатель (2007-01-13 14:52) [50]

Чтобы подавить всех своей эрудицией можно еще про явное-неявное связывание dll нагрузить.

> [48] iZEN © (13.01.07 09:31)
> "Псевдостатически", если уместно это слово, -- можно, они
> будут грузится как DLL.

Угу, оберточно. К "статически" это ни малейшего отношения не имеет.

← →
Mva (2007-01-16 09:50) [52]

Не бери ничего в голову.
С Днём Рождения.

блин ну и умучался я с этой Вашей bds 2006 )) Найти похожие ветки