Archiving tool unhappy being in a 64-bit world

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
For years I've used an excellent but relatively little-known, archiving program called JAR32. It's by the same company that made the much better-known ARJ archiver. JAR is the big brother of ARJ and has a lot of excellent features...and I have rather a lot of archives in its format.

The problem started when I tried to install it on my laptop (64-bit Win 7). I had assumed JAR would run more slowly and perhaps with a few quirks, but that it would at least run.

It doesn't. Its installer won't even launch. There is no 64-bit version. This is going to be rather painful. The JAR-format archives are all on an XP system. I could devise a simple script to convert them all over to .ZIP format -- but it would take rather a long time. Is there any hack that can fool a 32-bit-only program into thinking it's running in a 32-bit system? Windows' compatibility mode is not doing the job.

It's a shame if this is ARJ's fate as well. ARJ had some very interesting features -- for example, it (like JAR) could be used as a sort of poor man's source-control system, enabling you to save "chapters" of the same file within the same archive. Can't do that with Winzip...
What made IBM's 360/370 series successful? Backward compatibility and hardware scalability without software change. The Intel/Microsoft conglomeration has achieved such a near monopoly they throw old software out! Your archives are no longer accessible? They'll happily bankrupt you when the tax man comes to look at your records and you can't see or show them!

But never fear, 7z from is here! It has 64b version, runs on Win7. It can expand your ARJ files. And its price is always right - free, open source! In its native mode 7z provides better compression than PKzip (or its alternate incarnations, such as WinZip, InfoZip, or the ZIP/UNZIP commands of the recent TCC versions) because it develops a single compression dictionary for the whole set of files it processes, which means that the overall compression is optimized, and the compressed file needs only a single dictionary, further reducing its size.

BTW, 64b code is not necessarily faster than 32b code. From my decades of IT experience, very few programs need integers larger than 32b, even (or especially) for memory addressing. How often do you use that much code plus data at the same time in a single program? If you do, it has to be either generated on the fly, or - more likely - has to be read from disk. And you will use a few percent of a percent in any one run. That rest will be chaff.
I do use 7-Zip and like it -- yes, it's fast and compresses well. There's one thing I've tried to do with it that continues to baffle me. It appears to have a "freshen archive" command that works like wzzip's "f" option (as with the old pkzip), but to get this working requires both the "u" command and the "-u" switch with a bunch of arguments. I've tried what appears to be the correct grouping of arguments for "-u" and it hasn't worked properly yet. This is why I'm tempted to upgrade my old copy of Winzip and get the updated command-line plugin for it. At least "wzzip -f" or "wzzip f" (whichever it is) works and is simple. (Why they continue to have zipping and unzipping at the command line split into two programs baffles me. I mean, pkzip is long gone. It was great while it lasted. So why not merge this functionality into a single console app?)

Back to 7-Zip: the problem is that the archives in question are in .J format -- not .ARJ format. 7-Zip doesn't support the .J format. (Again, JAR is ARJ's big brother that never caught on in a big way.)

It's too bad no other archivers (that I know of) ever had a "chapters" feature like JAR and ARJ. Of course no software company would want anything less than full-blown source-control -- but that "chapter" feature was sure handy in a pinch.
Have you tried WinRAR? Or running JAR in a DOSBox?

Edit: Checking shows JAR running in earlier windows versions.
Edit 2: RAR archives even support file versioning...
-ver[n] File version control

Forces RAR to keep previous file versions when updating
files in the already existing archive. Old versions are
renamed to 'filename;n', where 'n' is the version number.

By default, when unpacking an archive without the switch
-ver, RAR extracts only the last added file version, the name
of which does not include a numeric suffix. But if you specify
a file name exactly, including a version, it will be also
unpacked. For example, 'rar x arcname' will unpack only
last versions, when 'rar x arcname file.txt;5' will unpack
'file.txt;5', if it is present in the archive.

