jcmvbkbc

Функция scanf крушит программу

Скорее всего ты ошибаешься, и "программу крушит" вот это:

push numderA
call [printf]

printf ожидает первым параметром форматную строку.

Как в ситуации ниже, поступает компилятор?

Компилятор вставляет вызов string::operator <. Если это std::string, то оператор выполняет лексикографическое сравнение, т.е. сравнивает символы обеих строк по очереди до первой различающейся пары, меньшей будет та строка, которой принадлежит символ с меньшим кодом.
В примере "100.05" < "100.03" результат будет false потому что 5 > 3.

Могут ли быть какие-то проблемы

Для такого сравнения строковые представления чисел должны начинаться разрядами одного веса. Т.е. можно сравнивать "100.05" и "099.1" (первая цифра и слева и справа -- сотни), но нельзя сравнивать "100.05" и "99.1" (слева первая цифра -- сотни, справа -- десятки).

Почему не получается деление div на ассемблере в С++?

char b1 = 3, b2, b3 = 1 , res2; //1 байт el, bl, ah    ]]  cbw -> short
  short w1= 1000, w2 = 500, w3 = 2;
//(w1 - w2) * w3 / b1

div bl

Потому что (1000 - 500) * 2 / 3 = 333, а это не влезает в один байт результата, а значит ты получаешь исключение. См.

во-первых компилятор даёт предупреждение, … , но ошибки не производит. Я спокойно линкую файл недо-драйвера с основным ядром, (конечный результат - .efi),

Дело в том, что у EFI-приложений нет динамической линковки, а неопределённый символ после копирования из .so в .efi просто ссылается в никуда. Если вывести неопределённые символы для bootx64.so, то inportb будет среди них:

objdump -t bootx64.so | grep UND
0000000000000000         *UND*  0000000000000000 inportb

В qemu результат вызова этой функции выглядит так:

Trace 0: 0x7fb15d338e80 [0000000000000000/000000007e6e22de/0x40c2b0]
----------------                      
IN: 
0x7e6e2081:  bf 60 00 00 00           movl     $0x60, %edi
0x7e6e2086:  b8 00 00 00 00           movl     $0, %eax
0x7e6e208b:  e8 90 57 00 00           callq    0x7e6e7820

Trace 0: 0x7fb15d3390c0 [0000000000000000/000000007e6e2081/0x40c2b0]
----------------                      
IN: 
0x7e6e7820:  af                       scasl    (%rdi), %eax
0x7e6e7821:  af                       scasl    (%rdi), %eax
0x7e6e7822:  af                       scasl    (%rdi), %eax
0x7e6e7823:  af                       scasl    (%rdi), %eax
0x7e6e7824:  af                       scasl    (%rdi), %eax
0x7e6e7825:  af                       scasl    (%rdi), %eax
0x7e6e7826:  af                       scasl    (%rdi), %eax
0x7e6e7827:  af                       scasl    (%rdi), %eax
0x7e6e7828:  af                       scasl    (%rdi), %eax
0x7e6e7829:  af                       scasl    (%rdi), %eax
0x7e6e782a:  af                       scasl    (%rdi), %eax
0x7e6e782b:  af                       scasl    (%rdi), %eax
…

С другой стороны, если предоставить такую функцию:

unsigned char
inportb(unsigned short port)
{
        unsigned char v;
        asm volatile ("in {%1|%b0}, {%b0|%1}\n" : "=a"(v) : "d"(port));
        return v;
}

то она прекрасно вызывается и возвращает значение.

Можно добавить опцию -zdefs в команду линковки чтобы получать ошибку линковки при наличии ссылок на неопределённые символы.

Чтобы посмотреть, какой именно код выполняется, я запускаю qemu с монитором в консоли (дополнительным ключом -monitor stdio). Я нажимаю ESC когда в QEMU запускается tianocore и выбираю Boot Manager -> EFI Internal Shell, а там пишу fs0:efi\boot\bootx64.efi, после этого в мониторной консоли включаю логгирование (командами logfile log, log in_asm,exec), после чего нажимаю enter в консоли EFI. После этого можно смотреть в файл log и искать в нём знакомые байты из objdump.

По сути pic должен генерировать прерывания 18 раз в секунду

По сути не PIC, а таймер. А в твоём коде не видно ни как ты инициализировал таймер, ни что таймерное прерывание разрешено в PIC.

Второй вариант инициализации не работает

Ну да, не работает. Таким образом можно инициализировать только первый элемент union. Есть ещё вот такой вариант инициализации, начиная с C++20.

GetWindowText() записывает в массив char'ов через символ

GetWindowText(obj.hEDIT,(LPWSTR)&msg, sizeof(msg));

Если это массив char, то надо использовать GetWindowTextA и не приводить указатель на массив к типу LPWSTR.

Последний аргумент GetWindowText, кстати, это не размер буфера, а количество символов в нём, так что туда надо (было бы) передавать не sizeof(msg) а sizeof(msg)/sizeof(*LPWSTR).

У меня есть два make-файла, первый вызывает второй.
Мне хотелось бы получить некоторые данные из второго make-файла.

Не предусмотрено такое логикой make, разве что через eval это можно накостылить. Обычно, когда нужна тесная связь между разными Makefile, один из них подключают в другой (и получают большой логический Makefile поделённый на несколько файлов).

Например, в них нет файла kernel/sched.c

например git log -- kernel/sched.c легко объяснит, что с этм файлом случилось.

насколько критично, что я буду изучать ядро по данной книге, т.е. по устаревшей версии ядра?

совсем не критично, потому что то, что написано в книге имело место в прошлом, а с помощью git можно проследить, что с тех пор изменилось.

"11 22 22 33 33 33"
Должно вывестись:
"11 occurs 1 times
22 occurs 2 times
33 occurs 3 times"
но "33 occurs 3 times" не выводится в консоль. В чем может быть причина?

if (val == currVal) ++cnt;
            else 
            {
                std::cout << currVal << " occurs " << cnt << " times " << std::endl;

В том, что после 3го "33" по-прежнему выполняется ветка if (val == currVal) ++cnt;.

Перемещение по стрелками и буквам ( j k ) вниз и вверх не работает.

в любом файле или в одном конкретном? Может быть этот файл состоит из одной единственной строки? Что о нём говорит wc -l <имя файла>?