If I understand correctly with the method you're describing you'd have to create an image, put an partition table in there, put a FAT-partition in it and place the ISO into that FAT-partition. I guess some bootsector will be written into the image to allow chainloading the ISO. Then through DriveDroid the image would act as an USB stick and could be accessed from Windows to place ISO files onto.
Let's start again form scratch (I am not familiar with the way DriveDroid works, nor with Android, so I will just try and explain how the methoid works on a "normal" USB stick, SD card or anyway *any*device that is seen by BIOS and that is - or can be - partitoned).
A "partitioned" device (or "hard-disk-like") means that it's first (512 bytes) sector is a MBR (Master Boot Record)
No matter if the MBR contains booting CODE or not it will ALWAYS contain at least TWO sets of DATA:
- the partition table, i.e. 4 (four) 16 byte each entries at offset 446, that are commonly numbered (using grub4dos and many other tools 0 based numbering convention) as #0, #1, #2 and #3
- the "Magic bytes" 0x55AA at offset 510
Most "small" partitioned devices will have only one partition entry filled with actual partition addresses, at the most two.
If you prefer 99.99% devices will have either of:
- one single Primary partition spanning over the whole device size, and whose addresses will occupy entry #0
- two Primary partitions, the first spanning over almost the whole device size and the second - often called "fake" partition - spanning over the last cylinder (this is created by some tools to increase the chances that a BIOS will recognize the device as "hard disk-like") that will occupy entries #0 and #1
- one Primary partition and one single Extended partition (that can contain more than one volume) and that will also occupy entries #0 and #2
Even if there is a third partition in use, it will occupy entry #2, so in 99.999999999% of cases the entry #3 - addressed in grub4dos as (hdn,3) will be empty (all 00's).
Any Dos and Windows will check the partition ID in all partition entries and if one has an ID of 0x00 the entry will be considered "empty/not valid").
Any Linux will check the partition entries and NO matter the ID will check if there is *anything* it can mount/recognize at a given address (provided that the address itself is not all 00's).
So, you copy the .iso file to the filesystem on the pre-esisting parittion (no matter if FAT, FAT32 NTFS or Ext2/3/4 as grub4dos can access all of them, with a small caveat that will talk about later), let's say that your .iso file is called Mylinux.iso (and that you can access it as a file from DOS/Windows as - say - F:\Mylinux.iso or from Linux as /mnt/sda1/Mylinux.iso.
Using the partnew command in grub4dos (but as said you can do the same with any hex/disk editor) you simply write to the MBR, in entry #3 the "blocklist" that belong to the file Mylinux.iso (in the form of both CHS and LBA address i.e. along the "syntax" that the MBR entry requires).
Then you use the grub4dos (but as said you can probably use another loader) to map (temporarily) the /Mylinux.iso to a "virtual CD" drive and chainload this Virtual CD drive "as is".
Typically a Linux CD (or .iso) will attempt (and succeed) to load in "real mode" two things:
- a kernel
- a intird (initial Ram Disk)
as soon as those are loaded it will switch to "protected mode" (and the grub4dos virtual CD" will "cease to exist").
A number of Linux Distro's already have provisions built-in to find and load the actual .iso file (if you prefer to create a new Virtual CD with the contents of the .iso), but all of them, even those that do not have that provision, will scan the MBR of the "hard-disk-like" device and will find the entry written earlier and treat the disk sectors addressed there as if they were an actual partition (or volume).
If you prefer we are providing the Linux kernel a way to access the SAME area with two different methords, as "file" or as "volume".
The little caveat I hinted about before with Ext2/3/4 is that the actual Mylinux.iso file NEEDS to be contiguous to allow being mapped as a partition/volume in the MBR and this is not always the case on these filesystem (and since the good Linux guys after all these years are still in full denial mode abnot the possibility that a large file may be fragmented on ext2/3/4 filesystem there is not AFAIK a remedy for this -when it happens).
Now, what I don't know is if your nice app exposes the actual "whole device" or only the "partition" (or "volume" or the *whatever* that gets a drive letter in Dos/Windows) i.e. if the first sector of the *whatever* it exposes is a MBR or a PBR.
If the latter, it is still possible (at least for FAT16/32, proved, but I believe for NTFS also) to modify the PBR in such a way that is at the same time a PBR and a "fake" MBR (thus allowing the needed four partition entries).
This is BTW the approach traditionally used by makebootfat:
The 4 Gb is a limit of the FAT32 filesystem, but it relates to a single file, so you can have as many up-to-4-Gb-in-size .iso images as they fit in the actual SDcard available space, as each time you boot you can select WHICH image you map in the partition table.
I hope this clears the matter.
If you explain in more details what your nice app "exposes", I am sure we can help you to find a suitable solution, be it involving grub4dos or not.