В вышеуказанной инструкции есть одна необязательная настройка: указано Use of MFC: Use MFC in a shared DLL. Это и необязательно, а иногда и просто неверно - обычно требуется Use Standard Windows Libraries. Но это пустяки. А вот что не пустяк, способный крови попить просто немеряно: почему-то в Visual Studio 8.0 (в отличие от VS 6.0) сборка FLL-модуля в конфигурации WinDebug приводит к тому, что Visual FoxPro у пользователей не может распознать формат библиотеки и подключить ее. Пишет Invalid dll format. При этом на компах с установленной студией все работает прекрасно. Все шаманства с т.н. дистрибутивным пакетом C++ от мелкомягких никакого результата не дали. У пользователей без установленной визуальной студии работает только фллка собранная в конфигурации WinRel!!! (без отладочной информации). Собранные в среде Visual Studio 6.0 фллки работают в обоих конфигурациях. К сожалению, старые сборки дают на новых машинах с последними релизами WinXP необъяснимые глюки, поэтому у меня задача пересборки библиотеки стала на повестку дня.

Ну я внимательно посмотрел экранчики вордовского файла с инструкцией по сборке fll. Они почти ничем не отличаются от стандартной мелкософтовской инструкции. Как я упомянул, отличия всего два: в ваших экранчиках использование MFC указано как "in shared DLL", мелкомягкие на этот счет вообще помалкивают - а по умолчанию эта опция стоит в положении "use standard Windows libraries". Для примера, на чем это может отразиться. В моей fll-ке я использовал функцию _Dialog() API VFP, которая, в свою очередь, опирается на стандартный Messagebox. Так вот, если установить опцию "use in shared dll", то моментально возникают проблемы - целого ряда функций линкер не находит. Нужны особые телодвижения, чтобы он разрешил ссылки на них. Второе отличие даже не отличие, собственно. Мелкомягкие вообще помалкивают насчет особенности с WinDebug/WinRel. Точнее, они пишут, что собирать в конфигурации WinDebug надо при отладке, что-де можно вызывать как отладочный инструмент сам VFP (ага-ага, то-то кому-то удовольствие несказанное разбираться в ассемблерных кодах, не смешите мои тапочки). А, дескать, пользователю надо передать в конфигурации WinRel, но совершенно не объясняют, почему. Я-то полагал изначально, что дело просто в традиционном подходе "ой, не хочу давать читать мои коды". Полная фигура умолчания насчет того, что fll-ка в конфигурации WinDebug на компе без полной студии просто неработоспособна. Ну это стандартный подход мелкомягких - жрите что подают, не нравится - не жрите. Что касается пересборки под новой студией. Объясню. Я в свое время написал себе энной количество стринговых функций, реализующих работу с токенами (вдохновила сторонняя библиотека под Clipper - был такой язык :)). Все было отлажено, работало чудесно. Комп новенький, чистенький такой, никакого мусора на нем еще нет. А на днях пришлось устанавливать задачу на новом компе с WinXP со всеми последними сервис-паками. И при вызове одного отчета, в котором использованы функции токенизации, наступила крышка - задача просто повисает. Чудность в том, что на таких же компах с WinXP именно этой баги нет. Пересобираешь fll-ку (ничего в ней не меняя!) под новой студией - баг уходит. Такой вот кайф.

Игорь Горбонос,

Трудно сказать. Проблема-то в том, что собранные под 6-ой студией fll-ки работают на любых компах пользователя в любой конфигурации сборки. Не установлены же дебажные версии dll-ок мелкомягкими по умолчанию в операционке! А вот при сборке под 8-ой студией библиотеке, собранная в конфигурации WinDebug, работает только при наличии самой студии (причем неважно, какая это студия - Express или любая иная). Я тут на этот счет нарыл в инете одну ссылку - у чела была точно такая же проблема. Он написал, что причиной проблемы было отсутствие на компе пользователя MSVCR80.DLL. Но прямое вкорячивание этой dll-ки рядом с fll-кой ничего не дало. Пришлось-де использовать инсталлятор, в котором указать использование WinSXS. Это типа решило проблему. К сожалению, он не написал, о каком инсталляторе идет речь. Я попробовал было его метод, толку - ноль. Использовал Install Shield, пытался соорудить проект типа setup в самой студии. При этом меня насторожило, что на компе пользователя тьма-тьмущая этих самых MSVCR80.DLL. Причем размещаются они вовсе не в system32, а в каталогах самих приложений (например, ESET'а), а то и в личном каталоге пользователя. Спс этому треду, читая его что-то меня натолкнуло вчера попробовать WinRel (до того у меня по умолчанию стоял WinDebug). Хорошо хоть до сих пор у нас страна советов - попытки выяснить что-то в англоговорящем инете - глухое молчание.

Игорь Горбонос,

Уважаемый, не стоит повышать накал обсуждения. Особенно, когда не знаете, что пробовал собеседник. Совет ваш насчет рантайма от 8-ой студии - в пользу бедных. Был протестен первым делом. Толку - ноль. Я вообще-то, если вы могли заметить, проблему свою порешал, работоспособную версию fll получил. И всего-то хотел подсказать сообществу, какие грабли скрываются в пользовании новой студии. Как грится, не нравится совет - не читайте и не пользуйте. У нас швабода.