If you specify -ver switch without a parameter when unpacking,
RAR will extract all versions of all files that match
the entered file mask. In this case a version number is
not removed from unpacked file names. You may also extract
a concrete file version specifying its number as -ver parameter.
It will tell RAR to unpack only this version and remove
a version number from file names. For example,
'rar x -ver5 arcname' will unpack only 5th file versions.

If you specify 'n' parameter when archiving, it will limit
the maximum number of file versions stored in the archive.
Old file versions exceeding this threshold will be removed.
Last edited:
I have used WinRAR, though I got a bit frustrated with its CLI due to the lack of support for a "list contents of archive" switch. What a bizarre omission. I haven't used WinRAR in quite a while. Maybe they fixed that. I hadn't realized that WinRAR supports versioning -- good to know about. Then again I just installed TortoiseHG and even though appearances can be deceiving to "noobs," it does look super-easy to use and looks very robust -- certainly less stressful than Perforce or other source-control apps I've used in the past.

The business of having to unpack and repack all of those JAR archives on the ancient XP box -- changing them to some other archiving format entirely -- is the daunting bit. I suppose I should just call the developer and find out if there's some arcane workaround...

Thanks for these suggestions, Joe. I will look into them. I guess to avoid future complications I should just consider the .J format a thing of the past, even though that JAR program makes extremely robust archives (you can optionally add recovery records to a .J archive -- and they do help. In all the time I've used sundry ZIP tools, I've seen several corrupted archives and I have never been able to recover the busted archives with any "zipfix" tool. I had one, and only one, corrupted JAR archive (out of MANY), and I was able to recover its contents using its recovery mode. I don't know what caused the corruption in any of these cases, but the fact that the ZIP files were lost for good and the one corrupted JAR file could be restored did get my attention. I wonder which of these other formats (.7z or .rar) is the most robust...
.7z is not likely to be robust - robustness comes from redundancy, compression from removing (hidden or unintentional) redundancy. My best success restoring corrupted data came from redundant storage, i.e., the whole data stored in more than one location (preferably geographically separated, so a single event cannot destroy all copies. All copies on separate computers is not really enough if the hardware is colocated.

As for dirt cheap source control, my text editor is set up to always save the unedited version of files; I have a set written a suite of 3 or 4 4NT batch programs (of course they work in TCC, too) which store the nnnn-th generation of all source files in subdirectory Vnnnn. Crude, wastes a lot of disk space, no change finder, but not only does it work, but it is also fast and simple. Wasted diskspace? My laptop's 60GB drive is still more than 30% free, so who cares... Alas, my editor won't run under Micro$oft Vista or later... (thanks to Borland's buying and abandoning it), and I cannot afford its Win7 compatible successor.
If I'd backed up already-corrupted .zip archives, they'd still have been corrupted if I had copied them from the backup media (or site). What made the difference with the JAR archives was that the recovery records placed into them enabled me to restore the files in the corrupted archive. That's what I was thinking about when I said "robust," and perhaps it's not the right term to use.

I had spent a while looking at sundry articles on the web about "simple" open-source version-control systems. It sounded as if TortoiseHG (Tortoise for Mercurial, which includes Mercurial itself) was about as simple to set up as it could be. I found this to be true, and if you're looking for simple source-control, this looks like the ticket to me (so far). When it comes time to do merging...well, they all seem a bit difficult in that regard. Learning the paradigms involved is the hard part (the syntax itself is no big deal). I did think of rolling my own via TCC scripting and was on the verge of making some notes about how I'd do that. Then I decided to download TortoiseHG and take a look at it. I'm impressed by the simplicity. I will probably have some simplistic source-control routines set up using it, long before I could have finished making vaguely equivalent TCC scripts.
May 20, 2009
The problem started when I tried to install it on my laptop (64-bit Win 7)
I have not a 64 bits system on which to test it, so I have only some vague ideas. Did You try the 32 bits version or the 16 bits version? 16 bits software does not run on 64 bits windows. Can You install the windows xp mode to try to run jar from there? Did You try to install AND/OR run it with right click and run as administrator?


Rodolfo Giovanninetti
What made the difference with the JAR archives was that the recovery records placed into them enabled me to restore the files in the corrupted archive.
RAR has recovery records also.
Of course I am advocating that immediately after you validate a newly created archive you back it up, while the originals are still available. For robust computing, no systems should have fewer than two physical drive, and you could use Windows' ability to make the two drives mirror each other, or use RAID architecture, You should also make sure that your memory had ECC, strong processor temperature controls, etc., etc.

Of course, I am slacking of, too, and not even use the backup resources I pay for...
I have not a 64 bits system on which to test it, so I have only some vague ideas. Did You try the 32 bits version or the 16 bits version? 16 bits software does not run on 64 bits windows. Can You install the windows xp mode to try to run jar from there? Did You try to install AND/OR run it with right click and run as administrator
The program is a 32-bit app -- and its installer just doesn't like to run in any circumstances (as far as I can tell) in a 64-bit system. I've pretty much decided at this point just to live with the situation as-is -- and be glad that I can at least still extract and re-archive the files. It would have been VERY grim if I'd simply backed them up, then tossed out the old XP system, only to find that I had no way of restoring the archives on my own machine.

JohnQSmith: thanks for the note about RAR and recovery records. It's been an interesting challenge finding a way to download the non-GUI rar executable, though. It doesn't seem to be on the WinRAR site. (Unless it's already in the distribution archive with WinRAR.)
Re: RAID array. Well, I had one of those, once. The main drive failed. Fine. Back up from the RAID array.

Oh. The RAID array was no good, somehow. The physical drive seemed to be fine. But something had been corrupted. Lost everything. I haven't been quite as thrilled about RAID arrays since that time. Had that problem once with an external backup drive, too. Worked for a while. Then suddenly: nope.
For many programs once I run the installer on one system, I can just copy the installation directory to another system, and it runs! You may want to make a copy of your registry before and after installation, and find the changes made by the installer. If installation requires the use of an activation key, you may need to use that on the other system, too.
Your comments about failing RAID systems are interesting. Of course, if the hardware which creates the redundancy permitting recovery fails, you need to fix that hardware. If the drive itself fails, recoverability depends on the extent of redundancy. Redundant recording on a single device protects only against local damage, e.g., a scratch on a magnetic or optical disk's recording surface - this requires a program designed to provide redundancy on the particular device type. And oh, if you want reliable computing, you better use memory with ECC on a hardware platform which supports it - if you can find any in today's complacent world, and set ECC handling to providd clear warning its use was required, because that is often a sign of hardware deterioration.
Of course, if the hardware which creates the redundancy permitting recovery fails, you need to fix that hardware.
It's been a while now, but as I recall the hardware was ok. Something else had gone wrong — and I don't know what. It was enough of a disaster that my major concern became not hurling myself out of a basement window in despair.

Far too late to do anything about it now. I know that using RAID is a very standard thing, but from now on I'm going to place a bit more stock in redundant backups to external drives and/or (maybe) the cloud, though I'm not nearly as enthusiastic about the cloud as I know a good little geek in the 21st century is supposed to be.
May 20, 2009
What errors do You get?
I did these tests on a windows 7 64 bits machine and for me it seems to work.
I downloaded the file "jar102x.exe" from the site "".
I tried to run this setup and, as I expected, it failed, because it is a 16 bits software and so it cannot run on 64 bits windows.
Then I downloaded and installed 64 bits winrar from "".
I right click on "jar102x.exe" and chose to extract to a subfolder.
At the command prompt, I went to that subfolder and ran "jar32.exe a foobar".
It created the file foobar.j that I could list with "jar32.exe l foobar", test with t, extract with x.
So, at least in my case it appears to work.
When I tried to run jar16.exe it failed, again because it is 16 bits.


Rodolfo Giovanninetti