Столкнулся с интересной ситуацией. Пишу код на VC++ v.6 sp.6:



Здесь DllWinMain() экспортируемая функция из runtime библиотек vfp9r.dll / vfp9t.dll. А "Emery.fxp" это объектный модуль Visual FoxPro, программный код которого:



Так вот в 6-й Визуал Студио это все работает великолепно. Можно делать и консольный вариант, тоже работает, разве что только черное командное окно болтается под ногами.

Хорошо, думаю, теперь самое время наваять аналогичную программу в Qt. Пишем там аналогичный код:



Проектный файл (в кодировке Windows-1251) будет таким:



И вот, непереводимая игра слов, этот код не работает, Ошибки (нарушение доступа к памяти) выдаются либо в vfp9r.dll (vfp9t.dll) либо в msvcr71.dll. Что странно, ведь это библиотеки самого M$!

Все попутные эксперименты ничего не дали. Разве что удалось запустить без проблем другую функцию из того же VFP модуля:



хотя использовать ее для наших целей бессмысленно (да и не вполне корректно).

В итоге пришлось брать в руки тяжелую артиллерию, применять отладчик «Оля Дебаговая» для параллельной отладки «хорошего» кода из VC++-6.6 и «плохого» от Qt-5.8.

В конце концов, выяснилась следующая ситуация. VC++ хранит инициализированные переменные в секции данных (доступных на чтение и запись), а Qt – в секции ресурсов (доступных только на чтение). И надо же функция DllWinMain() зачем-то переписывает имя "Emery.fxp". Поскольку в секции данных это допустимо, то все ОК, а в секции ресурсов получаем критическую ошибку доступа. А функция DllOleInit() этой фигней не страдает и хотя держит имя в секции ресурсов, но ограничивается только чтением его, что тоже допустимо.

Отсюда ясно, как нам действовать дальше. Надо просто вместо статической переменной использовать динамическое. Такой вот метод годится, но громоздкий:



В итоге нашелся более эффективный вариант



И наш код в Qt наконец-то заработал!

Здесь продемонстрированы несколько моментов программирования, которые могут быть полезными начинающим, так как поиск подобной информации в сети занимает довольно много времени.

MasterZivда запросто. Может быть порядка 10 причин для того, чтобы это не работало.
Да, нет! Причина здесь одна. Говорю же, смотрел под отладкой. Имя файла у Qt-5.8 храниться в секции «.rdata» (Access «R»). А у VC++-6.6 в секции «.data» (Access «RW CopyOnWr»).

MasterZivНапример, QT-программа и FoxPro используют разные С-runtime library, а VC -шная программа -- одну и ту же.
Как следствие, при работе VC -шная программы CRT инициализируется верно, а при работе QT-шной -нет.
Я забыл сказать, что использовал упаковки qt-opensource-windows-x86-mingw530-5.8.0.exe и qt-opensource-windows-x86-mingw530-5.7.1.exe, т.е. с компилятором minGW, поэтому эта версия Qt С-runtime библиотеки от VC не использует.

Кстати, deployment Qt-5.8 не на всех операционках Windows поддерживается. Например, portable версия не будет работать на Win 2008 Server R2, хотя Qt-5.7.1 там работает (нюансы всего лишь в паре файлов). Чтобы это понять тоже пришлось поломать голову. Возможно, новые версии Qt будут более совместимы с различными версиями Windows.

SiemarglВо первых, Qt - не компилятор, а библиотека с IDE. Судя по msvcrt71, Qt Creator ТСа использует Visual Studio .NET 2003
Нет. Уже сказал, что использовал компилятор minGW-5.3. А msvcrt71.dll использует vfp9r.dll / vfp9t.dll. Кроме этой dll-ли необходим еще файл ресурсов vfp9renu.dll. При использовании графики VFP может понадобиться GdiPlus.dll. Не помешает также config.fpw с командой «SCREEN = OFF» и может быть «CODEPAGE = 1251». Это все хозяйство использует Визуал ФоксПро, а не КюТэ.

SiemarglВполне возможно, что Foxpro собран VC6 и потому конфликтов нет.
Конфликтов нет по причине использования VC-6 места хранения статических переменных в секции «.data» (Access «RW CopyOnWr»), а не «.rdata» (Access «R») как в Qt-5.

