On 21/09/15 01:55, Jerome H. Fine wrote:
I used the above example when I created a CD which had files to be used
with RT-11 in addition to being a normal CD under Windows. I found that
for a normal CD under Windows, sectors 0 to 15 (hard disk blocks 0 to 63)
on the CD were empty. I don't know if that area is reserved for boot
code
under Windows when the CD is bootable, but my goal did not require the
CD to be bootable under Windows.
I did something very similar (or rather, used someone else's code to do
something
very similar) with ODS-2 under OpenVMS and ISO9660 (which is what Windows
uses for CD media iirc).
As you say, ISO9660 leaves the first 16 (or thereabouts) 2048 byte
blocks undefined.
ODS-2, on the other hand, uses them. So the code builds an ISO9660 CD
and then
overlays the ODS-2 structure on top. It finds the ISO9660 directory
structures and
arranges for them to live in BADBLK.SYS so VMS is happy enough when
mounting the
media. All the ODS-2 structures get packed into the beginning of the
image so anything
looking at the ISO9660 side sees nothing untoward. This only works well
for filetypes
that have no special structure under ODS-2: basically CR-LF text files
and binary
formats (such as PDF). I still have a CD that I built this way many
moons ago.
I remember reading a message in one of the EASYnet NOTES conferences
(inside DEC) which more or less said that ISO9660 leaving those initial
blocks
free wasn't a coincidence and that DEC's representative (Andy Goldstein
perhaps)
had pushed for that.
Antonio
arcarl...@iee.org
