Рекомендации Dynamic-Link Library - Как избежать тупика?

Question

Фон

Я прочитал рекомендации по использованию библиотеки Dynamic-Link и понял, что я могу и не могу делать в DllMain.

Теперь, скажем, у меня есть решение для Visual Studio 2013, содержащее много проектов. каждый проект генерирует различные двоичные файлы / файлы lib.

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

Теперь этот служебный проект может определять некоторые общие функции, которые вызывают, например, функцию LoadLibrary, которая основана на приведенной выше ссылке: никогда не выполняйте следующие задачи из DllMain

Вопрос

1. Как я могу реализовать универсальную функцию, которая "знает", что она не может использовать определенный API, потому что она вызывается в рамках области действия DllMain функционировать?

2. Можно ли получить доступ к блокировке загрузчика Windows и тем самым отключить определенные вызовы или изменить алгоритм функции, если она заблокирована?

пример

Проект Утилита

wstring GetUserName() // just an example!
{
   // do something including LoadLibrary call
}

Проект А

BOOL WINAPI DllMain(
  _In_  HINSTANCE hinstDLL,
  _In_  DWORD fdwReason,
  _In_  LPVOID lpvReserved
)
{
   // calls Utility - GetUserName()
}

Проект Б

int _tmain(int argc, _TCHAR* argv[])
{
   // calls Utility - GetUserName()
}

Пока вызов функции GetUserName() прекрасно в Project B, это запрещено в Project A

Я хочу сделать мю решение умным таким образом, чтобы избежать таких случаев.

Теоретический подход

wstring GetUserName() // just an example!
{
   if( IsLoaderLocked() )
      // do something excluding LoadLibrary call
   else
      // do something including LoadLibrary call
}

if( IsLoaderLocked() ) это не настоящий код, конечно. Просто пример условия, которое я хотел бы оценить перед вызовом "опасного" API.