Исполняемый файл программа будет иметь наибольший размер если программа создавалась на
В операционных системах Windows (с файловыми системами FAT32 и NTFS) полное наименование не должно превышать 255 символов. Имя вписывают пользователи по своему усмотрению, а расширение файла обычно состоит всего лишь из трех или (реже четырех) символов английского алфавита, причем эти наборы символов для расширений стандартизированные и показывают какого типа рассматриваемый файл. Например, файл «house.jpg» исходя из имени, содержит информацию о доме, а исходя еще из расширения — это некоторое изображение здания.
Стандартные и популярные расширения файлов:
doc – текстовый документ редактора Word,
xls – электронная таблица программы Excel,
txt – простой тестовый документ,
jpg, png, gif – изображения,
avi, jpeg, mp4, mkv – видеофайлы,
mp3, wav – аудиофайлы.
exe – исполняемый файл.
Виды файлов: исполняемые файлы, архивные, файлы с атрибутами. Возможности архиваторов. Виды атрибутов файлов. SFX – архив. Поиск и запуск программ из разных режимов работы: командного, из оболочек, графического.
Исполняемыми файлами называются файлы, содержащие в себе готовые к запуску компьютерные программы.
Архивный файл - это специальным образом организованный файл, содержащий в себе один или несколько файлов в сжатом или несжатом виде и служебную информацию об именах файлов, дате и времени их создания или модификации, размерах и т.п.
атрибуты файла – это параметры, по которым файл отличается от множества других файлов. К атрибутам можно отнести дату и время создания файла, имя файла, имя владельца файла, размер, права и метод доступа к файлу. Атрибуты указывают системе, что можно сделать с данным файлом.
Виды атрибутов
Для каждого файла соответствующая ему запись в каталоге (элемент каталога) содержит атрибуты файла. DOS и Windows 3.1 могут обрабатывать четыре атрибута файлов: «только для чтения» (read-only), «скрытый» (hidden), «системный» (system) и «архивировать» (archive). Каждый из этих атрибутов может быть либо установлен, либо нет.
Назначение атрибутов
Назначение этих атрибутов таково:
• Атрибут файла «только для чтения» предохраняет файл от изменений: для изменения или удаления файла с этим атрибутом требуется предварительно снять данный атрибут. Файлы на компакт-дисках также имеют атрибут «только для чтения», чтобы показать, что изменять эти файлы нельзя;
• Атрибут «скрытый» и/или «системный» используются некоторыми системными файлами (например, основные файлы MS DOS – IO.SYS и MSDOS.SYS, - имеют оба этих атрибута). Файлы с атрибутом «системный» не перемещаются программами оптимизации расположения файлов на диске (типа Speed Disk), а также обычно не копируются на сжатый диск при создании сжатого диска из обычного программами типа Drive Space;
• Атрибут файла «архивировать» устанавливается при создании файла и сбрасывается программами резервного копирования для обозначения того, что копия файла помещена в архив. Поэтому наличие атрибута «архивировать» обычно значит, что для файла не было сделано резервной копии.
Таким образом, большинство файлов имеет установленным только атрибут «архивировать». Остальные атрибуты («только дл чтения», «скрытый» или «системный»), как правило, не установлены.
Основными функциональными возможностями WinRAR являются:
Самораспаковывающийся или самоизвлекающийся архив (англ. self-extracting archive, сокращённо «SFX archive») — файл, компьютерная программа, объединяющая в себе архив и исполняемый код для его распаковки. Такие архивы, в отличие от обычных, не требуют отдельной программы для их распаковки (получения исходных файлов, из которых они созданы), если исполняемый код можно выполнить в указанной операционной системе. Это удобно, когда неизвестно, есть ли у пользователя, которому передаётся архив, соответствующая программа распаковки.
Основной способ использования самораспаковывающихся архивов — создание программ для установки ПО без использования систем управления пакетами.
Исполняемый код, присоединённый к архиву, может представлять собой полноценную программу распаковки. Так как существует вероятность выполнения кода распаковщика, самораспаковывающийся архив или замаскированный под него файл может использоваться для распространения вредоносного ПО.
Основные и дополнительные системные файлы ЭВМ. Функции системных файлов. Реестр, программа работы с реестром, программа для работы с файлами инициализации. Этапы загрузки ЭВМ. Способы и этапы перезагрузки ЭВМ.
Системный файл — компьютерный файл, необходимый для функционирования операционной системы. В зависимости от контекста может означать:
- .sys — расширение файла Microsoft Windows для файлов, используемых системой
- Системное хранилище в Mac OS
- Любой файл с указанным атрибутом «Системный».
- sys — корневой каталог в Sysfs
Системные файлы являются скрытыми по умолчанию. Для предотвращения случайного изменения или удаления системных файлов лучше всего оставить их скрытыми. Дополнительные сведения о просмотре системных файлов см. в разделе Отображение скрытых файлов.
Не рекомендуется изменять системные файлы, т. е. переименовывать, перемещать или удалять их, поскольку это может привести к неправильной работе компьютера. Если изменение системного файла сразу не отражается на работе компьютера, при следующем запуске ОС Windows или программы компьютер может работать неправильно.
Реестр (системный реестр) - это иерархическая база данных, содержащая записи, определяющие параметры и настройки операционных систем Microsoft Windows. Реестр в том виде, как он выглядит при просмотре редактором реестра, формируется из данных, источниками которых являются файлы реестра и информация об оборудовании, собранная в процессе загрузки. В описании файлов реестра на английском языке используется термин "Hive". В некоторых работах его переводят на русский как "Улей". Microsoft в своих документах переводит это как "Куст". Файлы реестра создаются в процессе установки операционной системы и хранятся в папке %SystemRoot%\system32\config (обычно C:\windows\system32\config). Для операционных систем Windows 2000/XP это файлы с именами
default
sam
security
software
system
.В процессе загрузки система получает монопольный доступ к данным файлам и, поэтому, стандартными средствами работы с файлами вы ничего с ними сделать не сможете (открыть для просмотра, скопировать, удалить, переименовать). Для работы с содержимым системного реестра используется специальное программное обеспечение - редакторы реестра (REGEDIT.EXE, REGEDT32.EXE), являющиеся стандартными компонентами операционной системы. Для запуска реестра используется "Пуск" "Выполнить" - regedit.exe
В Visual FoxPro для автоматической установки рабочей среды используются файлы инициализации FOXPRO.INI и CONFIG.FPW.
Ну, если бы Вы немного разбирались в теме вопроса, то можно было бы о чём поговорить!
Капитан Гугл в данном случае прав. Дело в том, что размер результирующего исполняемого файла даже для одной и же программы может быть разным в зависимости от параметров, котооые установлены.
Но конечно, можно оценить примерно размер в каких-то пределах. Но всё это можно проще экспериментальным путём. Сделайте компиляцию большого количества программ и усредните соответствие исходного и получаемого размера. Это и будет некоторым утешением Вашего любопытства!
Юрий-17 Оракул "Сделайте компиляцию большого количества программ" (10^6 - 10^15 . ) "и усредните соответствие исходного и получаемого размера. Это и будет некоторым утешением" того, что Вы ответили!
Юрий-17 Гений (76246) Ну, во-первых, проблема у Вас, а не у меня, иначе бы не задавали вопрос. Во-вторых я это как раз могу сделать, но с какой стати я должен это делать? Мне что больше делать нечего! В-третьих Вам я дал совет совершенно бесплатно, если не хотите не пользуйтесь - Ваши проблемы! В-четвёртых, судя по ранее опубликованным комментариям неясно, представляете себе ответ на это вопрос или нет, но гонора у Вас предостаточно! В-пятых исходя из личного опыта, я могу судить что, даже, если Вы примерно знаете как ответить - ответ будет неверным, хотя признавать ошибки Вы не захотите Ну и в-шестых - желаю Вам успеха!
Хорошо, ответ "проделать все те же действия, которые проделает компилятор, вручную", тебя устроит?
Комплиляция - сложный и нетривиальный процесс. Результирующий файл, в зависимости от настроек компилятора и своего содержимого, будет включать:
- системные заголовки определенного типа исполняемого файла (ручаюсь, ты даже не думал, что бывают разные) ;
- ресурсы, если такие были;
- определенные библиотечные функции (а может, программа будет расчитывать, что они будут в системных файлах) ;
- данные самой программы (например, в зависимости от битности целевой системы массив целых значений из 1000 элементов может занимать от 2000Б до 8000Б) ;
- код, размер которого также будет заметно различаться при разных настройках оптимизации на разных компиляторах (в некоторых случаях - в полтора-два раза, а то и больше) ;
- что-то еще, что не попадает под предыдущие пункты, но, скорее всего, я забыл добавить.
Ну так вот, на каком простом примере ты хочешь, чтобы тебе это показали?
Капитан Гугл Искусственный Интеллект (145912) Я знаю, что на этот вопрос нет прямого ответа - по крайней мере такого, который ты хотел бы увидеть. А есть мой первый ответ, и он правильный: откомпилировать и посмотреть.
Давно прошли те времена.. . Посмотри, сколько места займет текст "Hello, world!". Это когда-то выжимали байты. Помню, в восьмидесятые меня поразила "хвалилка" ребят, создавших Fox. (Не браузер, а DBF-ную СУБД) . Меньше, чем в два килобайта, они втиснули вполне разборчивый (несмотря на наличие только спикера) куплет песенки с бежавшим по экрану разноцветным текстом самой "хвалилки" да еще и все (три) лампочки на клаве в такт моргали. Это было круто. Тогда.
Используй компоновщик gold вместо gnu-ld, он собирает меньший по размеру исполняемый файл.
Каждая из приведенных фраз это, конечно, целая дискуссия, но у всех одна цель - уменьшить размер бинарного файла.
Объясните, пожалуйста, почему так важно иметь как можно меньший по размеру бинарный файл? Связано ли это со скоростью загрузки приложения, кэша инструкций процессора, или еще с чем-то?
Связано со скоростью загрузки. Несколько раз попадались .exe файлы по несколько гигабайт, так они грузились от 10-ти минут до получасу.
А вам самим не противно, когда вы наделали бинарник метров на 100? Я помню времена, когда на 1 дискету влезала ОС, среды разработки и еще место для игрушек оставалось. А сейчас хелловорлд будет весить раз в 10 больше.
Это лучше спросить у тех, кто так утверждает. Как правило, им не найдётся, что сказать. Но причины могут быть и адекватные, тогда человек сможет объясниться (это редкое явление).
@ixSci: Проблема может быть, например, с «борьбой» за кеш процессора. При компактном коде вероятность того, что часто используемые куски объектного кода окажутся в кеше, больше.
2 ответа 2
Для начала предлагаю отвлечься от слова "исполняемый" и рассмотреть просто файл. Что значит большой размер? Файл потребует больше места для хранения, он дольше будет копироваться или как-то иначе обрабатываться, когда речь идет об обработке его содержимого, а не просто имени или даты создания. В таких случаях часто прибегают к механизмам дополнительного сжатия информации, проще говоря, архивированию. Это уменьшит размер и время копирования, но для последующей обработки, вероятнее всего, придется выполнить распаковку, что может в итоге даже увеличить время обработки по сравнению с несжатым файлом.
Теперь, чем отличается исполняемый файл от обычного? Он так или иначе содержит код, набор инструкций, которые должен выполнить (обработать) процессор. Понятно, что размер программы зависит от предоставляемого функционала, и наращивание логики приведет к увеличению размера. В большинстве случаев это не является проблемой, так как диски становятся всё больше, память и процессоры быстрее, а архитектурные решения опираются на декомпозицию: разделение кода на модули/библиотеки и подгрузку кода по мере необходимости. Но в некоторых ситуациях, например, в микроконтроллерах ресурсы серьезно ограничены и там идет борьба за размер, и использование разных техник оптимизации.
Кстати, для исполняемых файлов тоже существуют архиваторы, один из них, это UPX.
Рустэм Галеев 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 пустые секции).
Мне надо чтобы этот файл упаковался вместе с моей программой в один файл.
Вы осознаете то, что h файлы подключаются на этапе препроцессора, а Вам похоже нужно на этапе исполнения? или вы хотите включить текстовый файл внутрь cpp на этапе препроцессора (компиляции)?
@ThreadShakur вам прямой путь в документацию почитать о файловом вводе выводе. P.S.: std::ifstream/std::ofstream
4 ответа 4
На основании Вашего комментария становится ясно, что нужно встроить текстовый файл непосредственно в исполняемый *.exe файл. Такого рода задачу можно решить разными способами, например:
Использовать файл ресурсов и компилятор ресурсов для соответствующей ОС (или IDE). Например, для Windows.
Преобразовать с помощью утилит типа xxd Ваш файл в массив данных и включить его непосредственно в код, например:
Какое решение будет для Вас оптимальным зависит от используемой ОС, IDE и необходимости в кросс-платформенности подхода.
1) Создаётся файл ресурсов.
2) В ресурсы добавляется новый файл (через контекстное меню) НЕИЗВЕСТНОГО ЕЩЁ КОМПИЛЯТОРУ типа, например BINARY. Если не уверены что добавилось, то заходите в .rc файл и правьте руками. Будет строка типа:
3) Во время работы программы обращаться стандартными средствами: Пример кода:
Мне кажется, что человек спрашивает по сути, как ему в проекте (как я понимаю, на Visual C++) обратиться к файлу, который лежит в папке с проектом. В этом случае - надо учесть, что текущим каталогом при запуске из IDE становится не папка, в которой лежит .sln -файл проекта, а в которой лежат исходники и .vcxproj (для Visual Studio). И именно в нее и надо укладывать этот 1.txt .
Если ошибся в трактовке вопроса - мои извинения, тогда смотрите ответ @Xambey.
Текущая папка для отлаживаемого проекта задается через Debugging - Working Directory (по умолчанию она установлена в $(ProjectDir), что попадает под ваш ответ).
Надо проверять отсутствие fail / bad битов. Проверка на eof приведет к зацикливанию, например, если файл вовсе не удалось открыть. Да и закрывать явно не обязательно, т.к. это сделает деструктор.
Да вы не поняли все, я знаю как файл считать.. про папку с проектом я имел ввииду папку с исходниками в проекте. то есть вот программа есть у нас 1.exe лежит в папке porga.. Мне надо файл читать не из папки proga а чтобы как бы этот файл упаковался вместе с моей программой в один файл
Читайте также: