#1 Burning Software

Hello,

I am currently creating a CdvdBurnerGrabber object on process start-up and then maintaining that object over the lifetime of the process. That seems to work fine for internal devices that can't be removed while the process is running.

We will soon be testing USB-based devices which can be plugged and unplugged as the user wishes while our process is running. Can you tell me if unplugging the USB-based device while we have an open CdvdBurnerGrabber object will invalidate that object for all time (e.g. an open file handle goes bad)? Or will the CdvdBurnerGrabber just return errors while the device is unplugged, but successfully reconnect and continue as before after the device gets plugged back in? Is there a way to detect that the CdvdBurnerGrabber has gone stale due to device removal?

Thanks!
Chris

Yes of course. We keep handle to USB device inside StarBurn. If you're using "Safely Remove Hardware" Wizard to disconnect your hardware (proper way) - Windows would not allow you to remove USB (or any external like FireWire or maybe eSATA) burner while it's in use with StarBurn. However if you use brutal disconnect (software or manually) - we can do nothing with it. Handle would be invalidated and StarBurn would return error at the next device access.

What you say is simply undoable Nobady would guarantee device would appear under it's name, using the same address. We just cannot recognize two say USB burners with the same names and firmware revision. So even if we'd like to rewrite all of the PnP stuff Windows has inside of the StarBurn we cannot stop at random place and just continue execution perfectly when device like you say would be plugged back.

Thanks...that was my suspicion...I will just have to delete the burner grabber object once it goes bad and create a new one when the device gets plugged back in.

-Chris

Yes. However you'll have hard times processing WM_DEVICECHANGE system message as you'll have no idea it's OLD hardware returned (could be new one... Different one).

Also be very careful with manual disconnect. Quite a lot of the software installs SCSI filters and they may break when device would just go away telling nothing to nobady.

Thanks!

Oh... One more thing. If you're using SPTI transport it's a bad idea to keep handle opened all the time. B/s windows would not be able to mount fresh new file system after you've recorded the CD/DVD - somebody (Starburn) has handle opened over the volume. So correct way to code your software is:

1) enumerate devices. keep SCSI addresses (for ASPI) or device names (for SPTI).

2) when required - create device object using stuff from (1) and do all job (burning-grabbing etc)

3) destory device object

That's proper way all of the software is created We do have some plays with device handle inside ASPi layer so you CAN have device object opened all of the time but in general it's a bad idea (you make RDS cheat Windows storage stack). If you're coding your software from the scratch - do in the proper way from the very beginning

My 0.02$

Thank you very much!

Thanks very much for your input! I'm not coding from scratch but I always refactor to do it the right way . Will get right on it...

-Chris

No problem

P.S. I'm checking long names support for the memory files and callback names for them. Would write down estimates today or tomorrow.