Compressing Data in VC
We have an application we run on Windows NT and Windows 2000 servers (we are finally just upgrading to 2000). This application has a number of components, but we have a question that is related to 2 of them that handle printing specifically.
The first of these components creates PS files from PS data it finds in an MQ Series queue. It saves to a UNC, although the \\server\share\file.ps is currently local to the server upon which the component is running.
The second program copies those to a printer via that printer's UNC (which is part of the filename). These printers are across the network.
These PS files can often be relatively big (1-2 MB) because they have embedded Asian language fonts. At the same time, the reason they have these fonts is that they are destined for printers in Asian countries. The networking to these countries is pretty poor and it can take 5-10 minutes to send the file to the remote printer. That's a problem when we're sending thousands of files in a day.
We can't reduce the content of the PS file, but we think we could compress the file as we send it across the network. The files compress to about 1/3 of their original size when we zip them.
We are thinking of having the first program saves to a remote UNC, and running the second program on those remote servers (the servers being in the same office as the printers). We might even be able to do this with a workstation.
These components were written in Visual C/C++. We originally wrote them in VS v6.0, but we're now working with it within the Visual Studio .Net framework (but it's not managed code or anything). These two components run as Windows services (they have the necessary service code in them).
We're rather not purchase a vendor DLL if we don't need to and we would like to know if there is a Windows API for compressing/decompressing data or files already available that we could test and use?
The first of these components creates PS files from PS data it finds in an MQ Series queue. It saves to a UNC, although the \\server\share\file.ps is currently local to the server upon which the component is running.
The second program copies those to a printer via that printer's UNC (which is part of the filename). These printers are across the network.
These PS files can often be relatively big (1-2 MB) because they have embedded Asian language fonts. At the same time, the reason they have these fonts is that they are destined for printers in Asian countries. The networking to these countries is pretty poor and it can take 5-10 minutes to send the file to the remote printer. That's a problem when we're sending thousands of files in a day.
We can't reduce the content of the PS file, but we think we could compress the file as we send it across the network. The files compress to about 1/3 of their original size when we zip them.
We are thinking of having the first program saves to a remote UNC, and running the second program on those remote servers (the servers being in the same office as the printers). We might even be able to do this with a workstation.
These components were written in Visual C/C++. We originally wrote them in VS v6.0, but we're now working with it within the Visual Studio .Net framework (but it's not managed code or anything). These two components run as Windows services (they have the necessary service code in them).
We're rather not purchase a vendor DLL if we don't need to and we would like to know if there is a Windows API for compressing/decompressing data or files already available that we could test and use?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
our experience is that shelling to command-line is fairly error prone and provides very poor diagnostics information upon failure. We have the data we need to compress in memory (from MQ), so we want to compress that string and do the write to the UNC. If that doesn't work, we'll fail back to something lesser.
I would have expected Windows 2000 and XP to have some sort of compression API, at the very least to support the compression it does itself.
We could use Dynazip (it's not too expensive), but just thought there would be something around.
I would have expected Windows 2000 and XP to have some sort of compression API, at the very least to support the compression it does itself.
We could use Dynazip (it's not too expensive), but just thought there would be something around.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
there is a numer algorithms and different implementations available, as source code or library, but the concept of combining different (small) utilities or modules togeather (like piping the data to the next process) is much safer than trying to incorporate everything into a single application. So if an improvement or bug correction is dont to a part of it (like file compression), you just exchange it without having to recompile and eventually change other parts.
shelling to command line is more error prone only if you don't check the resulting error code.
one important questio is how do you want to decompress the file.
hth,
g.
shelling to command line is more error prone only if you don't check the resulting error code.
one important questio is how do you want to decompress the file.
hth,
g.
ASKER
We have 2 programs, one that writes the data to a file and another that reads the file and prints it. We want the first to compress and the second to decompress, in memory.
Command-line is more error prone regardless of checking. The options of available exit codes is gernally poorer for command-line utilities.
So far as combining modules, we're talking about a program that is 1-2000 lines of size, which is hardly monolithic. Our application is already comprized of 12 interoperating components (sharing information via MQ queues).
We also don't want open source. We want something commercially supported. We find that works best for support.
Command-line is more error prone regardless of checking. The options of available exit codes is gernally poorer for command-line utilities.
So far as combining modules, we're talking about a program that is 1-2000 lines of size, which is hardly monolithic. Our application is already comprized of 12 interoperating components (sharing information via MQ queues).
We also don't want open source. We want something commercially supported. We find that works best for support.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
PS: did you know Solaris 10, the OS of Sun is going open source?
then copy it to the remote computer. There, you can uncompress it directly to the print spooler.
There are several (command-line) compression utilities, many of them are free to use even for commercial applications:
gzip, zip, winzip command line interface, arj, rar, lha, ...
You may first want to test which of them compresses your files best and fast.
If this is an issue, use .zip files so even windows-only people will know what they are an how to unpack them.
gl,
georg
PS: winXP has "built-in" zipping, but it is a dll and the user interface is crap, and so there is no convenient way to call it
out of an application or command line.