• (cs)

    Somebody else can have fist comment. That hurts my eyes too much to read through it.

  • idfk (unregistered)

    inb4 .mkv!

  • Schmuli (unregistered)

    How is this zipping? What part of that script actually zips anything?

  • (cs)

    No wonder the C guys think VB sucks if this is their only experience of it!

  • Alan (unregistered)

    Jeez - just pay for Winzip command line already.

  • (cs)

    You're going to make me read code first thing Monday morning to find teh funnay? That's cold blooded... ;)

  • Tempura (unregistered)

    So, it's not a zip, but a self-extracting tar, disguised in vb. Not bad.

  • Bill (unregistered)

    I like this: CString m_outputfilename = m_outfile; CString outpath = outfolder;

    That's classy coding right there. He never uses outfile or outfolder again. He names them in the function, and then promptly renames them in the first two lines of the function.

    Quality stuff.

  • AdT (unregistered)

    Mmmmm, meta-spaghetti. Things I like best:

    • It never checks whether the whole fopen + fprintf stuff actually worked.
    • Declaring many variables in one scope, in particular "fileName" and "filename"
    • Assigning to "BOOL ret" only to use it just once
    • Declaring and assigning to the nested dwRetVal only to use it... never
    • Hard-coding "syswow64"
    • Assigning Nothing to variables at the end of the script, just in case...
    • Sleep 1000 of course :-)
    • If GetTempPath fails, open a file, append a string to an uninitialized buffer, then try to open another file without closing the first one. Priceless!
  • Phil (unregistered) in reply to Schmuli
    Schmuli:
    How is this zipping? What part of that script actually zips anything?
    It first creates a small empty ZIP file by actually writing a valid header (and nothing else) to the destination ZIP. It then uses the Windows shell extensions to add the required files to the ZIP via a "Copy" operation--like copying files from one folder to another. Since Windows treats ZIP files like folders that can be copied into, this adds them to the ZIP. Actually it's a rather clever idea to avoid the use of complex (sometimes unreliable) third-party libraries, but it's implemented a bit strangely.
  • (cs)

    It looks like it uses vbscript to output a script to do the actual compression, then runs it.

    It outputs an empty ZIP file and then uses the Windows Explorer ZIP shell extension to mimic the user ability to drag and drop files into that ZIP and have them automatically compressed. Clearly the programmer didn't know how to do this directly from C and couldn't be arsed to RTFM.

    Of course if the user disables the shell extension or is on an earlier Windows OS that doesn't have it, the program fails with no error.

    A more fool-proof solution would have been to use an external process like 7za.exe (7-zip), which, AFAIK, can be bundled as long as you include the license. Of course a library would be even better.

  • (cs)

    this guy/girl is not stupid or inexperienced... the function is actually very clever ... i love how the text file with the PK+magic number signature is written and it turns automatically into folder where the files are be copied ...

  • Anonymous (unregistered)

    Jesus Christ, this code has just made my day even worse.

  • reaver121 (unregistered)

    Sorry, couldn't resist :

    My eyes ! The goggles, they do nothing !!

  • AdT (unregistered)

    Adding three more to my list:

    • It's not even the same "FILE *fp", so this code just leaks a FILE no matter what.
    • "CString p"
    • Not only is it very bad style to declare the poorly-named lpPathBuffer1 at the start of the function although it is used only in a nested block. This buffer is also completely redundant.
  • The_Assimilator (unregistered) in reply to Phil
    Phil:
    Schmuli:
    How is this zipping? What part of that script actually zips anything?
    It first creates a small empty ZIP file by actually writing a valid header (and nothing else) to the destination ZIP. It then uses the Windows shell extensions to add the required files to the ZIP via a "Copy" operation--like copying files from one folder to another. Since Windows treats ZIP files like folders that can be copied into, this adds them to the ZIP. Actually it's a rather clever idea to avoid the use of complex (sometimes unreliable) third-party libraries, but it's implemented a bit strangely.

    Apart from the fact that the code itself is irredeemably retarded, I wonder if it'll work if Explorer isn't the handler for .zip files...

  • //my name (unregistered)

    The real WTF is the comments:

    //find temp directory; dwRetVal = GetTempPath(dwBufSize, //buffer length lpPathBuffer); //path buffer

    //get the windows directory; dwRetVal = GetWindowsDirectory(lpPathBuffer1,dwBufSize); //path buffer

    Without these comments I'd have spend all of, err, 1 nano-second working out that GetTempPath let me find a temp directory and that GetWindowsDirectory would let me, err, get the windows directory.

  • Phil (unregistered) in reply to The_Assimilator
    The_Assimilator:
    Apart from the fact that the code itself is irredeemably retarded, I wonder if it'll work if Explorer isn't the handler for .zip files...
    Sure will. That's a totally different thing.
  • (cs)

    Thank the lord for VB being a Windows only technology. The ZIP header and folder thing is very clever thought. What I don't seem to find is if this thing truly does any compression.

  • MeBerserk (unregistered)

    I think C++ just scared the shit out of him and tried to solve it by using VB =)

  • Reader (unregistered)

    Real programmers can write VB in any language.

    At least after someone showed them how to i/o-stream.

  • (cs) in reply to ubersoldat
    ubersoldat:
    What I don't seem to find is if this thing truly does any compression.
    Normally it will, if the system is relatively sanely configured. It's relying on Explorer's handling of the zip format to do the work for it. But goodness me, it's a fragile lash-up; if only there were zip tools that could be driven directly from the command line...

    (Making the header inside a .vbs file written from C++? Priceless.)

  • Frost (unregistered)

    The real WTF is that the attempt to be 64-bit compliant isn't correct.

  • Anon (unregistered)

    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

  • Anon (unregistered) in reply to Anon
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

  • Dakman (unregistered)

    At first I just saw the large group of fprintf calls, and I thought "Okay, he's just writing a bunch of headers" then I looked closer and... Oh dear god no.

  • St Mary's Hospital for the Sunken Donkeys (unregistered)

    He needed something in order to zip a folder full of files?

    Geez...

    ...get tar and gzip. It's open source.

  • hcs (unregistered)

    Yeah, I was expecting something that only added one file at a time to the zip, but that kept creating a zip and adding the previous zip to it instead so you end up with one file zipped N times instead of N files in a zip (or maybe adding one file with each level so you end up with something like a list in Lisp). I guess the "nesting" is just the C program writing VB.

  • (cs) in reply to Anon
    Anon:
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    I've been doing that for a while now. I think the process is almost done.

    1 <== The entire Internet.

  • Tim (unregistered)

    "Jeez - just pay for Winzip command line already."

    Glad you didn't write this either! The best solution would be to use the minizip library (in zlib/contrib).

  • configurator (unregistered)

    I like the way he runs "cmd.exe /c cscript //B " + filename instead of just "cscript /B " + filename...

  • (cs)

    TRWTF is that the "Full Article" view displays the exact same thing as the Summary view.

  • drBeat (unregistered)

    misleading indentation:

    if((fileName[0] != '\0'))
    fp = fopen(fileName,"w+");
