найти каталог программы сжатой upx

[Сквозняк]

В программе сжатой upx ParamStr(0) возвращает пустоту. Можно ли это победить?

[Nik]

Если с другими параметрами всё нормально, то первый можно заменить на Application.ExeName - там тоже полный путь к exe.

[Odyssey]

Application.ExeName внутри вызывает ParamStr(0).
Насколько я понимаю, победить это можно только отказом от upx.

[NTFS]

Эта беда (ЕМНИП) только для Linux - распаковка идет куда-то далеко и неудачно, потому каталог реальной программы неопределен.

Решение - не использовать UPX (во времена терабайтных винтов это не так актуально), или перестроить программу так, чтобы не требовалось определять путь к исполнимому файлу (например, хранить конфиг в /etc, переменные в /var и т.д.)

[alexs]

, или перестроить программу так, чтобы не требовалось определять путь к исполнимому файлу (например, хранить конфиг в /etc, переменные в /var и т.д.)

Самое верное решение.
Во всех ос есть свои правила хранения данных/конфигов и тюдю Изобретать своё не нужно - иначе появляются перлы вида хранения данных в ProgramFiles или ещё чего.

[WAYFARER]

Впринципе как вариант если все нужно хранить в одном каталоге, можно инсталлить программу в папку /opt, а в программе указать абсолютные пути к файлам вида '/opt/myprogram/filename', но по мне, это тоже не есть гут, это как раз

перлы вида хранения данных в ProgramFiles или ещё чего.

А посему лучше воспользоваться советом выше)), а пользовательские файлы хранить в $HOME

во времена терабайтных винтов это не так актуально

Но, допустим, при скачивании вашей программы позволяет сэкономить несколько секунд/минут)))

[Vadim]

Но, допустим, при скачивании вашей программы позволяет сэкономить несколько секунд/минут

И кто же, при этом, мешал пользоваться 7zip'ом? Он давит программу куда лучше, чем upx, но, в отличие от него, не теряет каталог хранения.

[Maxizar]

Но, допустим, при скачивании вашей программы позволяет сэкономить несколько секунд/минут)))

А потом, при каждом старте программы тратить 0.01 сек или больше на распаковку программы.. (Вы скажете что секунда>>0.01 сек, Да но качаете вы программу 1 раз, а запускать будите сколько?) и не трудно посчитать что сжатие upx ничего толком то и не дает... даже наоборот, если распаковка проходит частями... мы получим замедления выполнения. Но это всего лишь ИМХО..

И кто же, при этом, мешал пользоваться 7zip'ом?

+1.

[Сквозняк]

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

Код: Выделить всё

