В эпоху современной разработки программного обеспечения и программирования термин «время выполнения» может означать разные вещи в зависимости от контекста и обсуждаемого языка. Я здесь, чтобы прояснить эти различия, сосредоточив внимание на том, как работает среда выполнения на C по сравнению с более современными языками, такими как Java или Python. Я намерен сделать эту статью ориентированной на начинающих программистов, поэтому не буду углубляться в сложные концепции.

Что такое среда выполнения?

По своей сути среда выполнения — это сама программа, которая читает и выполняет код, написанный разработчиком. Но это сбивает с толку, когда некоторые разработчики используют среду выполнения с языком C.

Современные языковые среды выполнения

В таких языках, как Java или Python, среда выполнения — это сама программа, которая читает ваш файл myfile.js, поэтому вы запускаете такие программы nodejs, как: узел myfile.js и механизм v8 (это механизм JavaScript, он анализирует и выполняет JavaScript code.) управляет всем, независимо от того, создаете ли вы новый файл, запускаете дочерний процесс и т. д., и, самое главное, вы не можете делать ничего такого, чего не позволяет v8.
Но когда вы запускаете программу c, вы не делаете c myfile.c, вам просто нужно скомпилировать ее один раз, и теперь вам больше не нужен gcc, просто запустите ее напрямую.

C «Среда выполнения»

В C нет отдельной программы, работающей вместе с вашим кодом так же, как в Java или Python. Вместо этого то, что часто называют «средой выполнения» C, на самом деле представляет собой набор статически вставленного кода и инструкций, добавляемых во время компиляции. Это минимальный набор инструкций, включенный в окончательный двоичный файл для выполнения определенных необходимых задач на уровне ЦП/ОС. Он обрабатывает создание и удаление кадров стека для вызовов функций (используя такие инструкции, как PUSH, POP, CALL, RET в ассемблере). Даже это можно переопределить, предоставив собственную функцию __start с использованием встроенного ассемблера, предоставляя разработчикам полный контроль над точкой входа и инициализацией программы.

void __start() {
// Custom entry point, no standard library initialization
// You have no access to argc and argv here unless you access them manually from registers
// you can create you own custom stack setup, initialization and etc here.

// Exit directly using a syscall
asm("mov $60, %rax; mov $0, %rdi; syscall"); // exit(0) syscall
}

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

Сила и ответственность C

В C вы можете вызывать системные вызовы напрямую, используя встроенную ассемблерную сборку, для взаимодействия с ядром способами, которые обычно не разрешены ОС, именно так создаются вредоносные программы. Встроенная ассемблерная программа позволяет разработчикам писать инструкции на языке ассемблера в коде C. Это часто используется для кода, критичного к производительности, или для доступа к определенным аппаратным функциям.

Встроенная сборка в C

• Встроенная ассемблерная программа позволяет разработчикам писать инструкции на языке ассемблера в коде C. Это часто используется для кода, критичного к производительности, или для доступа к определенным аппаратным функциям.
• Он обеспечивает возможность прямого выполнения инструкций ЦП.

Прямое взаимодействие с ядром

• используя встроенный ассемблер, программист может напрямую вызывать системные вызовы, минуя библиотеки более высокого уровня.
• Например, мы можем использовать встроенную ассемблерную сборку, чтобы настроить регистры с соответствующими параметрами для системного вызова, а затем запустить его.
• Поскольку встроенная сборка позволяет осуществлять низкоуровневый контроль над системными ресурсами, ее можно использовать для обхода механизмов безопасности или непосредственного управления ядром. Именно так вредоносное ПО может выполнять несанкционированные действия, такие как доступ к защищенной памяти, перехват системных вызовов или манипулирование процессами и их памятью.
• Вредоносное ПО может использовать уязвимости в ОС или использовать эти низкоуровневые взаимодействия для выполнения таких задач, как кейлоггинг, повышение привилегий или скрытые операции.

В Linux C есть ФЛАГ, который позволяет напрямую записывать данные файла на устройство хранения, минуя некоторые механизмы кэширования ядра, называется флагом O_DIRECT, который используется в сочетании с системными вызовами открытия и записи. Этот флаг гарантирует, что данные не буферизуются в оперативной памяти и не управляются ядром в пространстве ядра. Данные напрямую записываются на жесткий диск, JVM не позволит вам этого сделать, и это всего лишь один простой пример.
вот простой пример:

asm volatile (
"syscall"
: "=a" (written)
: "0" (1),
"D" (fd),
"S" (buffer),
"d" (BLOCK_SIZE)
: "rcx", "r11", "memory"
);

*Примечание: * (записано) — переменная, созданная внутри main(), (1) — номер системного вызова для записи, (fd) — куда будет записан файл, т.е. int fs = open("path .log",O_WRONLY; (BLOCK_SIZE) — еще одно имя переменной. Оно более сложное.

Эволюция сред выполнения

Важно понимать, что концепция среды выполнения развивалась с годами. «Среда выполнения» C 70-х годов сильно отличается от надежных сред выполнения, которые мы видим в языках 2000-х годов. Эта эволюция может привести к путанице при обсуждении среды выполнения, особенно между разработчиками, знакомыми с разными эпохами программирования.

Заключение

Я думаю, что люди сейчас сравнивают время выполнения 1970-х годов со временем выполнения 2000-х, из-за чего новых разработчиков путают со старыми разработчиками.
Решение конкретной проблемы является основной задачей любого языка программирования. Вы не хотите писать целую среду для создания API на C, у нас есть nodejs, и он хорош в этом, и вам не нужно писать чистый код на JavaScript, потому что мы у меня уже есть C, и он великолепен в этом. Зачем изобретать велосипед, давайте воспользуемся ими и создадим потрясающую машину, , если только вы не хотите покататься на ней по Марсу.