Войти
ПрограммированиеФорумОбщее

В C/C++ про дефолту типы знаковые или беззнаковые? (2 стр)

Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 Следующая »
#15
10:51, 27 июля 2021

Gradius
> Реверсю старую ДОС-игру. Она как раз написана на Watcom C.
Ностальгия... Когда же это было то... год 1995й, примерно, может даже раньше. 10й watcom, dos4gw... Там же и С++ был, древний, еще без темплейтов и stl.
11я версия watcom и под винду была, только ей уже почти не пользовались.


#16
(Правка: 11:37) 11:26, 27 июля 2021

foxes
> Ты пытаешься превратить код ассемблера в код для С современных компиляторов, но
> при этом пихаешь его в Watcom - это странно. Тебе так не кажется?
> Не важно из чего изначально был получен ассемблер, IDA выдает совсем иное.

Мне проще и легче собирать приложение под ДОС и его отлаживать.  Чтобы нарисовать пиксель на экране в ДОСе, нужно написать пару строк на ассемблере, и писать в видеопамять напрямую.  Чтобы нарисовать пиксель в винде, нужно написать в 10...100 раз больше. И трахаться с локом-анлоком поверхностей.  Или SDL.

Сейчас поставлена цель получить работающую игру в ДОСе.
Адаптация под винду с помощью SDL - будет второй этап.

foxes
> Просто определись с тем что код от Hex Rays не для Watcom C. Хотя наверняка
> можно под него настроить.

У меня всё компилится.
Выдачу с IDA и Hex-Rays подвергаю обработке: скрипты (свои и питоновские) + немного ручной обработки.
Всё собирается.

foxes
> И еще, твоя тема во флейме, а там в основном троли себе цену набивают.

Ну не сюда же её переносить. Форум посвящён разработке игр, а не реверсу.
Учитывая родственность темы, я лично принял решение разместить во флейме.
Если у вас есть какие-то полезные предложения, можете изложить их здесь или в личку.

Zab
> Ностальгия... Когда же это было то... год 1995й, примерно, может даже раньше.
> 10й watcom, dos4gw... Там же и С++ был, древний, еще без темплейтов и stl.
> 11я версия watcom и под винду была, только ей уже почти не пользовались.

Эх! Да!
А я всё думал в то время... Как игры получают доступ к пикселям выше 64 кБ  видеопамяти!
Про ДОС-экстендеры, LFB и VESA 4F05h  я ещё не знал.

Долго просидел на TurboPascal с его 16 бит.
А потом ассемблерными вставками перевёл в Unreal Mode (плоский 32-битный режим).  Но это не работало в 98-й винде в отличие от DPMI.

А в то время, между прочим, Кармаки всякие писали Думы.... На нормальном коммерческом Watcom, о котором мало кто слышал...
Приходилось давиться 16-битным Turbo Pascal + TASM.  Это было на пиратских дисках.  Но ватком не попадался...

Осваивал извращения типа EMM386, XMS... Но они не давали доступ к видеопамяти за пределами 64 кБ.
А режим chained 256 kB (4 видеоплоскости по 64К )был не интересен, из-за того что там битовую маску через порты дополнительно выставлять надо было (чтобы загасить пиксели или защитить их от изменения). 

#17
11:36, 27 июля 2021

Gradius
> Чтобы нарисовать пиксель в винде, нужно написать в 10...100 раз больше.
С появлением WinG (позднее доросшего до DirectX) в Win95 все упростилось. Эта заплатка просто отключала на время GUI и позволяла рисовать как в DOS (причем, давала не один экранный буфер, а сразу два - нарисовал кадр, переключил, рисуй новый). Единственный минус - эта штука зверски несовместима сама с собой. Подбор нужной версии - дело трудное и местами безнадежное.

#18
(Правка: 11:43) 11:39, 27 июля 2021

Gradius
> скрипты (свои и питоновские) + немного ручной обработки.
А ведь этого всего могло бы и не быть.
Gradius
> Сейчас поставлена цель получить работающую игру в ДОСе.
Можно просто подобрать что-то подходящее djgpp
http://old-dos.ru/files/52/1.html
Но дело твое.
Gradius
> Если у вас есть какие-то полезные предложения, можете изложить их здесь или в
> личку.
Следить за входными параметрами и описывать структуры - решает больше половины проблем для Hex Rays. Но слишком много ручной работы, тут ни куда не деться.

