Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
How about some more info? What compression method to use, etc.? Most people are probably not comfortable using some shady tool on their game install with no info whatsoever.
This "tool" is just an user interface for it.
And it's options are pretty self explanatory.
It's literally a front-end UI for Windows 10's compact.exe commandline tool -- and an incredibly badly written one, at that. (I would personally not be caught dead trying to use it...)
So... let's see what compact.exe has to say...
How badly written is this front-end then?
Well...
Rather than using the Process class in .NET to call compact.exe directly, it starts up a new instance of cmd.exe -- you know; the standard command prompt -- and then instruments that by pushing WriteLine commands to it via the standard input stream.
It actually spawns 2 cmd.exe instances; first it attempts to detect the system codepage using the chcp command. Then it closes that command prompt and starts up a new one with the encoding settings matching what was read by chcp, so that output from cmd.exe can be read back correctly and doesn't end up garbled, on e.g. Russian systems.
The chchp detection is unnecessary. There's a built-in way in .NET to grab the default console encoding used on the local system. You can simply access the public static Console.OutputEncoding[msdn.microsoft.com] property to get it.
Ofcourse; this detection and setting of encoding is unnecessary in general. If you would just call compact.exe directly, instead of going through cmd.exe, you could set the input and output encodings to UTF-8 and compact.exe should happily work and send you back readably data for practically any language known to man -- and then some.
Moving on, the way the program reads from and writes to its first cmd.exe instance -- the one that does the dumb chcp detection -- is prone to deadlock because it uses a synchronous read of output, which may block on the error stream not having been read.
(Always, always use async reads for both the standard output and standard error streams if you redirect and hook them. Or you will have users ending up in deadlock states. This is not a matter of 'if', but a matter of 'when'.)
Because the program executes compact.exe through the 2nd cmd.exe instance it spawns, it has no way to know when all data has been passed through the standard output and/or error streams. It cannot wait for the process to exit, because the process it is actually listening to is cmd.exe, and not compact.exe
It would have to make an educated guess, at best. And actually it doesn't even do that.
It literally has a method called "LetsKillStuff", which is run on exit of the GUI. And yes; that does more or less exactly what its name suggests.
Said method uses the .NET Process class to create a powershell instance, much like the same extra hoop of using cmd.exe instances, and then uses taskkill.exe to force close any compact.exe instances that are in mid-flight. I hope I do not need to explain why THIS IS AN EXTREMELY BAD IDEA.
Regular NTFS compression is not exactly the same as the advanced settings for compact.exe in Windows 10.
You can achieve higher compression ratios with the latter, but there are some trade-offs. E.g. higher CPU usage -- also during decompression. Also, compressed state is not maintained. If a file undergoes any operation other than a plain read, it ends up back in its decompressed state.
The tool mentioned in the opening post of this thread is plain awful though. Nobody should use that junk. Just call compact.exe yourself from the commandline.
It's just a gui for a built in tool in Windows 10, are you even on Windows 10?
It will not work on any other OS. Works perfectly fine for me and compresses Nioh to 22gb disk space with XPRESS8K Compression Algorithm.
I used the XPRESS16K. You also need to be on Windows 10 since it uses a Win10 feature.
You're completely right, of course - so I've patched it up hopefully. Would you mind checking v2.1's code to see if I've got any major screwups left?