SiemarglСекция ресурсов - это совсем не то, возможно путается с секцией константных данных.
Вполне возможно. Вот только сейчас обратил внимание, что Resources имеют секцию «.rsrc», которую я попутал с секцией «.rdata». Виноват :) !

SiemarglИтого - налицо конфликт версий кода собранного разными CRT/компиляторами. Возможно, VC7.1 стал по другому - строже обращаться с константами.

Решение - не съезжать с VC6, возможно взяв Qt старой версии, или же разобравшись, что действительно происходит при инициализации.
Это уже по факту не по теме. А Qt старой версии брать нет необходимости. Все работает и в новой, если создавать имена файлов динамически для функций типа DllWinMain() из vfp9r.dll / vfp9t.dll, что и продемонстрировано в итоге.

NekZEmery,

>LIBS += vfp9r.dll
А разве там не .lib-файл должен быть?
Очень хороший вопрос!

Нет, все работает, как указано. Проект прилагается. Только файлы Visual FoxPro ищите в Интернете самостоятельно. Их легко найти в программах написанных на VFP, хотя распространять не рекомендуется.

Кстати, это очень важный момент. Qt не требует, судя по всему, lib-файлов, а VC++ требует, поэтому для последнего приходиться создавать файлы vfp9r.lib / vfp9t.lib самостоятельно. С чем и поздравляю :) !

MasterZivДа нет, здесь продемонстрирован феерический бред, который люди несут, когда не понимают, что не всякую DLL можно так вот запросто взять и вызвать...
Так ведь вызвал же :) ! Далее будет больше – использование inproc DDE сервера в программе на Qt (на VC6 это уже сделано), отображение и навигация в Qt иерархических данных, как в справочниках 1С. При этом, никакого COM'a и никакой регистрации в реестре.

Dima Tvfp9r.dll это рантайм 9-го фокспро. По сравнению с 6-м (vfp6r.dll) у 9-го сменился рантайм С++ (надо msvcr71.dll)
В данном случае, это ничего не меняет.

Dima TИ 9-й кривой в плане размножения копированием. Кривизна в том что если что-то не так, то он просто вылетает с ошибками доступа к памяти. Никаких внятных сообщений.
У меня пока особых проблем не было, хотя в этом направлении работал много.

Dima TПри размножении копированием надо вместе класть



Это я знаю, только тут не все файлы приведены.

Dima TНо это не панацея, бывают еще ньюансы.
Знакомая ситуация :) .

Dima TЭто COM-класс, а не библиотека из функций. Может оказаться что как COM-класс он уже зарегистрирован и vfp9r.dll находит остальные DLL не те что рядом, а те что зарегистрированы. Если они из разных сервиспаков - работать не будет.
А вот тут можно поговорить. vfp9r.dll / vfp9t.dll это фиктивные COM-классы, или, если хотите, не стандартные. Т.е. стандартным образом вы с ними работать не сможете, и никто не может, Интернет в доказательство. Одно из двух, либо там просто стоят пустые заглушки, которые поставили для показухи, либо используются секретные ГУИДы (которые голыми руками, даже с Олей Дебаговой и ИДОй не возьмешь), о которых, кроме M$ никто не знает. Кроме КОМовских функций, там используются и обычные экспортируемые функции, с которыми и происходит реальная работа. В частности с функцией VFPDllGetClassObject(). Спрашивается, зачем она нужна, если есть обычная КОМовская функция DllGetClassObject()?

Для получения доступа к возможностям ядра VFP из C++ можно воспользоваться несколькими способами. Технически осуществимы следующие варианты:

1. Использование OLE сервера VFP (запускаемого как «vfp9.exe /automation» либо «vfp9.exe /regserver», выгружается как «vfp9.exe /unregserver»)
2. Создание COM сервера, средствами VFP (single threading на базе vfp9r.dll либо multi threading на базе vfp9t.dll).
3. Создание внешнего приложения VFP (exe-файла на базе vfp9r.dll).
4. Применение DDE сервера, построенного средствами VFP (на базе однопоточного vfp9r.dll).

Их можно разделить на стандартные и нестандартные способы реализации.

