Исполняемый файл программа будет иметь наибольший размер если программа создавалась на
Я заметил, по крайней мере, в Windows, что вы можете скачать прямой исполняемый файл со статической связью и запустить его напрямую, или написать свою собственную программу и выполнить ее (даже динамически) без необходимости ее установки.
Это подводит меня к моей главной мысли . какова цель процесса установки? Я имею в виду, может быть, помимо реестра Windows . Однако в целях практичности и использования можно иметь одну независимую автономную программу, которую можно запускать, хранить в энергонезависимой памяти и получать к ней доступ через файловую систему любого устройства, на котором она находится, и запускаться в ОС. Так в чем же дело со всем этим бизнесом «установи это», если многие замечательные программы практически любой величины могут работать идеально, не проходя конфигурацию установки? Меня это немного озадачивает, и кроме базы данных или других систем конфигурации метаданных / доступа, какая здесь реальная разница, если последний (установленный исполняемый файл) работает и работает так же, как автономный?
Есть ли здесь разница, о которой я не знаю, с не установленной программой по сравнению с установленной?
PS: Это относится не только к ОС Windows, но и к любым, которые реализуют аналогичную функцию.
Есть несколько причин, почему программы приходят как установщики, а не как отдельные исполняемые файлы:
Размер файла касается
Программы с большим количеством больших зависимостей могут объединять установщики на основе Интернета, которые загружают зависимости и размещают их в общем расположении, так что они могут совместно использоваться несколькими программами. Например, DirectX - это очень большая библиотека. Если каждая отдельная программа в вашей системе, которая зависит от DirectX, просто объединяет с собой всю среду выполнения DirectX, она будет занимать достаточно много места. Это может показаться неважным в возрасте 4 ТБ жестких дисков, но учтите, что твердотельные накопители имеют гораздо меньшую емкость, и они широко используются на ультрабуках, некоторые из которых имеют всего 64 ГБ дискового пространства. И, конечно, помимо DirectX, есть много других общих библиотек.
Очень большие и постоянно обновляемые программы лучше всего распространять в виде набора из множества небольших файлов вместе с программой запуска или программы обновления, которая проверяет наличие обновлений в Интернете и, если существует какое-либо обновление, загружает только необходимые изменения. Если все большие программы были отправлены как один монолитный исполняемый файл, весьма вероятно, что процесс исправления потребует повторной загрузки всего исполняемого файла, так как исправление исполняемого исполняемого файла на диске практически невозможно из-за блокировок файлов. Кроме того, поскольку средство обновления должно знать, где находятся его файлы, оно часто сохраняет этот путь к каталогу в известном месте в реестре.
Проблемы удобства пользователей
Установщики для очень больших программ, таких как Visual Studio и Microsoft Office, позволяют пользователю отменить установку определенных функций, если пользователь знает, что они им никогда не понадобятся. У этого есть 3 потенциальных преимущества: это уменьшает потребление дискового пространства; это может уменьшить время загрузки и потребление полосы пропускания, если установщик является веб-загрузчиком; и это может уменьшить «беспорядок» и «раздувание» на компьютере пользователя, уменьшить количество пусков меню / ярлыков на рабочем столе, уменьшить количество запускаемых программ и т. д.
Установщики для сложных программ часто поставляются с опциями конфигурации, которые пользователь может настроить с помощью удобного графического интерфейса как части установщика. Посмотрите, например, установщики MySQL или SQL Server, которые могут пройти весь процесс настройки и запуска сервера базы данных, прежде чем вы даже нажмете «Готово» в установщике.
Установщики могут запросить у пользователя необходимую информацию, например, лицензионные ключи, которые нужно вводить только один раз. Это может упростить разработку самой программы, сократить число выполняемых ею действий и проверять, когда она запускается. Это также дает пользователю уверенность в том, что после успешной установки программа должна «просто работать» - в программе больше нет «ловушек», которые могут помешать им использовать ее.
Проблемы совместимости
Некоторые программы конфликтуют с другими программами. Это простой и прискорбный факт разработки программного обеспечения. Перед установкой программы, которая, как известно, конфликтует с другими программами, часто полезно сначала проверить систему, чтобы увидеть, установлена ли несовместимая программа. Пользователь может быть предупрежден, если это так. Например, существует очень опасный потенциал несовместимости в более старых версиях VMware и VirtualBox, что привело к появлению «синего экрана смерти», поскольку одна программа будет пытаться использовать специальную инструкцию процессора виртуализации после того, как она уже была зарезервирована для пользователя другим продуктом. , Если бы вы просто предоставили конечный продукт пользователю без установщика, вам пришлось бы проверять наличие несовместимых продуктов на каждом запуск вашей программы, который может замедлить запуск программы.
Программы могут зависеть от других компонентов системы, которые могут быть установлены только на общесистемном уровне, а не на уровне пользователя. Чтобы установить эти специальные компоненты системы, обычно требуются права администратора и обычно должен запускаться установщик.
Повышенные привилегии и специальные услуги
Учитывая все эти причины, почему установщики полезны, вот несколько замечаний с другой стороны:
Многие программы, даже те, которые доступны для загрузки только в качестве установщика, требующего прав администратора, можно принудительно «распаковать» из своих установщиков и запустить непосредственно без их установки. Другие программы, особенно программы с открытым исходным кодом, переупаковываются в автономные исполняемые файлы PortableApps . Следует отметить, что некоторые программы, распакованные из установщика, будут иметь сниженную функциональность, ошибки или другие проблемы.
В операционных системах, отличных от Windows, почти всегда можно просто загрузить (или скомпилировать) программы и запускать их как обычный пользователь без получения root. Есть несколько исключений в отношении пакетов, которые являются основной частью операционной системы, но для большинства пользовательских приложений вы можете запустить его в своем домашнем каталоге, не устанавливая его в масштабе всей системы, используя менеджер пакетов. Windows - это особый случай, поскольку большинство настольных программ в Windows имеют установщик и обычно не могут быть установлены другим способом.
Даже на платформах, отличных от Windows, программы, которым требуется возможность загрузки модуля ядра, поставляются с каким-то инсталлятором, который компилирует модуль ядра и устанавливает его в нужную директорию. Вы также можете ожидать появления установщика в том случае, если программа является демоном, который будет запущен с использованием сценария системной службы, например, в /etc/init.d . Этот тип «сжатых двоичных файлов» является менее распространенным методом распространения в GNU / Linux, но большинство дистрибутивов Linux по-прежнему предоставляют большую часть программного обеспечения в форме устанавливаемых пакетов, для каждого из которых для установки требуется root-доступ (доступ администратора).
Выводы
Использование установщика или нет - это выбор, который должны сделать производители программного обеспечения. Есть преимущества и недостатки использования установщика. Многие поставщики предпочитают распространять свое программное обеспечение как в качестве установщика, так и в виде отдельного двоичного файла или, по крайней мере, в виде ZIP-файла, который можно просто распаковать и запустить. Для программного обеспечения, которое абсолютно не требует инсталлятора, это очень прагматичный путь, который делает всех счастливыми. Обычно программное обеспечение, которое поставляется не в какой-либо иной форме, кроме как с установщиком, является программным обеспечением, которому требуются административные привилегии для установки какого-либо компонента, поскольку установщик является наиболее элегантным способом получения необходимых привилегий.
Лично я нахожу инсталляторов очень раздражающими в моей повседневной работе, потому что иногда я хочу запустить программу, когда у меня нет прав администратора на компьютере, который я использую. У меня довольно большой опыт ручной распаковки инсталляторов для извлечения программных файлов внутри, а затем их правильной работы. Тем не менее, на моем персональном компьютере дома, где у меня всегда есть административный доступ, я нахожу установщики полезными и удобными, потому что большинство установщиков предоставляют мне полезные опции, такие как создание ярлыка на рабочем столе, что мне пришлось бы вместо этого делать вручную без него.
Рустэм Галеев aka Roustem
3. Исполняемые файлы Windows
Как сделать, чтобы программа заработала? Работа приложения начинается с того, что операционная система создает процесс. Это не просто загруженная в память программа пользователя; процесс предполагает создание множества внутренних системных структур для обеспечения работы программы и предоставления ей различных ресурсов, таких как память, процессорное время, доступ к установленному в системе оборудованию и т.д.Важнейшим ресурсом являетcя виртуальная память. Каждый процесс получает в свое распоряжение собственное виртуальное адресное пространство памяти размером 4 Гб. Это значит, что он может обращаться по любому из адресов памяти от 0 до FFFFFFFFh. Но это значит также и то, что различные процессы могут использовать одни и те же адреса, не мешая друг другу. Система работает с памятью в виде блоков фиксированного размера, называемых страницами (обычно по 4 Кб; на современных процессорах могут быть страницы также по 2 Мб) и использует страничную переадресацию для отображения одних и тех же виртуальных адресов различных процессов в разные области физической памяти. Кроме того, при недостатке физической памяти временно неиспользуемые данные могут сохраняться на диске, освобождая физическую память для других виртуальных адресов (это называется подкачкой).
Расширение "exe" осталось в наследство от старых досовских исполняемых (executable) файлов. Используемый в настоящее время формат исполняемых файлов Windows называется "Portable Executable" (PE), поскольку один и тот же формат используется для разных платформ. Более того, он построен на основе шаблонов, являющихся общими и для объектных файлов формата COFF (используемых в том числе в мире Unix), а также построенных на их основе библиотечных файлов и файлов импорта (.lib). Формат PE в системе Win32 является универсальным: его используют не только исполняемые файлы (exe), но и динамические библиотеки (dll) и их особые разновидности -элементы ActiveX (ocx) и системные драйверы (sys и drv).
Как и старый формат exe для DOS, PE-файл состоит из заголовка и собственно образа исполняемой программы. Образ программы, как уже отмечалось, может быть составлен из одной или нескольких секций. Заголовок же можно условно разделить на "старый" и "новый" (см. рис.)
"Новый" заголовок составлен из собственно PE-заголовка и таблицы секций, которая фактически является картой отображения записанных в файле секций образа программы в память. В PE-заголовке выделяют также несколько составных частей, но для нашего рассмотрения они несущественны. Отметим лишь каталог смещений-размеров, который указывает на расположение и размеры специальных служебных таблиц. Для размещения последних могут быть выделены отдельные секции в образе программы, но это не является обязательным; в принципе, для всей программы можно использовать одну единственную секцию, разместив в ней и данные, и код, и все необходимые вспомогательные структуры.
Теперь рассмотрим все подробнее. Поскольку попытка запуска создаваемых нами программ под DOS маловероятна, можно без особых проблем обойтись без программы-заглушки DOS. PE-заголовок в этом случае будет следовать сразу за старым заголовком DOS, а именно - непосредственно после 4-байтного поля со смещением 3Ch, т.е. по смещению 40h (само поле 3Ch будет содержать в данном случае это же значение). Единственное, что нужно еще оставить в старом заголовке - это сигнатуру в виде 2 ASCII-символов 'MZ' в начале файла (байты 4Dh 5Ah). Остальные поля могут содержать нули - загрузчик Windows их не использует.
Поля PE-заголовка приведены в таблице 1. Смещения указаны относительно начала заголовка, а жирным шрифтом выделены те поля, при неверных значениях которых Windows откажется загружать программу. Остальные поля либо содержат необязательные данные (например, указатель на размещение и размер отладочных данных), либо для них предусмотрены значения по умолчанию (как для размеров кучи и стека), либо используются лишь для определенных видов файлов (например, флаги dll или контрольная сумма).
Таблица 1. PE-заголовок
Смещение | Размер, байт | Поле | Типичное значение |
---|---|---|---|
0 | 4 | Сигнатура 'PE' | 50h 45h 00 00 |
4 | 2 | Тип процессора | 14Ch |
6 | 2 | Число секций в образе программы | - |
8 | 4 | Время/дата создания файла | - |
0Ch | 4 | Указатель на таблицу символов | 0 |
10h | 4 | Количество отладочных символов | 0 |
14h | 2 | Размер дополнительного заголовка | E0h |
16h | 2 | Тип файла | 10Fh |
18h | 2 | "Магическое" значение | 10Bh |
1Ah | 1 | Старшая версия компоновщика | - |
1Bh | 1 | Младшая версия компоновщика | - |
1Ch | 4 | Размер кода | - |
20h | 4 | Размер инициализированных данных | - |
24h | 4 | Размер неинициализированных данных | - |
28h | 4 | Смещение точки входа | - |
2Ch | 4 | Смещение секции кода в памяти | - |
30h | 4 | Смещение секции данных в памяти | - |
34h | 4 | Адрес загрузки образа в память | 400000h |
38h | 4 | Выравнивание секций в памяти | 1000h |
3Ch | 4 | Выравнивание в файле | 200h |
40h | 2 | Старшая версия Windows | 4 |
42h | 2 | Младшая версия Windows | 0 |
44h | 2 | Старшая версия образа | - |
46h | 2 | Младшая версия образа | - |
48h | 2 | Старшая версия подсистемы | 4 |
4Ah | 2 | Младшая версия подсистемы | 0 |
4Ch | 4 | Зарезервировано | 0 |
50h | 4 | Размер загруженного файла в памяти | - |
54h | 4 | Размер всех заголовков в файле | - |
58h | 4 | Контрольная сумма | 0 |
5Ch | 2 | Подсистема | 2 или 3 |
5Eh | 2 | Флаги dll | 0 |
60h | 4 | Зарезервированный размер стека | 100000h |
64h | 4 | Выделенный размер стека | 1000h |
68h | 4 | Зарезервированный размер кучи | 100000h |
6Ch | 4 | Выделенный размер кучи | 1000h |
70h | 4 | Устарело | 0 |
74h | 4 | Число элементов в каталоге смещений | 10h |
Далее в PE-заголовке следует каталог размещения вспомогательных таблиц: первые 4 байта для каждого элемента являются смещением начала соответствующих данных относительно базового адреса загрузки, следующие 4 байта - размером этих данных. Хотя число элементов в каталоге указывается в поле PE-заголовка, Windows 9* не допускает значения, меньшего 10h. Структура каталога фиксирована; указатели на соответствующие данные должны следовать в следующем порядке:
- таблица экспорта;
- таблица импорта;
- таблица ресурсов;
- таблица исключений;
- таблица сертификатов;
- таблица настроек;
- отладочные данные;
- специфичные для архитектуры данные;
- глобальный указатель;
- таблица локального хранилища потоков (TLS);
- таблица конфигурирования загрузки;
- таблица связанного импорта;
- таблица импортируемых адресов (IAT);
- дескриптор отложенного импорта;
- зарезервировано;
- зарезервировано.
Это не значит, что все перечисленные данные должны присутствовать. Если те или иные данные отсутствуют, соответствующие поля каталога содержат нули. Мы будем рассматривать эти структуры по мере того, как начнем с ними работать.
Таблица секций следует непосредственно после PE-заголовка (после каталога смещений). Каждый вход таблицы имееет следующий формат (см. табл. 2).
Таблица 2. Строка таблицы секций
Смещение | Размер, байт | Поле |
---|---|---|
0 | 8 | Произвольное имя секции |
8 | 4 | Размер секции в памяти |
0Ch | 4 | Смещение секции в памяти относительно адреса загрузки |
10h | 4 | Размер данных секции в файле |
14h | 4 | Смещение начала данных секции в файле |
18h | 12 | Используется лишь в объектных файлах |
24h | 4 | Флаги секции |
Таблица секций имеет столько входов, сколько секций в образе программы. Расположение секций в файле и в виртуальной памяти созданного процесса может не совпадать. Данные различных секций как в файле, так и в памяти располагаются не вплотную друг к другу - они должны быть соответствующим образом выровнены. Например, если код занимает всего 2 байта, следующая за ним секция (допустим, данных) располагается не по смещению +2 байта, а на границе следующей страницы, т.е. как минимум через 4 Кб, если это образ в памяти, и минимум через 512 байт для образа в файле. Значения для выравнивания в файле и в памяти указаны в PE-заголовке, причем они обязательны.
Секция может содержать т.н. неинициализированные данные. Фактически, это просто резервирование определенных адресов памяти под будущие переменные. Для таких данных место в файле не отводится; память резервируется лишь при загрузке на исполнение. Если вся секция содержит лишь неинициализированные данные, поля размера данных секции в файле и смещения начала данных секции в файле равны нулю. В любом случае, когда размер секции в файле меньше указанного размера секции в памяти, остаток заполняется до нужного размера нулями.
Поле флагов секции - то самое, где задаются атрибуты страниц памяти, отводимых под секцию. Возможно использование до 32 флагов (по одному на каждый бит 4-байтного значения), но часть из них зарезервирована, другая часть используется лишь в объектных файлах. Биты нумеруются от младшего к старшему, начиная от 0 (самый младший бит - 0, самый старший - 31). Наиболее употребительные для исполняемых файлов следующие:
бит 5 - секция кода;
бит 6 - инициализированные данные;
бит 7 - неинициализированные данные;
бит 28 - секция может быть общей (разделяемой - shared);
бит 29 - разрешено исполнение;
бит 30 - разрешено чтение;
бит 31 - разрешена запись.
Например, в секции кода с разрешениями на чтение и исполнение установлены следующие флаги:
Секция с инициализированными данными с разрешениями на чтение и запись:
Та же секция, но с разрешением только для чтения:
Перейдем, наконец, к практике и составим шаблон заголовка PE-файла, имеющего 3 секции с минимальными размерами. Тогда в памяти каждая будет занимать 1000h (1 страница - отвести меньше памяти невозможно), а в файле - 200h байт (1 сектор диска). Такими же будут и значения выравнивания. Первой пусть идет секция кода; назовем ее '.code' (см. рис.) Она будет располагаться по смещению 200h от начала файла, а в памяти - по смещению 1000h от адреса загрузки (первую страницу памяти и первые 200h байтов файла занимает заголовок). Секция кода будет иметь флаги, которые мы вычислили ранее (60000020h)
Следующей будет секция с данными только для чтения; назовем ее '.rdata'. Она будет расположена в файле по смещению 400h, а в памяти - по смещению 2000h. Флаги: 40000040h. За ней - секция данных с разрешениями на чтение и запись: '.data', расположение в файле - 600h, в памяти - 3000h; флаги: C0000040h.
Теперь составим командный файл для отладчика debug. Имеет смысл сначала создать специальную папку "Шаблоны". В ней сохраним этот файл для использования в дальнейшем. Открываем Блокнот и набираем:
Бинарный файл с заголовом будет называться 'Header.bin', его размер - 200h байт. Сначала очищаем "область сборки" - первые 200h байт, затем набираем стандартные сигнатуры. Программы-заглушки у нас не будет - PE-заголовок следует непосредственно за DOS-заголовком; заодно это сэкономит размер заголовка.
А вот дальше пойдут поля PE-заголовка, которые нужно будет настраивать для каждого отдельного exe-файла. Чтобы было удобнее редактировать этот файл в дальнейшем, оставим здесь комментарии - а для этого нам придется изменить способ ввода и перейти в режим ассемблирования.
Режим ассемблирования начинается с команды 'a', за которой следует смещение, по которому нужно вводить данные. В нашем случае, PE-заголовок начинается со смещения 40h от начала файла, поэтому к значениям смещения в таблице 1 нужно добавлять 40h. Близко отстоящие друг от друга поля можно набирать "в один заход"; когда же разрыв большой, можно выйти из режима ассемблирования (оставив для этого пустую строку) и вновь набрать 'a' уже с новым смещением. В "разрыве" при этом останутся нули. Учтите, что комментарии можно оставлять лишь "внутри" режима ассемблирования - вне его отладчик выдаст ошибку.
Имеет смысл также выделить те участки, которые нужно будет в дальнейшем редактировать (как этот случай - число секций может каждый раз быть разным); для этого удобно выделять каким-либо способом строку с комментарием, чтобы она сразу бросалась в глаза. Оставшуюся часть файла для debug приведем, как есть; она не должна вызвать проблем (обратите внимание на пустые строки - их нельзя удалять; и помните про обратный порядок байтов в числах, требующих более 1 байта):
Перед записью созданного "образа заголовка" сдвигаем его на 100h байт, чтобы все записалось правильно. Сохраним этот текст в файле "Header.txt".
Теперь у нас есть шаблон, который можно вставлять в начало exe-файла с 3 секциями, размеры которых не превышают 200h байт каждая. Чтобы протестировать его, нужно собрать "настоящий" exe-файл с его использованием. Для этого немного схитрим: вставим две пустые секции (содержащие лишь нули) в качестве секций данных; а в секции кода используем всего 2 байта: EB FE. Это инструкция, передающая управление на себя (как мы узнаем в дальнейшем). Т.е. наша программа просто зацикливается; но пока нам большего и не надо.
В блокноте создадим еще 2 простых файла. Первый - "s1.txt" (содержит наш "код"):
Второй - "s2.txt" (секция в 200h байт, заполненная нулями):
А теперь в том же Блокноте создаем файл "make.bat":
Первый вызов debug исполняет команды, записанные в файле header.txt (при этом создается файл header.bin). Отчет выводится в файл report.lst; это необходимо для того, чтобы можно было проверить, не были ли допущены ошибки.
Второй вызов debug исполняет команды в файле s1.txt, создавая файл s1.bin с нашей "секцией кода". Перенаправление с двумя знаками >> означает, что отчет записывается не с начала указанного файла (затирая его содержимое), а добавляется в его конец. Третий вызов debug выполняет s2.txt, создавая пустую секцию в файле s2.bin. Наконец, мы объединяем эти секции в единый файл с расширением exe, причем заметьте - файл s2.bin использован дважды (2 пустые секции).
Все языки программирования делятся на два типа — интерпретируемые и компилируемые.
Интерпретаторы
Программируя на интерпретируемом языке, мы пишем программу не для выполнения в процессоре, а для выполнения программой-интерпретатором. Ее также называют виртуальной машиной.
Как правило, программа преобразуется в некоторый промежуточный код, то есть набор инструкций, понятный виртуальной машине.
При интерпретации выполнение кода происходит последовательно строка за строкой (от инструкции до инструкции). Операционная система взаимодействует с интерпретатором, а не исходным кодом.
Скомпилированные программы работают быстрее, но при этом очень много времени тратится на компиляция исходного кода.
Программы же, рассчитанные на интерпретаторы, могут выполняться в любой системе, где таковой интерпретатор присутствует. Типичный пример — код JavaScript. Интерпретатором его выступает любой современный браузер. Вы можете однократно написать код на JavaScript, включив его в html-файл, и он будет одинаково выполняться в любой среде, где есть браузер. Не важно, будет ли это Safari в Mac OS, или же Internet Explorer в Windows.
Компиляторы
Компилятор — это программа, превращающая исходный текст, написанный на языке программирования, в машинные инструкции.
По мере преобразования текста программы в машинный код, компилятор может обнаруживать ошибки (синтаксиса языка, например). Поэтому все проблемы забытых точек с запятыми, забытых скобок, ошибок в названиях функций и переменных в данном случае решаются на этапе компиляции.
При компиляции весь исходный программный код (тот, который пишет программист) сразу переводится в машинный. Создается так называемый отдельный исполняемый файл, который никак не связан с исходным кодом. Выполнение исполняемого файла обеспечивается операционной системой. То есть образуется, например,.EXE файл.
Примеры компилируемых языков: C, C++, Pascal, Delphi.
Препроцессинг
Эту операцию осуществляет текстовый препроцессор.
Исходный текст частично обрабатывается — производятся:
- Замена комментариев пустыми строками
- Подключение модулей и т. д. и т. п.
Компиляция
Результатом компиляции является объектный код.
Объектный код — это программа на языке машинных кодов с частичным сохранением символьной информации, необходимой в процессе сборки.
Компоновка
Компоновка также может носить следующие названия: связывание, сборка или линковка.
Это последний этап процесса получения исполняемого файла, состоящий из связывания воедино всех объектных файлов проекта.
EXE файл.
Заходим в Сервис -> Настройки -> Опции компиляции. Поверяем, стоит ли галочка напротив 2 пункта. Если стоит, то убираем ее.
Теперь откройте свою программу и запустите ее.
Откройте директорию, в которой у вас лежит исходный код программы.
Кликаем по приложению. Как вы видите, после ввода данных, окошко сразу закрывается. Для того чтобы окно не закрывалось сразу, следует дописать две строчки кода, а именно: uses crt (перед разделом описания переменных) и readkey (в конце кода, перед оператором end).
Подключаем внешнюю библиотеку crt и используем встроенную в нее функцию readkey.
Теперь окно закроется по нажатию любой клавиши.
Среда разработки включает в себя:
- текстовый редактор;
- компилятор;
- средства автоматизации сборки;
- отладчик.
На сегодня все! Задавайте любые вопросы в комментариях к этой статье. Не забывайте кликать по кнопочкам и делится ссылками на наш сайт со своими друзьями. А для того, чтобы не пропустить выход очередной статьи, рекомендую вам подписаться на рассылку новостей от нашего сайта. Одна из них находится в самом верху справа, другая — в футере сайта.
Сценарии входа в систему представляют собой пакетные файлы, файлы команд или исполняемые файлы программ , которые могут быть назначены для учетных записей пользователей. Сценарии входа в систему предназначены для установки среды пользователя без управления всеми се деталями. Сценарий входа должен размещаться на контроллере домена, проверяющем запрос пользователя на вход в систему. [5]
В любом случае при наличии текстовой версии DFM-файла среда Delphi перед использованием их в исполняемом файле программы все равно преобразует его в формат двоичного ресурса. [6]
Компилятор читает не исходный файл источника, а результат работы препроцессора и компилирует его в исполняемый файл программы . Вам уже приходилось встречаться с директивой препроцессора include: она предписывает найти файл, имя которого следует за ней, и вставить текст этого файла по месту вызова. Этот эффект подобен следующему: вы полностью вводите данный файл прямо в свою исходную программу, причем к тому времени, когда компилятор получит исходный код, файл будет уже на месте. [7]
В рассматриваемом варианте программы предполагается, что база данных находится в подкаталоге DATA того каталога, в котором находится исполняемый файл программы . Псевдоним создается процедурой TFormi. Непосредственное создание псевдонима выполняет процедура AddstandardAiias, которой в качестве параметра передается имя псевдонима и соответствующее ему имя каталога. Так как во время разработки программы нельзя знать, в каком каталоге будет размещена программа работы с базой данных и, следовательно, подкаталог базы данных - DATA, имя каталога определяется во время работы программы путем обращения к функциям Paramstr и EtractFiiePatch. [8]
Хотя сервер регистрируется только один раз, программа ServDemo при автономном выполнении регистрируется каждый раз при удалении системного реестра или изменении пути к каталогу с исполняемым файлом программы . [9]
Следует отметить, что программы по расчету гидросистем как правило малы по объему, и легко выполнятся в редакторе языка программирования, поэтому имеет смысл задавать исходные данные в теле программы операцией присвоения, не создавать исполняемые файлы программы , а производить расчеты прямо в редакторе языка, при этом экономится время на ввод многочисленных исходных данных и сохраняется возможность корректировки программы. Для того, чтобы начать написание программы, прежде всего нужно иметь: схему гидравлическую принципиальную, исходные данные и алгоритм расчета. Необходимо знать, какие именно параметры необходимо вычислить с помощью данной программы и точно знать последовательность вычисления неизвестных величин. [10]
Когда приложение состоит из отдельных процессов, один из них ( обычно, главный модуль программы) может запускать один или несколько дополнительных. Следовательно, нужно запустить только главный исполняемый файл программы , а управлять запуском исполняемого файла для каждого дополнительного процесса не нужно. Например, если в бухгалтерском приложении с несколькими процессами выбрать команду платежной ведомости, то программа может запустить исполняемый файл модуля платежной ведомости. [11]
В этой главе дается обзор некоторых наиболее известных средств разработки программ на языке Фортран. Кратко рассмотрев основные этапы генерации исполняемого файла программы , мы перейдем к знакомству с трансляторами и некоторыми средствами отладки. Количество компиляторов и систем программирования на Фортране велико и существенно превышает количество компиляторов, например, для такого популярного языка, как Паскаль. В одной книге невозможно дать полное описание даже одного компилятора. [12]
Начинается главный модуль словом program, за которым следует имя программы, совпадающее с именем проекта. Имя проекта задается в момент сохранения проекта, и оно определяет имя создаваемого компилятором исполняемого файла программы . [13]
В одном случае интерпретаторы переводят исходный код в машинные команды, и компьютер сразу же их выполняет. В качестве альтернативного варианта компиляторы переводят исходный код в исполняемый файл программы , который затем можно использовать самостоятельно. Хотя с интерпретаторами работать легче, большинство серьезных программ создается с использованием компиляторов, поскольку скомпилированный код выполняется намного быстрее. [14]
Читайте также: