Подскажите, почему библиотеку APLib нельзя применять для любых типов данных (или все таки можно ?) Суть в том, что некоторые секции (например DATA в дельфовых прогах) повреждаются после распаковки, т.е. оригинал и распакованная не совпадают , хотя начало секции распаковывается правильно, а через байт 200-300 уже нет... =(
PS: для запака использую саму библу, для распаковки - ассемблерный листинг c ESI и EDI в качестве указателей...

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Может версия старая, там бывали баги? Выкатывай пример - либу, неупакованные данные, и кусок кода, коим жмешь. Сам натыкался на ткие повреждения данных, но только на старых версиях библиотеки.

| Сообщение посчитали полезным:

Версия APLib 0.42

function PackSection(source1:pointer; size:dword):pointer;
begin

form1.CurFileSz:=size;
form1.aPLib.Source := source1;
form1.aPLib.Length := size;
form1.aPlib.CallBack := @CallBack;
form1.aPLib.Pack;
PACKEDSECTION:= form1.aPLib.Length;
if form1.aPLib.Length = 0 then Exit;
result:=form1.aPLib.Destination;
end;

For I:=1 to FILE_HEADER.NumberOfSections do begin
temp:=pointer(GlobalAlloc(GMEM_ZEROINIT,SECTION_HEADER[I].SizeOfRawDat a));
SetFilePointer(hFile,SECTION_HEADER[I].PointerToRawData,NIL,FILE_BEGIN );
ReadFile(hFile,temp^,SECTION_HEADER[I].SizeOfRawData,bread,NIL);
PackSection(pointer(temp),SECTION_HEADER[I].SizeOfRawData);

Для распаковки используется листинг на асме, входящий в состав библиотеки (начинается с cld)
Момент в том, что другие секции распаковываются верно, кроме этой

Прикладываю оригинал, запакованную и неверно распакованную =)

33b8_datasection.rar.zip

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon, у меня бывал идиотский глюк, когда функция распаковки\упаковки просто падала на запаковываемых данных, вылезая за пределы выделенного буфера. Для выделения памяти стал юзать SysAllocStringByteLen, как и в примерах aPLib, и все прошло...

| Сообщение посчитали полезным:

MoonShiner
У меня был точно такой глюк, когда я использовал VirtualAlloc в асме при распаковке, когда начал использовать GlobalAlloc - вроде прошло... И еще один глюк встретил - когда перед началом распаковки стоит к примеру - mov dword [esp+11C], eax - значение из eax соответсно пишется двордом в esp+11C, распаковка падает где то на середине, сместил эту команду на пару назад (чтобы она не была последней перед началом распаковки) - всё ок...

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Имел место такой трабл ... но чуть подругому.
Если прогу пишешь на дельфе с OOП как обычно вобшем (D7) то всё работает ок, пакует и анпачит.
А асли на чистом АПИ пишешь то слетает какраз на этом месте при паковке.Хотя всё ф-ци идентичны. Мож какие нибудь опции линкера или компилера влияют я так с этим и не разобрался. Данную траблу так и не решил, можете и мне заодно намекнуть в чём дело

| Сообщение посчитали полезным:

MoonShiner пишет:
SysAllocStringByteLen, как и в примерах aPLib, и все прошло...
странно но ничего кроме
FileIn := TFileStream.Create(OD.FileName,fmOpenRead or fmShareDenyWrite);
GetMem(Buffer, FileIn.Size);
Length := FileIn.Size;
FileIn.Read(Buffer^, Length);
я там не увидел ... поправте где нужно смотреть плиз

| Сообщение посчитали полезным:

Из всего выше написанного можно заключить что либа никак не годится
для серьёзного использования, есть ли нормальная альтернатива?

| Сообщение посчитали полезным:

Нормальная альтернатива - JGALC и LZH, только вот где взять полные исходники для пака и анпака =(

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Афтору надо писать на конкретном примере! Реальная альтернатива - lzma =)
JCALG1 - говно, слишком медленный и мясистый распаковывщик. Можно конечно попробовать свежий ffce от джибса, но не факт что там нет косяков - этот метод еще моложе аплиба.
Про lzh это наверно шутка, это название метода сжатия, а lzh алгоритмов полно, один хуже ругого. Один из лучших в аспаке последнем и в скажем CAB архивах,, остальное детские поделки, типа японских lha подобных пакеров прошлого тысячелетия с окном в 2кб =))
Если нужен именно чистый lz упаковщик, то лично мне нравится UCL от оберхумера, это действительно промышленно вылизанный упаковщик, даже в насовских спутниках используется для сжатия трафика.

