-
Notifications
You must be signed in to change notification settings - Fork 0
05 SampleProgram
SampleProgram is a windows console application project that builds and integrates the features of this solution.
SampleProgram consists of main ripper and tray_door_lock. main is the main program and entrypoint that uses ripper to create an ISO 9660 image of any CDROM/DVD media found in the drive.
ripper demonstrates RAII paradigm by locking the cdrom tray door, and unlocking it on all return paths.
The main program makes fixed hard coded selection of the first physical cdrom drive found in the system at runtime. It logs to a fixed hard coded log file called "ripper.log", and creates an iso image file in the fixed hard coded location "cdrom_image.iso".
The main program now shows progress message during the rip/read operation that typically takes some minutes to complete. The progress indication has been added by modifying the behaviour of cd_rom_device::get_image() This used to issue a single large blocking synchronous read operation to the underlying kernel device. While that approach is/was optimal for efficiency, it offered no opportunity to maintain a progress tracking value, e.g. to be interrogated by a std::thread for the purpose of showing progress to the user. A method simulate_resource_limitation() now leverages the out-of-resource exception handling - which falls back to use ever more granular (cylinder, track, and sector sized) reads if memory is scarce. At 'cylinder size', it is very easy to track %progress over the rip. However, this will not be a reliable progress indication if a real out of resource exception occurs.
Large dvd images can exceed the virtual address space available to the 32-bit build binaries. In these circumstances an exception will be reported (to the console).
Image files ripped from cd's that are not ISO 9660 format, obviously won't be ISO 9660 compliant, and the fixed .iso extension of the image file will then be a falsehood. Windows will advise you that such a file is 'corrupt'. On Windows 10 Home 1803 edition the file won't be mountable, and if you try, you will need to eject the failed new volume (visible in the left panel of the file explorer), before the backing file can be accessed or deleted. With all of Windows 7-10 you'll see something similar to this.
Signalled program termination (Eg ctrl+break ctrl+c) demonstrate an important limitation of RAII. Destructors are not invoked if a process is signalled to stop. A terminated process releases its resources more brutally. This means that system state cannot be reliably restored using RAII techniques alone, and that fact compromises the design (that I naïvely selected to use). If the program is terminated in this way during reading (when the CDROM tray door is locked) then the door will remain in the locked state. This could pose a real practical difficulty because the kernel device may refuse an unlock request coming from a different process from the one that locked it, and you might need to reboot to get your disk back! This whole effect will only be visible if your hardware supports tray door locking. Hint: As an exercise, provide signal handler(s) and issue a preventative speculative unlock whenever the program is signalled to stop.