I write for a roleplaying site. One of the things I do is, I’ve created my own language for one of the races in the game.
Many years ago, a friend of mine wrote a simple program that will translate English text into the text of the language. It requires a few files, including a .txt file that needs to be kept updated with new words. You type in the English definition, hit tab, and write the constructed language’s translation all on the same line.
One of the programs’ files is an .exe file. Is there a service that will allow me to share this program, including the .exe file, with people for their enjoyment? E-mailing it through gmail seems to be right out; gmail thinks I’m sending a potentially harmful file.
It seems that recent versions of Windows actually has zipping built in. Here are some instructions for how to do it.
If that doesn’t work, as someone else mentioned, 7zip is free, and there are many other free archivers out there. It’s frankly mind-boggling that in the year 2022, WinZip is still trying to soak people for $29.95 when free alternatives are everywhere!
I expect so, though I haven’t done it myself. Certainly worth a try.
Either way, I’d personally would still zip it. Just better practice to distribute a single file instead of making someone download multiple files.
Another vote for 7Zip. A must have for your PC toolbox. It also uncompresses other file types like RAR and TAR. It will also extract files from an .ISO, so you don’t have to mount it in a virtual drive.
As for emailing your files, I would never accept a compressed file even from someone I know. Email addresses can be spoofed and have a virus or ransomware injected into the file.
Ask around in your role-playing community and there may be sites they use to share files. Or you can use file sharing services like Dropbox or Mega. You create your account and allow visitors to download the file(s). I’m not sure if it’s part of the free service, but you can also require a password to download.
If it’s a popular game, you may be able to upload your files to software sites like softpedia.com or snapfiles.com
Edit: Yesterday I got an email with a .HTML attachment saying to open it. I checked to see if it was from a customer and even if it was I still wouldn’t have opened it. It wasn’t from a customer and I forwarded the email to IT. I was told that it was sent to two other employees, with one on longer with us.
Read up on how to create a HASH to verify the size and integrity of your file. This allows the user to check that the file is identical to what you uploaded. Sharing a file that’s been hacked can at best give you a bad reputation, at worst, it may get you banned from whatever game you’re involved in.
Yeah, I’d recommend 7-zip on Windows. You’ll want to use a password that is not easily guessable and not transmitted in the email to encrypt the file. I know of at least one mail scanning program that will guess the passwords used to encrypt the file to see if it can extract the contents of the archive and examine them.
I decided to use 7Zip to compress the file, and Google Drive to distribute it. Gmail blocked my attempt at sending the 7Zip-compressed file because of the executable.
Of course, the person I gave the invitation to, knew about it in advance; we were just talking about it.
Sure; you just won’t get any extra compression from it. Same goes for 7-zipping a zip file–even though it compresses better on average, the compression process mostly breaks any further compression, since good compressors depend on knowing the type of content in the file–English text, executable code, images, etc. Once you compress, that information is lost.
You can always give them the password in person or over the phone. Then, the person knows only to accept a file that decrypts with that password.
I doubt that it would. The product I support can generally handle several types of archives. As long as they aren’t password protected, it can process them several levels deep.
It’s been years since I had to do this. What I recall doing:
Rename the .EXE file to some other name. Zip it up with all the other files to be sent. (I was doing this back in the PKZIP days.) Tell the other person to unzip the zip file and rename the file back to be a .EXE
Another approach I used sometimes was to make a zip file of all the files, then rename that to be something other than .ZIP, then make a zip of that. Or something like that. It took heroic contortions to get it past gmail.
ETA: I also remember reading that there was some provable mathematical theorem that making a zip file of a zip file would ALWAYS compress it to something smaller – thus you could make a zip of a zip of a zip of a zip of a zip (It’s zip files all the way down!) – and each zipping would get smaller. But . . .
But the amount of compression with each zipping would get smaller and smaller, approaching zero, and thus the resulting file size, while always decreasing, would approach some limit. And of course, file sizes come in multiples of bytes. So when you got down to where the next compression would be less than one byte, that was the limit. I don’t think it took very many zippings for this to happen – As noted in other posts above, the first zipping gets you most of the compression that you’re going to get.
In my experience a Zip of a Zip was bigger than the original.
The first Zip file did all it could to compress the file. Zipping that Zip could not compress further but necessarily added some data integral to letting a Zip file work.
In short, a Zip of a Zip of a Zip…only grew in size after the first one.
@Whack-a-Mole, I think that is right. I remember that happening too,
and yes, it conflicts with what I wrote. I’m not familiar with any
kind of compression technology, but I think I know what is happening:
First, the ZIP algorithm analyzes the data to be compressed,
determines what patterns of bytes can be compressed to what smaller
pattern, and builds a “dictionary” of those correspondences. Then it
write that dictionary followed by the compressed data. I believe that
if the compression is too minimal (which could happen after the first
or second zipping), then the dictionary itself can take up more bytes
than the compressed data does – thus ending up a losing proposition.
Second, because zipping can combine many files into one file, there
must also be some kind of “directory”, giving the original file names
to be restored. This, of course, is extrinsic outside of any data in
the files themselves. In a mathematical theory sense, I think that
would not count as part of the compressed data, yet it must be added
to the compressed file as written.
So the theory of compression could say that each successive
compression will make it smaller (even if only infinitesimally), yet
all that bookkeeping data overtakes that. I believe that some
versions of the zip program (WinZip, I think?) took note of files that
became larger, and then simply wrote the uncompressed file as-is
instead of writing a compressed file.
It’s exactly the opposite. The pigeonhole principle guarantees that you can’t reduce file size on average. Ultimately, if all possible files are representable, then to represent all possible files of length N, you need N*2N bits in total. Compression programs redistribute these bits so that “interesting” files compress to lengths <N, but that inevitably means that other files will end up larger.
That said, real-world programs can sometimes “cheat” by storing the extra bits in metadata, which isn’t counted (a silly example would be a program that reduced small text files to 0 bytes by storing the data in the filename).