Портирование софта, написанного на borland C++ builder с ассемблерными вставками на linux

Работать, как я понимаю, он должен в кернелспейсе. Там принято использовать at&t синтаксис ассемблера, и с C++ на C переписать надо. Трудностей дохрена будет :)

> Работать, как я понимаю, он должен в кернелспейсе. Там принято использовать at&t синтаксис ассемблера, и с C++ на C переписать надо. Трудностей дохрена будет :)

"Правильно, давайте и маму в дом затащим, только мамы нам в доме и не хватало" (из простоквашино).

В кернел нужно поместить только самый минимум, -- драйвер для работы с железом, а в юзерспейсей уже хоть на хаскеле писать код

переписывать там под гас - удовольствие еще то
особенно отлаживать

> Там принято использовать at&t синтаксис ассемблера

Т.е. код на асме нужно будет переписать полностью. Так?

А если, как написали ниже, написать только "драйвер", то остальной ассемблерный код нельзя оставить неизменным (с минимальными изменениями)?

> C++ на C переписать надо

А под linux-ом нет C++? Или в данном случае не подойдет?

tnx.

Есть С++, у товарища просто красноглазие. В данном случае не важно на каком языке будет интерфейс.

Сам ты красноглазик, читать умеешь? "На С++ написан _в основном_ интерфейс." Т.е., исходя из этого, в драйвере тоже C++ есть.

> Т.е., исходя из этого, в драйвере тоже C++ есть. Этого я точно не знаю. Как я понял, С++ используется для работы с WinAPI.

p.s. Вроде знакомый решил таки отказаться от идеи перехода на линь. В частности из-за различий в менеджменте потоков... Как я понял, в худшую сторону(?). Так, что сейчас тема представляет больше академический интерес. ;)

Написал бы хоть, что софт умеет, может под линуксом такое уже есть.

Надо посоветовать "знакомому" переписать его фаервол, который он написал на делфи, под линукс и BSD.

Если по делу - то использовать в g++ ассемблерные вставки в стиле BC не получится. Ассемблер, который вызовет наименьший культурный шок у разработчика, привыкшего к асм-вставкам на BC, - это NASM. Разумный путь такой: сначала провести рефакторинг в проекте под BC с тем, чтобы избавиться от asm-вставок, и сделать ассемблерный код по-нормальному, в отдельных процедурах. При этом в качестве транслятора использовать NASM. (Можно сначала использовать tasm, а когда все заработает с ним - перейти на nasm). И уже после этого переезжать на Linux и GCC.

> Написал бы хоть, что софт умеет, может под линуксом такое уже есть.

Не думаю. Он сам пишет софт для низкоуровневого восстановления данных с хардов. Подробности объяснить не могу (не специалист). Но, как я понял, мало прямого обращения к железу - оно еще и по тактам и потокам "просчитано" в какой-то мере. Потому и на асме вставки сделаны. Примерно так.

2All: tnx. Может быть кому-то данная тема будет тоже интересна. Кстати, сейчас на местном форуме открыли тему по части перехода Win -> linux. Может быть кто-то сможет подсказать аналоги: а. ВСВ6 хотя бы в части самого С++. Т.е., предположим, имеется прога, написанная на "чистом" С++ (т.е. без asm) в ВСВ6: есть ли возможность с минимальными затратами портировать данный софт под линукс? б. "обычный" асм под DOS/Win98, чтобы такой софт можно было портировать на линукс.

p.s. Хоть не совсем в тему, но "прорекламирую" собираемую по миграции Win->linux тему. Может быть это будет взаимовыгодно ;) http://forums.vl.ru/read.php?23,1019993 Да простят меня модераторы ;)

Еще раз всем спасибо. С вашего позволения добавлю ответы на указанные вопросы в "наш" FAQ. Если получится нормальный проект - всегда буду рад поделиться накопленной инфой.

Интересно, чего же добился этот товарищ используя ассемблер.

