Directory no longer gets archive attribute when being packed (if it's not already have it in unpacked form)
The issue remains with files. Files which doesn't have archive bit will have one if packed using either internal ZIP or internal TAR. Likewise, if a file in ZIP doesn't have archive bit, it will when unpacked. Means this issue affects both pack and unpack function.
Archive Formats (all passed):
Tested 7-Zip plugin (0.7.6.5). RAR.EXE/WinRAR.exe (3.93, 4.01). ARJ, ARJ32 (2.85, 3.15). LHA/LHA32 (2.55/1.06). ACE (2.04). Not sure about others but I just tested these (what I have).
ZIP packers (all passed):
I also tested other ZIP packers: 7Zip 9.20, WinRAR 4.01, IZArc 4.1.6, PKZIP 2.50, 4.00, 5.00, 6.00 (command-line), Info-ZIP 3.0 (command-line). All are able to store/unpack file without archive attribute bit set properly.
Others (all failed):
tar (GNU tar) 1.12 produces same result as TC (ie. adding archive attributes to packed files). PKZIP (for DOS) 2.04g, 2.50 does (old behaviour, perhaps?)
Conclusion:
I'm not sure about TAR format specification, especially it's not DOS/Windows native. But as for ZIP, I can be very sure that almost all packers (for Windows) tested actually behaves as they should. Except WCMZIP32

Seems like this behaviour is still there in current build of TC (8.0 b11). Is it intentional (say, have to rewrite the whole pack/unpack routine) or not...?
P/S: I figured that, without WCMZIP32.DLL, TC can still unpack ZIP files, only can't create one? Does this mean to fix this thing both EXE and DLL have to be fixed?
P/S #2: I'll test x64 later, if this generates interest, or somebody else can too