#19
11:39, 27 июля 2021

gudleifr
> С появлением WinG (позднее доросшего до DirectX) в Win95 все упростилось. Эта
> заплатка просто отключала на время GUI и позволяла рисовать как в DOS (причем,
> давала не один экранный буфер, а сразу два - нарисовал кадр, переключил, рисуй
> новый). Единственный минус - эта штука зверски несовместима сама с собой.
> Подбор нужной версии - дело трудное и местами безнадежное.

Интересно! Я не знал!

В 98-й я рисовал прямо на рабочем столе через линейный буфер видеокадра(LFB), когда перешёл в 0-е кольцо.
Правда, организация видеопамяти там была не линейная, а мозаичная:  квадратиками зигзагом.

#20
(Правка: 11:44) 11:44, 27 июля 2021

foxes
> Можно просто подобрать что то подходящее djgpp

Это тоже из разряда под ДОС. GCC под DOS.

Ватком понимает C99 (включается недокументированным флагом -za99) и С++.
Более мне ничего не надо )))

foxes
> http://old-dos.ru/files/52/1.html

Вначале нужна скорейшая гарантия, что полученный и исправленный код будет работать.  Библиотеки потом будут!


foxes
> . Но слишком много ручной работы, тут ни куда не деться.

Я бы сказал, что работы овер-дохрена... В основном она заключается в поиске причин, по которым отреверсенный код не идёт или идёт не как надо.

#21
(Правка: 12:25) 11:52, 27 июля 2021

Gradius
> В основном она заключается в поиске причин, по которым отреверсенный код не
> идёт или идёт не как надо.
Обычно это решается заменой таких вот странностей структурами.

  *(u32*)(esp+0x1C)=(u32)&tmaps[v9];
  *(u32*)(esp+0x20)=0;
  *(u32*)(esp+0x24)=0;
  *(u16*)(esp+0x28)=0;
  *(u16*)(esp+0x2A)=0;

Часто подобные структуры являются каким то стандартом либки или производной от него. Можно прямо в Hex Rays добавлять структуры и он его будет иногда подхватывать, особенно если это какая-то глобальная шляпа. Лучше начать с введения известных структур если есть зависимости от библиотек.

Допустим переменная palette очевидно указатель на какой то массив, а не просто int. А что это за массив можно узнать только разбирая код FindColor. При этом остальные методы использующие palette не будут обращаться к ней с кривым преобразованием, а бубут использовать по назначению после замены типа данных на "unsigned int8*" или "color*" где color это структура с 3 или 4 полями по байту.

Gradius
> 2)  Процедура с нестандартной передачей параметров: 2 параметра через стек по
> типу __cdecl, а остальные через регистры:
https://ecstatica2.livejournal.com/44713.html
https://docs.microsoft.com/ru-ru/cpp/cpp/fastcall?view=msvc-160

#22
11:59, 27 июля 2021

Gradius
> А в то время, между прочим, Кармаки всякие писали Думы.... На нормальном
> коммерческом Watcom, о котором мало кто слышал...
Почему же не слышали то... Я именно тогда тоже watcom'ом пользовался, года эдак с 1992-93го. Игры писали симуляторного типа. Остатки тех досовских проектов еще были активны года до 96-97го. Под виндой ватком-компилятор не использовался, он вчистую проигрывал всем, даже микрософту.

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

#23
(Правка: 12:31) 12:20, 27 июля 2021

foxes
> Часто подобные структуры являются каким то стандартом либки или производной от
> него. Можно прямо в Hex Rays добавлять структуры и он его будет иногда
> подхватывать, особенно если это какая-то глобальная шляпа. Лучше начать с
> введения известных структур если есть зависимости от библиотек.

Очень легко рассуждать со стороны, будучи не ввязаным в дело...  Про игру мне известно только то, что в её отладочной информации в конце EXE. Которую IDA, кстати, не смогла обработать.  С помощью ваткомовских утилит и моей головы с руками был написан парсер имён переменных и функций.  Рассчитаны их адреса и впихнуты с треском в IDA с моей помощью.  Число параметров процедур и длины переменных(с их типами) из отладочной инфы я не стал доставать (это слишком муторно, там иерархия объектов.  Без знания формата - это мёртвое дело).  Я положился на IDA и на свой мозг.

Остальное мне неизвестно! Только дедуктивный метод раскуривания.  Смотрю, тестирую, ставлю гипотезы, делаю выводы...

