скажу честно, этот zlib мой первый опыт с c++ вообще) поэтому я выбирал студию мягких как инструмент, который будет указывать мне на тупые ошибки с достаточным описанием, чтобы решить её, по крайней мере я на это надеялся

но у меня с zlib'ом остался один весьма неразрешенный вопрос - компилироваться-то он компилируется, да вот не работает как надо, вопросы по проблемам в работе и последний рабочий исходник в этой теме выложить или создать отдельную тему?

на всякий случай вот сами проблемы:

1. при запаковке файла через указание параметров только в deflateinit (уровень сжатия) пишется статус "зашибись, все okay", но когда открываю файлик сжатый тем же notepad++, то в конце файла отчетливо вижу мусорные символы (один и тот же символ, русская буква Н, или в Hex это CD), количество которых зависит напрямую от директивы



если сделать chunk 1, то количество мусорных символов явно меньше, всего 2 или 3, как следствие такой файл потом не распаковывается

2. пытался распаковать файл, от которого у меня есть: исходный сжатый и распакованный (для сверки), распаковка не удалась... точнее в первый раз как-то распаковалось больше 80%, не было лишь последних двух строк текста содержащих



изначально распаковывал со стандартными параметрами в inflateinit, потом использовал inflateinit2 и перебрал все допустимые windowBits (диапазоны от -15 до -8 и от 8 до 15), распаковка так же не удалась, хуже того, больше не удается сделать распаковку хотя бы 80% файла, что-то явно случилось за это время...

p.s. по рекомендации borisbn почистил от мусора (после чистки проверил, запускалось, значит лишнего не удалил) и приложил те 400 кб исходного проекта к сообщению, еще в архиве исходный сжатый файл comp_00020.lua и его распакованная версия decomp_orig_00020.lua

Это сообщение отредактировал(а) ohos - 24.1.2012, 23:34

Присоединённый файл ( Кол-во скачиваний: 8 )
 zlib_console_test.rar 396,67 Kb

У вас проблемы не со студией, и даже не с zlib 

Вы просто элементарно не правильно работаете с файлами.

Добавлено через 10 минут и 54 секунды
да, чуть не забыл, в исходниках поменяйте размещение файлов с L:\ на С:\

(не хотел загрязнять свой С:\)

Это сообщение отредактировал(а) volatile - 25.1.2012, 13:51

Присоединённый файл ( Кол-во скачиваний: 7 )
 111.zip 3,21 Kb

Где возможность? С основания C эта возможность была через строку -lz в вызове компилятора. Куда её вписывать этой студии?
Не надо мне разсказывать про 4-х уровневые менюшки, к тому жэ разные на китайской и французской версии. Это -- другое.

вы это о чем? о каком основании  С:  

tzirechnoy, в студии можно вообще работать без IDE, с голимой комм.строкой
Как я понял вы это считаете пределом совершенства?   

дальнейший спор неуместен. Не нравиться студия, ради бога.
мне это как-то по-барабану.

volatile, благодарю вас, я посмотрел отличия, если я правильно понял, то они лишь в отсутствии знака + в функциях fopen, запаковка исходного файла и распаковка работает, но после я пытался распаковать один странный файл упакованный вроде бы zlib 1.1.3 с заголовком кратным 31, во время распаковки возникает ошибка и я решил более точно определить, где именно в inflate функции из файла inflate.c это происходит путем вывода сообщений в консоль, но студия ругается на использование там PRINTF или fputs, как правильно их там использовать?

например ошибка:

ссылка на неразрешенный внешний символ _PRINTF в функции _inflate

если вставить в inflate.c функцию



Это сообщение отредактировал(а) ohos - 26.1.2012, 01:13

+ не причем. у вас файл после записи в него не закрывался. И позиция указывала на конец.
А вы пытались из него читать. в итоге ...


В С/С++ имена функций регистрозависимы.
функции PRINTF не существует...


ohos, возможно вам рано браться за такие проекты?
Может стоит сначала почитать учебники.
Вы не знаете самых основ.

volatile, согласен, рано по уровню знаний в c++, но к сожалению не по необходимости, к тому же учиться никогда не поздно, а учиться на нужном и дельном примере еще и интересно 

я попробую вечером набрать в правильном регистре функцию, просто слишком привык в некоторых языках к независимости

volatile, прошу прощения, но если у вас еще есть желание помочь в решении вопросов, то они уже появились

printf сработало, нужно было действительно писать маленькими буквами и я добавил вывод сообщений в функции inflate и затем inflate_blocks, чтобы понять, где "разница" и как её избежать при распаковке "странного" файла, в отличие от того, который был пожат этим же консольным приложением, в результате я нашел то место "различия", оно оказалось в функции inflate_blocks, точнее говоря в куске её кода



