-
Hi,
I’d like to propose an improvement for password protected archives.
Actual behavior is:
If I open an archive, which is password protected and make a typo in the password dialog, I’ll get the message, that the password was wrong and I end up with an empty window. I need to reopen the archive to be able to enter the password again.Improved behavior:
Tell me, that the password was wrong and give me the chance to enter the correct password to decrypt the archive. -
Hello!
I know I have been asking for this feature some time ago, but as nothing has changed let me ask again:
The ZIPX-format offers an algorithm, that compresses JPEG-files by about 20-30%. Please add compression (packing) support for this in ZIPX-archives to Powerarchiver. Extraction of JPEGs packed into ZIPX by this algorithm is already supported by Powerarchiver for a long time, so it should not be difficult? Or is it a licensing problem?
Thanks! -
Hi,
I’d like to suggest, that the correct archive type is (always) selected, when adding files by drag & drop to an archive.
This is already happening if the archive has the correct extension. For example, if I’m adding files to test.zip, zip will be selected. If I’m adding files to test.7z, 7z will be selected as format in “Add dialog”.
But this won’t be working, if the archive has not the “right” extension.
So XPI files (Firefox addons) for example are ZIP files. PowerArchiver opens them without any problems, but if I try to add file by drag & drop, PowerArchiver won’t auto select “ZIP”, but use the last selected archive format, while PowerArchiver already knows, that I’m trying to add files to a ZIP. -
I love this, only there is one problem. The UAC elevation feature does not extend to Mount Image option in the add-on software PA provided. It is most annoying whenever I am on highest UAC settings and I mount an ISO, every time I open and create a virtual drive UAC appears. I also do not want to completely disable UAC.
Is adding UAC elevation for mount image feature possible?
-
The now defunct Bulkzip had Nanozip (nz) as an option this would be great to have for compatibility with my .nz files, so I don’t have to install Bulkzip separately.
-
Hi.
I noticed that when I want to run the Virtual Drive for the first time inside the PowerArchiver Burner it prompts to download it form the internet.
I was wondering, would it be OK to include this utility straight into the offline installer to be able to set it up locally?
Thank you!
-
How about recognising a few more (or all) of the file formats that are basically renamed zip files and treating them is if they are zip files.
For instance Android .apk files are just renamed .zip files.
Libreoffice/Openoffice ODF documents are all, as far as I am aware, just renamed .zip files. (.odt, .ott, .ods, .ots, .odp, .otp, .odb, .odf etc.) -
-
-
Would it be possible at all in some future version perhaps, to have a “find file” function?
Reason I ask is that I was looking for a certain file I knew existed in an archive, but I had to unzip it then use another tool to find the file. It would have saved that extra step if that function existed in PA itself. -
Hi.
Is there a way to enable the user to encrypt the files inside a ZIPX archive that has already been created?
This could save time for large archives that the user may need to encrypt at a later stage or that he/she has forgotten to enable encryption before creating the archive,
Thank you!
-
Hi.
I would like to see a new feature implemented: a ‘Fast Extract’ Mode.
Currently PowerArchiver extracts files to a temporary directory and then moves them to the target directory chosen by the user. At least via drag and drop.
This can be both time consuming and needs free space on the system drive for large files.
Is there a way to directly extract files to the target directory with PowerArchiver?
And if not, can a feature like this be considered for future updates?Thanks very much!
-
Hello.
I believe it would be useful to implement Serpent-256 encryption for PAE/PAE2 formats, even though PowerArchiver offers strong encryption ciphers already.
(deleted part advertising other software - admin)
Do you think this will be a useful addition?
Thank you for the consideration!
-
Hello!
I think it would be a great option to make the portable version of PowerArchiver compatible with PortableApps (i.e. adding the necessary files and folders to integrate it smoothly into their structure).
I own various other commercial programmes which -when installed in portable mode- offer to make the becessary changes without needing an extra installer or the official PortableApps repos.
Thanks for opinions or perhaps even a realization of this.
A.Borque -
Presently, PowerArchiver 2019 (any build) cannot rename PBS filenames by single clicking on such entry or right-click menu has no “Rename” feature!
Hmm, even pressing F2 on selected entry does nothing :(
-
Please add support for ownCloud / Nextcloud, thanks.
-
-
SOLVED Native 64-bit support
-
Hi guys. I figured it’s time to make my pitch, now that Winrar decided to go x64, and Microsoft announced win7 to be the last x86 OS, and 64-bit processors are a lot more common than they were just a year ago. Perhaps it is time to have a native 64-bit version (I can see that that’s unlikely for PA2010, but maybe PA2011 or even later releases of 2010)?
Winrar people claim that utilizing 64-bit processing yields better performance, and there are all those pesky UI issues that creep up every now and then. Overall, it’s a bit frustrating to use a 64-bit OS and not have software that utilizes its abilities.Also, I really like to hear whether your statements regarding faster rar compression than Winrar are still relevant after they also introduced multi-core support (and they alone have native x64 support). Will you get around to do competitive comparisons of compression rates and times between PA and its main competitors, where each suite is operated at best configuration?
Thanks, and sorry for the lengthy post.
Also, in the possibility that someone has already posted rearding this issue, let me just say that I did an advanced search that came up empty (but I already know that it sometimes doesn’t work) -
there is no performance benefit from using 64bit for compression purposes. Only benefit you will see from using 64bit OS will be more memory. Sooner you realize that, less dissapointed you will be at the end :-).
This has been mentioned several times before and unfurtonaly there is no magic wand which will make applications suddenly run faster in 64bit :).
As to the multicore, WR has multicore for rar compression, we have it for zip and 7zip. Neither of us have it for unrar/unzip (its a lot more complicated), we just have better optimized unrar performance.
-
and there are all those pesky UI issues that creep up every now and then.
if you mean things like white background in shell extensions, that was due to 64bit shell extensions :).
Also we cant compare directly WR compression to PA, as they dont support multicore for zip and we (obviously) cant compress to rar.
-
spwolf, I hope I don’t sound as if I don’t appreciate your product. It’s really good. In fact, if someone would have told me a few years ago that I’d be paying money for an archiving utility, I’d probably laugh.
As I said, it’s really only a matter of time before you’d have to make the move to x64, so I thought perhaps it could happen sooner rather than later. I can live without it.
Nevertheless, you didn’t really answer me regarding the comparisons. You could compare compression rates of WZ and PA in zip/xzip files, and you could compare compression rates obtain in rar format opposed those you incorporate in PA. Also, users will probably be interested by differences in compression times between PA and WR/WZ even when compressing with different methods (after all, as long as the difference in file size is only a few percents, I really see compression time playing a key role in my decision when I choose a format for backup/distribution). Don’t you think?Thanks again spwolf. You really have a winning product. This all is only about making it even better.
-
sure, but there would be no difference due to it being 32bit and 64bit.
it is all about time - we could make pointless 64bit version just because so we can tell our users that it is superior, or we could spend that time and add useful features - like multicore support for zip we added in PA 2010.
as i said before, there are no benefits i can see from having 64bit version.
For instance, i tested unrar on 64bit version and compared it to ours (-m5 + solid archive) and ours is still faster, and its 32bit! :-).
-
i think sooner people realize they gain nothing with 64bit with exception of addressing more memory, less dissapointed they will be once they move to 64bit Windows.
-
I have to agree with Spwolf, I personally see no point in re writing PowerArchiver to another model supporting 64Bit.
The team at PA strive above any other Archive tool to interact with their customers in order to resolve, fix, develop and improve the service and features of their application.
This interaction has in its self created a significant increase in usability and speed.
All this without the need of 64bit.
Microsoft’s Primary reason to move their OS to 64bit is due Memory, Security and Cost. But they will still have to support software running on 32bit for Decades to come… And if you do your research the 64bit Processor was actually invented and used in super computers around the 1960’s. It wasn’t until 2003 that AMD and Intel adapted the technology to be used within the PC.
That’s 5 Decades so working on that timeframe who knows how compression algorithms will develop and by that time PA would have adapted their software to suite.
-
The only time the move to 64 bit will HAVE to be made is when a 64 bit version of Windows is released which will NOT run 32 bit apps. 64 bit is NOT obligatory or necessary at the moment at all. 32-bit apps still get several memory benefits running under a 64 BIT OS.
Talking of speed of 64 bit apps…a programmer told me that even the 64 bit version of office 2010 uses a 32 bit subsystem (MAPI interface) and that also holds back any speed ups.
DrT
-
Hello,
i still think the task to support native x64 should be made.
even if there is only a 5% - 8% Speed Inrcrease of Compression/Decompression.I Have different Archivers Running on Windows 7 x64 and Windows 7 x86 (on my Notebook, will switch later because i need more RAM)
Powerarchiver 11.64
WinRAR 3.93
and
Squeez 5.62On x86 Windows Powerarchiver is the Fastest, closely followed by WinRAR then in the last Place Squeez because it has no Multicore Support is the slowest.
On my x64 Windows WinRAR x64 is the Fastest then comes Powerarchiver and then Squeez witch runs as a Native x64 App - It Still can Keep Up even if the Development Stopped.
-
there is no difference in WR 32bit and 64bit when it comes to extraction, i tested it when we made our improvements to unrar.
-
ie there will be no 5-8% improvement due to 64 bit… but there are improvements to be found in general optimizations to be sure, probably even greater than that…
We will have to make 64bit version once 64bit delphi compiler comes out, mostly because it is marketing - you cant convince people there are no tangible differences :)… It is easier to advertise “64bit version - faster and more secure!!!”.
-
Hello,
that maybe so for Extraction/Decompression but on my PC the Compression is faster not by much but Still faster.
Ok. That Delphi (or RAD Studio) still no x64 Compiler has is strange and is a Problem. So I guess we have to wait.
-
Hello,
that maybe so for Extraction/Decompression but on my PC the Compression is faster not by much but Still faster.
indeed - it is faster for sure, i tested it - we are talking about WR though, so you cant compare it to PA directly :).
but here is the thing - we managed to make much bigger improvements in 32bit (and 32bit in 64bit OS) with general optimizations in unrar, so i would guess if we could create rars, we could do similar types of improvements as well :).
-
indeed - it is faster for sure, i tested it - we are talking about WR though, so you cant compare it to PA directly :).
That is so with most of the Archivers or Compression Programms. :-) Even if You could compare them because they can compress the same formats. There is still no direct Comparsion possible.
but here is the thing - we managed to make much bigger improvements in 32bit (and 32bit in 64bit OS) with general optimizations in unrar, so i would guess if we could create rars, we could do similar types of improvements as well :).
Yes. I think you could. ;-) Witch is why i also bought Powerarchiver. If you also could add some features i need witch are present in the Other Archivers i think i could and would Stop using WinRAR and Squeez.
Best Regards,
R. Landscheidt
-
well post away with the wishes so we can know what you want!
-
Hello,
Well i think i posted them in "What format next? December 2009) but i’l make an new Thread with them.
-
Hello,
i still think the task to support native x64 should be made.
even if there is only a 5% - 8% Speed Inrcrease of Compression/Decompression.I wonder how you managed to measure those differences. <10% is not noticeable in general use.
DrT
-
Hello,
Well i think i posted them in "What format next? December 2009) but i’l make an new Thread with them.
one thread per major wish, thats much easier for us to keep track of things…
-
Here you go:
http://www.powerarchiver.com/forums/showthread.php?t=4867new thoughts on 32bit or 64bit dilemma… post away!
-
64bit engine version for new PAF? Vote away here:
http://ideas.powerarchiver.com/ -
I know I might be going over new ground but correct me if I’m wrong.
doesn’t powerarchiver need to access file management tools to get files. File managers need to access the 64bit windows file system why doesn’t powerarchiver?
-
@splash3313 said in Native 64-bit support:
I know I might be going over new ground but correct me if I’m wrong.
doesn’t powerarchiver need to access file management tools to get files. File managers need to access the 64bit windows file system why doesn’t powerarchiver?
As mentioned recently on forums, x64 is coming with PA 2017.
But as to your question, PA 2016 already has x64 parts such as shell extensions so it works properly. PA 2017 will be full x64 so we can address more than 2 GB of memory for new format.
-
@splash3313 Ah, so you’re one of those weirdos that denies that 32 bit software runs on 64 bit Windows :-)
-
Actually 32 bit software will run just will have problems on 64bit computers when it comes to file management not my words microsofts.
-
@splash3313 Can you provide a reference for that please?
-
@Brian-Gregory https://blogs.msdn.microsoft.com/oldnewthing/20081222-00/?p=19763/
basicalyl the link is old but gets to the point that a 64bit operating system use emulation to run 32 bit software.
http://www.digitaltrends.com/computing/32-bit-64-bit-operating-systems/
-
64bit and 32 bit store files slightly different that is why on a 64 bit system programs that are v32 bit might not be able to see all files available on your computer.
-
x86 programs run perfectly (and start faster) on x64 system. Only thing not available is addressing over 2GB of memory.
Since in 2017 we are adding our own format where you can use more than 5-6 GB of memory, realistically, when needed, we are also adding full x64 version of PA.
Also, codecs built from grounds up might support faster instructions in x64, so with .pa format you will see up to 30% faster performance in x64 than in x86… for .zip, performance difference is nowhere as close, if any.