Здравствуйте, позарез необходимо 16-битный .obj прилинковать к Win32-проге. Он был написан на асме, причём исходник утерян безвозвратно. BCB 6.0 ругается - мол, не буду 16-битный код линковать... Можно ли, на худой конец, декомпилировать этот .obj и заново его скомпилять? Сам файл прилагается в аттаче... Заранее спасибо. _1298727383__CX24EO1.OBJ
Devicetator Ты представляешь, чем занимается код из CX24EO1.OBJ? Например, кусочек Код (Text): ... mov DX,021h in AL,DX or AL,4 out AL,DX mov AL,020h out AL,020h ...
Ага, скорее всего не будет это работать в Win32 даже через DVM. Почему бы не написать 16-битное приложение (BC++ 5, MASM, TASM) и запускать в чистом досе?
Devicetator а декомпильнуть, перелопатить, потом прикомпелить никак ??? ващето такой код будет работать,тока для начала Дэйла Роберца читать !
CARDINAL Не обязательно. Если код расчитан на выполнение в реальном времени, то под виндой он работать не будет и никакие эмуляторы не помогут.
Quantum пардон, сорец не глядел. А вот то , что он работать не будет, даже по куску вышепреведенного кода, вполне вероятно, поскольку на современные мамы апик сажают(хм, вообщето это часть проца), а там и порты другие соответственно, редко в режиме пик в винде последние работают. Так что действительно этот кусок кода может устроить большой бабах в системе блин
All 1. Во-первых, есть прога под ДОС, работает, но под ДОС вышестоящему руководству работать не пристало - злодеи перелопатить заставили... 2. В режиме эмуляции MS-DOS программа работает исправно, но медленно -> надо под W32 написать... 3. Сведения об .obj: содержит функции контроллера КАМАК для снятия показании термопар (в режиме реального времени). CARDINAL Как перелопатить, если нет даже примерного описания функции: есть только параметры, а чего и как эти функции делают - нет...
Devicetator Вам повезло. Что значит медленно? Это очень странно и как-то не вяжется с "содержит функции контроллера КАМАК для снятия показании термопар". Программа имеет сложный пользовательский интерфейс? В чистом досе она работала быстрее? Предлагаю оставить прогу как есть и написать оболочку под Win32, чтоб через пайп общалась с 16-битной прогой. Или собрать 16-битную DLL в Borland C++ 5, если объектник в борландовском формате.
Quantum 1. "медленно": а) "странно и как-то не вяжется...", но работает... б) Программа выводит таблицы показании и периодически их дополняет (обновляет). в) Под ДОС всё летает... под W32 же... хмм... происходит тормоз, т.е. задержка порядка 1 сек., что в режиме реального времени, где +-0,5 сек уже грозит выходом рабочего стенда из строя (вплоть до пробоя труб давлением или высокой температурой). г) Интерфейс под ДОС простенький - таблички, менюшки, ввод/вывод текста (параметров схемы). 2. "Предлагаю оставить прогу как есть и написать..." а) Не сочтите за "даунито хромосомо", но что такое "пайп"?.. б) А черт его знает в каком он формате Можно ли определить его формат?
Devicetator Тут Iczelion объясняет с примером использования. Если 16-битное приложение графическое ("таблички, менюшки"), то пайп может не помочь. А чем этот объектник в оригинале собирался в экзешник? Turbo C++?
Devicetator что то я тебя тоже не понял !!!!!! прога работает медленно, никак не вписывается в границы реалтайма. Ну и зачем тебе винда нахрен ???? NTVDM сам по себе тормоз да и глюкавый порядком. Это раз. А во вторых, если эта прога такая важная птица, то тебе скорее всего нужно либо оставить дос, либо вообще перейти на реалтаймовую платформу, типа QNX скажем. Требованиям последнего условия как ты понимаешь не отвечает ни дос ни винда.
Quantum Спасибо! Ознакомлюсь. А чем объектник собирался - история умалчивает... Начальство сказало - надо, дало этот объектник, кое-какие исходники и кое-какую ерунду и пожелало удачи... CARDINAL Мне-то эта винда нафиг не сплющилась, а выбирать операционку не дано... И сроки жмут по страшному...
Devicetator Формат объектника - OMF. Чем скомпилен OMF иногда указывается в поле Translator, но в данном случае это поле отсутствует. Можно заключить, что не TASM'ом. Я полагаю, что этот файл всё равно подойдёт Борланду. Версия 5.01 поддерживает 16-битные модули, но это всё на случай если с пайпом не получится.
Quantum 1. Вариант с пайпом не катит, надо упор на DLL делать, тем более что через пайп навряд ли будет работать быстрее. 2. "Версия 5.01 поддерживает 16-битные модули..." Как я понял, просто "Add to project..." CX24EO1.obj засунуть? Ну, BCB 5 у меня нет, есть 3 и 6. В BCB6 не прокатывает, а в ВСВ3 ругается мол: [LinkerError] Unresolved external 'CDREG(unsigned int*,int,int,int,int)' referenced from D:\F1.OBJ. 3. Если собирать DLL, то её вид такой(при этом в Exports пусто!!! Что не есть гуд!): #include <vcl.h> #pragma hdrstop USEOBJ("CX24EO1.OBJ"); void _export CDREG(unsigned int*,int, int, int, int); int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*) { return 1; } В общем-то ничего удивительного: тело фунции CDREG не указано. Как заставить брать его из .obj?
Devicetator Если тормоза из-за DVM, то и DLL быстрее работать не будет. "CDREG" в объектнике именуется "_CDREG". Попробуйте объявить его как Код (Text): extern "C" _export CDREG(unsigned int*,int,int,int,int)
Quantum 1. extern "C" _export CDREG(unsigned int*,int,int,int,int) а) если в проекте приложения: не работает - говорит то же самое [LinkerError] Unresolved external... б) если в проекте Dll в ВСВ3: экспорта всё равно нет... 2. Подскажи как собрать Dll с экпортами под Win16. а)Можно, конечно, взять старенький tlink (из ВС3) и собрать dll, но она наотрез не хочет работать, т.к. ничего не экспортирует. Использовали следующий код, но точку входа в Dll в ВС3 не знаем как написать, может так?.. #include <windows.h> void FAR _export CDREG(unsigned int*,int, int, int, int); int WINAPI DllMain(HINSTANCE hinst, unsigned long reason, void* lpReserved) { return 1; } б) Может собрать Def_file и явным образом указать экспортируемые функции, типа: LIBRARY CX24EO1.DLL EXPORTS @CDREG$qpuiiiii @1 ; CDREG(unsigned int*,int,int,int,int) или указать через _export, чтобы без указания секции EXPORTS, затем использовать def_file для компиляции старым tlink?
