Click here to Skip to main content
12,997,166 members (70,214 online)
Rate this:
Please Sign up or sign in to vote.
See more:
Our software requires frequent updates to the executable file (.exe). We run on XP, WIN 7 and WIN 8.

Years ago we developed the technique of packaging the updates in a .ZIP file and distributing that file along with an installer program. The installer program calls a copy of PKZIP25 (DOS) that we are licensed to distribute with our software and which resides on the target machine.

That solution has worked like a charm for at least 10 years.

In the last month we are finding that the .EXE is no longer being extracted. The files scroll through the DOS box cleanly, i.e. there are no error messages.

Antivirus is off.

Users do have rights to access the drive.

The .ZIP file can easily be extracted by hand using Windows Explorer.

We are stumped.

We can't use patch MSI's because the programs can reside anywhere and our users are generally too unskilled to be able to find them.

Anybody have any ideas on what we can do?


Posted 24-Apr-13 6:10am
Zoltán Zörgő 24-Apr-13 12:21pm
Please note, that if you want to extract executable in any subfolder of program files you need elevated privileges when UAC is enabled.
Keith Barrow 24-Apr-13 12:24pm
dg6yhw11 24-Apr-13 12:50pm
The files are off the root on a stand-alone computer, or the root of a mapped network folder.

We call the VB6 Shell function. The command prompt always has admin priviliges when called by hand but I don't know the privilige level when its called programmatically.

Thanks for helping.
Sergey Alexandrovich Kryukov 24-Apr-13 12:37pm
Did you change the platform? From which to which? Such thing as "DOS box" does not exist for quite a long time now...
Mike Meinz 24-Apr-13 12:37pm
The question to ask, which you probably already asked, is "What changed?" Something changed in the environment. I can't help you with that but I can offer an alternative.

If you want an alternative to using PKZIP25, you could develop your own software using the methods in .NET Framework System.IO.Compression Namespace to compress and decompress the EXE files.
dg6yhw11 24-Apr-13 12:48pm
Thanks. I'll look into that.

We have been studiously avoiding .NET - our software has 245,000+ lines of code and moving it would be impossibly expensive.
Mike Meinz 24-Apr-13 12:57pm
You don't have to convert all your software to .NET. You could just develop your compression and decompression program using the .NET Framework.

Also, FYI, I converted all of my software to VB .NET from VB6 in 2003 using the built-in migration tool and have upgraded it recently from VB .NET 2003 to VB .NET 2012 wih very little effort.
dg6yhw11 24-Apr-13 13:04pm
I didn't know that there was a conversion tool still around, other than the tools that would cost me $20,000 to use of course.

I had totally forgotten about interop. Thanks for that suggestion.

Mike Meinz 24-Apr-13 13:13pm
To be clear, the conversion tool that I used was built into Visual Studio .NET 2003. The next version that I acquired was VS 2012. I don't know if VS 2012 or any of the other versions between my original 2003 version and VS 2012 contain the VB6 to VB .NET upgrade tool.

Sergey Alexandrovich Kryukov 24-Apr-13 12:38pm
What's your programming language?
dg6yhw11 24-Apr-13 12:47pm
Thanks for answering.

We write in VB 6.

The DOS box does still exist, albeit in very restricted size.

To execute the PKZIP25 we call the Shell function and it opens the DOS box.
Sergey Alexandrovich Kryukov 24-Apr-13 13:12pm
There is no such think as DOS box, unless you use something like Windows 95 or the like... Please do yourself a great favor and wake up... :-)
dg6yhw11 24-Apr-13 14:14pm
Kind of stong, Sergey.

I'm guessing that you might not be running US versions of Windows because the DOS box is very much alive in WIN 7 and WIN 8.

Perhaps I should call it by the term cmd prompt?

Doesn't matter, it is clear that you and other don't really understand the problem is NOT the decompression tool itself because it hase worked perfectly on the same machines with same OS before.

No the issue is that something is allowing the decompression utility to write any file EXCEPT an EXE and that this behaviour is new.

Sergey Alexandrovich Kryukov 24-Apr-13 17:07pm
I bet this is not really a "DOS box".

Don't you mean "CMD.EXE"? This is not a DOS box, not even close. This is a decent native Windows, protected-mode application, 64-bit or 32-but.
Face it: there is no "DOS box", there is no "DOS".
Sergey Alexandrovich Kryukov 24-Apr-13 17:08pm
And it does really matter. In the past "CMD prompt" was really a DOS box, absolutely different by its nature. It's not just words. You can ignore facts and say "does not matter" as much as you want, but guess who is the looser in this case?
dg6yhw11 24-Apr-13 17:18pm
OK. You win.

I'll stop calling it a DOS Box and refer to it as a "little black and white window that runs DOS programs and shows DOS commands" - or is it no longer correct to call it DOS, perhaps we should call it "command line character strings display area that can also run DOS programs"?

