Михаил степанович

Вопрос, на самом деле, заключается не в выборе межу LoadLibrary и #include, а в выборе между явным и неявным связыванием.

При неявном связывании компоновщик добавляет в PE-секцию импорта дополнительный блок импорта конкретно указанной библиотеки. Этот блок обрабатывается загрузчиком PE в момент подготовки к запуску процесса. Эта информация тебе уже должна быть знакома. К моменту передачи управления в точку входа процесса все неявно связанные библиотеки уже загружены и готовы к работе. Код процесса не нуждается в явном управлении загрузкой таких библиотек.

Явное связывание выполняется полностью кодом процесса, для чего и применяется набор функций для работы с библиотеками. Явное связывание - это большая рутина. Но иногда без этой рутины никак.
Поиск динамических библиотек при работе LoadLibrary[?] осуществляется в соответствии с определенным порядком. При этом, путями для поиска динамических библиотек можно управлять в ручном режиме, добавляя новые или замещая имеющиеся пути поиска.

Директива препроцессора #include[?] лишь косвенно относится к вопросу. На самом деле к вопросу относится директива #pragma comment( lib )[?].
Прагма работает только для cl - компилятора от Microsoft. Подключаемая таким образом статическая библиотека должна находиться в перечисленных Library Path, в настройках сборки проекта. Эта прагма является альтернативой прямого указания статической библиотеки в настройках сборки проекта.
Эту директиву любят использовать в сторонних заголовках, код для которых поставляется только в бинарном виде, в статических или динамических библиотеках. Вместе с динамической библиотекой такого решения поставляется и библиотека статическая, в которой находятся инструкции для неявного связывания с динамической библиотекой. Результатом работы #pragma comment( lib ) с такой статической библиотекой будет неявное связывание твоего кода с указанной динамической библиотекой.

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

Насколько я понимаю.
В include описывается библиотека, она может быть статической линковки, так и динамической.
В случае динамической линковки компилятор берет на себя все ваши вызовы loadLibrary, getProcAddress и прочее.

1) Откуда берёт библиотеки LoadLibrary ?

Папка приложения, Системные пути (PATH), knowdlls, полный путь до библиотеки

2) Проверяет ли LoadLibrary подпись библиотеки, если берёт её из системных путей ?
да,
https://msrc-blog.microsoft.com/2014/05/13/load-li...

3) Уменьшится ли размер исполняемого файла если использовать только LoadLibrary, без #include ? {Один не в счёт, надо же как-то брать HMODULE, WINAPI и прочие штуки ...}
Линкуйте библиотеки динамически, размер уменьшится, LoadLibrary ни как не влияет.

4) Что лучше использовать #include или LoadLibrary ?
5) Если библиотека существует и существует метод к которому я хочу обратится, может ли появиться ошибка ?

Понимание что они такие жирные
https://rsdn.org/article/cpp/crt.xml
Как загружается PE файл
https://rsdn.org/article/baseserv/peloader.xml

Ну да, используйте extern:

extern "C" {
        //сишный код
        int g(double);
        double h();
        ....
    };

Можно и очень легко. Просто выделите в вашем проекте Си код в отдельный файл с расширением .c

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

<?php if ( have_posts() ) : $ir = 0; while ( have_posts() ) : the_post();

  if ( $ir == 0 || $ir == 1 ) {
    get_template_part( 'template-parts/article-wide' );
  } else {
    get_template_part( 'template-parts/article' );
  }

$ir++; endwhile; endif; ?>

dialog, например.