Charles Ashford's COMPRESS

[comp1]

Hi everybody,

I've attached an old arithmetic coder named "COMPRESS" by Charles Ashford. This program did great things for its time with extremely low resource requirements. It was very, very slow as well but achieved the best compression ratio.

I've attached the source code. Could someone make a 32-bit/NT compile of the two programs (compress.c and expand.c) into 2 EXE files for me?

I have a new Win7 64-bit test machine and I only have 16-bit compiles of the program so they don't run on 64-bit OS's.

Thanks guys and enjoy the historical wonder for those of you who don't have it

[biject.bwts]

I did a quick look at it had to add an include to string.h and replaced movmem with memmove dropped the occurances of far. It compliled with out errors but did not run. so not sure what the "far" or "movmem" did and replaced farmalloc with malloc. But in the end it did not run.

[comp1]

Thank you for trying. Can anybody else get it to work?

[biject.bwts]

Actaully gave it more thought got it to work compressing test.c order 2 the memmove movmem function need a little more changing not sure if it what you want but here it is

[comp1]

Actaully gave it more thought got it to work compressing test.c order 2 the memmove movmem function need a little more changing not sure if it what you want but here it is

I will test it when I get home.Thank you.

[biject.bwts]

Use at your own risk I did not take a major look at code. But
book1 768,771 compress to and back to same file
order length

0 439,714
1 439,714 looks like order 0 and 1 treated the same
2 295,216
3 271,666
4 271,285 looks best at order 4
5 277,145
6 281,815

*** tried order 10 but it crashed so becareful ***
so more work may be needed to bring it up to snuff.

[comp1]

Hmm well I never found any documentation that explains or specifies the allowed range. I will try to run it this evening and report back.

[comp1]

Use at your own risk I did not take a major look at code. But
book1 768,771 compress to and back to same file
order length

0 439,714
1 439,714 looks like order 0 and 1 treated the same
2 295,216
3 271,666
4 271,285 looks best at order 4
5 277,145
6 281,815

*** tried order 10 but it crashed so becareful ***
so more work may be needed to bring it up to snuff.

I tried to run it and I get that it is not a valid Win32 application. I am trying to run it first on XP SP3 32-bit before running on Win7.

Is it possible to make it run on XP SP3 32-bit?

[biject.bwts]

I compiled it for 64 bit code. Sure you can compile it the source code is there it will likely compile for 32 bit code I think the changes I made would work for 32 bit as well as 64 bit. I only included the 64 bit since you claimed you have a 64 bit machine.
If you need a free compiler MinGW is free and that is what I used.

[comp1]

Thanks biject.bwts

But would anyone else be able to help me compile a 32-bit version? I did mention that this will be tested on a Win7 64-bit but also on an older XP 32-bit system. A 32-bit version would therefore work on either machine no problem.

I do not know anything about programming or compiling, this is why I'm asking for assistance. Any help would be greatly appreciated.

Thanks.

[biject.bwts]

Ok here is the 32 bit version. But the code crashes for some inputs I checked this on one case of book1 got same result as the 64 bit version. But if you don't know how to program or compile what is the point. Learn to do it on your own. You can get free stuff on net for MinGW stuff

[comp1]

Ok here is the 32 bit version. But the code crashes for some inputs I checked this on one case of book1 got same result as the 64 bit version. But if you don't know how to program or compile what is the point. Learn to do it on your own. You can get free stuff on net for MinGW stuff

I appreciate your help and your suggestion

What is most important about compiling to me is being able to compile some 16-bit DOS code into 32-bit (or 64-bit) windows executable code.

Again, thanks for your help and your patience.

[nburns]

There would be at least two different 32-bit endpoints, because there are likely to be limits built in that assume a small memory: compile as a Win32 exe, but retain the exact same 16-bit behavior; or, be partially rewritten to become the 32-bit software it would have been if it had been written for 32-bit from the start. Doing the full conversion can be difficult for code you didn't write yourself. Especially for compression code, because compression code works at the bit level and tends to use hardware-level optimizations. The first endpoint would be easiest to do, but 16 bits was small.

It's been a while since I've seen near and far pointers.