Пользуюсь модулем Шумика.
Спотыкается на файле в 286М.
Google не помог.
Похоже на приговор. Обычным Zip-ом не хочется пользоваться.
Но может есть выход?

На какой функции из zlibwapi спотыкается и код ее вызова?

1. zipWriteInFileInZip
2. =zipWriteInFileInZip(THIS.zipfile_id,@m.sbuff,LEN(m.sbuff))
Не мой код и по 2-му пункту (там непонятка) могу сказать, что он работает много лет.
Памяти хватало

Если речь про то что в фоксе создаётся "строка" с содержимым 286Мб-ного файла (для передачи в АПИ-функцию, или ещё для чего - не важно), то в принципе вполне себе может и падать по нехватке памяти. Этот размер весьма близок к пределу (с учётом того что фокс как минимум сделает 2 копии этой строки (точнее памяти выделит столько) для передачи в функцию и потом для приёма назад результата - раз уж через @ прописано).
Память для строки ему нужна непрерывным блоком, так что чутка "поработав" в фоксе, скажем те же более мелкие файлы поупаковывав, на раз придём к ситуации что для 3 непрерывных кусков по 286М уже и нет свободной памяти.
Не нужно для упаковки в архив гонять файлы через фоксовую память. Пусть сам упаковщик их и читает прямо с диска, удобными для себя порциями - не в курсе реализовано ли это в библиотеке, если нет - то используй банальный 7z в консольном варианте.

zlibwapi.dll работает в серьезных приложениях типа Wordperfect, где многомегабайтными упаковками не пахнет.
Удобная штука. И термометр вставить можно.
Жаль, но эта таблица, а это журнал проводок, у некоторых юзеров и на ГБ потянет.
Сжимается очень хорошо.
7z - да, хорошо, что он есть. Банальный, но бесплатный!



Исправлено 1 раз(а). Последнее : Ydin, 27.03.18 08:48

Vfpcompression.fll есть:
- делает ZIP из файлов (и из переменной тоже умеет вроде),
- память не жрет (попробовал сжать несколько файлов много Г в файл 1.2Г, диспетчер не показал пожирания памяти),
- не без недостатков (имена файлов сохраняет как есть, т.е. в виндовой кодировке, а сторонние раззиповщики наблюдают их в ZIP-е как будто они записаны в OEM, отсюда "кракозябры", но это лечится)

Для сжатия "в общем" не требуется сразу весь объём сжимаемых данных подавать алгоритму - потому в принципе не проблема хоть 100500 терабайт сжать (если формат архива позволит). Вопрос в конкретной реализации твоего (взятого тобой) кода - фоксовой части прежде всего. Из я вижу что какой-то буфер передаётся функции. Если этот буфер (содержимое этой строки) и есть ЦЕЛИКОМ твои 286Мб (или тем паче гигабайт) - ну извини, кто ж виноват что ты настолько неправильно используешь механизм (хотя я не спорю - возможно что он и сам имеет такие ограничения - может быть в dll не предусмотрено "потоковой" передачи сжимаемых данных)
По логике вещей, надо сравнительно небольшими порциями передавать на обработку данные - какими именно, и как именно весь процесс организовать я не в курсе - надо изучить АПИ этой dll и исходя из этого уже и писать фоксовый код обёртки.

Это не мой механизм. Я или в решениях его взял или в Уфе у Шумика из Алматы. Он работал все время.
Dll-ку это не знаю
Включил 7Z. Тоже проблема. В новую тему вынесу