Working in memory

A memory stream would be in memory.
If you want to map a file on disk into memory you could use filemapping but it's not directly supported by the .net framework.

Is there any way to basically do the same thing with a compressed file.  Just say a zipped file.  The reason being is that there is an application that catalogs medical image files into a database.  This medical image is a dicom file that is compressed.  The file contains header information that must be extracted to load into our database.  The way we are doing it now is having to use an activex control to decompress the file into another file on the hard drive and then reading the header information.  The activex control function that decompresses the file takes and input file and an output file as a parameter.  Is there basically any way to decompress files to memory instead of a physical file on disk?????????????

Thanks
Kendal

You probably can't override the internal workings of you ActiveX control, but you could switch to another compression utility that allows you to work in memory (such as #ziplib http://www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx).

I will look into that tool.  I believe I have used it in the past to my satisfaction.  I will just have to determine whether it can decompress a dicom file(the format that these medical files are compressed to).  Would you happen to know?

Thanks,
Kendal

First, I must say that from my knowledge of DICOM files (I have some experience in medical imaging as well),
Their headers are usually not compressed (if these files comply with the DICOM standards) - Only the pixel data is compressed.
So, basically, if all you need is the headers, you can read them without decompressing the whole file.


If not, here's a crazy idea for a solution that COULD work (it's a little out there...)
What you could "theoretically" do is as follows: (The ActiveX implementation might not enable using this technique)

Create a named pipe. Named pipes have special "filenames" to open them
a named pipe has a filename that mapps to it: \\.\pipe\PipeName
(Look up CreateNamedPipe in the MSDN)

Named pipes don't have .NET framework support built in, you will need to do some PInvokes.

You could create such a named pipe, call the ActiveX passing the named pipe as a parameter, and read/write on the other end of the pipe depending on whether you want to use it as a source or destination "file". Then you would achieve what you wanted: decompress into memory.

Important Note:
Pipes have various I/O modes including blocking vs non-blocking. You may have to create a separate thread to read from the pipe that the ActiveX writes to for example (especially if the decompressed data is big).

Like I said, It's quite "out there" ;)

Hope this helps,
Eran

Let me elaborate a little more on this situation.  This is not exactly my project, but my coworkers.  I have had a little doings with this.  What we have are compressed dicom files on a PACS server.  Once files are sent to the PACS server, it automatically compresses the files.  The current application's purpose is to go through these files and catalog them into a database.  The database needs certain information that is only available in the header file of the dicom file.  So currently the application uses an activex control called ZLibTool to decompress the file over the network to the local machine.  Once decompressed, the application uses another activex control called ezdicom to open the uncompressed dicom file and access the header information.  The header information is actually embedded into the dicom file.  So in an attempt to speed up the application and not have to uncompress the file over the network to the local machine, I was looking for a way to uncompress into memory and then access that dicom files header information.  So far I think I might be able to make the ZipLib(posted above) work for the decompression into memory, I am still working on that.  Next would be the ezdicom activex control.  I think I am going to have to stick with that control to access the header information as I cannot find any other open source utility that can do that.  The only problem ezdicom presents is that a service does not want to allow activex controls.  I did find a workaround though.  Add a form to the service, add the ezdicom control to the form, instantiate the form, and never show the form.  Therefore I have access to the control through the form and the form will never show.  How does all of that sound???

Thanks,
Kendal

Underneath it all, an ActiveX is merely a COM object that you should be able to use even without a form.

It is possible however that the ezDicom specifically requires a hosting WINDOW in order to operate.
Using a form as a solution sounds ok... (if simple COM doesn't work)

If I was to try it without a form, how could I access the COM object?  The only way so far I have been able to use it is to drag and drop the activex control from the toolbar, when I do the axezdicommax reference is added.  There are 2 references to the ezdicom tool, ezdicommax and axezdicommax.  I can manually add ezdicommax, but the only way the axezdicommax is added is when I drag and drop the control.  That is the only time that I can access the methods of the control that allow for header extraction.  What do you think?????

Thanks,
Kendal

Thank you both for the info.  Eternal, you answered the part of the question about working and unzipping in memory, and Eran, you answered my part about the DICOM files.  Excellent information and examples.  I have gladly split the points between the two of you.  

Thanks again for all of the help.
Kendal