Нестандартные способы отличаются тем, что мы непосредственно задействуем в c++ проектах некоторые недокументированные экспортируемые функции из runtime-библиотек VFP (vfp9r.dll / vfp9t.dll).

Очевидно, что приведен не исчерпывающий список возможностей, хотя и вполне достаточный для наших целей.

Dima TДля начала проверь что он вообще работает, сделай простейший проект на фоксе


скомпилируй в EXE, скопируй EXE куда тебе надо и запусти.
У меня реально работают в паре с 1С77 профессионально сделанное внешнее приложение на Фокпро-8 (непосредственный расчет заработной платы, связь по DDE каналу). Так что, если вы не против, я не буду возиться с этим примером :) .

Dima TPS Использование vfp9r.dll как обычной DLL нигде не документировано, по крайней мере самим МС.
Согласен, но никто не запрещал использовать экспортируемые функции из dll. Поэкспериментировали с прототипами и все дела.

Dima TДля доступа к базам VFP есть Microsoft OLE DB Provider for Visual FoxPro 9.0
Этот способ оставим на любителя.

MasterZivВо-первых, не VC и QT, а два разных компилятора, MS C/C++ и какой-то еще, причем еще и неизвестно, какой - QT приложения могут собираться разными компиляторами, в том числе и тем же самым, что и приложение, собираемое в VC. Компиляторы могут по-разному оформлять данные в памяти. Во-вторых, есть разные версии этих компиляторов, каждого. В третьих, есть разные режимы сборки, release, debug и другие. разные режима оптимизации кода. Что ты там с чем собирать пытался - тоже загадка. В четверых, есть проблема One Definition Rule, нарушение которого влечет по стандарту неопределенное поведение, т. е. полную неизвестность, приложение может работать, а может и не работать.
Конкретные вопросы можно задать, я отвечу. Сборка стандартная Release, компилятор minGW-5.3, Qt-5.7.1, оптимизации нет. Здесь существенно то, что Qt помещает статические переменные в секцию только для чтения, VC++ в секцию чтение и запись. Иногда это может приводить к коллизиям, как в данном случае, ведь и экспортируемая функция и сам dll-ка тут не с бухты-барахты, а очень даже по делу. Если бы я не запустил эту тестовую программу в Qt, пришлось бы менять концепцию, что для меня имело бы большое значение.

MasterZivНа практике в разработке на C/C++ нарушение ODR чаще всего выражается в использовании нескольких экземпляров библиотеки C runtime library в виде статических (.lib) или динамических (.dll) библиотек. В каждом приложении (!не в dll, а именно приложении!) C Runtime должен быть только один, либо приложение вообще не должно использовать C Runtime. Это правило очень часто нарушается, к тому же очень сложно иногда бывает его не нарушить, потому что любая dll может использовать другие dll и так далее каскадно, включая все системные библиотеки и драйвера, и порой как это все будет прогружено в конечной операционки на машине пользователя, ты вообще не знаешь. А последствия могут быть любыми, в том числе и полная неработоспособность приложения, и наоборот, видимая работоспособность. (Как я люблю говорить, ваша программа не работает, но вы еще об этом не знаете).
Здесь msvcr71.dll использует только vfp9r.dll / vfp9t.dll, а Qt может использовать какой угодно runtime, одно другому никак не мешает. Deployment для Qt никто не отменял, там есть свои нюансы, о которых я уже успел здесь высказаться.

MasterZivКроме этого, CRT не только должен быть один в приложении, но еще должен быть правильно инициализирован, причем не просто глобально, а в каждом потоке приложения. Приложения на VC часто это делают автоматом, другие приложения возможно, должны делать это руками.
Согласен, многопоточное программирование требует хорошего внимания и вникания.

MasterZivВ общем, как видишь, есть порядка 20 причин, почему одна и та же функция в dll может не работать при вызове из одного приложения, и не работать из другого, кроме банальной проблемы записи в константную строку, которая тоже по-разному может оформляться разными компиляторами и их версиями.
Абстрактно, да, но конкретно – нет. Я привел одну-единственную причину, которая в данном случае имеет место быть. В других случаях могут быть остальные 19 причин, но о них можно начать говорить только тогда, когда они произойдут («решать проблемы по мере их поступления»).