else(fp = fopen("C:\\Zip.vbs","w+"));
    p.LoadString(RESID_30);

    And anyway, what is this RESID_30 string? A double quote? Couldn't he be bothered to look up how to escape a double quote inside A C++ string?

  • Scriptease (unregistered) in reply to configurator

    "cmd.exe /c ..." spawns a new shell thread while "cscript /B" would block the program flow

  • (cs) in reply to Anon
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on.
    Why reinvent the wheel? 42.zip exists...

    np: Tocotronic - Über Sex Kann Man Nur Auf Englisch Singen (Digital Ist Besser)

  • Lego (unregistered) in reply to Anon
    Anon:
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    Actually, once the zips of zips reached a sufficiently high level of disorder the combined size of all the zips would start to grow because each iteration adds a small amount of overhead to the file. Eventually the process would create a file consuming all secondary storage on the host system.

    -Lego

  • (cs) in reply to Scriptease
    Scriptease:
    "cmd.exe /c ..." spawns a new shell thread while "cscript /B" would block the program flow
    Except for the fact that CreateProcess does exactly that:
    The calling thread can use the WaitForInputIdle function to wait until the new process has finished its initialization and is waiting for user input with no input pending. This can be useful for synchronization between parent and child processes, because CreateProcess returns without waiting for the new process to finish its initialization.
    np: Louie Austen - Too Good To Last (Remix) (Too Good To Last)
  • (cs) in reply to Lego
    Name changed to provide anonymization:
    Anon:
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    Actually, once the zips of zips reached a sufficiently high level of disorder the combined size of all the zips would start to grow because each iteration adds a small amount of overhead to the file. Eventually the process would create a file consuming all secondary storage on the host system.

    -[Name removed to protect the guilty]

    Alright class, this is a nice example of someone not getting the joke, or - even worse - getting the joke and still acting like it was serious. Now, can anyone point me where he failed his "Spot sarcasm" check?

  • James (unregistered)

    I don't know why everybody's acting like this makes their eyes bleed. Is it dumb to have your C++ code write your VBScript for you? Sure. But if you're stuck on an XP machine (and you know it will always be at least XP) and there are procedural hurdles to importing/using 3rd-party software, VBScript is the way to go. Sad, but true.

    I grant you that he should have broken out the VBScript in a separate file and just invoked it as if it were a command-line zip util, but the basic concept is sound. Of course, I make no excuses for the quality of the rest of his code...

  • sxeraverx (unregistered) in reply to Lego
    Lego:
    Anon:
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    Actually, once the zips of zips reached a sufficiently high level of disorder the combined size of all the zips would start to grow because each iteration adds a small amount of overhead to the file. Eventually the process would create a file consuming all secondary storage on the host system.

    -Lego

    Whoosh!

  • Eyes bleeding (unregistered)
    dwRetVal = GetTempPath(dwBufSize, //buffer length lpPathBuffer); //path buffer

    This kind of stuff drives me crazy. No comments on the heart of the algorithm or on WTF s/he is doing... But s/he takes the time to tell us that dwBufSize is the size of the buffer and lpPathBuffer is the path buffer. Gee, thanks for nothing!

  • (cs) in reply to //my name
    //my name:
    The real WTF is the comments:

    //find temp directory; dwRetVal = GetTempPath(dwBufSize, //buffer length lpPathBuffer); //path buffer

    //get the windows directory; dwRetVal = GetWindowsDirectory(lpPathBuffer1,dwBufSize); //path buffer

    Without these comments I'd have spend all of, err, 1 nano-second working out that GetTempPath let me find a temp directory and that GetWindowsDirectory would let me, err, get the windows directory.

    Prime example of why comments should tell why not what. I only hope the young whippersnappers are listening.

  • (cs)

    Hard coded paths = the programming equivalent of murdering kittens. Seriously. Don't put files on my damn C:\ drive root. I don't care if you can't find your temp folder.

    Also: can't he just use the system environment variables that VBS already gives you?

    Aside from how retarded this is (what if you've disabled the Windows zip functionality? I know I have), it's actually kind of an intriguing solution.

  • Anon (unregistered) in reply to Lego
    Lego:
    Anon:
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    Actually, once the zips of zips reached a sufficiently high level of disorder the combined size of all the zips would start to grow because each iteration adds a small amount of overhead to the file. Eventually the process would create a file consuming all secondary storage on the host system.

    -Lego

    No, no, no. You just don't have good enough compression algorithms. My project is to zip the entire contents of the universe down to a single bit which will then be tied to the state of the light switch in my office.

    Light switch on = universe exists Light switch off = ...well....you don't want to know what happens when I turn the lights off!

    Note to self: Leave a note for the cleaners telling them to please not turn off the lights.

  • Anon (unregistered) in reply to cod3_complete
    cod3_complete:
    //my name:
    The real WTF is the comments:

    //find temp directory; dwRetVal = GetTempPath(dwBufSize, //buffer length lpPathBuffer); //path buffer

    //get the windows directory; dwRetVal = GetWindowsDirectory(lpPathBuffer1,dwBufSize); //path buffer

    Without these comments I'd have spend all of, err, 1 nano-second working out that GetTempPath let me find a temp directory and that GetWindowsDirectory would let me, err, get the windows directory.

    Prime example of why comments should tell why not what. I only hope the young whippersnappers are listening.

    All my comments look like this

    x = x + 1 // add 1 to x

  • Anon (unregistered) in reply to Anon
    Anon:
    All my comments look like this

    x = x + 1 // add 1 to x

    Yikes! I fail, left out the semi-colon

    x = x + 1; // add 1 to x

    Much better now.

  • mh (unregistered)

    This one gives me a bad case of the bends.

    Boom, tssssh, it's the way I tell 'em.

  • Lego (unregistered) in reply to sxeraverx
    sxeraverx:
    Lego:
    Anon:
    Anon:
    With the Matryoshka doll comment I was expecting to see it zip individual files, then zip the folder of zip files recursively giving you a zip of zips of zips, and so on. But this, is so much more insidiously retarded.

    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    Actually, once the zips of zips reached a sufficiently high level of disorder the combined size of all the zips would start to grow because each iteration adds a small amount of overhead to the file. Eventually the process would create a file consuming all secondary storage on the host system.

    -Lego

    Whoosh!

    Sorry, my mistake! I thought, for a moment, that intelligent discussion was a possibility in this forum.

    Silly me.

    -Name removed to protect the guilty

  • Paladin (unregistered) in reply to ubersoldat

    it does only by virtue of the windows zipped folder does a standard compression on anything dragged&dropped or copied into it.

  • clm (unregistered) in reply to Anon
    Or, repeatedly zip the same file until you reach the singularity of the 1 bit file.

    No, the singularity doesn't occur at a 1-bit file. You only reach a singularity if, after zipping it down to one bit, you zip it One More Time.

    It's at this point that the file collapses in on itself.

Leave a comment on “Zipping Files - The Matryoshka Doll Way”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article