Про понимание ID'ой глобальных шляп - это из ряда фантастики. 

Это не Java, не NET, и не C#.  Это нативный код под x86.
И здесь мало что обломится в прямом человеческом представлении.

И код, который вы привели - это моё. И оно рабочее. Мне так удобнее. 

Ставится цель получить компилируемый рабочий код игры для сборки его на 32-битные платформы.  При этом мне фиолетово, будет ли кто-нибудь его понимать или нет. Главное, что есть возможность  хотя бы из адекватно названных процедур и глобальных переменных понять логику работы игры.

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

#24
(Правка: 12:28) 12:24, 27 июля 2021

Zab
> Почему же не слышали то... Я именно тогда тоже watcom'ом пользовался, года эдак
> с 1992-93го. Игры писали симуляторного типа. Остатки тех досовских проектов еще
> были активны года до 96-97го. Под виндой ватком-компилятор не использовался, он
> вчистую проигрывал всем, даже микрософту.

Я с 99-го года начал программировать.
Сразу определился с тем, что под ДОС прогать приятнее. Ибо всё прямо и свобода.
Винду не любил.

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

Я с этим не сталкивался. Работал с памятью выше мегабайта напрямую. Ни у кого её не просил.
ДОС-экстендеры прошли мимо меня вплоть до 2003-го года.  Переводил CPU в плоский режим и использовал верхнюю память как мне хотелось.  Делить её не с кем было.

Это потом я узнал про TMT Pascal, а вместе с ним про PMODEW.  Поже перешёл на Си... ну и про ватком я узнал из книги Зубкова "Ассемблер для DOS, Windows и Unix"

#25
(Правка: 12:35) 12:25, 27 июля 2021

Gradius
> Очень легко рассуждать со стороны, будучи не ввязаным в дело...
Я тоже с этим много возился, все начинается с простых структур.
Gradius
> Про понимание ID'ой глобальных шляп - это из ряда фантастики. 
Ты с начало попробуй. Просто от того что ты объявишь одну структуру и не заменишь тип одной переменной ни чего не произойдет.
Gradius
> И вот что удивляет, что это месево вычислизмов компилируется и работает.
Ну все таки привод типов ни чего не ломает в логике.

#26
(Правка: 12:35) 12:34, 27 июля 2021

foxes
> Допустим переменная palette очевидно указатель на какой то массив, а не просто
> int. А что это за массив можно узнать только разбирая код FindColor. При этом
> остальные методы использующие palette не будут обращаться к ней с кривым
> преобразованием, а бубут использовать по назначению после замены типа данных на
> "unsigned int8*" или "color*" где color это структура с 3 или 4 полями по
> байту.

Ещё раз обозначу рамки цели: нужен компилируемый и рабочий код на 32-битные платформы.
При этом как названы байты в памяти - указатель на массив или на структуру - мне не важно.

Это не Human-Understanding code.  Это пофиксенный выхлоп с Hex-rays на языке Си.

#27
(Правка: 13:21) 12:38, 27 июля 2021

Gradius
> И код, который вы привели - это моё. И оно рабочее. Мне так удобнее. 
Я понимаю, но вместо тебя это мог бы сделать Hex Rays.
Gradius
> При этом как названы байты в памяти - указатель на массив или на структуру -
> мне не важно.
Я это не для того чтоб тебе это стало важно, а для адекватной работы самого Hex Rays - что избавляет от ручной работы и дедуктивного поиска во многом. К тому же структуры это не ооп, это и есть Си, даже в асме есть структуры.

#28
13:48, 27 июля 2021
Я что-то упускаю?

> Чтобы нарисовать пиксель в винде, нужно написать в 10...100 раз больше

Казалось бы, именно сама запись пикселя в область памяти buffer[w*y+x]=color; что там, что там.

> с локом-анлоком поверхностей

А нужно ли? Буфер из памяти отправляется на отрисовку одним вызовом StretchDIBits или BitBlt. Ну и InvalidateRect при желании.

В чём цель lock/unlock?

#29
(Правка: 14:07) 14:06, 27 июля 2021

А в чём вообще контекст трагедии?

Что там за игра, которую надо непременно реверсить, а не к примеру написать самому, с поддержкой нужных ОС (а по сути аппаратных платформ)?

И в чём предметная суть SetPixel? Т.е. для чего он нужен в игре?
Т.е. не спрайт, не буфер целиком, а именно пиксель?

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее