Hi there,

    Is there a way to "compress" the exe on xBase? I have programs that on
clipper they used to have 2/3Mb and now they are close to 12mb..

Well thanks for you attention.

[]s
Marcelo

Marcelo,

>     Is there a way to "compress" the exe on xBase? I have programs that on
> clipper they used to have 2/3Mb and now they are close to 12mb..

Yes, there are programs such as Shrinker at www.blinkinc.com . I think 
another is called Aspack.  But these program come with a downside. If 
you run multiple copies of the exe on the same machine, it could 
actually use more memory, since the dlls don't get shared in this case 
(normally they do).

If you are wanting to compress the exes for distribution purposes, then 
I suggest DeltaPatch (also at www.blinkink.com).  This allows you to 
send just a patch containing the difference of the two files.  I've used 
DeltaPatch for years and love it, I've never had any problems wih it.

Hope that helps,
-Brent

Alright I'll keep that in mind Brent, thx a lot!


"Brent Dubs" <bdubs@vanityshops.com> wrote in message
news:MzJGjbYKFHA.3576@S15147418...
> Marcelo,
>
> >     Is there a way to "compress" the exe on xBase? I have programs that
on
> > clipper they used to have 2/3Mb and now they are close to 12mb..
>
> Yes, there are programs such as Shrinker at www.blinkinc.com . I think
> another is called Aspack.  But these program come with a downside. If
> you run multiple copies of the exe on the same machine, it could
> actually use more memory, since the dlls don't get shared in this case
> (normally they do).
>
> If you are wanting to compress the exes for distribution purposes, then
> I suggest DeltaPatch (also at www.blinkink.com).  This allows you to
> send just a patch containing the difference of the two files.  I've used
> DeltaPatch for years and love it, I've never had any problems wih it.
>
> Hope that helps,
> -Brent
>

Hi Brent

How has been the performance with Deltapatch ? I have been a happy user of
Blinker all these years.
Though had a bad patch since we upgraded to Blinker 7.x, still trying to get
the issue resolved.

However, with our EXE size too increasing of lately, would like to ship in
the form of a patch like Deltapatch.
If you could share your experience further re: its feature, it would help me
a lot.

Its just a patcher or got a built-in setup creator too ?

Thanks

Anand

"Brent Dubs" <bdubs@vanityshops.com> wrote in message
news:MzJGjbYKFHA.3576@S15147418...
> Marcelo,
>
> >     Is there a way to "compress" the exe on xBase? I have programs that
on
> > clipper they used to have 2/3Mb and now they are close to 12mb..
>
> Yes, there are programs such as Shrinker at www.blinkinc.com . I think
> another is called Aspack.  But these program come with a downside. If
> you run multiple copies of the exe on the same machine, it could
> actually use more memory, since the dlls don't get shared in this case
> (normally they do).
>
> If you are wanting to compress the exes for distribution purposes, then
> I suggest DeltaPatch (also at www.blinkink.com).  This allows you to
> send just a patch containing the difference of the two files.  I've used
> DeltaPatch for years and love it, I've never had any problems wih it.
>
> Hope that helps,
> -Brent
>

Anand,

> How has been the performance with Deltapatch ?

I haven't had any real problems using DeltaPatch at all. The only 
problems I've had sending a patch to any of our store sites, has been 
related to dial-up file transfers errors. But that wasn't DeltaPatch's 
fault, it was the phone lines. So I actually can't remember any 
DeltaPatch problems. I've been using it for about 5 years now.

Here is the process I use for creating a patch:

1. Create two directory stuctures similar to the structures you want to 
change: For example, If I want to patch the exe called MyApp.exe in the 
directory called APPS, and I want to add a file called NAME.DBF to a 
directory called DATA.  On my computer I create 2 sets of directories.

new---APPS
     |
     --DATA

old---APPS
     |
     --DATA

2. Since I want to alter (patch) the already existing file MyApp.exe, I 
put a copy of the MyApp.exe that the site already has on their computer 
in the APPS sub-directory of the "old" directory.  I put the new copy of 
the MyApp.exe in the APPS sub-directory of the "new" directory. Since 
I'm adding a new file NAMES.DBF to the data directory, I put the file 
only in the DATA sub-directory of the "new" directory, and nothing in 
the old.

3. The DeltaPatch wizard asks me to point to the "old" directory and the 
"new" directory. Then it compares the two.  It sees that both 
directories have a MyApp.exe, so it records only the differences between 
the two files, and it sees that there is a NAMES.DBF in just the "new" 
directory, so it records all of that file (but compresses it).

4. I send the file to the site.

5. I then have a program that I wrote that automatically sees the patch 
file and runs the DeltaPatch command line program to apply the patch 
without any interaction from the users.

So it's quite simple really.  I believe that DeltaPatch also has an 
user-friendly patching program that the end users can use to apply the 
patch. I just perfered to make my own that didn't require any interaction.

Over the years I've sent hundreds of patches, each to hundreds of sites, 
and it's worked flawlessly for me.