#!/bin/sh
p=`(echo ${BASH_SOURCE[0]}) 2>&1`
p=${p%%:*}
d=${p%/*}
cd $d
./my_proga `pwd`

Осталось узнать как обойтись без утилиты pwd и передавать данные непосредственно из переменной $d

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

После запуска программы память освободится а дисковое пространстро, нет. Постоянно запаковывать и распаковывать неудобно. Кроме того, fpc кроссплатформенный, а лазарус поддерживает несколько тулкитов. В программе тянущей за собой много картинок и мультимедии, исполняемый файл занимает относительно немного места и можно положить ещё несколько сборок бинарника сделав кроссплатформенную и кросстулкитную программу (специально для тулкитофобов). Но вспомогательные бинарники в сумме будут весить прилично, неплохо бы их пожать.

[WAYFARER]

И кто же, при этом, мешал пользоваться 7zip'ом?

Да никто, но это предполагает, что пользователю придется иметь 7zip:)

PS. Да я это так, к примеру просто было:).

А потом, при каждом старте программы тратить 0.01 сек или больше на распаковку программы..

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

Добавлено спустя 4 минуты 41 секунду:
Я upx использую обычно только для сжатия самого Lazarus после пересборки, и только в Windows, тогда запуск происходит в разы быстрее.

[Maxizar]

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

Ну такого не может быть... То что файл с меньшим размером прочитается с диска быстрее спору нет... но он будет распоковываться чуть больше чем время нужное для прочтения не упакованного файла с диска... Тобишь запуск программы сжатого UPX будет проходить медленнее... А чтение с диска быстрее...

Чтобы не казаться голословным провел эксперемент:
UPX 3.07 (08 Sep 2010: ) Win32
OS: WinXP SP3
Lazarus 0.9.29.

Создаем программу в лазарус. Провел эксперемент с программой (пустая форма) при загрузке которой выходим методом Close:

Код: Выделить всё

procedure TForm1.FormShow(Sender: TObject);
begin
  close;
end;

Теперь проводим тест:
- Запускаем программу сжатую UPX и не сжатую, замеряем время от старта до выхода.
Программа теста:

Код: Выделить всё

unit Unit1; 

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, process, FileUtil, Forms, Controls, Graphics, Dialogs,
  StdCtrls;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end; 

var
  Form1: TForm1; 

implementation
uses performancetime;
{$R *.lfm}


Procedure RunProg(Const ProgName:String);
var
   AProcess: TProcess;
begin
   AProcess := TProcess.Create(nil);
   AProcess.CommandLine := UTF8ToSys(ProgName);
   AProcess.Options     := AProcess.Options + [poWaitOnExit];

   AProcess.Execute;
   AProcess.Free;
end;

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var Delay:TPerformanceTime;
begin
   Delay:=TPerformanceTime.Create(false);
   Delay.Start;
   RunProg(Edit1.Text);
   Delay.Stop;
   Caption:=FloatToStr(Delay.Delay);
end;

end.

Где модуль performancetime:

Код: Выделить всё

unit PerformanceTime;
{  =============================================================================
 Модуль PerformanceTime содержит описание класса  TPerformanceTime, который
 позволяет измерить время выполнения куска кода. Необходимо инициализировать
 переменную типа TPerformanceTime, выполнить метод Start. проделать работу (код)
 Выполнить метод Stop, после чего в св-ве Delay будет время выполнения кода
 в секундах.
 Пример:
     T:=TPerformanceTime.Create;
     T.Start;
     Sleep(1000);
     T.Stop;
     Caption:=FloatToStr(T.Delay);//покажет время равное 1 секунде +/- погрешность

 Так же в классе есть учет погрешности за счет вызова внутренних процедур класса.
 За это отвечает параметр в конструкторе. если он True то будет учет погрешности
 (задержка самого таймера, за счет вызова процедур)

 Примечание: Позволяет измерять время выполнения кода. Если код "быстрый" можно
 использовать for I:=1 to N do (Код), после чего полученное время разделить
 на N, При этом чем выше N тем меньше будет дисперсия.
 Чем выше частота процессора, то по идее точность должна быть выше, по крайней
 мере в Windows.

 Среда разработки: Lazarus v0.9.29 beta и выше
 Компилятор:       FPC v 2.4.1 и выше
 Автор: Maxizar
 Дата создания: 03.03.2010
 Дата редактирования: 12.01.2011
 }
{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils,
  {$IFDEF windows}
  Windows;
  {$ENDIF}
  {$IFDEF UNIX}
  Unix, BaseUnix;
  {$ENDIF}


  Type
    TPerformanceTime=class
      private
        FDelay    :Real;   //измеренное время в секундах
        TimerDelay:Real;   //Задержка (время) самого вычисления в секундах
        StartTime :Real;   //Время начала теста в секундах

      public
        constructor Create(EnabledTimerDelay:Boolean=True);

        property  Delay:Real read FDelay;
        procedure Start;
        procedure Stop;
   end;

  Function  GetTimeInSec:Real;   //вернет время в секундах, с начало работы ОС

implementation


function GetTimeInSec: Real;
var
  {$IFDEF windows}
  StartCount, Freq: Int64;
  {$ENDIF}

   {$IFDEF UNIX}
  TimeLinux:timeval;
  {$ENDIF}
begin
  {$IFDEF windows}
   if QueryPerformanceCounter(StartCount) then //возвращает текущее значение счетчика
    begin
      QueryPerformanceFrequency(Freq);   //Кол-во тиков в секунду
      Result:=StartCount/Freq;           //Результат в секундах
    end
  else
    Result:=GetTickCount*1000;           //*1000, т.к  GetTickCount вернет милиСекунды
  {$ENDIF}

  {$IFDEF UNIX}
   fpGetTimeOfDay(@TimeLinux,nil);
   Result:=TimeLinux.tv_sec + TimeLinux.tv_usec/1000000;
  {$ENDIF}
end;

{ TPerformanceTime }
//------------------------------------------------------------------//
constructor TPerformanceTime.Create(EnabledTimerDelay: Boolean);
var TempTime,TempValue:Real;
begin
  TimerDelay:=0;

  if EnabledTimerDelay then
   begin
    TempValue :=GetTimeInSec;    //Первый раз холостой, чтобы подгрузить нужные системные dll
                                 //Но за одно и записали в TempValue число.
    TempTime  :=GetTimeInSec;    //Теперь уже за правду записали время.
    TempValue :=TempValue-GetTimeInSec-TempTime;  //Тут пытаемся сделать работу подобной проц Stop
    TimerDelay:=GetTimeInSec-TempTime;            //подсчитали потери (погрешность) самого таймера (по идее проц Stop)
   end;
end;
//------------------------------------------------------------------//
procedure TPerformanceTime.Start;
begin
   StartTime:=GetTimeInSec;
end;
//------------------------------------------------------------------//
procedure TPerformanceTime.Stop;
begin
   FDelay:=GetTimeInSec-StartTime-TimerDelay;
end;
end.

Результаты (статистика по 10 запускам программы)
Без сжатия UPX: Время = 0.13 сек.
С сжатием UPX: Время = 0.23 сек.

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

IMHO: Смысла в использовании UPX для программ, чтобы ускорить или уменьшить файл не вижу... Для уменьшения размера при передачи используйте архиваторы и инстоляторы (Inno Setup).
IMHO 2: Использования программ подобных UPX, позволяет затруднить взлом и снятия дампа программы, при ее иследовании скажем в Olly dbg, и то для новичков, опытные же дебагеры просто посмеются.. тот же Olly dbg UPX, распаковывает вроде даже из коробки.

[Padre_Mortius]

Использования программ подобных UPX, позволяет затруднить взлом и снятия дампа программы, при ее иследовании скажем в Olly dbg.

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

[coyot.rush]

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

Откуда такие подробности
Тогда уж лучше ASprotect

Добавлено спустя 10 минут 22 секунды:

Осталось узнать как обойтись без утилиты pwd

Имхо вполне "штатная" утилита Linux

[Сквозняк]

Смысла в использовании UPX для программ, чтобы ускорить или уменьшить файл не вижу... Для уменьшения размера при передачи используйте архиваторы и инстоляторы (Inno Setup).

Как раз для уменьшения веса лазарусных демок смысл есть. Их много, а если пожать, то не так жаба душит. Замедление запуска на несколько миллисекунд никакой роли не играет. Жать можно из локальной менюшки. Архиваторы и инсталляторы в данном случае как "ни пришей к компилятору рукав", мало от них пользы. Если запускать пожатую демку из консоли коммандой ./fyle, то ParamStr(0) выдаст подходящую для запуска прибавку к пути.

Добавлено спустя 8 минут 51 секунду:

Имхо вполне "штатная" утилита Linux

Знаю, но как-то нет уверенности что вдруг какую-то утилиту не заменят на "более прогрессивную" или какому-то дистростроителю вдруг не хватит этих килобайт чтобы впихнуть в 4 гиговый образ что-то "мегапрогрессивное и верное". Постоянно идёт резня чтобы вписаться в некий психологический размер установочного образа. Решил вопрос так

Код: Выделить всё

#!/bin/sh
p=`(echo ${BASH_SOURCE[0]}) 2>&1`
p=${p%%:*}
d=${p%/*}
cd $d
./proga $PWD'/'

Можно кликать мышкой или запускать из консоли или другим скриптом.
Если ParamStr(0)='' то нужно считывать значение ParamStr(1)

[Maxizar]

Сквозняк.. Про вес и сжатие архиваторами и все такое мной было сказано в противовес высказыванию:

Но, допустим, при скачивании вашей программы позволяет сэкономить несколько секунд/минут)))

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

Из за чего я проделал эксперемент, который показывает, что через 10 запусков программы, ваши улучшения перейдут в ухудшения.

- а использовать или нет ЭТО выбор каждого и с этим можно спорить до посинения.
Лично я выгоды не вижу., по этому UPX не использую

Откуда такие подробности

Можно прочитать тут: Введение в крэкинг с нуля, используя OllyDbg

Тогда уж лучше ASprotect

Читаем там же

Как раз для уменьшения веса лазарусных демок смысл есть

Я и не говорю, что в UPX нет смысла. Но просто утверждение, что при сжатии UPX, программа стартует и все такое быстрее, я вас поздравляю.
А если вы используете UPX именно для сохранения пару метров, ну разве кто против.. ради бога. Можите все exe файлы пожать в системе.