Sergey Alexandrovich Kryukov 24-Apr-13 17:25pm
Nobody tries to "win" you or hurt your feelings, why would you be so negative about it. I'm trying to help you because this is really important for you to understand, in relation to your ZIP problem too — I gave you a reasonable advice. No need to get irritated and use reduction ad absurdum.
dg6yhw11 24-Apr-13 18:07pm
Sergey - that was an attempt at humor.

In American English the terms DOS Box and Command prompt are identical. You use a command prompt to open a "DOS box". There is no difference. There is a "box" (= window) that is running MS-DOS, therefore it becomes a "DOS box".

There is no "technical" term "DOS Box" in Microsoft Literature that I know of.

Google it - you'll see many old references to the term: example from some university "Open a DOS Box (Command prompt)...".

You can tell I'll never be a diplomat :)
Sergey Alexandrovich Kryukov 24-Apr-13 18:26pm
I appreciate the humor and diplomacy. But I don't trust such source of information, do you? Why do you think that Google result can dictate me anything at all. Just the opposite: 95% (this figure is not a "technical" data but rather a meme, of figure of speech :- ) of the Web content is a complete trash; that includes computer information... See the point.

Could we wrap up on that?
Wish you the best of luck,
dg6yhw11 24-Apr-13 18:40pm
The matter is closed.

I really do appreciate all you've done, seriously.

Sergey Alexandrovich Kryukov 24-Apr-13 18:44pm
Thank you very much for your nice words.
I even pretty much sure that you could use my advice and even accept it formally. :-)
dg6yhw11 24-Apr-13 13:01pm
Thanks for the Solution Sergey but it doesn't address the root issue.

Even though PKZIP25 is an ancient relic, it still decompresses the file.

The newer versions will still decompress the file.

The issue is that the OS or something is stopping that from being written to the disk.

Sergey Alexandrovich Kryukov 24-Apr-13 13:09pm
How it does not address it? Not true. You application is obsolete; 7-zip will perfectly ZIP and unzip the ZIP file, and its library will do, too, as you can link it to you VB (how it's possible to work with V6 these days? any particular reason to torture yourself?).
dg6yhw11 24-Apr-13 17:03pm
Thanks for all your comments, Sergey.

The issue is not if PKZIP25 can properly unzip the file. It does. The zip file contains many more files than the one .exe and they all extract just fine. I have no reason to believe that PKZIP will consider program bits to be any different from data bits.

I said your solution does not address the issue because the issue is that the file is not written to the disk when it is unzipped, AND this is new! The PKZIP worked perfectly, extracted all files, in early March. Now for some mysterious reason it no longer works for .exe files.

It was my hope that someone would know if, perhaps, M$ had added some new layer of security or whatever that only affected programmatic writing of executable files to the disk... or something similar.

We use VB6 because our software works. There is no advantage to our users to try to go from a stable, compiled environment to something bloated, interpreted and god-awfully slow, that only offers features that benefit our programmers doctors (by requiring much hand surgury due to all the typing!!!) To all you soon to be commenters yes - I know about intellisense.

We sell heads-down keyboard entry software where speed and accuracy is of utmost importance. There is no bling wanted or needed.

It would be much greater torture to rewrite all that code :)
Sergey Alexandrovich Kryukov 24-Apr-13 21:22pm
I understand the heaviness of this situation.
Wish you the best of luck, call again.
Zoltán Zörgő 24-Apr-13 13:45pm
Sergey is absolutely right. You don't need to translate/rewrite your whole code to .net (although those 250k of lines are not that much and you would wonder how much coding burden .net is taking from your shoulders), just make your installer to keep up with the time and technology. There are several free zip implementations for .net you could use. I like very much command line tools, but a PKZIP 2.5 is dating from 1998, and the highest windows version it was intended to support is NT4 - version 9 and above is supposed to support Windows 7. Well, I am really not wondering that you encountered problems, I am wondering how you managed not to encounter problems till now...
Just a note: I would never buy a software that is built on the technology you are still using, and the vendor is not committed to support win7 or 2008R2 at least without hacking the system. Not speaking about the GUI: those old applications were designed with other thoughts in mind than usability and ergonomy and even less nice look - things that current users wishes to have.
Sergey Alexandrovich Kryukov 24-Apr-13 14:33pm
Very good points here, Zoltán.

1 solution

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

Using any excavated artifacts like PKZIP25 these days looks quite weird, to say the least. Moreover, I would not even consider using any separate application. You can easily embed one of the libraries working with ZIP in your code. The first one which comes to mind is open-source 7-ZIP:[^],[^].

Depending on the platform and language you use, chances are, you can find bindings for them. In particular, this is a .NET wrapper:[^].

Even better, you could switch to Microsoft technology for Patching and Upgrades. Please start here:[^].


After OP's clarification on the language: even with VB6, you can use the ZIP library:[^].


This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170622.1 | Last Updated 24 Apr 2013
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100