-Brent

Thanks very much Brent for the info.

Will checkout DeltaPatch eval edition.

Anand

"Brent Dubs" <bdubs@vanityshops.com> wrote in message
news:zntjfwwKFHA.3104@S15147418...
> Anand,
>
> > How has been the performance with Deltapatch ?
>
> I haven't had any real problems using DeltaPatch at all. The only
> problems I've had sending a patch to any of our store sites, has been
> related to dial-up file transfers errors. But that wasn't DeltaPatch's
> fault, it was the phone lines. So I actually can't remember any
> DeltaPatch problems. I've been using it for about 5 years now.
>
> Here is the process I use for creating a patch:
>
> 1. Create two directory stuctures similar to the structures you want to
> change: For example, If I want to patch the exe called MyApp.exe in the
> directory called APPS, and I want to add a file called NAME.DBF to a
> directory called DATA.  On my computer I create 2 sets of directories.
>
> new---APPS
>      |
>      --DATA
>
> old---APPS
<snip>

Anand Gupta wrote:

> How has been the performance with Deltapatch ? I have been a happy user of
> Blinker all these years.

Two years ago, I have tested about 10 different patch creation tools... 

DeltaPatch was the fastest of all of them. For example, a patch creation
run that took one minute with DeltaPatch, took over half an hour with other
tools.

Some where more flexible and had a lot of additional features like
configurable GUI for the patch applying program, but none of them could
beat the performance of DeltaPatch.

One thing that is missing is the ability to use the whole functionality of
the patch creation GUI in the command line version. There are a lot of
optional setting in the GUI tool that are not reflected in the script
language which can be used to create patches "on the fly" without user
interaction.

Thomas

Thanks Thomas for the feedback.

Unable to download the demo/eval copy yet. Should be doing it very soon now.
Does the 'resultant' patch it (deltapatch) creates is just a binary or has
option to be created with some setup wizard kindda thing too?

Anand

"Thomas Braun" <nospam@software-braun.de> wrote in message
news:171ku64zt08z3$.1f8alupzzvtef.dlg@40tude.net...
> Anand Gupta wrote:
>
> > How has been the performance with Deltapatch ? I have been a happy user
of
> > Blinker all these years.
>
> Two years ago, I have tested about 10 different patch creation tools...
>
> DeltaPatch was the fastest of all of them. For example, a patch creation
> run that took one minute with DeltaPatch, took over half an hour with
other
> tools.
>
> Some where more flexible and had a lot of additional features like
> configurable GUI for the patch applying program, but none of them could
> beat the performance of DeltaPatch.
>
> One thing that is missing is the ability to use the whole functionality of
> the patch creation GUI in the command line version. There are a lot of
> optional setting in the GUI tool that are not reflected in the script
> language which can be used to create patches "on the fly" without user
> interaction.
>
> Thomas

Anand Gupta wrote:

> Unable to download the demo/eval copy yet. Should be doing it very soon now.
> Does the 'resultant' patch it (deltapatch) creates is just a binary or has
> option to be created with some setup wizard kindda thing too?


The patch creation process can be done with a wizard (GUI) or a script
language and a command line tool.

The resulting patch can be a binary patch file which has to be applied with
a command line tool, or a exe file with the applying tool and the binary
patch data in one.

Deltapatch has go no GUI interface for the patch apply part of the program,
only command line / CRT...

I used to distribute the patch exe with Inno Setup.

Thomas Braun

Marcelo,

>     Is there a way to "compress" the exe on xBase? I have programs that on
> clipper they used to have 2/3Mb and now they are close to 12mb..
> 
> Well thanks for you attention.

You can, but there is no gain because they will still occupy the same
amount of memory.  In addition, if the application is run multiple times,
each instance will totally occupy it's own area of memory.

An uncompressed Xbase++ application (or any other application for that
matter) doesn't load a second copy, but instead uses the same instance of
code.  What it does do is create it's own data area in memory for heap,
stack etc.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

It was the best of lines, it was the worst of lines...

Great, thx for the advice Phil!


"Phil Ide" <phil@idep.org.uk> wrote in message
news:ifqhhx9wzcgi$.dlg@idep.org.uk...
> Marcelo,
>
> >     Is there a way to "compress" the exe on xBase? I have programs that
on
> > clipper they used to have 2/3Mb and now they are close to 12mb..
> >
> > Well thanks for you attention.
>
> You can, but there is no gain because they will still occupy the same
> amount of memory.  In addition, if the application is run multiple times,
> each instance will totally occupy it's own area of memory.
>
> An uncompressed Xbase++ application (or any other application for that
> matter) doesn't load a second copy, but instead uses the same instance of
> code.  What it does do is create it's own data area in memory for heap,
> stack etc.
>
> Regards,
> -- 
> Phil Ide
>
> ***************************************
> * Xbase++ FAQ, Libraries and Sources: *
> * goto: http://www.idep.org.uk/xbase  *
> ***************************************
>
> It was the best of lines, it was the worst of lines...