Только не говорите про скорость и размер бинарника. Компилятор оптимизирует по скорости не хуже человека, а в данном случае я думаю даже лучше. Если гуй использует vcl, то и выигрыша в размере не будет видно.

Если программа действительно тормозила лучше бы он применил более хитрые алгоритмы, чем делал рутинную работу, изображая из себя машину.

ИМХО, единственное что он получил это трудности на свою голову. Пусть извлечет урок и перепишет заново, хотя бы на C.

PS. Если он добился тех же результатов, что и OnTrack в EasyRecovery, то респект ему и уважуха.

> Интересно, чего же добился этот товарищ используя ассемблер.

Эта тема у нас обсуждалась на форуме: _ttp://forums.vl.ru/read.php?23,1019209

В чем оно работает:

_____ Вопрос не совсем понял - "на чём" - это в смысле языка? среды? железа?

Если язык - то в основном ассемблер. И немного С. Если среда - то сейчас юзаю Borland C++ Builder 6.0. В принципе устраивает. Если железо - в основном у меня работают машины уровня целерон-пень три частотой 500-900Мгц и шиной 100-133.

_____

Оттуда же, правда, из спора о быстродействии и конкурентноспособности явы. Т.е. "что именно добился, используя asm":

_____ cld mov EDI,EBX mov cx,[EDX] rep insw

Это между прочим тривиальнейшая в нашем деле операция ;) И ещё кстати учтите, что непосредственно во время выполнения сего кода железом будет выдана серия(то бишь не одно) аппаратных(не программных!!) прерываний... а ещё - в это же время, то есть физически одновременно, по шине PCI идёт обмен данных в DMA режиме, причём может быть даже по двум каналам... _____

В общем у него, как я понимаю, программно-аппаратные решения для восстановления данных.

> Может быть кто-то сможет подсказать аналоги: а. ВСВ6 хотя бы в части самого С++. Т.е., предположим, имеется прога, написанная на "чистом" С++ (т.е. без asm) в ВСВ6: есть ли возможность с минимальными затратами портировать данный софт под линукс?

Ох, С++ в linux конечно есть - g++. Но! сомнительно что на BCB получается писать удерживаясь в пределах стандартных библиотек С++. я не знаю легко-ли портировать программы использующие VCL. Борланд забросил свой kylix (ЕМНИП он умел C++), VCL "по простому" тоже не перетащишь - там и ассемблер и что гораздо серьёзнее - Win32 API. Приложения можно переписать на Gtk+ или Qt - в качестве бонуса их можно будет сделать кросс-платформенными и собирать как для linux так и для win32.

Так что минимальные затраты на портирование в части интерфейса примерно равны затратам на написание с нуля. Но есть возможность запускать под wine.

> б. "обычный" асм под DOS/Win98, чтобы такой софт можно было портировать на линукс.

Ещё более сомнительно. Ибо основной мотив использования asm в dos - это доступ к "железу" и экономия на run-time языков высокого уровня ценой использования BIOS/DOS API. В linux первое для прикладных программ недостижимо, а второе недостижимо в принципе. Впрочем, см. http://asm.sourceforge.net/

>cld mov EDI,EBX mov cx,[EDX] rep insw

О да! Ядро оперирует с диском в DMA, а чертовы ламеры в это время читают строку из порта контроллера того же диска. Если он захватывает блокировку то замедляет обращения к диску всей системы до уровня PIO, не захватывает -- разрушает данные на диске.

Пусть откроет блочное устройство как файл и тем самым увеличит и скорость и надежность и портабельность.

> Если он захватывает блокировку то замедляет обращения к диску всей системы до уровня PIO

Так обращение к диску всей системы не просто не требуется, а вообще отключается нафик:). По крайней мере под виндой контроллер вырубается полностью, чтобы не мешался.

>Пусть откроет блочное устройство как файл и тем самым увеличит и скорость и надежность и портабельность.

