none7

Ассемблер это тоже не более чем формализированный текстовый файл, компиляторы оперируют машинными кодами, которые процессор воспринимает как конкретную инструкцию к действию. Для процессора нет ни функций, ни переменных лишь память в стиле JS-TypedArray и последовательности инструкций вроде load, store, add, sub, compare, goto to ptr if(compare is signed_less), в той же памяти в виде бинарных чисел.
Именно Ваш пример любой оптимизирующий компилятор просто сотрёт. То есть просто запишет инструкцию return попутно ругнувшись на unused variable, а может вообще стереть всю функцию и её вызовы, ведь это никак не повлияет на результат.
Хотя конечно зная один из Ассемблеров выбранной процессорной архитектуры(а их как известно немало) можно без особого труда написать примитивный, не оптимизирующий компилятор, который будет передавать сгенерированный Ассемблерный файл в транслятор Ассемблера. Который просто транслирует Ассемблерные инструкции в соответствующие бинарные, машинные инструкции.
Вообще если хотите сделать свой язык программирования, то советую смотреть в сторону llvm. Это позволит Вам не заморачиваться с поддержкой бесчисленных процессорных архитектур и оптимизации машинных кодов под них. На хабре даже есть статья как сделать свой llvm компилятор.

Пароли в принципе нельзя хранить, ни на диске, ни в памяти, ни к чему хорошему это не приводит. Даже мастер-пароли могут украсть во время их ввода и обработки. Но справедливости ради сервера хранят секретные ключи, чтобы мы могли к ним подключится с шифрованием. Они всего лишь уповают на разграничение привилегий операционной системой. Но если другая программа запущена с привилегиями Вашем программы или более высокими или злоумышленник имеет физический доступ к Вашему железу, то они могут прочесть все ваши секреты. Но на Windows или Android это разграничение бесполезно, на первой куча мусора исполняется с максимальными привилегиями, а на второй дыры не закрывают вообще и только самоё свежее железо в состоянии хранить секреты.
Безопасность это комплекс мер и простым действиями на уровне программы её не обеспечить.

Процессоры x86-64 могут адресовать 256Тб виртуальной памяти. Будет ли оптимальным полный перебор всех блоков по 4к? Будет ли вообще приемлемо хранить информацию о каждом 4к блоке каждого процесса, при таком объёме виртуально памяти у каждого? Очевидно, что таблица свободных блоков проиндексированная по размеру необходима. Windows кстати во избежание разрастания этих таблиц выделяет виртуальную память блоками по 64к.
Обычно выделением виртуальной памяти под переменные занимается куча(heap), а приложению отдаёт память сколько попросят, независимо от размера блока виртуальной памяти. Естественно, что первое выделение не меньше одной страницы.

С машинной точки зрения нет особой разницы между bool,char и int, просто первые 2 в памяти обычно занимают меньше места. Также операции -x и x^255 выполняются одинаково быстро, то есть тоже никакой разницы.

#include <iostream>
#include <string>

int main() {
    std::string s1, s2;
    std::getline(std::cin, s1);
    std::cin >> s2;
}

В чистом C нет динамических строк, есть только числовые переменные, указатели(ссылки), структуры и массивы фиксированного размера. Самым близким к JS коду, но и самым кривым будет такой код:

char line[8];
*line = 0;
for(strcat(line, "#"); strlen(line) < 7; strcat(line, "#"))
    puts(line);

Проприетарное ПО в принципе не может распространятся вместе с GPL кодом. Даже если если он идёт в отдельном исполняемом файле. С LGPL ещё можно динамически линковаться не изменяя, а полностью свободные в этом плане только BSD, MIT, Apache.

Вот говорил же злые хакеры всё уже сделали за Вас. Утилита PE Tools, выбрать процесс, выбрать исполняемый файл, ПКМ, PE editor -> read only, FLC(File Location Calculator), RVA, VA, file offset, считает, что угодно из чего угодно. Делать подсчёт в патчере смысла нет, если это не тот самый исполняемый файл, что и у Вас, то Вы его своим RVA to FO попросту сломаете. Просто запишите хеш файла и смещение в файле в исходник патчера. Кстати нагуглить код функции было проще простого rva to file offset

Таблицу импорта пофиксить трудно. Нужно тщательно изучить формат PE, разобрать EXE-шник на части, добавить новую секцию перед секцией ресурсов, в которой сформировать новую таблицу импорта, оставив старые "Thunk RVA". Затем собрать заново пересчитав расположение каждой секции на диске. Но всё уже написано за Вас злобными вирмейкерами :), а Вы похоже даже не пытались найти такие утилиты. подсказываю Google: add dll to import

Вся эта модель не более чем условность, нужно её рассматривать, как иерархию структур данных, а вовсе не незыблемые и скрытые друг от друга уровни. В некоторых случаях в направлении отправки пакета может учитываться даже прикладной уровень, а HTTP разбираться непосредственно из Ethernet-кадров. HTTP ничто не мешает содержать Ethernet кадры. NAT определяющий направление отправки по номеру порта TCP и UDP вообще уже стал обыденностью. Прикладных протоколов содержащих IP-адреса и порты, вообще не должно быть в OSI, так как не позволяет абстрагироваться, но их полно. И это вышло боком при появлении IPv6, а с другими протоколами сетевого уровня они вообще несовместимы и на это закрыли глаза. И весь этот бардак нынче зовётся сетевым стеком.
IP конечно содержит механизм фрагментации, но по причине неудачного проектирования используется редко и не для TCP. TCP изначально создан для фрагментации бесконечных потоков данных с проверкой факта доставки, поэтому влезает на сетевой уровень, чтобы знать MTU, а получив некоторые ICMP пакеты даже разрывать соединение(no route, unreachable). Удалённому узлу, TCP тоже сообщает свой MTU.

Если именно а,b,c, и не экономить каждый байт, то

cmp ax, 'a'
setb cl
cmp ax, 'c'
seta ch
or ch, cl
jne default
call [ax + jump_table - 'a']
default:
ret
jump_table dd getHelp, openTextEditor, reboot