Burning CD with IMAPI - how to avoid creating temporary files?

  • Thread starter Thread starter Ahti Legonkov
  • Start date Start date
A

Ahti Legonkov

Hello!

I am writing an application that will run in a system where there is
only a 1Gb flash drive where XPe, the application and database
resides. The users must be able to copy some or all of the data to a CD.
After hours of googling and surfing msdn I finally managed to build a
program that writes some files to multi-session CD using IMAPI. But
these IStorage and IStream bits (see code below) are bothering me -
the data doesn't get written to CD until RecordDisc is called.
Obviously the staged data must be kept somewhere (most probably in
some directory on the flash drive). It poses a problem - if there
isn't enough free flash drive space, I would not able to burn a CD. It
must be possible to burn CD without making copies of files prior to
burning (nero and roxio don't copy). But is it possible with IMAPI? If
it is then how would I do that? Should I look into third party APIs
instead?

// select recorder and set format etc.
//...

// XXX: can this be done without temporary files?
CComPtr<IStorage> pStorage;
StgCreateDocfile(L"test", STGM_DIRECT | STGM_CREATE |
STGM_READWRITE | STGM_SHARE_EXCLUSIVE, NULL, &pStorage);
{
CComPtr<IStream> pStream;
pStorage->CreateStream(L"file.txt", STGM_DIRECT | STGM_CREATE |
STGM_READWRITE | STGM_SHARE_EXCLUSIVE, 0, 0, &pStream);
DWORD dw = 0;
pStream->Write("1234567890", 10, &dw);
}

pJolietDiscMaster->AddData(pStorage, 0);
pDiscmMster->RecordDisc(false, true);


Thanks!
 
Ahti,

I am not an expect in IMAPI but I think what you are talking about is called direct UDF packet-writing on disc feature.
You'd need to install a 3rd party UDF packet writing driver for direct drive letter access to your CD/DVD drive. It makes your CD or
DVD drive act as a standard, transparently write-enabled drive. Nero (InCD) and Roxio (DirectCD) support the feature. Also, IBM DLA
(used to be free, I don't know if it is still free now) supports it as well.

Also, take a look at the MountRainier drive technologies. It is not the same but still provides a transparent way to access
compliant CD/DVD drives.

Other than above, I don't think there is a way to force IMAPI to avoid creating temporary times for staging (if there are IMAPI
experts out there, please correct me if I am wrong here).
You can move the CD recoding temporary storage though to another partition. Here is the steps how you do that:
http://support.microsoft.com/kb/308572. (if you deal with HKUS\.DEFAULT branch you can set this up for all users). Although I may be
useless with the set up you've got there unless you care willing to split the drive in two partitions leaving the second one for the
recording cache only.
 
KM said:
Other than above, I don't think there is a way to force IMAPI to avoid creating temporary times for staging (if there are IMAPI
experts out there, please correct me if I am wrong here).
Click to expand...

I was thinking about this and got an idea - it may be possible if I
provide my own implementations of IStorage and IStream. Has anyone
tried that? Any pitfalls to be aware of?
You can move the CD recoding temporary storage though to another partition.
Click to expand...

Well, I am not the one that makes decisions about this particular
hardware setup, so in this case unfortunately the idea of creating CD
recording cache partition isn't very useful.
 
Hi Ahti,

I have only involved in XPe development for a few weeks but I have written
an application by using IMAPI for a few months. I have encountered similar
problem that you had. The temporary files created by IMAPI quickly max out
my hard drive as I did my test multiple times. In my case, I was using a
newer API to create a temporary file, StgCreateStorageEx() with a specified
filename in the first parameter. You used StgCreateDocfile(L"test",
STGM_DIRECT | STGM_CREATE |
STGM_READWRITE | STGM_SHARE_EXCLUSIVE, NULL, &pStorage). It is not
hard to imagine you max out your flash drive quickly because it has only 1Gb.
The flash drive may not even have 650 or 700 MB space for a regular CD
capacity when you exclude the space occupied by your embedded OS. The
situation is even worse when those temporary files got accumulated when you
specified "test" as the temporary file name. My suggestion is 1) Use newer
API call, StgCreateStorageEx() to create temporary storage with "NULL" as
your first parameter. The temporary file will be removed automatically once
data has been added to the stage image. This should eliminate the
accumulation of temporary files over time. I suspect it works the same with
your StgCreateDocfile(). Second, if specifying null as first parameter
doesn't help, then very obvious your application in flash drive need more
storage space, you may have to consider using 2GB or 4 GB flash drive which
are not very expansive nowdays.

I also have my own question for you guys. My IMAPI application ran well in
Windows XP Professional and data written to CDs without problem. However,
when I ran it on my newly created windows XP Embedded (SP2, not Feature Pack
2007) in the same machine but different partitions, it didn't work. The call

pIStorage->CreateStorage(wVolumeName, STGM_READWRITE|STGM_SHARE_EXCLUSIVE,
0, 0, &pIVolumeStorage)
returns pIVolumeStorage as a null. As a result, I couldn't create a folder
in the CD and I couldn't copy files to the CD. I have tried the following
things but they didn't work.
1) I have included Ole32.dll in "Program Files\System32" in the embedded
image, that is required by CreateStorage() in MSDN. It didn't work.
2) Then I registered Ole32.dll in my XP Embedded environment. The
registration succeeded but I still got a null pointer for pIVolumeStorage
when I ran my application.
3) Then I changed the IMAPI application folder to allow everyone "full
control". Still it didn't work.

I ran out of options, can anybody help?
 
Chip,

If you mentioned the hresult code you get from the API call, it would help.

You may want to monitor your API cal with tools like Regmon/Process Monitor to see what registry class entries are getting accessed
ad not resolved. Likely, a required COM object is missing from your image.
 
Back
Top