[solved] Кто рюхает managed+unmanaged C++
я, кстати, не шарю, просто была как-то проблема с самоотладкой проги (она что-то делала с буфером обмена, так вот если он был связан со студией, которая отлаживала эту прогу, то там тоже какая-то жесть начиналась подумал, может у тебя тот же случай 
я, кстати, не шарю, просто была как-то проблема с самоотладкой проги (она что-то делала с буфером обмена, так вот если он был связан со студией, которая отлаживала эту прогу, то там тоже какая-то жесть начиналась подумал, может у тебя тот же случайСпасибо.
Я может глупость скажу, но ты не должен там WINAPI написать разве?
во, как раз написал этот ответ
просто вот меня глючило: почему unmanaged работает-то? может там в настройках проекта что странное и по умолчанию там stdcall поставился как-то?
Я написал ответ в треде. Если поставить __stdcall (или WINAPI то тогда в эту функцию вообще не передаётся управление и код не вызывается из VS, в которой я отлаживаю приложение. Что интересно, в unmanaged-варианте я ставил WINAPI и он соответствовал __cdecl, а здесь - __stdcall. Так что там явно должен быть __cdecl (по умолчанию).
Ещё момент: после выполнения return можно походить по ассемблерному коду и AV вываливается довольно скоро (где-то через 10 инструкции и 3 jmp но вот понять в нём я ничего не смог...
И на данный момент я не понимаю, чем отличается экспортированная из managed-dll функция с #pragma unmanaged от обычной экспортируемой функции из unmanaged-dll.
Ещё момент: после выполнения return можно походить по ассемблерному коду и AV вываливается довольно скоро (где-то через 10 инструкции и 3 jmp но вот понять в нём я ничего не смог...
И на данный момент я не понимаю, чем отличается экспортированная из managed-dll функция с #pragma unmanaged от обычной экспортируемой функции из unmanaged-dll.
Так что там явно должен быть __cdecl (по умолчанию).
@Mikhail, the parameters will be passed correctly no matter what convention is used, these two differ only in who cleans up the stack.
Чёрт, теперь я уже не уверен. Но почему же тогда при выставлении __stdcall функция вообще перестаёт вызываться?
читай комменты
> since all the parameters seemed to look right with default __cdecl convention ... I don't think calling convention is an issue.
Ненене, ты не спеши В cdecl и stdcall порядок параметров не различается, там только разница кто стек чистит, caller или callee. То есть именно на return-е эта разница и проявляется. Так что ты лучше разберись, почему она у тебя не вызывается через stdcall... Там же при декларировании stdcall случается какой-то mangling и его надо повторить там где ты декларируешь, какую функцию вызывать (autoexp.dat?)
PS. вы уж простите что я сюда, лень на stackoverflow акк заводить
Ненене, ты не спеши
В cdecl и stdcall порядок параметров не различается, там только разница кто стек чистит, caller или callee. То есть именно на return-е эта разница и проявляется. Так что ты лучше разберись, почему она у тебя не вызывается через stdcall... Там же при декларировании stdcall случается какой-то mangling и его надо повторить там где ты декларируешь, какую функцию вызывать (autoexp.dat?)PS. вы уж простите что я сюда, лень на stackoverflow акк заводить
PS. вы уж простите что я сюда, лень на stackoverflow акк заводитьок, я там так же ответил
я тебя там дублирую считай В cdecl и stdcall порядок параметров не различаетсяВ этом меня уже просвятил, точно, я знал
читай комментыРаботаю над этим
где-то через 10 инструкции и 3 jmpну посмотри, есть ли среди них что-то похожее на add ESP, smth
Друзья! Я знал, что доброфорум мне поможет! Теперь я знаю, чем отличаются __stdcall и __cdecl, и что есть разница между __declspec(dllexport) и module definition file (хотя я так до конца и не понял, почему последний выключает name mangling). В любом случае, проблема решена!
Оба автора безошибочно определили причину проблемы - неправильный calling convention (порядок вызова?) функции, за что получают по плюсику. Отдельный бонус для в виде принятого ответа на stackoverflov (в результате чего его репутация преодолевает символическую планку в 3333) за объяснение того, как вырубить name mangling.
Оба автора безошибочно определили причину проблемы - неправильный calling convention (порядок вызова?) функции, за что получают по плюсику. Отдельный бонус для в виде принятого ответа на stackoverflov (в результате чего его репутация преодолевает символическую планку в 3333) за объяснение того, как вырубить name mangling.
а ты понял, почему unmanaged работает? Моя телепатия: ты скачал из сэмплов проект целиком, а не только исходник и там в проекте проставлен stdcall. Или что-то другое? Просто этот факт реально затуманивал проблему
Как раз потому, что там оставался от сэмплов WINAPI, но в нём я делал экспоерт функции через .def-файл, на что даже не обратил внимания. Я только видел, что depends.exe показывает функцию без name mangling, как и при __cdecl, из чего я сделал вывод, что в unmanaged WINAPI значил __cdecl. И был не прав
В managed dll я модифицировал скопированную функцию какого-то примера exporting unmanaged function from managed dll, где не стояло WINAPI, но был __declspec(dllexport)! Вот так я сам себя запутал.
Короче, единственное, что мне пока не совсем понятно, почему экспорт через .def-файл отрубает name mangling.
В managed dll я модифицировал скопированную функцию какого-то примера exporting unmanaged function from managed dll, где не стояло WINAPI, но был __declspec(dllexport)! Вот так я сам себя запутал.
Короче, единственное, что мне пока не совсем понятно, почему экспорт через .def-файл отрубает name mangling.
Как раз потому, что там оставался от сэмплов WINAPI, но в нём я делал экспоерт функции через .def-файл, на что даже не обратил внимания. Я только видел, что depends.exe показывает функцию без name mangling, как и при __cdecl, из чего я сделал вывод, что в unmanaged WINAPI значил __cdecl. И был не право, это важно для меня, потому что я уж испугался, что WINAPI может значить __cdecl. Тогда ок
Короче, единственное, что мне пока не совсем понятно, почему экспорт через .def-файл отрубает name mangling.да, это я тоже целиком не понимаю. Т.е. вот вроде бы принято экспортировать из независимых от языка (программирования) dll-к нормальные имена функций, но почему это работает именно так — хз, должно быть hysterical raisins (c)
> Короче, единственное, что мне пока не совсем понятно, почему экспорт через .def-файл отрубает name mangling.
Это потому, что по формату .def файла ты не можешь проэкспортировать две функции с одинаковым именем и разными calling convensions, а через dllexport можешь. Вот и получается что в одном случае манглинг и не нужен, путаницы не может возникнуть, а в другом нужен.
Собственно в .def файле ты можешь вообще функцию проэкспортировать под другим именем. Вот и считай что ты там задекларировал замангленное имя проэскпортировать под незамангленным.
Это потому, что по формату .def файла ты не можешь проэкспортировать две функции с одинаковым именем и разными calling convensions, а через dllexport можешь. Вот и получается что в одном случае манглинг и не нужен, путаницы не может возникнуть, а в другом нужен.
Собственно в .def файле ты можешь вообще функцию проэкспортировать под другим именем. Вот и считай что ты там задекларировал замангленное имя проэскпортировать под незамангленным.
не, реально, смешно же, пойти на stackoverflow, расписать проблему, потом найти решение на старом доброфоруме 
причем считай не одно, а два одинаковых одновременно еще на доп. вопрос ответил.
причем считай не одно, а два одинаковых одновременно еще на доп. вопрос ответил.Ну stackoverflow крутая тема, там рано или поздно что-нибудь дельное посоветуют, аудитория там очень широкая. А с доброфорумом - как повезёт. Есть шанс, что ответят быстро и дельно, а может и вообще никто не заметит. И, опять же, публика привередливая: может заминусовать с тем, что вопрос не достоин её внимания
там тоже может заминусовать
особенно меня радует, как там реально буквально за 40 секунд закрывают трололо-вопросы типа кто быстрее перл или питон
А про рано или поздно — это как раз не факт там, вопросы быстро тонут, иногда надо баунти ставить, тогда, в принципе, шансы повышаются. А так-то да, надо еще пиарить вопрос среди друзей, в соц-сетях там и др.
особенно меня радует, как там реально буквально за 40 секунд закрывают трололо-вопросы типа кто быстрее перл или питон
А про рано или поздно — это как раз не факт там, вопросы быстро тонут, иногда надо баунти ставить, тогда, в принципе, шансы повышаются. А так-то да, надо еще пиарить вопрос среди друзей, в соц-сетях там и др.
вопросы быстро тонутС одной стороны да, но с другой у меня не раз бывали вопросы, на которые дельные советы давали через несколько дней. Причём сначала, похоже, спрашивают всякие более-менее очевидные вещи, и если это не помогает (как это обычно и бывает потом откуда-то приходят матёрые батьки и начинают уже что-то мудрить
Мне интересно, это у кого-то хобби такое, или есть саппорты, которым платят, чтобы они отвечали на профильных форумах на вопросы по их тематике? Где-то читал, что репа на stackoverflow способна хорошо украсить резюме.Оставить комментарий
Serpent555
Да не затруднит вас обратить внимание на сей вопрос.