Как программа выполняется? Где Операционные системы играют роль?
Я думал, что первый объявит класс Levels и статический внутренний класс Items. Элементы могут ссылаться на Levels.Items и будут статичными.
Хотя второй будет объявлять простой внутренний класс, доступ к которому можно получить с помощью Levels.Items, как показано ниже:
Levels.Items hello = new Levels.Items();
РЕДАКТИРОВАТЬ: это совершенно неправильно, прочитайте комментарии и другие ответы .
8 ответов
For starters, a modern CPU has (at least) two modes, a mode in which it's running the core of the Operating System itself ("kernel mode") and a mode in which it's running programs ("user mode"). When in user mode, the CPU can't do a whole lot of things.
For instance, a mouse click is typically noticed in the kernel, not user mode. However, the OS dispatches the event to user mode and from there to the correct program. The other way around also requires cooperation: a program can't draw to the screen freely, but needs to go through the OS and kernel mode to draw on its part.
Similarly, the act of starting a program is typically a cooperation. The shell part of the OS is a user-mode program too. It gets your mouse click, and determines that it's a mouse click intended to start a process. The shell then tells the kernel-mode part of the OS to start a new process for that program.
When the kernel mode needs to start a new process, it first allocates memory for bookkeeping, and then proceeds to load the program. This involves retrieving the instructions from the binary, but also hooking up the program to the OS. This usually requires finding the entry point (classically int main(int argc, char** argv)) of the binary, and all points where the program wants to call the OS.
Different Operating Systems use different ways to hook up programs with the OS. As a result, the loading process differs, and the file formats for binaries can differ too. It's not absolute; the ELF format for binaries is used for a number of Operating Systems, and Microsoft uses its PE format on all its current Operating Systems. In both cases, the format does describe the precise format of the binary, so the OS can decide whether the program can be hooked up to the OS. For instance, if it's a Win32 binary, it will be in the PE format, therefore Linux won't load that, Windows 2000 will, as will Windows 7-64. A Win64 binary on the other hand is in PE format too, but Windows 2000 will reject it.
It will not run on other processors since 01010110011 means something on x86 and something else on ARM. x86-64 happens to be backwards compatible with x86 so it can run x86 programs.
The binary is in a specific format that your OS understands (windows = PE, mac/linux = ELF)
With any normal binary, your OS loads it into memory and populates a number of fields with certain values. These "certain values" are addresses to api functions that exist in shared libraries (dll, so) such as kernel32 or libc. Адреса API необходимы, потому что сам двоичный файл не знает, как получить доступ к жестким дискам, сетевым картам, геймпадам и т. Д. Программа использует эти адреса для вызова определенных функций, которые существуют в вашей ОС или в других библиотеках.
По сути, В двоичном файле отсутствуют некоторые важные части, которые должны быть заполнены ОС, чтобы все работало. Если ОС заполняет неправильные части, двоичный файл не будет работать, поскольку они не могут взаимодействовать друг с другом. Вот что произойдет, если вы замените user32.dll другим файлом или попытаетесь запустить исполняемый файл linux на mac osx.
Так откуда же libc узнать, как открыть файл?
libc использует системные вызовы, которые низкоуровневый доступ к основным функциям ОС. Это' это похоже на вызов функции, за исключением того, что вы делаете это, заполняя определенные регистры ЦП, а затем инициируя прерывание (специальная инструкция ЦП)
Так откуда же ОС тогда узнает, как открывать файлы?
Это одна из вещей, ОС делает. Но как он знает, как разговаривать с жестким диском? Я не знаю точно, как это работает, но я полагаю, что ОС делает это, записывая / считывая определенные области памяти, которые, как оказалось, сопоставлены функциям BIOS.
Так откуда BIOS знает, как разговаривать с жестким диском?
Я тоже не знаю, я никогда не занимался программированием на этом уровне. Я предполагаю, что BIOS жестко подключен к разъемам жесткого диска и может отправлять правильную последовательность 1 и 0, чтобы общаться с жестким диском «SATA». Вероятно, он может сказать только простые вещи, такие как «прочтите этот сектор»
Так откуда жёсткий диск знает, как читать сектор?
Я на самом деле этого совсем не знаю, поэтому я позволю кому-нибудь из тех, кто занимается аппаратным обеспечением продолжить.
Два способа:
В первую очередь ответ - «системные вызовы». Каждый раз, когда вы вызываете функцию, которая должна выполнять какие-либо операции ввода-вывода, взаимодействовать с устройствами, выделять память, процессы разветвления и т. Д., Эта функция должна выполнять «системный вызов». Хотя инструкция системного вызова сама является частью X86, доступные системные вызовы и параметры для них зависят от ОС.
Даже если ваша программа не выполняет НИКАКИХ системных вызовов (в чем я не уверен возможно и, конечно, не очень полезно) форматы, которые обертывают машинный код, различны для разных ОС. Таким образом, форматы файлов exe (PE) и исполняемого файла Linux (обычно ELF) различаются, поэтому исполняемый файл не может выполняться в Linux.
EDIT: это детали низкого уровня.
ОС вступает в игру, когда вы пытаетесь получить доступ к «службе», которую она абстрагирует для вас на аппаратном уровне, например, открываете файл внутри «базы данных», называемой файловой системой, генерируете случайную номер (каждая современная ОС имеет эту функцию).
Например, в GNU / Linux вам нужно заполнить регистры и вызвать int 80h для доступа к «службе» (на самом деле называемой «syscall»).
Ваша программа не будет работать в другой ОС также потому, что существуют разные форматы файлов для исполняемых файлов, например, Win имеет COFF / PE, Linux имеет формат файла ELF (как и любой другой формат файла, он также содержит «метаданные», например HTML (или SGML)).
ОС предоставляет (а) среду, в которой работает ваш машинный код, и (б) стандартные службы. Без (a) ваш код никогда не будет выполнен, а без (b) вам придется реализовать абсолютно все самостоятельно и напрямую воздействовать на оборудование.
Также я хочу добавить , что ОС обрабатывает запуск программы. Он подготавливает пространство процесса и инициализирует его, чтобы программа могла начаться, загружает программные инструкции и передает управление программе.
The OS provides the tools and API for access to certain features and the hardware.
For example to create a window on Microsoft Windows, you need the OS's DLL to create the window.
Unless you wish to write the API yourself, you'll use the API that the OS provides. That's where the OS come into play.
Машинные инструкции, сгенерированные языком высокого уровня, будут подходить для соглашений о вызовах библиотек, обеспечивающих те вызовы, которые вы делаете, включая любые системные вызовы (хотя они обычно заключены в библиотеку пользовательского пространства где-то , поэтому подробные сведения о том, как выполнить системный вызов, могут не потребоваться).
Кроме того, это будет подходить для архитектуры целевого набора команд, за некоторыми исключениями (необходимо соблюдать осторожность, например, относительно предположений относительно размеров указателя, примитивные типы, макеты структур, реализации классов в C ++ и т. д.).
Формат файла будет определять необходимые перехватчики / общедоступные функции и данные, чтобы операционная система могла выполнять ваш код как процесс и запускать процесс для требуемое состояние. Если ты' Если вы знакомы с разработкой C / C ++ под Windows, концепция подсистемы диктует уровень начальной загрузки, предоставляемые ресурсы и подпись точки входа (обычно main (int, char **) в большинстве систем).
Есть несколько хороших примеров того, как выбор языка высокого уровня, архитектуры набора команд и формата исполняемого файла может повлиять на возможность запуска двоичного файла в любой данной системе:
Языки ассемблера должны кодировать для определенного ISA. Они используют инструкции, относящиеся к семейству типов ЦП. Эти инструкции могут работать на процессорах других семейств , если эти процессоры поддерживают данный набор инструкций. Например, код x86 будет работать в определенной степени в операционной системе amd64 и определенно будет работать на процессоре amd64, работающем под управлением операционной системы x86.
C абстрагирует большую часть специфики ISA. Несколько очевидных исключений включают размер указателя и порядок байтов. Различные хорошо известные интерфейсы будут предоставляться на ожидаемом уровне через libc, такие как printf , main , fopen и другие. К ним относятся ожидаемые состояния регистров и стека для выполнения этих вызовов, что позволяет коду C работать в различных операционных системах и архитектурах без изменений. Могут быть предоставлены другие интерфейсы либо напрямую, либо путем обертывания специфичной для платформы интерфейса в ожидаемый интерфейс для увеличения переносимости кода C.
Python и другие подобные «виртуализированные» языки работают на еще одном уровне абстракции, и опять же с несколько исключений, например функции, которых нет на определенных платформах, или различия в кодировке символов, могут работать без изменений во многих системах.