| Сообщение посчитали полезным:

Ксати вышел новый APLib - v.0.43, но бага осталась
Еще раз всё перепроверил - подозреваю что это связано с дельфовым компонентом для сжатия, попробую жать асмом

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

DrGolova пишет:
Если нужен именно чистый lz упаковщик, то лично мне нравится UCL от оберхумера
Были бы очень признательны за ссылку на какойнить сорец по теме ...

| Сообщение посчитали полезным:

6aHguT
Да от оберхумера то нетрудно сырец найти (он помойму даж с упхом идёт в комплекте), только вот к дельфе не прикрутить , надо всё тогда на сях писать =(
на www.compression.ru http://www.compression.ru навалом всяких пак алго нашел =)
Интересно, что PESpin тоже использует APLib, но секцию эту пакует и распачит верно

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon пишет:
PESpin тоже использует APLib
Да много чё его использует, и всё работает видать у нас ручки кривоваты
Я щас lzma заюзать попробую если не покатит то тоды на асме всё перепешу тогда проблем точно не возникнет. Но на АПИ дельфи мнебы конечно было удобнее.

| Сообщение посчитали полезным:

6aHguT пишет:
Я щас lzma заюзать попробую
Получится если, дашь исходник библы для запака и асмовый код распака ?

6aHguT пишет:
видать у нас ручки кривоваты
У нас - это у меня или у обоих ?

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Качнул сорс lzma а он для никсов оказался, а для вынь чёто непопался мож кто укажит где взять, чтоб быстрей дело пошло, полдня на поиски неохота терять ...
А из сорцов Inno Setup гиморно вытаскивать.
Smon пишет:
У нас - это у меня или у обоих ?
Есессно у обоих но у меня даже больше

| Сообщение посчитали полезным:

6aHguT пишет:
мож кто укажит где взять

www.7-zip.org/sdk.html

| Сообщение посчитали полезным:

> Качнул сорс lzma а он для никсов оказался

Да не песди - он кросплатформенный - я его и под винду собирал и под бздю.
Могу собрать тебе dll но не на delphi - сей убогий язык как оказалось я забыл - сегодня с помощью двух гуру со скрипом написал прогу на дельфе в десять строк за пол часа. Было стыдно

| Сообщение посчитали полезным:

DrGolova пишет:
сей убогий язык как оказалось я забыл - сегодня с помощью двух гуру со скрипом написал прогу на дельфе в десять строк за пол часа
А помнится как-то писал PE_Files.pas - полезная ведь штука
Ксати что интересно по поводу aplib'а - если паковать все секции одним потоком а не по отдельности - то проблем с целостностью данных нет

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

на данном сайте есть значительно лучьшие альтернативы
http://fg.fatal.ru http://fg.fatal.ru

| Сообщение посчитали полезным:

Во, я нашел такую же багу в AlexProtector =) 1.0 Beta 2
Тоже юзается аплиб..... После упаковки прога на дельфах падает, причем так же, секция DATA распачится неверно =) причем падает уже после оеп...
Когда я сделал всё одним потоком - дельфовые перестали падать, зато начали падать C++ Builder'ские с неверной распаковкой секции импорта Ясно то, что дело не в самой библе, а в асмовом коде распаковки, что-то где то не учтено... (хотя учтено в том же песпине и пекомпакте)
DrGolova пишет:
Можно конечно попробовать свежий ffce от джибса
Где бы его только взять, на офсайте то нет...

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

Smon ага)) была у меня такая бага )

-----
Пиво, сиськи, транс

| Сообщение посчитали полезным:

Предположу, что не обрабатывали TLS.AddressOfIndex. Его надо редиректить в другое место, т.к. при запуске DWORD по этому адресу обнуляется, а в Дельфовых прогах (Delphi 200x) адрес указывает в середину пакованной секции, поэтому секция нераспаковывается.
Хотя хз в чем у вас прабла была, но я юзаю аплиб 0.42 давно и с делфи у меня праблов нет.

| Сообщение посчитали полезным:

FEUERRADER
И действительно - бага из-за этого ). Респект тебе, а я чёт и не подумал об обнулении адреса из тлс Вот теперь тему можно закрыть

-----
"Пусть видят, что мы не шутим. Стволы для понта, ножи для дела" Lock, Stock & Two Smoking Barrels

| Сообщение посчитали полезным:

т.е. проблема в упаковщике, а не в компрессоре? ошибка не имеет отношения именно к aPlib?

-----
EnJoy!

| Сообщение посчитали полезным: