Распространяемый компилятор - DLL для MS Visual Studio

Я делаю обучающую игру по программированию для своего старшего проекта, и я ищу компилятор, который может скомпилировать DLL, которая затем может быть динамически загружена в приложение Visual Studio 2008 C ++.

Важная идея здесь заключается в том, что компилятор является распространяемым. Если бы VS был распространяемым, я бы использовал это.

Пока что у меня был некоторый успех с использованием MinGW, но этот успех ограничен. В настоящее время я могу загружать и работать только с одной DLL за раз. В тот момент, когда я пытаюсь загрузить вторую, приложение VS C ++ вылетает с ошибкой нарушения прав доступа.

Мне удалось без проблем загрузить две библиотеки DLL, скомпилированные в самой VS, поэтому это наводит меня на мысль, что это что-то специфическое для MinGW, это библиотеки DLL, и то, как они взаимодействуют с LoadLibrary () и так далее.

Я работаю над этой проблемой довольно долгое время и разочарован. Если кто-то знает другой компилятор, который, как вы знаете, будет работать вместо MinGW, или если вы видели эту проблему, возможно, вы знаете, почему вторая DLL вызывает сбой. Я уверен, что это связано с тем, что каждая DLL каким-то образом наступает на другую, но я понятия не имею, что это было бы и как узнать.

Это может быть способ компиляции библиотеки DLL или ее загрузка; Я понятия не имею.

Буду очень признателен за отзыв, спасибо!

Изменить: это простые вызовы g ++ и dlltool для создания DLL http://pastebin.com/f675df4b0

Это источник одной из моих DLL. http://pastebin.com/f5c062611

Это код в моем приложении C ++ для загрузки библиотеки DLL. http://pastebin.com/f52f94a18

-Майкл


visual-studio dll mingw loadlibrary redistributable
person Michael Peddicord    schedule 17.02.2010    source источник
comment
Можете попробовать дать еще немного информации о падении. Где он рушится. В вызове LoadLibrary или при вызове какой-либо из конкретных функций, которые вы импортировали?   -  person Laserallan    schedule 18.02.2010
comment
Это общий сбой нарушения прав доступа. Прямо на LoadLibrary (). Но всегда при загрузке второй DLL. Он никогда не дает сбоев при первом вызове LoadLibrary (). Если я смогу сегодня вечером, я вставлю исходный код dll, команды компиляции dll и код функции LoadLibrary ().   -  person Michael Peddicord    schedule 18.02.2010

Ответы (2)


arrow_upward
0
arrow_downward

Вы возвращаете 0 из DllMain. Согласно спецификациям вы должны вернуть TRUE, если что-то не пойдет не так. Однако я не понимаю, почему это должно приводить к другому поведению на MSVC или MinGW. В нем также говорится, что LoadLibrary должна возвращать 0, если DllMain возвращает FALSE, поэтому это может не быть фактическим объяснением.

Действительно ли DllMain вызывается как в версии MSVC, так и в версии MinGW, произойдет ли что-то, если вы удалите в нем комментарий к вызову окна сообщения?

Дополнительные сведения о DllMain см. На странице http://msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx.

Еще одна вещь, которая может быть интересна, если вы действительно вызываете AiFunction из первой dll перед загрузкой второй. Если да, можете ли вы попробовать загрузить обе библиотеки DLL без вызова какой-либо функции dll между ними и посмотреть, работает ли она лучше?

Я подозреваю, что MinGW и MSVC по-разному упаковывают структуры ввода и вывода и что каким-то образом это несоответствие размера приводит к повреждению некоторой памяти при вызове AiFunction. Вы можете проверить это, сравнив результаты sizeof () для вывода и ввода внутри и вне dll и посмотреть, совпадают ли они. Это не гарантирует, что он правильный, но если он не совпадает, вы можете быть уверены, что что-то пойдет не так.

Наконец, меня беспокоит, что возвращение вывода потенциально может стать проблемой в долгосрочной перспективе, если вы начнете вводить виртуальные вызовы и тому подобное, поскольку это может быть реализовано иначе в MSVC и MinGW. Если вы сохраните его без виртуальных функций и подобных вещей, все будет в порядке, если структура упаковки будет соответствовать.

person Laserallan    schedule 18.02.2010
comment
Вы дали мне посмотреть на несколько вещей. DllMain был в порядке, он устранил одну из моих проблем, но не основную. Пока что DllMain нормально вызывается при загрузке первой DLL. Но когда я вызываю второй, у него есть ошибка доступа внутри LoadLibrary. Я удалил весь лишний код, пока не осталась только одна функция экспорта (без структуры или включений), и она по-прежнему загружала бы первую и вылетала из-за второй. Кстати, sizeof были такими же. Я думаю, что имма сломается и просто использует VS .. черт возьми, это просто старший проект, верно? - person Michael Peddicord; 22.02.2010

arrow_upward
1
arrow_downward

Было бы достаточно просто использовать Visual Studio Express? Компилятор можно загрузить бесплатно, и он избавит вас от лишних хлопот, пытаясь добиться совместимости библиотек DLL.

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

person Weembles    schedule 17.02.2010
comment
Я смотрел это раньше. Хотя Visual Studio Express можно загрузить бесплатно, распространять его нельзя. Но спасибо. - person Michael Peddicord; 18.02.2010
comment
Просто из любопытства, почему вам нужно лично распространять компилятор, а не разрешать конечным пользователям загружать его самостоятельно? - person Weembles; 19.02.2010