MasterZivну вот, видишь, ты собираешь приложение разными компиляторами, и они используют разные рантаймы C. И хочешь, чтобы оно работало.
Проблема найдена и исправлена, поэтому все работает. Я ведь здесь не вопросы задаю, а информацией делюсь, может кому-то будет интересно.

[quot MasterZiv]То, что константные строки в VC кладутся в незащищаемый от записи сегмент данных, это была особенность именно версий VC6 и до нее.
Эту информацию возьму на заметку!

MasterZivQT5.8 - современная библиотека, её по хорошему вообще нельзя с такими древними приложениями как VC 6 и Fox pro использовать - у них точно рантаймы разные.
QT5.8 у меня с VC6 напрямую не работает, с ним (точнее, версией 7.1) работает runtime VFP. А можно или нельзя QT5.8 работать с VFP, на это отвечу, что почему бы и нет? Можно, если получается. Когда и если возникнут проблемы, тогда будем искать другой путь. Благо доступных движков баз данных сейчас хватает. Просто начал с того, что мне больше нравиться и вполне допускаю, что это будет не окончательный вариант. Хорошо, если в программе можно будет подключаться к выбранному движку БД. Чем больше их будет, тем лучше.

MasterZivКстати, QT - это еще и приложение на C++, там еще есть куча проблем, специфичных для C++: inline STD code и рантайм C++.
Ну, волка боятся, в лес не ходить :) .

MasterZivEmeryЭто уже по факту не по теме. А Qt старой версии брать нет необходимости. Все работает и в новой, если создавать имена файлов динамически для функций типа DllWinMain() из vfp9r.dll / vfp9t.dll, что и продемонстрировано в итоге.

Еще раз, это не "работает", это "делает вид, что работает" , т. е. оно не работает, но ты об этом еще не знаешь...
Разницу чувствуешь?

Сказано красиво, но не более того. Доверяй, но проверяй!

Dima TРантайм Visual FoxPro (DLL) не имеет ограничений на распространение. Лицензия разрешает его копировать.
Да, если такая лицензия есть, а если нет?

SiemarglEmery,

MinGW использует msvcrt.dll, у него своей либс нет.
Да, это так, но проблем в нашем случае не возникает.

Dima TЭтих файлов достаточно для работы приложения VFP9 под WinXP и выше.
Если VFP использует графику, может понадобиться GdiPlus.dll. А почему вы про vfp9t.dll ничего не пишите?

Dima TСкажем так: это недокументированные классы.
Я бы сказал, что это скорее не используемые классы (стандартные КОМ-функции). Представлены, скорее всего, для мебели.

Dima TПринцип работы приложения на VFP такой:
Внутри EXE небольшой загрузчик и байт-код самого приложения для интерпретатора, т.е. тех самых DLL.
Загрузчик это вызов из vfp9r.dll / vfp9t.dll DLLWinMain() с двумя параметрами. Первый параметр – имя файла, содержащий объектный код VFP (*.fxp; *.app; *.exe файлы). Второй параметр – опция отображения, типа SW_SHOWDEFAULT, в реальности параметр может быть произвольным, явной зависимости не видно.

Dima TКак этот загрузчик находит, загружает и передает байт-код на исполнение в DLL - это внутреннее дело разработчика DLL, т.е. MS, т.к. они изначально предусмотрели только такое использование этих DLL. Все остальные варианты это лайфхаки умельцев.
Из предыдущего абзаца принцип работы ясен. Экспериментальные проверки это доказывают. Другое дело, что более одного объектного файла VFP за один раз вы не исполните. Чтобы работать с произвольными VFP скриптами нужно создать отдельный поток и там выполнить объектный модуль VFP, который переводит VFP в решим DDE сервера (либо используя любую межпроцессную / межпоточную технологию, благо VFP поддерживает WinAPI) с помощью команды




Далее, из других потоков нашей же программы обращаетесь к пользовательскому DDE серверу VFP для выполнения любого потока команд и обмена данными.

Кстати, M$ не документировал работу системного DDE сервера VFP, хотя есть примеры использования
системного DDE сервера Access / Excel / Word и др. Однако, это не сильно надо, а то бы пришлось вычислять эту информацию.

Dima TИМХО если уж что-то изучать, то тот самый загрузчик.
У вас еще остались вопросы?