Self extracting zip - not valid zip file

Jan 29, 2009 at 1:08 PM
I am trying to use the latest code to extract a self extracting [.exe] archive file. When i do ZipFile zip = ZipFile.Read(archieveName), then it throws that the archive is not valid format.

Can someone please help? The .exe contains just 2 files and i can open it properly and view contents even in win rar.

Thanks in advance
Feb 3, 2009 at 3:16 PM
Edited Feb 9, 2009 at 3:30 AM
The DotNetZip library is not designed to open and read self-extracting zip files.

The library can produce a self-extracting zip.    The library cannot READ a self-extracting zip.

Curious: How did you produce the self-extracting zip file?

The thing is, a self-extracting zip is not actually a zip file.  It is an EXE that contains a zip file.  As there is no standard format or specification for how the EXE should embed the zip file (as far as I know), there is no standard way for a tool or library to "read" a self-extracting zip file produced by another arbitrary tool or library.   This would not prevent a tool or library from reading self-extracting zips that were "self created".   So, WinZip might - I don't know this, but it might - be able to read SFX files that were generated by WinZip, because the tool could make assumptions about the file format.  But WinZip won't be able to read an SFX created by DotNetZip, and vice versa.

In general, though, the only thing you can do with a self-extracting zip file is... extract it.

Feb 4, 2009 at 9:33 AM
I am creating the self-extracting zip file using winzip. I cant remember off hand but it has an option to create a self extracting exe file rather than a .zip file.

Is there anyway I could extract this with your dll??

Also could you please advise how easy / hard is it to add progress of individual file in the code as i would ideally like to have a progress bar advising what % of file 1 has been extracted if there were 2 files in the achieve?

Thanks in advance - and a very nice code.

Feb 4, 2009 at 4:47 PM
The DotNetZip library opens zip archives.  It does not open self-extracting zip archives.  Sorry!

As for an extract progress event - v1.7 has that capability.  v1.7 is currently at "preview" status.
Feb 9, 2009 at 8:12 PM
Is there any way to change your mind on this? I really want to use your library instead of CSharpZip, but this is a blocker. I deal with alot of sfx files. Every other library and tool seems to handle them, so it can be done.

Most sfxs are created via a simple append, e.g. copy /b my.exe, or some code variant. There is not even a need to update the PE header. If I remember the zip structure, the central directory is at the end of the file. If the offsets are from it, everything should work, otherwise you have to find the start of the appended data. Found an article that might be a good jumping off point,

If your algorithm isn't 100% that is okay, for every sfx file it works on that is a win for your users.

Feb 9, 2009 at 10:32 PM
I can look into it. 
I was not aware that SFX support is so interoperable. 

What is it you specifically want the library to do?  Can you clarify ? 
Also, it would help if you created a workitem to track this. 
Feb 9, 2009 at 11:17 PM

I've looked several times and so far I do not see a specification for how SFX archives commonly work.  I looked for this when I built the SFX capability into the library, and found none. (Lacking any guidance, I went and invented an approach for SFX for DotNetZip. )  I looked again when alag20 initially asked for this, and found nothing.  I looked again now, still found nothing.  

I read the webpage you directed me to - it describes one way to format a SFX.  As far as I could tell, it did not state that this is the approach taken by WinZip, or any other Zip tool.

Is there a spec published by WinZip or PKWare? Something I have missed?
Does SharpZipLib read SFX files created by some other tool? 


Feb 10, 2009 at 2:18 PM
I would like the library, ZipFile constructor and Read() method, to be able to accept a sfx file and open/read it.

I know that zlib, SharpZipLib, 7-zip, WinRAR and WinZip all successfully open the various sfx files that I have.

Yes, there is not sfx standard. However, I believe that we can scope the problem space in order to be 80% successful. We can classify sfx files into two classes: a) those that are a stub.exe + (i.e. created via copy /b a+b c or equivalent), and b) those where the is not at the end of the file (i.e. there are pre/post markers, special .data section, ...). Let's ignore class b. For class a, the central directory is at the end of the file and thus discoverable.

My memory is foggy, but I am guessing that the offsets in the central directory are from the beginning of the file, thus the math to get to file entry is BeginningOfFile + FileHeaderOffset. BeginningOfFile is always 0 and is really just setting the file pointer to the beginning. However, when the first few bytes of the file are not a file header signature, then BeginningOfFile needs to be calculated to a non-0 value. One algorithm to calculate it is a small modification of the code presented in the article at, you don't need the last few lines starting at readfile(). While the article is specifically about how the have the sfx stub.exe find the, the same "finding" logic would still apply to your library. The author states in the second reply "This method is simple and reliable; Rar self-extractor uses it (see Archive::IsArchive method in UnRAR sources)." 

Feb 10, 2009 at 6:23 PM

ok Mike,
Your memory isn't that foggy.
I think it shouldn't be difficult to do; as you said it is a simple matter of arithmetic. Figuring it out will not be difficult.