Hello Phil,

"Phil Ide" <phil@idep.org.uk> wrote in message 
news:ifqhhx9wzcgi$.dlg@idep.org.uk...
> Marcelo,
>
>>     Is there a way to "compress" the exe on xBase? I have programs that 
>> on
>> clipper they used to have 2/3Mb and now they are close to 12mb..
>>
>> Well thanks for you attention.
>
> You can, but there is no gain because they will still occupy the same
> amount of memory.  In addition, if the application is run multiple times,
> each instance will totally occupy it's own area of memory.

It's even worse. An uncompressed exe will require less physical memory than 
a
compressed one. That's because physical memory is only allocated on demand.
If you don't use some pages in your exe, no physical memory is allocated.
But creating the executable from a compressed file will allocate memory.

>
> An uncompressed Xbase++ application (or any other application for that
> matter) doesn't load a second copy, but instead uses the same instance of
> code.  What it does do is create it's own data area in memory for heap,
> stack etc.

Things are a little different. The processes will back parts of their adress 
space
with the same file, the executable. Because of Windows' memory management
this results in sharing the same physcial memory between processes.

Of course, if changes must be applied to the code in memory when the process
is started by the loader (e.g. address changes), pages affected by such 
changes
cannot be shared (they will be backed by the paging file). That's why it's a 
good
idea to "base" and "bind" your programs and dlls. It speeds up loading and 
puts
a lower burden on your physical memory and your paging file.

Best regards,

Michael.

I use UPX.EXE to compress .EXE, .DLL etc.

I have a EXE with 6,548,480 bytes and UPX.EXE it compressed it to 476,160 
bytes

Nolberto Paulino
Un cordial saludo

"Michael Hoffmann" <m.hoffmann AT compar.cc> escribi en el mensaje 
news:CWrpIhtKFHA.3104@S15147418...
> Hello Phil,
>
> "Phil Ide" <phil@idep.org.uk> wrote in message
> news:ifqhhx9wzcgi$.dlg@idep.org.uk...
>> Marcelo,
>>
>>>     Is there a way to "compress" the exe on xBase? I have programs that
>>> on
>>> clipper they used to have 2/3Mb and now they are close to 12mb..
>>>
>>> Well thanks for you attention.
>>
>> You can, but there is no gain because they will still occupy the same
>> amount of memory.  In addition, if the application is run multiple times,
>> each instance will totally occupy it's own area of memory.
>
> It's even worse. An uncompressed exe will require less physical memory 
> than
> a
> compressed one. That's because physical memory is only allocated on 
> demand.
> If you don't use some pages in your exe, no physical memory is allocated.
> But creating the executable from a compressed file will allocate memory.
>
>>
>> An uncompressed Xbase++ application (or any other application for that
>> matter) doesn't load a second copy, but instead uses the same instance of
>> code.  What it does do is create it's own data area in memory for heap,
>> stack etc.
>
> Things are a little different. The processes will back parts of their 
> adress
> space
> with the same file, the executable. Because of Windows' memory management
> this results in sharing the same physcial memory between processes.
>
> Of course, if changes must be applied to the code in memory when the 
> process
> is started by the loader (e.g. address changes), pages affected by such
> changes
> cannot be shared (they will be backed by the paging file). That's why it's 
> a
> good
> idea to "base" and "bind" your programs and dlls. It speeds up loading and
> puts
> a lower burden on your physical memory and your paging file.
>
> Best regards,
>
> Michael.
>
> 

Nolberto Paulino wrote:

> I use UPX.EXE to compress .EXE, .DLL etc.
> 
> I have a EXE with 6,548,480 bytes and UPX.EXE it compressed it to 476,160 
> bytes

Hi Nolberto, 

please don't post unneeded binaries here - in case of UPX, just post the
location where someone can find them (upx.sourceforge.net) - this way you
are not forcing hundreds of people downloading 130 kb of data and putting
load on the Alaska server... there always is someone who has to pay for
the traffic...

In addition, Michael just explained why it is not a good idea to use exe
packers in windows, so even if the exe gets compressed by upx to 1/14th of
its size, at runtime it is still the same problems...

If you need compress the exe for distribution - I think it is a better idea
to use a conventional compression program like Winzip/Stuffit/Winrar or the
like or a installer like Innosetup than a exe packer...

just my few euro cents
Thomas

Marcelo,

I felt the same way initially about the exe growth from clipper to Xbase++. 
However, when taking into account the increases in memory (Ram/Disk), Mhz, 
and bandwidth in the period between Clipper and Xbase++, I concluded that 
this is a non-issue.

Rodd


"Marcelo Ramos" <mramos@caisoftdesign.ca> wrote in message 
news:7fuyjIYKFHA.1256@S15147418...
> Hi there,
>
>    Is there a way to "compress" the exe on xBase? I have programs that on
> clipper they used to have 2/3Mb and now they are close to 12mb..
>
> Well thanks for you attention.
>
> []s
> Marcelo
>
>