wisgest

В реестре помянете дефолтную кодировку для консоли
Start->Run->regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
сменить кодировку в OEMCP с 866 на 1251

После чего потребуется перезапуск.

Никаких по сути. Вы должны подтверждать владение доменом с помощью различных заголовков и настроек сервера, что гугл по сути проверяет. Если данные заголовков и сервера расходятся то это и будет спам.

function Vix_GetProperties(
  handle: VixHandle;
  firstPropertyID: VixPropertyID
): VixError; cdecl varargs; external 'vix.dll';

После cdecl добавляем varargs. Это позволяет в удаленную библиотеку , указать компилятору что можем передавать аргументы списком.

Всем спасибо большое!

Стандартный планировщик + notepad открывающий соответствующий текстовик.

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

Другим паттернам применение вижу редко, только если под какую-то замороченную бизнес-логику. Хотя кого я обманываю, на среднем сайте обычно происходит только один паттерн - доширак из костылей. Ну и стоит сказать, что SPA-фреймворки имеют свойство навязывать свои подходы к решению задач, но это отдельная тема.

Важно понимать, что паттерны проектирования - это просто хорошие идеи по поводу того, как организовать большой объем кода в той или иной ситуации. Это не "изучи тайное знание, запомни, и делай так всегда", не "используй паттерны, потому что великие их используют", это скорее "если не уверен как организовать код, возьми готовую идею, она вроде работает". Если вы будете просто решать задачи, то через N лет практики вы сами их все "изобретете", только не будете знать, что у них есть названия. Эффективно будет организовать себе заметку о том, какие из этих идей для чего примерно применяют, а потом, в процессе работы, в нее подглядывать, если встал вопрос "как организовать этот код".

А если у другой стороны.

вдруг понимает

Но понимание, это не установка факта. Поскольку соблюдение лицензионного соглашения это чисто бухгалтерский учёт, то если в должностной инструкции не сказано "подтверждать соблюдение лицензионного соглашения" — не ходите в бухгалтерию и не проверяйте проводки.