If I had some sample SFX files from those other programs to work with, it would be make it much easier.

If I do this work I would also have to re-design the DotNetZip SFX extractor.  This would allow DotNetZip to read its own SFX files, and if our theory holds, the other programs would then be able to read DotNetZip's SFX files.  This redesign would not be a ton of work, either.



Feb 11, 2009 at 7:13 AM

Ok, this is a bad news / good news / bad news message.

First the bad news.
My tests show that WinZip does not simply do the "copy /b a+b c" or equivalent.  Instead, in an SFX generated by WinZip 12.0, the ZIP file data is stuffed in its own Section formally stored within the PE file.  Therefore, scanning past the last Section in the PE header according to the idea described at, will not work. That will scan right past the ZIP data. Instead the library must scan TO the last Section (not past it), and begin looking for the ZIP file data there.  This section apparently has a well-known name: _winzip_.

Do other tools take this approach?  I'm guessing they don't!  As I said in the discussion thread, I couldn't figure out how to get 7zip to make a SFX/ZIP at all. 7zip makes SFX files that use the 7z format, not the ZIP format.

Once I get the zip stream, there's another problem.  In the WinZip case, the zip data is not just a valid zip archive inserted into the PE file.  In fact, all the offsets in the embedded zip data stream refer to positions in the actual .exe file.  So even though the zip data stream may be only 1000 bytes, it might have offsets that refer to position 0x02250E.

This isn't a disaster.   Actually, this is the good news.  Having gotten this far, it becomes clear that a WinZip SFX  - the exe file - is a valid zip file!    As long as the tool reading it doesn't make too many assumptions, the WinZip SFX can be read as a normal ZIP.   DotNetZip had just 2 places with those kinds of assumptions - just two minior changes required.  And voila, DotNetZip can read WinZip SFX files.  I just tried this.  It just works.  That's the good news. 
But wait!  Now for the other bad news.
An SFX generated with "copy /b" will NOT be a valid ZIP file, because the offsets will all be shifted, as I think you pointed out.  Which means it won't be readable right out of the gate, as is a WinZip SFX.  
I would need to introduce some larger changes in DotNetZip to handle an SFX file produced with a "copy /b" approach.  Before I can do that, I will need samples of these files!

Here's another question, Mike: what do you want to do with these SFX Files?  Do you want to modify them, update them, and then Save them again? If so, in which format?  If you want to save as a ZIP (by calling a Save() method in DotNetZip), then the important implication is that SFX stuff will get stripped, not preserved.  You're happy with that, right? 
If you want to save as an SFX, then there are two important implications: (a) the WinZip SFX UI will get replaced with a DotNetZip-specific UI, and (2) running the self-extractor will require .NET 2.0.  This last thing is a new dependency that a WinZip SFX does not have.  That may or may not be important to you.

In either case, whether you save as a ZIP or an SFX, the archive will be much different than what it started as.  Is this what you expect?

If that is not OK - in other words if what you are asking for is a tool that can edit and modify WinZip SFX files and then save them as WinZip SFX files, then the scope of this request is much different than what I originally thought.  I'd have some concerns about the reliability and testability of anything I built to satisfy such a request.

Feb 11, 2009 at 6:25 PM
Very interesting. Let me answer backwards.

I had not thought about the Save(). My first thought is to simply have Save() fail. That is, I'm okay with opening sfx files as read-only (allowing extraction only). One of my use cases is to opening custom sfx install packages and extracting some drivers from them. I don't need to save. Perhaps disallowing Save() is a good first step that can be revisited in the future. But if not, I would vote for saving a simple zip, i.e. stripping the stub exe and other noise.

I looked at 7-zip, yep, they don't create zip sfx files, but they do open them.

Have you looked at the zlib source to see how they open sfx files?

When I was googling the other day on sfx, it appeared to me that all of the freeware/shareware sfx programs out there were about providing an installer stub with copy /b creation instructions.

As for WinZip, I am not surprised they did all that work. It probably is the most robust solution. But it is cool that you got your code to work with minimal changes.

I really appreciate the time you are taking on this topic. I so much prefer your class design over SharpZipLib. Let me know if there is anything else I can do to help.

Can you please provide me with an email address that I can send some files to you to experiment with.

Feb 12, 2009 at 4:26 AM
Edited Feb 13, 2009 at 12:36 AM

Mike you can reach me at .  Send me those files and I will test them out.

As for Save(), - what I was trying to say is that either Save will work - either Save-to-ZIP or Save-to-SFX or even Save-to-Stream - but the key thing is, when saving from DotNetZip, the result won't exactly reproduce the user interface from the original SFX.    Once you call any Save() method, the original SFX logic will be lost.  If you don't need to save, then I guess it doesn't matter to you.

I have not looked at the zlib source to see how they open SFX files.  I will look around.

I am going to defer this SFX stuff to v1.8 so I can actually finalize v1.7.