А как на счет среднего по размеру exe и среднего количества dll ? Если серьёзно, то попробуй протестить в обоих случаях. И делай в том ваианте, где программа будет работать быстрее
Если ты планируеш использовать свой код в других проектах, выводи его в отдельнную dll. Так и удобнее и надежное, поскольку не нужно заботится о содержащемся в ней коде, если его работоспособность уже подтверждена ранее. Кроме того над каждой dll может работать отдельный программист. Что касается скорости. Прграмма использующая dll точно загружается медленнее, и теоретически, медленнее работает. Но особого замедления в плане фпс я не замечал. Windmill 2
Меня, как потребителя, больше интересовал бы одинокий exe-шник: в файлах не путаешься. Ну, это если мнение потребителей вас интересует, конечно. Бледные дрыщекролики следят за вами
Меня, как потребителя, больше интересовал бы одинокий exe-шник: в файлах не путаешься. Ну, это если мнение потребителей вас интересует, конечно.
Можно при инсталяции лить dll в System32, И проект сам будет их оттуда подгружать. В плане работоспособности зависит от того как линковать эти dll, статически или динамически, если их линковать при запуске программы, то они подгружаются еще до Энтри поинт самого exe, то есть перед инициализацией самой программы. На счет работоспособности отвечу легко и просто, dll - это обычный com объект, на них построена винда, на них заложен DX и OpenGL - инициализация com объекта занимает пару сотен тактов, так что на быстродействии это не как не скажется, по крайней мере для глаза точно)).
Как заметил уважаемый (лично мной) nilrem, в плане фпс Вы ничего не заметите, ну а на счет скорости работы, она основанна только на инициализации, и все функции которые локализированны в компиляторе основаны на WinAPI функциях которые инициализируются компилятором по умолчанию и Вы этого не видите, однако взглянув в IDA или Ольге (OllyDBG) да просто в таблицу импорта EXE вы увидите там либы, которые Вы можете присягнуть самому черту, Вы никогда не подключали.
Quote
Меньше шансов на взлом де компилятора и больше придётся попотеть!
Тут уже зависит от уровня знаний кодокопателя, можно и в либу сделать антиотладку не хуже чем в ехе)) не говоря о полиморфности и прочих приблудах, как тарить Точку входа, хучить кольцо, отлавливать VM и тд.
Ну и собственно по сабжу.
Quote
А как на счет среднего по размеру exe и среднего количества dll ?
Золотые слова. (ИМХО). Делайте оптимально и как лучше и удобнее Вам, а от обычного пользователя лишнее можно спрятать.
Akyltist, dll -dinamic link library динамически загружаемые библиотеки. Есть ещё статически загружаемые библиотеки в C/C++ это lib файлы, есть файлы описания языков C/C++ h и hpp. hpp это С++. Определения функций. Статические библиотеки должны линковаться жёстко определением путей к файлу библиотеки. Динамические библилиотеки потому и динамические, что могут вызываться по мере надобности. Кроме того в Винде есть интересная возможность. Винда может помнить динамические библиотеки даже после выгрузки приложения. В XP Твикере есть опция выгружать динамические библиотики при выгрузке приложения. Зачем это нужно. Если динамическая библиотека не выгружена Виндой то при следующем запуске приложения загрузка идёт быстрее. Статические библиотеки принадлежат только одному приложению тому к которому они прилинкованы, и выгружаются вместе с ним. Загружаются тоже вместе с ним. Но такой подход имеет минус. Расход оперативной памяти. Кто не работал на старых компах не поймёт. Тогда программисты извращались как могли испыользуя Верхнюю и Нижнюю память. Запускали программы не по дефолту, а через батники которые сначала запускали менеджере памяти и выводили память в нужный режим, а потом программу запускали. Это была целая наука. Управление памятью в MS DOS. Всё изменилось с появлением Винды. http://vkontakte.ru/id56359373 Строю Город, обустраиваю Остров. Присоединяйтесь.
Сообщение отредактировал anisimov - Четверг, 19 Ноября 2009, 01:31
Не совсем так, для файлов компоновки нужны строгие пути, для компиляторов, а для самой загрузки это не важно. Дабы не трогать компиляторы С++ и файлы компоновки к которым нужны те самые строгие пути, рассмотрим линковку либ на другом ЯП. Вот глаз падает на Дельфина.
Накатаем простейшую либу:
Code
library MyLib;
uses SysUtils, Classes;
function Algebra(x,z: real; metod: integer):Double; stdcall; var d: Double; begin case metod of { d взят для того чтобы избежать переполнения, хотя при умножении тут это не поможет))) но все же не стоит забывать о багах. Создадим видимость что мы о них помним } 0: d:=x+z; 1: d:=x-z; 2: d:=x*z; 3: if z<>0 then d:=x/z; else d:=0; end; result:=d; end;
exports Algebra;
begin end.
Важно помнить, что если при разработке dll использовалось соглашение stdcall, то и при её вызове должно использоваться тоже stdcall. Это делает возможным работать с нашей Dll другим программам используя данное соглашение.
Соберем простейший проект для статической загрузки dll и проверим, так ли особо нужны строгие пути.
type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end;
var Form1: TForm1;
implementation
function Algebra(x,z: real; metod: integer):Double; stdcall; external 'project1.dll'; {$R *.dfm}
procedure TForm1.Button1Click(Sender: TObject); begin Form1.Caption:=FloatToStr(Algebra(5,3,2)); end;
end.
Пытаемся запустить и у нас вылетает ошибка: Все правильно, ведь библиотека находится в другой папке. Но мы ее не будем кидать в нашу папку с этим проектом, нет нет, мы ее кинем в папочку WINDOWS и теперь пробуем запустить. Вуаля проект запустился. Тоже самое будет если ее кинуть в windows/system windows/system32 и ряд других папок. Именно об этом я и говорил.
Не Важно, статическая либа или динамическая. Все либы можно слить в эти папки, и тогда у Вас останется голый ехе в Вашей папке. Как я и говорил.
Теперь о недостатках статических либ. 1) Если необходимых программе функций и библиотек много, то процесс их загрузки может занять значительное время. Однако вызовы будут происходить при работе быстрее, так как либа уже подгружена в память. 2) Функции будут отнимать оперативную память, причем все и одновременно, хотя программе возможно они не нужны в один и тот же момент времени. 3) Если какая-нибудь из необходимых библиотек отсутствует, то загрузка программы станет невозможна, т.е. таким образом невозможно реализовать, например, механизм плагинов. Поэтому следите что Вы поставляете в комплекте все файлы. А при распаковке уже решайте куда Вам их кидать. 4) В конце концов, компоновщику при компоновке программы понадобятся .LIB файлы на каждую подключаемую библиотеку. Наверное именно это и имел ввиду Уважаемы собеседник anisimov.
Ну что же, поедем дальше, что кота тянуть .. э .. за... хвост!!!
И так попробуем подгрузить либу динамически, пишем проект, дамы и господа.
Комментарии на русском посмотрите в папке с прилагаемым архивом) лень переписывать). Сразу предупреждаю, если dll не будет в папке с проектом или в папках перечисленных выше) такие как windows, то будет ошибка чтения). А если нашу dll скинуть в папку windows то прога все нормально посчитает). Если не хотите эрроров то выставит он еррор в 0.
Ну и на последок, как видим для нашей самописной длл мы не писали ни каких файлов компановки, так как: Мы знаем имена функций непосредственно, и знаем какие параметры она использует.)))
Всем счастливо прочитать, лью архив иду пить чай.
Всем с уважением желаю доброго времени суток. Дернем по чайку коллеги.
Prooject.rar - тут файлы проектов Din.rar - скомпилированный проект динамической загрузки Stat.rar - скомпилированный проект статической загрузки dll.rar - скомпилированная Dll.
