Slashdot Log In
Examples of Obsolete File Formats?
Posted by
Cliff
on Tue Aug 30, 2005 05:55 PM
from the w/-humans-it's-memory-w/-machines-it's-data-files dept.
from the w/-humans-it's-memory-w/-machines-it's-data-files dept.
reedk writes "I was having a discussion with my boss about long-term archives, and we got on the topic of older files becoming un-readable by newer versions of software. Not only are those old Ami pro files unreadable by today's common word processors, but I have heard that newer version of Office can't consistently open very old versions of Office documents. With the increasing retention periods being forced by current and coming regulations, this could become a problem of compliance in the future. We want to pursue this topic, but to build support for it internally, I am looking for examples of older file formats that are no longer readable by newer version of the same software or due to the market death of the product. If true, this would lend a lot of force behind moving to products that have an open file format. Can Slashdot readers come up with examples of this, or ways they have had to get around these kinds of problems?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Print to/create PDF? (Score:2)
.. but not for all kinds of data (Score:2)
Re:Print to/create PDF? (Score:2)
pdf is good but make certain you have an older reader, old os and old machine to run it on.
you could always encode it with alphabits as well. just glue to 8 1/2 by 11 paper and you're set.
Re:Print to/create PDF? (Score:2)
Three Magic Words... (Score:2)
Dee....
Eff....
Re:Three Magic Words... (Score:2)
Plain text is the MOST standard, but doesn't really handle modern needs (embedded images, tables, etc.)
HTML may be a little better, because formatting isn't as important as content. Of course if your source is MS Word, the HTML generated is HORRIBLE.
I think the bottom line is that there really isn't a good format that easily handles complex documents. Theoretically, XML w/ SVG should work, bu
Re:Three Magic Words... (Score:2)
Given that the tax forms I download every year, I consider that a blessing.
It's also nice that it's easy to convert documents such as manuals over to PDF. This is quite handy when buying second hand stuff. Okay, you can't edit a PDF (though you CAN fill out a form in PDF and save the options you've filled in. Again, PDF is a blessing for tax forms.) but there's still plenty of reason for it to hang around for quite a while.
Necessary. (Score:3, Informative)
example (Score:3, Informative)
For that matter, is there anything that can read VisiCalc files?
Flame ON!
Re:example (Score:2)
Perhaps it wasn't carefully saved after all...
Re:example (Score:2, Informative)
Open up the standards (Score:3, Interesting)
Also, if you know what the end result data is supposed to look like, would it be possible to start "decompiling" it? Works with binary executables (sometimes)...
Simple (Score:2, Insightful)
* RTF (quite universal)
* PDF (somewhat universal, will always have the same formatting)
* Plaintext (never becomes unreadable unless the file's character set ceases to exist somehow)
EBCDIC and dead voters (Score:3, Interesting)
To start, they used open records requests to get the details of people who recently voted, and details of those who recently died.
The goal was to find people who continued to vote after they died, which may sound funny, but is still happening [citypaper.com].
The data the government data gave us was on magnetic reels. The data on the reels was stored in a fixed-width EBCDIC format [dynamoo.com]. Talk about a dead format!
It turned out the local college still had a working magnetic reel reader, and was able to help me get the data out of EBCDIC into ASCII, but the project was cancelled anyway.
Re:EBCDIC and dead voters (Score:3, Informative)
The physical media might be near death, but I work on modern C++ code that reads and writes fixed block EBCDIC files.
Re:EBCDIC and dead voters (Score:2)
Re:EBCDIC and dead voters (Score:3, Interesting)
Wordstar 3.3 (Score:2)
Engineering + smaller programs. (Score:2)
Note... (Score:3, Insightful)
Well, yes and no. Let's say Ami Pro file format were fully documented. (I have no idea whether it is or isn't.) At what point would it be worthwhile for your company to actually write a file converter? I can certainly imagine a situation where it might be a cost-effective thing to do, but it's not the kind of thing that anyplace I've ever worked does routinely.
And from a retention point of view, I don't know if you _want_ whatever scumbag lawyer is subpoenaeing documents from you to be able to demand that you write him a converter. I'd rather be able to say "Here are our VisiCalc files. Enjoy!"
You wouldn't. (Score:2)
http://www.w3.org/Tools/Word_proc_filters.html [w3.org]
Remember, YOU want to know what you're sending to the lawyer BEFORE he does. Being surprised in Court is not a good thing.
I can still use an old DOS program (Score:2)
Whenever possible, I convert those to plain text- and store them on CDs.
DARPA requirements to solve this (Score:3, Informative)
I've had some wierd ones (Score:5, Funny)
It was, frankly, awful. Someone had clearly designed it as some kind of "One size fits all" type thing, except that as it was text based it didn't really work that well. Typically graphics, for example, had to be represented by a block that contained a filename: yep, graphics, sound, anything more complicated than a word or a number had to be put in a separate file. Neither my collegues nor I could understand why anyone would try to put so much effort into making it look hierarchical and extensible, and then not include support for data that isn't well represented as text. Hell, most of the files on our PCs can't easily be represented efficiently or usefully as text.
It was also remarkably inefficient. To give you some idea, when we converted it into plain text files in a more efficient form, the files were typically 60-70% smaller. I've always found gzip a good indicator of the efficiency of a file format - usually, plain text compresses to about 30% of the original size. In this case, it was frequently 10%.
Absolutely horrible format. I hope I never have to work with it again.
RFC 2397 (Score:2, Insightful)
I don't understand where you're going there unless the spec allows embeded raster images?
It's straightforward to make an <img /> or <object /> element that contains raster image data. Look up the data: URL scheme [faqs.org].
Re:I've had some wierd ones (Score:2)
It's horrendously inefficient. Saying "Yeah, you can in
how about codecs? (Score:3, Interesting)
Re:how about codecs? - BINGO (Score:2)
Consider the old Motion Pixels MovieCD codec. By today's standards the codec isn't much, and yes, if you happen to own any of the old MovieCDs you would be better served just buying the DVD of the movie.
However, precisely because the MovieCD format was killed deader than hell by the DVD, Motion Pixels went out of business, and the codec source, if it even still exists, is probably in some bankruptcy liquidator's sock drawer - I d
Some thoughts about it (Score:3, Interesting)
For images, I would look at the past to see what file formats were around before the internet was mainstream, circa 1995. I remember Paintbrush PCX as a file format, but haven't since a file in that format since then. TGAs and TIFFs were around and still are today, that might be one possibility. You also have SVG formats, and that being an XML file format, allows you to convert it to another format in the future.
As for text documents, one definite possibility is XML. You can convert to many other formats from XML (HTML, PDF, RTF, etc.) Another possibility is RTF and plain text, though you might lose some of the more advance features. You might even have to extend the XML to deal with anything special in your files. Latex or Tex might be another solution since it's still around, though I have no experience with it, beyond being awware of them.
I would also recommend keeping a copy of the original software you used at the time, in case you need to get access to the files with a program that actually created. This way, you still have some sort of access. If that means you need to keep a copy of the original O/S as well, so be it.
I happen to have a computer museum at my disposal (Score:5, Interesting)
A professor at the university where I work turned up with his original doctoral thesis from 1989 on disk. 3" disk, to be exact - the format that famously lost out to the ubiquitous 3.5" disk. He had written it on the Amstrad PCW 8256, a weird British CP/M machine from the mid 80s. No matter, I have several of these rotting in my loft!
But they don't boot. At this point you brace yourself for the long haul. The drive belts used to perish on those models, but look! There are loads of drive belts in the Maplin Electronics catalogue. You just need to order the right size.
No problem! You carefully dismantle the drive and dig out the belt. You broke it? No problem! Just makes it easier to measure. You can only measure the circumference, whereas Maplin only quotes the diameter? No problem! You are about to use Pi for the first and last time in your entire life! Order one that's slightly too big, and one that's slightly too small, just to feel safe.
When the belt arrives, you fit it. You carefully re-assemble the drive. You insert that CP/M boot disk that you carefully prepared in 1987, the one with the custom PROFILE.SUB that copies important utilities to RAMDISK. You power up and it boots! You feel young again.
Now your try your Locoscript boot disk - remember, Locoscript did not run under CP/M - it was an entire little operating system unto itself. It works, and when you swap disks (f7) you can read the Prof's work! It's yesterday once more! Shoo-bee-doo-lang-lang!
At this point I got lucky - I had the LOCOLINK package including the special Amstrad Bus PC parallel port link cable, so I was able to go Locosript PCW -> Locoscript PC -> Wordstar 3.3 -> Wordperfect 5.1 -> Winword. Those nice chaps at Ansible could have shortened that trip by a step or two.
In the absence of the proprietary LOCOLINK cable I could also have gone Locoscript 1 PCW -> Locoscript 2 PCW -> ASCII on PCW -> ASCII on PC via Kermit -> Winword. But I'd have lost all his bolds and underlines.
Now I got a fine bottle of Metaxa Greek Brandy out of this exchange, so I'm not exactly complaining. But I was shocked to realise that his files were younger than my eldest child, and she's got two years of school ahead of her.
In the absence of any credible international initiative to create a reliable permanent archive format, I'd say print it to acid-free paper, multiple copies in separate places, and hope for the best, like Cassiodorus.
Re:I happen to have a computer museum at my dispos (Score:3, Insightful)
I'd guess that CD-R is here to stay, given that it shows 0 signs of becoming unsupported on newly manufactured HW.
20 years ago, you could have said the same thing about a 3.5" floppy. When the iMac first came out in, what, 98, it was widely denigrated for not having a floppy. It's now getting increasingly harder to get floppy drives on PCs, and I wouldn't be surprised at all if they were special-order in another 5 years. In 10 years, your .sig file will be larger than the contents of a 1.4 MB floppy, s
Well duh... (Score:3, Funny)
Obsolete files from Kazaa (Score:2, Funny)
Maybe I should start using Windows?
Can you say, "Upward Compatibility"? (Score:2)
Modern code developers seemingly have no concept of upward compatibility. More's the pity.
Re:Can you say, "Upward Compatibility"? (Score:2)
Sorta like "upload" and "download." It would seem logical to "download" from one's own machine to the taget machine, and vice-versa, but that ain't how the nomenclature works.
reStructured Plaintext (Score:5, Interesting)
This system has worked superlatively. In addition to creating a documentation solution that will forevermore be accessible without special software, our authors can focus entirely on content without concern for layout and visual appearance, our customers get a reasonably open file format (PDF) that looks as good on-screen as it does in print. It's win-win all around, by my reckoning.
Hardware issues too (Score:2)
I used to work at a major corporation (you very likely own something made by them) who had a requirement to keep archives of their older engineering documents. The fire-safe was loaded with various tapes ranging back to many dozens of old open-reel tapes.
Of course, they hadn't had the (monstrous) tape drives to actually read these tapes for many years. I have no idea what they thought they were keeping them for.
What about the backup media formats? (Score:2, Informative)
Assuming that you've got some hardware that can physically read whatever it is, what about the backup software?
For example:
http://support.microsoft.com/?kbid=305381 [microsoft.com], complete with quote "this behavior is by design".
Realplayer (sort of) (Score:2, Interesting)
Realplayer 10 doesn't support Realplayer 2 "out of the box". It will happily connect to Real to download said codec if you want - although obviously this assumes that Real will always be with us.
Easy, MS Word when used for math (Score:3, Informative)
Amiga IFF (Score:2)
I know Gimp supports it via a plugin. Here's a Newtek/Lightwave link:
http://www.newtek.com/products/lightwave/developer
There's "open" and then there's *open*! (Score:5, Interesting)
Classic example: sharing MS Word files with other word processors. The problem isn't getting at the data in .DOC format (not an easy problem, but one that was solved years ago). The problem is rendering Word formatting using the conventions of other word processors. As anybody who's tried to import complex Word documents into Open Office will testify, that's a problem that's a long way from being solved -- if it ever is.
I've been working on a project for an organization that has a bunch of certificates created in Adobe Illustrator 6. The files are saved in EPS format, which belongs to Adobe, but is very well documented. So accessing the files should be a snap, right? Wrong. I have Adobe Illustrator 11 (better known as Illustrator CS), which uses completely different conventions for creating an EPS file. It can read the old files OK -- but it horribly mungs the formatting. Somebody's going to have to sit down and undo all that munging, which will be a day or two of work. Then we can make the simple change (inserting a new signature), that's the only change we want to make!
So true openness has more to it than knowing what all the bits and bytes do. It's making sure that all the different design teams for different products that use the format (or the same product at different times!) are on the same page when it comes to the fine details.
Print using an OCR font, save in Rich Text Format. (Score:2, Informative)
2)Two copies of archival quality media stored off site saved as RTF as well as the working format.
3) Regular on site archives.
4) Regular on site backups.
At least one off site facility should be a secure storage facility. The other should be accessible 24/7/365, therefore it should be on company property. Each site has paper and media. Archive quarterly.
However, mostly it sounds like you need to hire a real Technical Writer a
Retention requirements (Score:2)
If someone asks for access to those files, it's their problem/responsibility to make use of them. Of course, if it's something that someone within your company needs, then it would be nice of you to help them access the files in a useful mann
QPW (Score:3, Informative)
I have a lot of GeoWrite documents... (Score:3, Funny)
Thankfully, I can still get the PC/GEOS environment to work on various PCs at home, but at some point that won't be an option.
Shrink Wrapped Apple IIe (Score:3, Interesting)
Re:simple (Score:2)
OTOH, since you're a senior, there's probably little hope. Go ahead and troll.
Re:simple (Score:2, Funny)
Re:simple (Score:2)
Grammar.