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

Фон

я прочел Рекомендации Dynamic-Link Library и понял, что я могу и не могу сделать в 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.