Простой вопрос про DLL

[vg]

Подскажите, пожалуйста, для чего в .DEF файле в разделе EXPORTS умные люди в некоторых случаях используют ключевое слово PRIVATE при определении экспортируемых символов. Читаем MSDN...

"... The optional keyword PRIVATE prevents entryname from being placed in the import library generated by LINK. It has no effect on the export in the image also generated by LINK. ..."

Никаких других разъяснений и ссылок на бест практис не нашёл больше. Такое ощущение, что делают для того, чтобы "подстраховаться" на случай неявного связывания, для того, чтобы избежать конфликтов имён, учитывая что программер может неявно связывать несколько "однотипных" DLL, где в .LIB каждой DLL определены такие же символы...

Где всёж собака порылась?

Спасибо.

[vg]

Вопрос закрыт. Разобрался. Так и есть, как я предполагал.

[vg]

Вопросы продолжаются
С какой целью линкеру иногда указывают изменить базовый адрес загрузки DLL со значения по умолчанию 0x10000000 на, например, 0x1c000000?

Ред. Почему именно 0x1c000000? EXE может подключать явно несколько десятков DLL. Даже уже второй модуль не сможет быть спроецирован по этому базовому адресу.

Логичнее былоб для каждого модулю назначасть свой base address. Но ведь всё равно не угадаешь.... Это так, поскольку, в большом и динамичном проекте постоянно будут появляться новый функционал. И ты даже не знаешь, сколько будет DLL грузиться и в какой последовательности (эти DLL вообще будут писать другие тимы девелоперов возможно).

Короче, не понятно, блин.

[Earl Grey]

У тебя здорово дискуссия получается. Продолжай, пожалуйста

[vg]

У тебя здорово дискуссия получается. Продолжай, пожалуйста

Пожалуйста, если вам это интересно.

Пока есть только подозрение, что этот виртуальный адрес 0x1c000000 рекомендован производителем с учётом тех приложений, которые поставляются вместе с основным софтом производителя, для того, чтобы избежать "закрепления" страниц отображения в свопе файле "подкачки" модулей производителя (что может быть критичным для CAD/GIS приложений), если вдруг окажется, что прикладная (условно "моя") DLL грузится раньше одного из модулей производителя. Тогда по идее компоновщик должен будет модифицировать relocation section только для кода модулей поставщика. Со всеми вытекающими последствиями.

Второе подозрение - при явной загрузке прикладного модуля девелопера (условно, "моего") - про это вообще можно забыть. Поскольку копоновщика уже и след простыл. Пока не знаю точно.

[vg]

Разобрался... Там выше у меня были грубые промахи. Мне объяснили...

Тогда по идее компоновщик должен будет модифицировать relocation section только для кода модулей поставщика. Со всеми вытекающими последствиями.

Линкер создаёт relocation section, а модифицирует её в ран-тайме загрузчик. Это так ... чтобы терминология и ясность не страдали.

Второе подозрение - при явной загрузке прикладного модуля девелопера (условно, "моего") - про это вообще можно забыть. Поскольку копоновщика уже и след простыл. Пока не знаю точно.

Компоновщик здесь вообще не причём, поскольку он по определению не заполняет relocation section.
Но вот что я интересного узнал
Оказывается указатель на символ, экспортируемый dll, который получен при помощи LoadLibrary/GetProcAddress - это всего лишь указатель на запись в relocation section. Т.е. к реальному адресу функции не имеет никакого отношения! Т.е. в любом случае, что при явном (LoadLibrary/GetProcAddress), что при неявном ( __declspec(dllimport) ) связывании обращение к символам будет косвенным, через таблицы адресов импорта. Это очень прикольно, что указатель на импортируемую функцию так резко отличается просто от адреса (по тому как следует выполнять переход). Думаю, отличаетс даже от адреса функции, которая непосредственно в сегменте кода вызывающего процесса (когда в ран-тайме нет необходимости определять смещение базового адреса загрузки).