File Compress/Expand

a rather basic query: files on install disks etc are often in compressed format, *.EX_ for example; what was used to compress them in the first place, please?

I must have been expanding them for years now without the faintest idea of the answer to this... {!}

Good Luck, Hugh

 

Hi Hugh Jarss
I just don't want your post to get lost in the shuffle without a response.
Can you explain what you mean by your files get compressed? You're not talking about the file names themselves being truncated?

Daizy

 

Hi Daizy

the files that I meant are like on the Windows CD or wih a printer for example - they're often supplied "squashed" to save space (& install faster!)(sometimes)

I use PKZip usually if I want to compress something for myself, but there's lots of other programs around - PKZip usually makes a *.ZIP file which you'd Unzip to get back the original.... but there are lots of other types as well, things like LZH and ARC - & I think many, many more...

The files that I'm most interested in are the ones with extensions ending with an underscore, there are tons of them
DOS had a program EXPAND.EXE and W98 has something remarkably similar which do the conversion

C:>EXPAND EPSON9.DR_ EPSON.DRV

sort of thing, to expand the DR_ into the real driver file as used by Windows...

so, my very basic question, as yet unanswered {!} is, what program was used to perform this compression in the first place.. which leads on to:
?Which, if any, of the readily available compress/expand packages are compatible with this format?

Can it be I've got them all this time, because it's too simple?

ummm, what is this "shuffle" of which you speak, please?

Very Best Wishes, Hugh


A Crash A Day Keeps Sanity At Bay

 

There's no single system that you can use to decode the wide variety of OEM software that you will encounter. They use a variety of methods for compression and the means of expanding is included in the executable installation file. That's nice since it doesn't rely on you to have a certain software in order to decode their software.

Unless you are capable of decompiling the installation code, you cannot possibly know what compression algorithm was used for any particular software compression. Rest assured, it isn't anything you would have on your drive normally. There are literally many hundreds of ways that can be chosen.

The subject matter of file compression is very boring and only a true egg-head would find it interesting.

There are basically two method, lossy and lossless. lossy is used primarily for image files while lossless is needed for data compression where preservation of the original must be exact.

If you are still awake, take a look at the following links and you'll likely lose interest in the subject right away.

http://www.howstuffworks.com/file-compression.htm

http://dmoz.org/Computers/Algorithms/Compression/

Best regards.

 

Very well said Zephyr! In a billion years, I'd not have been able to explain it as eloquently as you just have. Thank you.


Lost in the shuffle = your post being pushed down the lsit and accidently forgotten about.

Daizy

 

Dear All,

call me an egg-head if you wish, but at the moment I find the subject of file compression extremely interesting indeed...

the particular form that I'm interested in is that used *by Microsoft* to decompress a 'new driver' package, under instruction of an INF file. I wish to perform the reverse task, compressing the file that I know I need to end up with, sort of thing -

if I can ever find out the answer to this, I will be able to make myself a floppy and never have to worry about my modem again. It would be a more pleasing solution to patching the older files in manually...

Best Wishes, Hugh

 

...further to previous, I've found

EXTRACT.EXE (in \WINDOWS\COMMAND among others)
EXTRAC32.EXE (in \WINDOWS)

...but I am still no closer to the answer to my query!

Best Wishes, Hugh

 

Software producers really don't want you to know how they have chosen to do that. That's why they use so many different methods. Their methods are intentionally obscure and used as a method of protecting their proprietary interests. They frown on anyone who attempts to reverse compile their software, which is what you are asking to do.

BTW, I didn't mean to imply that Egg-Head is in any way a derogitory term, quite the contrary, I admire anyone with such determination.

Good luck on your quest! I suspect you'll end up having to learn programming to crack this puzzle.

Best regards.

Daizy, Thanks for your kind words.

 

Hi Zephyr, Daizy and all...

well I scrabbled around a bit more without really getting anywhere [although did discover that DOS 6.22 EXPAND.EXE works fine on *some* of the compressed files - checked by doing FC /B to compare them with what they should end up as - but not on others][and seems no way of predicting which ones will play ball]so decided in the end just to make a floppy with the files that I needed and put a readme onto it as well - 'coz will almost certainly have forgotten it all by the time I need it! - at least I *hope* to have forgotten it by then, am not in a hurry to go through all that hassle again.

when I reinstalled everything, the (PCI) modem went in as COM5 (on the previous it had been COM2); not complaining, as a side effect is that we go a bit faster than we used to, used to get 42k667 on a good day, 33k6 otherwise... now we usually get 49k333 and I've even seen 50k667 - which made my eyeballs bulge a bit (or was it the coffee?)

oh dear - I _really_ don't want to get a name for reverse engineering software - but heck these INF files are only text files, not really that much worse than good old INI files. The only code I've ever taken to pieces was the start (only about the first 60 bytes - and that much was sheer hell! - it's cool until you start to hit jump instructions) of the monitor ROM for a 6800 development kit we had - and that was only because someone had lost the documentation! (oops) - even then, only took it on 'coz it was so similar to the 6809, for which I'd been writing machine code for 3 years back in the 1980's - the stacking order etc. is v. similar - I've never even tried for the IAPX86 family [and don't want to]. I *am* trying to learn programming though - well VB that is - really cannot get my head around these new-fangled object orientated languages - prefer procedural for my purposes, use C (yup, glutton for punishment here) - it's a real shame they've obsoleted the 6809. The biggest ROM we could blow was a 2716 (really). But 2KB went a long way in those days... {I only really stuck that bit in to explain why I tend to go for the low-level approach, happier if I can stick a 'scope on it, sort of thing... the more zappy the software the more it obscures things}

a big thankyou to all for taking an interest / helping etc etc... current hassles concern Direct Cable Connection which is a different thread altogether, I should b** well be able to suss this as I'm an Electronics Engineer, but... probably missing something dead simple somewhere [although cross eyed from checking - or perhaps it might be the coffee - dear Daizy, we have it by the pint here! - don't have to go down to the kitchen so often]

Very Best Wishes, Hugh.

 

Well that's just lovely Hugh!
You have it by the pint..and I drink it by the gallon!

Daizy

 

Yo Daizy, 'tis nearly 6AM here & I'm trying to catch up on the coffee front (tho' still a way to go, that's only the 5th pint) - you any good on Direct Cable Connections? noone's posted anything yet, I've tried it every which way I can think of without success...
May all your tomorrows be better than yesterdays, Hugh.