тут нормальный файл уходит в мод DRY, а исследуемый мной "странный" в TYPE (на новый круг распаковки, чего быть вроде не должно, потому-что все данные на распаковку умещаются в один размер CHUNK), но в данном куске я напрочь не понимаю, что означает проверка (!s->last) и как она происходит, найти в интернете оказалось довольно сложно, так как я пытался искать по ->, а все поисковые системы воспринимают знак минуса как логический оператор "не", а не текст, символ > правда тоже похоже для них не является просто текстом либо вообще заблокирован для поиска, но теоретически я догадываюсь, что s является переменной из объявления



а last проверка, стоит ли указатель в конце файла или нет, но это лишь "теория". так как я не знаю и не могу найти ответ из-за слишком продвинутых поисковых систем

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

хочу отметить еще, что оба запакованных файла имеют заголовок (2 байта) кратные 31, если бы "странный" был сломан совсем, то он бы тогда имел наверняка битый заголовок и то приложение, которое им пользуется не смогло бы читать файл, а оно использует как раз zlib.dll версии 1.1.3 (MD5 этой dll совпадает с теми, что я качал из интернета, значит zlib используется не измененный), а сейчас он всего лишь больше того, который у нормального (странный - 789C, нормальный - 7801)

еще хочу заметить, что у zlib при распаковке есть возможность указывать настройки в лице windowBits, но я уже пробовал его изменять, перебирал все диапазоны (от -15 до -8 и от 8 до 15), не помогло...

Присоединённый файл ( Кол-во скачиваний: 2 )
 zlib_console_test2.rar 518,23 Kb

ohos, как я понял вы хотите распаковать неизвестно откуда взятый файл, и он у вас не распаковывается.
А с чего вы взяли что он например не зашифрован, или что к нему не прибавили какие-то служебные байты в начале
(например название фала, или размер)?

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

volatile, откуда взят файл, известно, брал правда не я сам, гарантии отсутствия шифрования конечно же нет, но я уверен, что шифровать его еще поверх было бы глупо, потому-что он и так был в "самопальном" архиве, любой желающий его бы и так не смог открыть, к тому же шифрование сказалось бы на производительности, а это при сжатии и перечитывании файла при любом обращении к нему по моему недопустимая роскошь

к тому же одно время удалось пообщаться с человеком, который его из того архива самопального вытащил, он то и дал прогу для распаковки архива, говорил что не очень сложно было разобраться, но ни исходников того распаковщика ни объяснений не дал и контакт с ним потом потерялся, возможно он просто сильно забил на все это

я решил не идти сразу по пути реверс инжиниринга, так как в нем я еще больше не шарю, хотя когда-то пробовал на креклабе, решил проверить файл на возможность распаковки стандартным zlib, т.к. приложение использующее тот самопальный архив использует стандартную zlib.dll версии 1.1.3

то, что эта версия работает корректно сама по себе, я уже убедился и за это крайне благодарен вам, но необходимость разобраться что именно с тем странным файлом все же есть, при его просмотре в WinHex я заметил одну весьма странную осоденность, у него в конце идет много нулей и кусочек текста, не исключаю, что он тут просто лишний, но пока не пробывал перебирать распаковку с отрезанием последних байт файлов, хотя попробую и это на всякий случай

ohos, хорошо. Скинтье отдельно этот файл. Будет время я посмотрю.
Если есть распокованый он-же, то тоже скинтье

Естественно обещать что угадаю алгортм не буду. 

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

orig_source_00020.lua - оригинальный файл извлеченных из странного архива
orig_comp_00020.lua - сжатый вариант файла из странного архива
console_comp_00020.lua - сжатый вариант оригинального файла этой консолью, проблемы в работе которой обсуждались


в данный момент странна лишь одна вещь, файл извлекается, но консольное приложение пишет ошибку, я попробую еще раз перебрать все windowBits, так как в прошлый раз делал это с криво извлеченным из самопального архива)

Это сообщение отредактировал(а) ohos - 29.1.2012, 15:18

Присоединённый файл ( Кол-во скачиваний: 5 )
 zlib_console_test2.rar 0,68 Kb

я перебрал все варианты сжатия, затем стал искать файлы имеющие такой же заголовок 2 байта и сравнивать их на соответствие байт "странному" файлу, в итоге было найдено порядка 6-8 возможных опций при которых из 164 байтов "странного" файла совпадают аж 159! 

вот на всякий случай архив со всеми вариантами распакованными + точно тот, где совпадает 159 байт из 164

comp_00020_lvl5_winbits15_memlv2_strategy0.lua

параметры сжатия соответственно level 15, method 8 (константа) ,windowBits 15, memLevel 2, strategy 0

уважаемый volatile, полагаю теперь загадка "странного" файла не настолько тяжелая и вы мне поможете её разгадать? я пока что попробую поискать другие файлы из странного архива, для сравнения и проверки

Присоединённый файл ( Кол-во скачиваний: 2 )
 zlib_all_types.rar 884,89 Kb

Скорей всего это просто поврежденный файл, тем более что 

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

ohos, распаковщик должен расжать файл, независимо от способа запаковки. Если пишет ошибку, значит файл поврежден.
либо записан другим упаковщиком/другой версией.