Ну я думаю, что у него достаточно опыта, чтобы решить какой вариант быстрее и надежнее;). Он уже далеко не первый год занимается этим делом. На данный момент он юзает винду. Портабельность СЕЙЧАС не нужна. Просто был вариант вместо покупки доброго десятка копий винды попробовать портировать данный софт под линь и пользоваться линуксом.

Мдаааа... и это всё (!) что можно сказать...

Если у дяди нет денег на венду (сам признался) и железо (галимые целероны из прошлого столетия), то о чём вообще можно вести речь? Какая нафиг "квалификация"?

А данные на низком уровне восстанавливаются при помощи спец-техники и сервисных линий на винте.

>Так обращение к диску всей системы не просто не требуется, а вообще отключается нафик:). По крайней мере под виндой контроллер вырубается полностью, чтобы не мешался.

Чтобы отключить диск требуется закрепить все страницы первой необходимости в оперативной памяти, это как минимум весь executive, сервисы и собственно процесс этого кулибина со всеми библиотеками. К чему такие сложности, пусть юзает DOS.

Контроллер не может быть отключен в принципе, потому как именно в него втыкается винт. Отключив его мы потеряем связь с диском.

> Если у дяди нет денег на венду

У "дяди" софта на не одну штуку баксов.

> и железо (галимые целероны из прошлого столетия)

А зачем покупать другое железо, если этого хватает?

> Какая нафиг "квалификация"?

Человек входит в тройку сильнейших профессионалов Приморья. Не вам судить о его квалификации. Вас не просили оценивать квалификацию человека. Был задан конкретный вопрос. Не можете ответить - молчите в тряпочку. Да простят меня модераторы...

> Контроллер не может быть отключен в принципе, потому как именно в него втыкается винт. Отключив его мы потеряем связь с диском.

Отрубается контроллер в винде.

p.s. Не лично к вам, но: У меня до этого создавалось более положительное впечатление о "линуксоидах". Даром, что месяц, как на линукс перешел...

> А данные на низком уровне восстанавливаются при помощи спец-техники и сервисных линий на винте.

Я не знаю подробностей. Про "спецтехнику" упоминал выше. Читайте внимательнее.

p.s. Пересмотрел еще раз тему. Большинство более менее вменяемых постов было от анонимусов... Жаль... :(

>Отрубается контроллер в винде.

Знаете, а мне нужен контроллер в винде. Почему-то тот же ER не отключает его и никто никому не мешает, данные восстанавливаются просто изумительно.

Где можно купить его программу? Почему человек из тройки сильнейших профессионалов Приморья не может портировать свое творение в линукс?

> Знаете, а мне нужен контроллер в винде. Почему-то тот же ER не отключает его и никто никому не мешает, данные восстанавливаются просто изумительно.

Вы что подразумеваете под "восстановлением данных"? Восстановление всяким ширпотребным софтом? А если винт имеет физические повреждения - тоже "easy recovery восстанавливает изумительно"?

> Где можно купить его программу?

Вы считаете, что человек должен продавать свой инструмент, на котором он зарабатывает деньги?

> Почему человек из тройки сильнейших профессионалов Приморья не может портировать свое творение в линукс?

Потому, что он уже не один год пишет свой софт. Попробуйте портировать софтину, плотно работающую с железом на линукс, которая пишется уже лет 5.

>А если винт имеет физические повреждения - тоже "easy recovery восстанавливает изумительно"?

О, его программа умеет восстанавливать физические повреждения! Я потрясен!

Винт сначала приводится в юзабельное состояние пересадкой компонент с аналогичных винтов-доноров. Контроллер вполне заменяется и в домашних условиях, блок головок или коммутатор-предусилитель в гермозоне сложнее -- требуются спец. чистая комната и прямые руки. Редакторы серво-данных уже существуют, да они и не требуют повышенной производительности. Остальное вполне по силам ширпотребным программам.

Физические повреждения OnTrack чинит в лаборатории, но имхо 90% случаев это обычные bad-области, логические ошибки в данных или удаленные файлы.

>Попробуйте портировать софтину, плотно работающую с железом на линукс, которая пишется уже лет 5.

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

ignore mode on.