daly@ecs.umass.edu (Bryon Daly, ECE dept, UMass, Amherst) (02/02/91)
Hi everyone, Does anyone know the format that the Windows documents (*.txt) are compressed in on the installation disks? I accidentally deleted them earlier during a quest for more disk space, and need them back, but do not wish to install windows again. The docs exist on the disks separately, but are in a semi-compressed form (I assume that's what's wrong with them). Is there a way to get them back to normal text without the entire installation process? (On another occasion, the fileman program got cross-linked, and I wanted to restore that program from the disks, but it was also compressed somehow) *To any Microsoft people out there: In future programs, how about using a standard compression format like .zip or .arc, which would give better compression and avoid problems like mine :-) Thanks, Bryon Daly daly@omega.ecs.umass.edu
waynet@wiffle.techbook.com (Wayne Tilton) (02/04/91)
>Does anyone know the format that the Windows documents (*.txt) are >compressed in on the installation disks? Microsoft provides an (undocumented) expansion utility on the Windows #2 disk that is used to expand the compressed files. It's called EXPAND.EXE and should be copied to your main Windows subdirectory. The format is: EXPAND infile outfile where: infile is the filespec of the compressed file, normally on your A: drive. outifle is the filespec of the resulting uncompressed file. >*To any Microsoft people out there: In future programs, how about using >a standard compression format like .zip or .arc, which would give better >compression and avoid problems like mine :-) Why would they want to do that? They might have to pay ANOTHER COMPANY for using the compression/decompression programs and it might _seriously_ affect thier bottom line ;-) Hope this helps, Wayne
gg2@cunixf.cc.columbia.edu (Guy Gallo) (02/04/91)
Look for a program/utility on disk one called EXPAND.EXE. This is a decompression utility (like Pkunzip), and has a similar syntax: Expand fname x:\dir\destname
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (02/05/91)
In article <12281.27a9a905@ecs.umass.edu> daly@ecs.umass.edu (Bryon Daly, ECE dept, UMass, Amherst) writes: >Does anyone know the format that the Windows documents (*.txt) are compressed >in on the installation disks? I accidentally deleted them earlier during a Doesn't anyone read the menuals anymore? Look up "expand". Or if you trust me...nyuk nyuk nyuk :-) ... "expand a:foo.txt c:" or something like that. The expand utility is probably on the main setup disk. >*To any Microsoft people out there: In future programs, how about using a >standard compression format like .zip or .arc, which would give better >compression and avoid problems like mine :-) The dude who wrote the utilities was hired to write compression/decompression software such that MS wouldn't have to worry about software rights, etc. (just idle conjecture on my part...but he did a good job) >Thanks, >Bryon Daly >daly@omega.ecs.umass.edu -- Co-Op Scum "Bo doesn't know software" - George Brett "The galaxial hearth steams the sea as the sky blood red embrasses darkness" -John Constantine (HellBlazer) Glenn Steffler
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (02/08/91)
In article <cNFTw1w163w@wiffle.techbook.com> waynet@wiffle.techbook.com (Wayne Tilton) writes: >Microsoft provides an (undocumented) expansion utility on the Windows #2 Sorry bub, but the (undocumented) utility is detail both in the manual, and on the accompaning .txt files. I suppose it would be too difficult for people to read the .txt files, even thought the setup program gives to the opportunity. Just goes to show you what running DOS does to a person. :-) ...good explanation of expand deleted for brevity... >>*To any Microsoft people out there: In future programs, how about using >>a standard compression format like .zip or .arc, which would give better >>compression and avoid problems like mine :-) > >Why would they want to do that? They might have to pay ANOTHER COMPANY >for using the compression/decompression programs and it might _seriously_ >affect thier bottom line ;-) If one co-op student can do it for less money, and the same compression, why not?? What the hell is wrong with that? Gads! Can't fathom the idea? Well, I suppose it might look cheap, but let he who hast not picked a quarter from the street cast the first flame. :-) >Hope this helps, > >Wayne -- Co-Op Scum "Bo doesn't know software" - George Brett "The galaxial hearth steams the sea as the sky blood red embrasses darkness" -John Constantine (HellBlazer) Glenn Steffler
bcw@rti.rti.org (Bruce Wright) (02/08/91)
In article <1991Feb7.192957.7986@sunee.waterloo.edu>, gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) writes: > In article <cNFTw1w163w@wiffle.techbook.com> waynet@wiffle.techbook.com (Wayne Tilton) writes: > > ...good explanation of expand deleted for brevity... > >>*To any Microsoft people out there: In future programs, how about using > >>a standard compression format like .zip or .arc, which would give better > >>compression and avoid problems like mine :-) > > > >Why would they want to do that? They might have to pay ANOTHER COMPANY > >for using the compression/decompression programs and it might _seriously_ > >affect thier bottom line ;-) > > If one co-op student can do it for less money, and the same compression, why > not?? What the hell is wrong with that? Gads! Can't fathom the idea? > Well, I suppose it might look cheap, but let he who hast not picked a > quarter from the street cast the first flame. :-) A couple of points about this issue of using .ZIP or .ARC -format files for distributing software: 1) If you distribute just the archive, then the end-user will have to get a copy of PKZIP/PKUNZIP or ARC or one of the other utilities that understand these formats. It's no big deal for people that dial in to a lot of bbs's or who swap a lot of public domain or shareware software (those utilities are pretty universal in that user community), but it's important to realize that the entire microcomputer community isn't like that. Some users don't get things from bbs's at all. Some even have a _policy_ never to use such things - too much of a chance of a virus or a trojan horse. It might be a minor inconvenience for the typical hobbiest or incidental user to deal with a virus, but it could be a major problem in many business environments. Imagine the chagrin of a customer in such a situation finding that the company has to track down a copy of such an archive program in order to install a new piece of software!!! 2) If you distribute both the archive _and_ the unpacking software, you will in all probability have to pay a licensing fee to the company that makes the unpacking software. I don't know what licensing fee would be for such an arrangement (PKZIP asks for a contribution of $25, but presumably in a mass distribution such as described a lower license fee could be negotiated), but you can bet that the author is going to ask for something significantly > $0. If the product is relatively inexpensive, this is going to affect its profit- ability substantially. I don't know exactly what Microsoft sells Windows for (obviously the price they charge to the distributors is a huge discount off the list price), or exactly what their costs are (remember you have to pay for development, support and marketing costs as well as the simple production costs, so their costs must be substantial). I would imagine that their profit margin on Windows itself is paper- thin: it just doesn't sell for all that much. A game can be sold for a lot less with a pretty high profit because it requires less development and support; something as complex as Windows is naturally going to have more overhead. Adding even a small licensing fee to each copy for an archive program is going to add to the overhead and eat into that margin. (NB: This doesn't mean that they don't make a ton of money selling just Windows, never mind the add-ons like WFW and Excel. But when you're talking millions of copies, even a thin margin can add up pretty fast). To me it makes perfect business sense that Microsoft would "roll their own" - either by developing it in-house or by contracting another company to build something like EXPAND. I sort of doubt that they would be able to negotiate a much better deal from the archival software people - after all, that might cut into the archival software market: if a company already has, for example, a PKZIP license from the Windows distribution I doubt they'd be falling over themselves to register it again. So the archival software companies aren't going to want to let a license like that go for a trivial amount of $; since they have a pretty nice niche going already, why screw it up? It would make a BIG difference if the product were expensive and were being marketed by a small company - then there might be a significant advantage to paying the licensing fees (if only a few expensive copies are sold, the licensing fees may well be less than the cost of developing the compression software). I'll agree that in some abstract sense it would be "nice" if everyone could agree on a single compaction format. But unless it gets provided with the operating system I doubt it will happen - there are too many market forces pulling in other directions. Microsoft in the MS-DOS marketplace is hardly the only example of this kind of thing. It's called capitalism. Bruce C. Wright
waynet@wiffle.techbook.com (Wayne Tilton) (02/09/91)
>>Microsoft provides an (undocumented) expansion utility on the... >Sorry bub, but the (undocumented) utility is detail both in the >manual, and on the accompaning .txt files. I suppose it would be too >difficult for people to read the .txt files, even thought the setup >program gives to the opportunity. Just goes to show you what running >DOS does to a person. :-) EXPAND.EXE _is_ documented in the readme.txt file. I stand corrected. As for it being documented in the manual, that is also true. Unfortunately, it's documented in the 'Networks and Windows' section where few, if any, of us who are _NOT ON A NETWORK_, will ever see it! Just try to find any reference to it in the table of contents or the index. Try looking under 'EXPAND' or 'COMPRESS' or 'DISK FILES', or even under 'NETWORKS' for that matter! People might actually RTFM if they thought they could find what they were looking for in it! BTW, running DOS didn't do this to me, using manuals with good indices did. >>Why would they want to do that? They might have to pay ANOTHER >>COMPANY for using the compression/decompression programs and it >>might _seriously_ affect thier bottom line ;-) >If one co-op student can do it for less money, and the same >compression, why not?? What the hell is wrong with that? Gads! >Can't fathom the idea? Same compression? Good plan, bad implementation. Just tested the concept using PKZIP 1.10 on WIN disk #2 with the following results: Total size of uncompressed files: 1883310 = 100.0% Total size of compressed files: 1028092 = 54.6% Total size if individually ZIPped: 888274 = 47.2% Total size if combined ZIP: 886492 = 47.1% But of course, this is all totally irrelevant. The original poster's comment is still valid...why didn't they use a 'standard' compression/decompression program so discussions like this could have been avoided altogether, including my (apparently failed) light hearted attempt at MS bashing?? Wayne
otto@tukki.jyu.fi (Otto J. Makela) (02/10/91)
In article <1991Feb8.041654.16071@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes:
1) If you distribute just the archive, then the end-user will
have to get a copy of PKZIP/PKUNZIP or ARC or one of the other
utilities that understand these formats. [...]
True. A pain in the neck (or lower down) for people who don't have them yet.
2) If you distribute both the archive _and_ the unpacking
software, you will in all probability have to pay a licensing
fee to the company that makes the unpacking software. [...]
There are "free" versions of UnZip available, but for non-commercial use only.
Writing their own unpacker would probably not be a major task, since the format
is specified quite well in the zip application notes.
However, LHARC type sources are widely available with no strings attached.
They could use these with slight modifications, but then they would not be
"standard" anymore...
--
/* * * Otto J. Makela <otto@jyu.fi> * * * * * * * * * * * * * * * * * * */
/* Phone: +358 41 613 847, BBS: +358 41 211 562 (USR HST/V.32, 24h/d) */
/* Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE */
/* * * Computers Rule 01001111 01001011 * * * * * * * * * * * * * * * * */bcw@rti.rti.org (Bruce Wright) (02/10/91)
In article <OTTO.91Feb9182554@tukki.jyu.fi>, otto@tukki.jyu.fi (Otto J. Makela) writes: > In article <1991Feb8.041654.16071@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: > 2) If you distribute both the archive _and_ the unpacking > software, you will in all probability have to pay a licensing > fee to the company that makes the unpacking software. [...] > > There are "free" versions of UnZip available, but for non-commercial use only. > Writing their own unpacker would probably not be a major task, since the > format is specified quite well in the zip application notes. > > However, LHARC type sources are widely available with no strings attached. > They could use these with slight modifications, but then they would not be > "standard" anymore... The main problem with this is ensuring that the sources are _really_ available with no strings attached, or that the format is _totally_ in the public domain. I don't know what the copyright laws are like in Finland, but under US law it would be quite possible that if any of the code in any portion of the product (even the unpacking software) belonged to a different company or individual, it would be quite possible that the _entire product_ would be ruled a derivative work and royalties and/or damages might be assessed. Given the current mixed-up situation in the US regarding computer software copyright and patent law, using code of uncertain provenance is EXTREMELY risky, and not because of the danger of a hidden virus. It's not even certain that you can use a compatible file format for the archive file without running into trouble. IMHO the current situation is rather stupid. But _I_ didn't write the law! Bruce C. Wright
tporczyk@na.excelan.com (Tony Porczyk) (02/12/91)
The News Manager) Nntp-Posting-Host: na Reply-To: tporczyk@na.excelan.com (Tony Porczyk) Organization: Novell, Inc. San Jose, California References: <12281.27a9a905@ecs.umass.edu> <cNFTw1w163w@wiffle.techbook.com> <1991Feb7.192957.7986@sunee.waterloo.edu> <1991Feb8.041654.16071@rti.rti.org> Date: Sun, 10 Feb 1991 19:32:54 GMT In article <1991Feb8.041654.16071@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: ->In article <1991Feb7.192957.7986@sunee.waterloo.edu>, gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) writes: ->> In article <cNFTw1w163w@wiffle.techbook.com> waynet@wiffle.techbook.com (Wayne Tilton) writes: ->> >>*To any Microsoft people out there: In future programs, how about using ->> >>a standard compression format like .zip or .arc, which would give better ->>> [lots of stuff deleted for brevity] ->A couple of points about this issue of using .ZIP or .ARC -format ->files for distributing software: -> 1) If you distribute just the archive, then the end-user will -> have to get a copy of PKZIP/PKUNZIP or ARC or one of the other -> [stuff deleted] -> 2) If you distribute both the archive _and_ the unpacking -> software, you will in all probability have to pay a licensing -> fee to the company that makes the unpacking software. I don't 3) distribute self-extracting archive. The next 2 pages do not apply. Tony
aaron@jessica.stanford.edu (Aaron Wallace) (02/13/91)
In article <sNZ3w1w163w@wiffle.techbook.com> waynet@wiffle.techbook.com (Wayne Tilton) writes: >But of course, this is all totally irrelevant. The original >poster's comment is still valid...why didn't they use a 'standard' >compression/decompression program so discussions like this could >have been avoided altogether, including my (apparently failed) >light hearted attempt at MS bashing?? Could it be that the trouble of porting over the PKZIP code so that it could work in protected mode (Setup, don't forget, has to be able to uncompress files from *within* Windows) would have been about as difficult as writing a new utility from scratch? Note that EXPAND.DLL must be a Windows-compliant program. Or could it be that Microsoft wanted to be nice to developers so that they could rely on users having Expand on their system without worrying about licensing issues with PK-Ware or whomever. This is a silly issue, though, isn't it? I'm kindof glad that I don't have to find umpteen billion scratch disks to make a backup of Windows software; I remember ordering the 31 (or so) 360K disks for Winword 1.0! Never did feel like buying 3 boxes of disks to make a backup... Aaron Wallace
yeates@motcid.UUCP (Tony J Yeates) (02/13/91)
bcw@rti.rti.org (Bruce Wright) writes: > 1) If you distribute just the archive, then the end-user will > have to get a copy of PKZIP/PKUNZIP or ARC or one of the other > utilities that understand these formats. It's no big deal for > people that dial in to a lot of bbs's or who swap a lot of > public domain or shareware software (those utilities are > pretty universal in that user community), but it's important > to realize that the entire microcomputer community isn't like > that. Some users don't get things from bbs's at all. Some I have a number of pieces of shareware software that are 'self-extracting', what an elegant solution! I bought them thro' the US mail too. I also bought Corel Draw (now there's a company that deserve to succeed big time, as well as manuals and large numbers of discount vouchers...they include a video on how to use their software - brilliant!) - their software is also compressed, and it was also self extracting. They used a package which is available as shareware (I forget the name - it was based on the arc format) and I think it has some nominal registration fee ... it was specifically designed so that vendors (as opposed to the casual user) could compress their software if I recall correctly. > 2) If you distribute both the archive _and_ the unpacking > software, you will in all probability have to pay a licensing > fee to the company that makes the unpacking software. I don't > know what licensing fee would be for such an arrangement > (PKZIP asks for a contribution of $25, but presumably in a > mass distribution such as described a lower license fee could > be negotiated), but you can bet that the author is going to > ask for something significantly > $0. See above. (Its got to cost less than the cost of the extra disks required to hold the uncompressed software to be worthwhile). Is that just a one-off fee of $25 for registration, or a per copy fee (seems too high to be the latter). > I don't know exactly what Microsoft > sells Windows for (obviously the price they charge to the > distributors is a huge discount off the list price), or > exactly what their costs are (remember you have to pay for > development, support and marketing costs as well as the simple > production costs, so their costs must be substantial). I would > imagine that their profit margin on Windows itself is paper- > thin: it just doesn't sell for all that much. A game can > is going to add to the overhead and eat into that margin. Ain't that the truth. This is mass production software. Also, if you buy windows, chances are you be investing in other windows software - with a high chance that its produced Microsoft. > But unless it gets >provided with the operating system I doubt it will happen Now there's an idea. How about a rich set of versatile standard utilities that can be chained (forks & pipes?) together, supplied with the PC operating system........sounds like UNIX! It looks like DOS will never "grow up" ..... maybe OS/2 or UNIX will one day be cheap enough that we can forget about DOS, but then again, maybe not! (Perhaps the Free Software people will save the day with UNIX for a 386 PC?!) - Standard disclaimer
bcw@rti.rti.org (Bruce Wright) (02/15/91)
In article <1991Feb10.193254.12810@novell.com>, tporczyk@na.excelan.com (Tony Porczyk) writes: > In article <1991Feb8.041654.16071@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: > ->A couple of points about this issue of using .ZIP or .ARC -format > ->files for distributing software: > -> 1) If you distribute just the archive, then the end-user will > -> have to get a copy of PKZIP/PKUNZIP or ARC or one of the other > -> [stuff deleted] > -> 2) If you distribute both the archive _and_ the unpacking > -> software, you will in all probability have to pay a licensing > -> fee to the company that makes the unpacking software. I don't > > 3) distribute self-extracting archive. > > The next 2 pages do not apply. Except that the original question was about why not use a standard format like pkzip. A self-extracting archive, although useful, is not a standard format in the same sense as a .zip file. Moreover, Windows is already distributed with a compression program, and has a very fancy "self-extracting" script built into it. I'm not sure I see how your proposed solution is significantly different in its effect from the current situation (granted that there is perhaps a _minor_ difference in implementation, depending on how you define the words "self-extracting archive"). Remember that if you do a simple-minded decompression of _all_ the Windows drivers and fonts whether the target PC has the required hardware or not, you will end up needing a _lot_ more disk space to store all that extra stuff on. So you're likely to want to put some intelligence into the extract code - not unlike the way it is now. Bruce C. Wright
tneff@bfmny0.BFM.COM (Tom Neff) (02/15/91)
Remember that several standard compressed archive systems, including ZIP and ZOO, can _already_ build self-extracting .EXE files. These .EXE's can be run for simple self-extraction, or manipulated like any other archive if you already have the ZOO/ZIP tools.