jcmvbkbc

Если взять за основу эту схему, то становится понятно, как код процесса может узнать адреса текста, инициализированных данных, неинициализированных данных

Если мы говорим про обычные (не PIE) исполняемые ELF-файлы, то они слинкованы под конкретный адрес куда они будут загружены, и все адреса внутри одного исполняемого файла посчитаны заранее. Поэтому загрузка адреса функции или пременной в секции данных -- это просто загрузка константы в регистр.

и кучи

С кучей всё по-другому, потому что куча и объекты в ней полностью динамические. Выделение памяти для кучи -- это всегда системный вызов, который возвращает адрес выделенной памяти (и sbrk, и mmap).

не ясно, как становится известен адрес стека и аргументов командной строки

они инициализируются ядром ОС, согласно ABI, см. например, ABI x86_64, раздел 3.4.1.

Как перевести этот код с C++?

И, главное, зачем? И чем для этой цели не подошёл компилятор С++?

mov ebx, [ebp - 8]

Нифига не mov, должно быть lea ebx, [ebp - 8]

lea edx, [ebx + ecx + 4] ; add FirstThunk RVA to base. Offset &function is 4

Нифига +4 не нужно. Смещение &function == 0.

lea edx, [edx + 20] ;size of IMAGE_THUNK_DATA

Нифига не +20, размер этой структуры -- 4.

можно ли ее как-то улучшить

Зависит от того, что считать улучшением.
По размеру кода -- вряд ли можно улучшить существенно.
По скорости -- можно, если загружать данные из памяти выравненными словами и раскрутить цикл.
По простоте -- можно существенно улучшить, переписав её на С или вообще воспользовавшись готовой реализацией.

при компиляции флаг из реестра не удаляется. В чем может быть проблема?

В том, что ты засунул бинарный код в параметр функции, в котором должна быть строка с именем программы для запуска и её параметрами. Непонятно, почему ты ожидаешь, что WinExec бросится выполнять машинный код в этой строке. WinExec имеет код возврата, который недвусмысленно тебе сказал бы в чём ошибка (путь или файл для запуска не найдены), если бы ты его проверил.
И, кстати, байт с кодом 0 по смещению 0x246 -- это тоже часть шелл-кода, терминатор командной строки.

Байты из зеленой области, как я понял, это информация линкера golink. Так ли это?

Это заголовок файла формата PE. Да, его туда записал линкер. Нет, это не информация линкера, это информация в основном для загрузчика ОС, а так же для дизассемблера и прочих binutils.

Я смотрю сюда, и сдаётся мне, что начало инициализации sockaddr_in в твоём коде должна выглядеть так:

mov byte [sockaddr_in + 0], AF_INET ; sin_family
mov byte [sockaddr_in + 2], 0 ; sin_port[0] это старший байт sin_port
mov byte [sockaddr_in + 3], 80 ; sin_port[1] а это младший

Т.е. перепутана endianness sin_family и sin_port. sin_addr вроде нормально выглядит.

Фактически, по адресу 0x0060 лежит какой-то мусор, который никак не относится к тому, что я туда хотел положить.

Откуда взялся адрес 0x0060 и как вы поняли что там лежит?

TL;DR: код копирующий данные из FLASH в SRAM и обнуляющий .bss не линкуется по умолчанию. gcc вставляет ссылку на неопределённые символы __do_copy_data и __do_clear_bss в каждую единицу трансляции, в которой определяются объекты в секции .data и .bss соответственно. В написанных руками ассемблерных файлах их можно упомянуть явно.

Код может выглядеть как-то так:

void OutFloat(double v);

sub sp,16
mov bp,sp
fstp qword ptr [bp + 8]
call OutFloat
add sp,16

Т.е. можно выгружать значение из сопроцессора прямо в то место, где будет исходящий параметр для вызова функции.
Ошибка возникает из-за того, что нет команд mov пересылающих значение из памяти в память.

Правильно ли я понимаю

Правильно.

.file "main.c"
Зачем в коде название файла с исходным кодом

Для генерации отладочной информации в формате DWARF.

.ident "GCC: (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0"
...и версия моей убунты?

Это не версия твоей убунты, это строка идентификации компилятора, в которой оказалось имя твоей ОС.

Попадают ли они в исполняемый файл при окончательно компиляции и зачем используются?

Имена файлов попадают в таблицу символов как символы типа FILE и в секцию отладочной информации:

$ readelf -a hello | grep FILE
    28: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    37: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS hello.c
    38: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS crtstuff.c
    41: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS

Если отладочная информация включает в себя номера строк, то они тоже будут ссылаться на имя файла, ассоциируя диапазон адресов с номерм строки в конкретном исходном файле.

Идентификационная строка компилятора попадает в секцию .comment объектного файла, а оттуда -- в исполняемый файл:

$ objdump -s -j .comment hello

hello:     file format elf64-x86-64

Contents of section .comment:
 0000 4743433a 20284465 6269616e 20362e33  GCC: (Debian 6.3
 0010 2e302d31 382b6465 62397531 2920362e  .0-18+deb9u1) 6.
 0020 332e3020 32303137 30353136 00        3.0 20170516.

Всё это можно от исполняемого файла отрезать командой strip, objcopy или соответствующим скриптом линковщика.

Есть ли подобные статьи для 64-бит архитектуры?

Зачем? В этой статье почти нет процессорной специфики -- там описаны потроха С-рантайма, библиотеки С и динамического линковщика. Любая программа на С для любой архитектуры при запуске проходит через те же стадии.

Следующий сегмент располагается через 10h от предыдущего.

Следующий параграф. Сегментный регистр может указывать на любой параграф.

Не понимаю, почему пронумеровано от 0 до F

По одному адресу на каждый байт параграфа -- от 0 до F -- как раз 16 разных адресов.

Чтобы она запускалась -- её нужно скомпилировать, у тебя пока проблема с этим.

push ax dx
...
pop dx ax

tasm так не умеет, вроде. Если хочешь положить несколько регистров на стек -- пиши push для каждого регистра по отдельности.

Почему у меня при отладке (картинка 1), и при чужой отладке (картинка 2) в сегменте, внизу, где четыре строки es, значения совершенно отличаются, хотя это отладка одной и той же программы?

Мария, потому что память заполнена по большому счёту мусором. es в твоей программе не инициализирован, непонятно зачем ты на него смотришь. Надо смотреть на ds. В твоём отладчике Max находится по адресу 57ef:000a

;1 вариант
mov ah,02h
int 1Ah
inc cl
mov ah,06h
int 1Ah;

Мы получаем текущее время, прибавляем к минутам единицу и настраиваем будильник (случаи, когда 59 минут можно не рассматривать)

Время из int 1Ah возвращается в BCD. Чтобы увеличить счётчик минут на 1 inc cl недостаточно, нужно mov al, cl ; inc al ; daa ; mov cl, al.

как только ноты заканчиваются, DOS перестает на что либо реагировать

а зачем ты вызываешь void когда ноты заканчиваются?