Why the actual *need* of putting the fdubcd.img inside a .iso at all?
Unless there are some valid reasons (which at first sight I am completely missing 
), the current setup seems to me a lot like a matrioschka 
with compressed images expanded to memory to load images of compressed files that are expanded to memory again (ramdisk).
@Wonko, you are actually looking at this the "right" way, but I separated the "real" problem into pieces, because presenting all the story in just one topic seemed "too much", specially with so much different software involved (grub4dos, syslinux, memdisk, DOS, different booting media...).
A little bit of history, so to put things in context. In UBCD 5.0.3, fdubcd was booting a ram floppy disk, "A:". To access the DOS programs (inside cab files), fdubcd needs access to the booting media where the cabinet files were located. This access was not achieved in certain systems, so the DOS programs in cab files were not available.
In UBCD 5.1, the floppy image was inserted into a new fdubcd.iso, which now contains all the files that need to be accessed by fdubcd DOS. By using these 2 images, fdubcd was still booting to "A:" (fdubcd.img) and memdisk could still access the content of fdubcd.iso as an additional ramdrive. The only purpose of "booting" this fdubcd.iso was to provide (assure) access to the DOS programs, while still booting fdubcd using "A:".
The purpose of having grub4dos is to give more chances to boot into fdubcd, when memdisk fails for whichever reason. In UBCD 5.0.3, the entry for grub4dos was working as expected, because the cab files were located directly in the booting media. Once memdisk was working as needed in UBCD 5.1 (by DOS now being able to find the cab files in the ramdrive originated by fdubcd.iso), the entry in grub4dos needs a correction. As in UBCD 5.0.3, grub4dos is able to find the original boot media, but now the cab files are inside the new ramdrive based on fdubcd.iso; hence the current topic.
In theory, there are _other_ alternatives, without fdubcd.iso. Using a superfloppy image for fdubcd.img is one, and using a hdd image for fdubcd.img is another. Both options have their own negative effects.
The alternative I presented in this topic keeps both fdubcd.img and fdubcd.iso as in UBCD 5.1.1, by trying to find an adequate grub4dos entry.
But the ideal alternative would be to find the "real" problem: how to get access to the booting media (CD media or UFD) once the floppy image, fdubcd.img, boots (by means of memdisk) into fdubcd DOS. Solving _this_ problem would solve all the questions: we can get fdubcd.iso out of the equation, we don't need to find other alternatives with their own negative effects, the boot process would be faster and even more advantages that I'd rather avoid mixing in this topic.
In UBCD 5.1.1, we can still reproduce the original "real" problem. By using the method
Icecube described above ("dynamically" change the config for cd-roms while booting fdubcd, which I also do in my tests), we can see in Volkov Commander that all the CD-ROM drive letters are available for DOS, but when we try to display the content of those CD drives, it can't be shown and fdubcd DOS might hang. This behavior suggests that maybe something in the DOS scripts is not quite right, as DOS recognizes the drives, assigns them drive letters, but can't access their contents. Solving _this_ problem is the "real" solution for UBCD.
@ady +@Steve6375
Besides the "right" way with (hd96) (which still uses however the memdisk inside fdubcd.iso.gz)
this works alright for me in Qemu:
map --mem /ubcd/images/fdubcd.iso.gz (hd32)
map --hook
map --mem (hd32)/fdubcd.img (fd0)
map (hd32) (cd)
map --hook
root (fd0)
chainloader +1
boot
and should be more or less the answer to the first question, i.e. how to boot from CD bypassing completely the memdisk.
Seemingly if the .iso image is mapped to (cd) the driver "catches it", while it doesn't until it is mapped to (hd32) or similar. 
@Wonko, is that code working without having the content of fdubcd.iso (and maybe also the content of fdubcd.img) also available directly in the boot media? As I said before, when the content of fdubcd.iso and fdubcd.img is also available in the boot media, the grub4dos entry in UBCD 5.1.1 indeed works correctly and all the DOS programs are available. But having the same information 2 and 3 times in UBCD seems an expensive workaround. Please confirm if in the above test the content of fdubcd.iso is also copied into the booting media, or if instead you are using UBCD 5.1.1 "as-is" with the only exception of that grub4dos entry.
TIA,
Ady.
Edited by ady, 21 December 2012 - 01:47 PM.
came in, I will dare 
then the one in UBCD5.11.
, and all the other variations I listed and a few more.
