50 replies to this topic

[sambul61]

I placed a bootable .ima FreeDOS based floppy image onto a multiboot ISO host file. Both the ISO image and Floppy image on it are booted via Grub4DOS. My problem is, how to access additional files I placed on the same ISO, after booting from the Floppy image? I can probably use SHSUCDRD.exe for that. But how to make the floppy aware, what ISO file it's booted from? It can help to avoid problems, if the ISO image location has being changed later - and it will change if used on a different PC.

Edited by sambul61, 22 November 2010 - 04:53 AM.

[Wonko the Sane]

Use grub4dos to write in a .ini file of some kind, or directly edit with it a .bat that calls SHSUCDRD.exe with the "right parameters.
You will need to have a "conventional" naming scheme, such as an 8.3 one.


Wonko

[Icecube]

Because you already loaded the ISO image with grub4dos, you don't need to know the filename because the BIOS can now see the ISO as CD drive.
You just need SHSUCDX to access the ISO via its drive letter:
http://www.reocities...ucdx/index.html

[Sha0]

If you are not burning the .ISO to an actual, physical disc, but are mapping the .ISO as a drive with GRUB4DOS or MEMDISK, then you might wish to use the ElTorito.sys driver for DOS, courtesy of Bart Lagerweij and Gary Tong, which is included with Syslinux. It is a driver which should find .ISO-mapped disc drives, rather than physical optical disc drives.

[sambul61]

Wonko

Would 8.3 naming conversion presume not only 8-character ISO file name, but also mandatory placement of the file in root directory of a hard drive instead of arbitrary dir?

Icecube

What routing can find the ISO device ID mounted with grldr? Should I use SCSIMGR for this? Its required by SHSUCDX to assign a drive letter to the ISO.

Sha0

Will look at ELTorito.sys driver as well. But I'd like to try a more universal approach 1-st.

Edited by sambul61, 22 November 2010 - 05:17 PM.

[Wonko the Sane]

Would 8.3 naming conversion presume not only 8-character ISO file name, but also mandatory placement of the file in root directory of a hard drive instead of arbitrary dir?

That was just an idea if you really want to use SHSUCDRD.exe.

The write and dd commands of grub4dos can be used, but if you know the actual length of the string it is much easier, as dd has some limitations.

I mean, say you have a MOUNTRCD.BAT with contents like:

SHSUCDRD.EXE /F:?X:\images\my_iso_1.iso

You write a grub4dos command that replaces last (8+3+2) characters of the file, (filename+extension+CR+LF) with another string.
But you need all images in X:\images\.

Or you can replace the last (10+8+3+2) characters and have the image virtually anywhere, but still on a "same length" path.

More generally, WHY risking any conflict with:

• Filesystem
• Long Filenames
• Accented characters
• etc.

if NOT really, really needed?


Of course the other more "direct" solutions suggested by Icecube and Sha0 are much easier, you asked for it talking about SHSUCDRD...

More generally I don't understand the *need* or *usefulness* of .iso in this kind of context when we have HD images that work allright and need NOT ANY driver.

And even more generally, the "general idea" to get the best help is to ask about the GOAL (as opposed to the means through which you think "right" to reach it) this way it is possible that even more methods/paths can be suggested, possibly easier/faster/less error prone.

It is very easy, when forgetting the above, to fall in the "chocolate covered banana" trap:
http://homepages.tes...red-banana.html


Wonko

[sambul61]

That's all fine about banana, but a burnt ISO image would allow to use the same Hard Drive diagnostic tools by someone with a single HD - the one to be tested. Assuming there is no USB boot support, etc. Don't forget, that's all in part about learning experience for most of us.

Regarding replacing ISO file name characters with Grub4dos, did you mean that the actual ISO file name will change on the hard drive after that and remain changed after exiting the floppy, unless restored via DOS after dismounting the ISO?

I still would like to learn how to find the mounted ISO device ID, required by SHSUCDX ?

Edited by sambul61, 22 November 2010 - 05:57 PM.

[Wonko the Sane]

Regarding replacing ISO file name characters with Grub4dos, did you mean that the actual ISO file name will change on the hard drive after that and remain changed after exiting the floppy, unless restored via DOS after dismounting the ISO?

No, only the name invoked in the batch file is changed.

Maybe there is a misunderstanding.

From your initial post I thought that you have something like:
\myisos\Image_1.iso
\myisos\Image_2.iso
\myisos\Image_3.iso
...etc.

Maybe, once again, if you could post some actual details, like a dir listing of your current (or intended) setup and a more definite goal, it may help understanding....

I still would like to learn how to find the mounted ISO device ID, required by SHSUCDX ?

Same as above.

What I can get from your OP, is:

• you have made a .iso
• this .iso contains a freedos floppy image
• this .iso boots grub4dos as an El-Torito no-emulation bootsector
• this .iso contains a number of other .iso's

Then you want to boot from BIOS to this "outer .iso" (in the form of CD or DVD), load grub4dos, map the floppy .ima image, boot from it, then access one of the several .iso images contained in the "outer".iso.

Is this right?

Have you managed to do the above but with a single .iso inside the "outer" .iso?

Or, if you prefer, have you tried to do the above but with just one of the several .iso's set as "mounted"?


Wonko

[sambul61]

Say, the pass to the host ISO is:

F:\ISO_Images\HD_Diagnostics.iso

So why renaming it with Grub4dos?

As well, the ISO contains an .ima FDD with some tools. Also on the same host ISO are several other ISO and .ima files, and simply folders with data files and applications (not packaged into any image). The first task is to access these folders on the host ISO. Since its already mounted with Grub4dos, it remains to find its device ID, so that SHSUCDX can assign a drive letter to it. Once assigned, I can access it from my booted floppy. It looks like SCSIMGR command in DOS can be used to find the ID. The question still is: how?

Edited by sambul61, 22 November 2010 - 06:42 PM.

[Sha0]

Just use ElTorito.sys. It should drive any physical optical disc drive that you have booted from, as well as any MEMDISK and GRUB4DOS mapped optical discs, also.

[Wonko the Sane]

Say, the pass to the host ISO is:

F:\ISO_Images\HD_Diagnostics.iso

So why renaming it with Grub4dos?

Yes, evidently there is a misunderstanding.
I never said to rename ANY file, and definitely NOT what you call "host" .iso and I call "outer" .iso.
The idea was, since you asked about using SHSUCDRD, how to change the COMMAND line used to invoke it.

As well, the ISO contains an .ima FDD with some tools. Also on the same host ISO are severa other ISO and .ima files, and simply folders with data files and applications (not packaged into any image). The first task is to access these folders on the host ISO. Since its already mounted with Grub4dos, it remains to find its device ID, so that SHSUCDX can assign a drive letter to it. Once assigned, I can access it from my booted floppy. It looks like SCSIMGR command in DOS can be used to find the ID. The question still is: how?

Can you post your menu.lst?

Are you mapping just the floppy or also one of the inner .iso's?

Can you temporarily forget the "other" .iso's and have just:

• the "outer" or "host" .iso "F:\ISO_Images\HD_Diagnostics.iso"
• inside it a freedos floppy image and ONE, single .iso

Can you then post the name and path of this single "inner" .iso?

And how you are currently accessing the "outer" or "host" .iso "F:\ISO_Images\HD_Diagnostics.iso" from the booted Freedos Floppy image?

Autoexec.bat and Config.sys, please.


Wonko

[sambul61]

Starting point however is, I can't access the host ISO for now AT ALL. How to access it - that was the essence of my original question in the 1-st post (and even the title of this thread). Will try ELTorito.sys with SHSUCDX after it (if still required - it seems not from the Sha0's post).

However, if not using ELTorito, how to find out the mounted ISO Device ID? All other .bats and menus are irrelevant for now. We have a mounted ISO file, and need to find out its device ID from DOS automatically, so that we can use that "value" as SHSUCDX parameter to assign a drive letter to it.


Btw, another way to boot to DOS is to place the FreeDOS FDD image into boot sector of the host ISO. The question however remains the same: how to access the host ISO after booting it via Grub4DOS and apparently arriving at FDD DOS prompt after boot. ELTorito.sys again?

Edited by sambul61, 22 November 2010 - 07:33 PM.

[Wonko the Sane]

Starting point however is, I can't access the host ISO for now AT ALL.

I see.

However, if not using ELTorito, how to find out the mounted ISO Device ID? All other .bats and menus are irrelevant for now. We have a mounted ISO file, and need to find out its device ID from DOS automatically, so that we can use that "value" as SHSUCDX parameter to assign a drive letter to it.

No, you have a mounted .iso file.

We still don't know (since you don't post your menu.lst) HOW you are mounting this .iso.

May we have your menu.lst entry, please?

Eltorito.sys is a driver.
SHSCDX is a DOS extension.

Since CDFS is NOT inside DOS, you need BOTH the EXTENSION (MSCDEX or SHSUCDX) AND the driver suitable for your hardware CD device.

The driver for a booted "virtual" CD in no-emulation mode is Eltorito.sys:
http://www.nu2.nu/eltorito/

Examples:
http://grub4dos.sour...ex.php/Eltorito
http://syslinux.zyto..._driver_for_DOS


Wonko

[sambul61]

Thanks!

Are you saying that a mounted ISO file (as opposed to a real CD-ROM drive) doesn't get a Device ID? If it doesn't, how to use then SHSCDX to assign a drive letter to it? If it does, how to find it out?

As to mounting the host ISO from an HD via its Grub4dos menu boot:

title HD_Diagnostics ISO
map --mem (hd0,3)/ISO_Images/HD_Diagnostics.iso (hd32)
map --hook
root (hd32)
chainloader ()
boot

Then the host ISO Grub4dos menu.lst shows up, and the FDD is booted from the host ISO:

title Victoria FDD (RAM)
map (fd0) (fd1)
map --mem /VCR_FreeDOS.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1
boot

Edited by sambul61, 22 November 2010 - 10:40 PM.

[sambul61]

Wonko

Thanks for the links. Now its clear, one need both ELTorito.sys and SHSCDX to mount to a drive letter an ISO image after booting to DOS. The devil however is always in details.

So far not sure how to interpret the example claimed "working":

title booting FreeDOS from raw image (as harddisk) + FreeDOS installer CD\nit's up to the operating system to load a device driver for the virtual CD-ROM, for example:\ndevload eltorito.sys /D:eltorito\nshsucdx.com /D:eltorito
map --unsafe-boot /FreeDOS.img (hd0)
map /fdfullcd.iso (hd32)
map --hook
chainloader --force (hd0)+1

From the above it appears, Grub4DOS will by itself (assuming it includes ELTorito,sys - just wondering) mount the target ISO file after booting to a FreeDOS FDD - is that correct? All that will be done as a part of boot?

OR, the above means that Grub4DOS will write into a ramdisk an .ini file with the target ISO path:name. That name will than be used by ELTorito.sys after booting to DOS (provided the above "for example" line is included in Autoexec.bat) to mount the target ISO and assign a drive letter to it?

This causes another question: how to mount a different ISO, not included originally into Grub4DOS Menu.lst, but located on a drive, accessible after booting to DOS? Not all drives will be accessible due to driver issues, so drive letter assignments will change too compare to menu.lst. Again, how this thing is supposed to work?

What's the full list of parameters of ELTorito.sys ? Is there any meaningful documentation to ELTorito.sys? How to add a file path:name to it? On what drives it will presumably seach for ISO files - if any at all? The above "working" expression seems incomplete, as there may be many ISO images in different locations on various drives accessible from the FDD.

ndevload eltorito.sys /D:eltorito\nshsucdx.com /D:eltorito


Btw, anyone knows how to write a user input (say, an ISO file name) to a variable in FreeDOS (which can then be used in ELTorito.sys once its documentation is found or with SHSUCDRD to mount the ISO)?

Edited by sambul61, 23 November 2010 - 04:57 AM.

[Wonko the Sane]

Then the host ISO Grub4dos menu.lst shows up, and the FDD is booted from the host ISO:

title Victoria FDD (RAM)
map (fd0) (fd1)
map --mem /VCR_FreeDOS.ima (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1
boot

For the record, you NEVER need a boot command inside a menu.lst (but you need it on command line).

I see no point in exchanging floppies and then do the map --floppies=1

You see how you are again back to the multi-iso without having seemingly solved the single .iso problem?

Why don't you try from the "base"?

Set aside temporarily your project, you need to get the base before building on top of it.

Create a normal FreeDos boot floppy with a normal CD accessing set of entries with a generic CD-rom driver (like oakcdrom.sys or the like) and SHSUCDX.

Test the floppy image (as floppy) in Qemu.(mounting *any* .iso as CD)

Verify it works.

Now simply replace the generic floppy drive (say oakcdrom.sys) with eltorito.sys (changing the reference to it in config.sys).

Create a simple .iso with grub4dos as no emulation bootsector and add to it the floppy.

Have NOT a menu.lst in the .iso.

Test the .iso in Qemu:
at the grub4dos prompt, do simply:

map --mem /VCR_FreeDOS.ima (fd0)

map --hook 

root (fd0)

chainloader /kernel.sys

boot

What happens?


Wonko

[sambul61]

Hi Wonko,

Certainly, at this point selecting the right combo of commands in a Grub4DOS menu.list entry is a mistery to me. I just go by published examples, and they, as usual, reflect usage of various Grub4DOS versions by different ppl. Not surprising, something may be excessive or missing. I suspect, most users also go by example, as this program isn't easy to crack.

What's more important, it does work, I'm able to to boot the FDD after booting to ISO every time, so why experimenting with it? What's unresolved is the access to other ISO's from that FDD. However, I do understand your point: these ELTorito.sys and such very old drivers were developed for very basic staff, and don't necessarily have the ability to mount ISO's made with Grub4DOS bootsector etc. Hence, will try to simplify. Am I get it correctly, you suggest to burn a basic CD with FreeDOS FDD image on it, and try to boot that image? How this task will help in accessing ISO's from the FDD?

See, to mount ANY ISO at any time with ELTorito.sys, it's also required to have a FreeDOS "User Input-to-Variable Converter" to enter the ISO's name, or "Select a file-to-variable" utility, which is another problem to find. I tried Command Prompt's "Set /P variable=[text]" command, but its not working in FreeDOS. I also tried the tools like Readln.exe, but it seems too old to work normally in current FreeDOS ("Not enough space in environment" error, when entering a file name from its directory).

Probably, I'll convert the FDD .ima to .vhd in VMWare, following your advice, and than put that .vhd onto an ISO image or to a basic CD without Grub4DOS menu. However, to access other ISO's from that FreeDOS .vhd, the same drivers are still required (like ELTorito.sys), and we're back to the same topic again:

Where is the documentation to ELTorito.sys? What are its parameters? How it exactly works with multiple ISO's located in various places? Or, they must all be located in root of (what) drive? How to interpret the above "working" menu.lst example - you seems to be very good in analyzing Grub4DOS menu entries (and I'm quite pure on that) - why don't you try to interpret the above example?

Edited by sambul61, 23 November 2010 - 01:26 PM.

[sambul61]

How about finding a workaround? What if I make a FreeDOS based bootable USB Flash drive with required HD Diagnostics DOS-based tools? Is that possible - how exactly?

Once I made the USB Flash, will it be possible to mount located on the flash and other drives ISO and other image files after booting to it? By what means - again ELTorito.sys? If not, the only option seems to be to make a Grub4DOS based FreeDOS USB flash, and boot to each selected image file via Grub4DOS menu.lst placed on that flash. Which bring us back to the same issue, as there will be no access to other ISOs after booting to any ISO, unless...they all adhere to seemingly quite rigid unclear for now rules.

Edited by sambul61, 23 November 2010 - 03:26 PM.

[Wonko the Sane]

Well, it's quite clear that you go by "examples" (and yes, rest assured, MOST people do the same ).

BUT the grub4dos syntax has been documented and if you take your time you can LEARN from examples (as opposed to copy and paste from them).

As an example, if you take some time reading the guide:
http://www.boot-land...?showtopic=5187
http://diddy.boot-la...os/Grub4dos.htm
Particularly these parts:
http://diddy.boot-la...iles/basics.htm
http://diddy.boot-la...s/files/cli.htm
http://diddy.boot-la...s/files/map.htm
you should have a clearer idea if what you are doing.

You have to see grub4dos menu.lst EXACTLY as a batch file, it is a convenient way to replicate a set of instructions you issue manually.

This is also what I personally see as it's main advantage when compared to all other bootmanagers.

Typical of most bootmanagers:

• Copy an entry for the configuration file from "somewhere"
• Modify it (often "blindly") to suit specific configuration
• Try booting from it
• IF failed, boot "normally" than loop to #2

What you can do in grub4dos:

• issue a command
• see it's feedback
• loop to #1 until you get to issue the "boot" command
• If failed try another sequence of commands
• If successful write the sequence in a menu.lst entry

But here we are having a non-grub4dos problem.

It seems like you do not want (or are not able) to follow a few suggestions.

These suggestions (lately) are:

• Set aside temporarily your project, you need to get the base before building on top of it.
• Create a normal FreeDos boot floppy with a normal CD accessing set of entries with a generic CD-rom driver (like oakcdrom.sys or the like) and SHSUCDX.
• Test the floppy image (as floppy) in Qemu.(mounting *any* .iso as CD)
• Verify it works.
• Now simply replace the generic floppy drive (say oakcdrom.sys) with eltorito.sys (changing the reference to it in config.sys).
• Create a simple .iso with grub4dos as no emulation bootsector and add to it the floppy.
• Have NOT a menu.lst in the .iso.
• Test the .iso in Qemu:

You see, the problem is that if you don't want to do the above , I cannot do anything about it, if you are not able to, I can help you , just tell me which of the above 8 steps you have difficulty with, and i'll try and explain it further.

The above may be re-read at the light of the "common sense advice" attached to the Board Rules:
http://www.boot-land...?showtopic=9101
the whole Amendment #1 seems to be pertinent.

Particularly you may notice how I asked you to post your autoexec.bat and config.sys (or fdconfig.sys), I never mentioned .vhd, nor VMware, and more generally I am trying to help you in getting to the result in a step by step process, exactly to avoid the "go by example" effect, and you continue ignoring my requests or even attempting to follow the path I am desperately trying to point you at.


Wonko

[sambul61]

"Why don't you make a simple hard disk image and map it to RAM through grub4dos?" Sounds like a good advice...

The Grub4DOS Guide is not deep enough to highlight the menu.lst entries detail or give any background. I do read it and take code examples from it on priority basis. This site in general is one of the most competent, reach in content and user friendly, with very detail advice. Thank you for that!

OK, you suggest to try mounting a normal CD with oakcdrom.sys after booting from a DOS floppy instead of mounting an ISO file with eltorito.sys? I should explain earlier to have a number of CDRom drivers included on the FDD, and they work perfect every time, so all physical CDs are mounted as required. Can oakcdrom.sys mount an ISO file - I doubt, unless it's connected to QEMU as CD. Will try that... That will help to id the ISOs that mount without problems.

It seems like SHSUCDRD looks for a named ISO file in "current" dir only (where its called from), and possibly those listed in Autoexec.bat SET PATH). I assume the same for ELTorito.sys, which presumes manual input to change dir and enter the ISO name (not sure if ELTorito.sys accepts names, but SHSUCDHD.EXE does) if required after boot. Or more dirs can be auto added with SET PATH depending on drives connected, after their drive letters are assigned.

I use devload instead of config.sys entries to install all drivers (except himem.sys, etc). Everything seems to work fine with that. Is that good enough? What are the advantages of using QEMU compare to VMWare?

Now, I've an interesting question: is there any documentation to ELTorito.sys? It seems almost redundant by now.

Btw, I found a 1987 DOS utility to write a user input string to a variable: INPUT.COM It works perfect for the task in any DOS flavor. Very handy to manually enter a file path:name when required by ISO drivers.

Here is my .bat for ISO mount (where CD_MOUNT=SHCDX33E.COM):

:ISOMOUNT
@echo off
ECHO.
LH input Enter name of ISO file: /
rem LH SHSUCDHD.EXE /F:[?]%ANS%
rem SET CD_MOUNT=%CD_MOUNT% /D:*SHSU-CDH /L:0
LH eltorito.sys /D:eltorito
SET CD_MOUNT=%CD_MOUNT% /D:*eltorito /L:0
echo.
WBAT BOX " ^ Do you want to mount more ISO files? ^ ",Yes,No #2,10
IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 GOTO ISOMOUNT
:END

Edited by sambul61, 23 November 2010 - 08:52 PM.

[Wonko the Sane]

Now, I've an interesting question: is there any documentation to ELTorito.sys?

Short answer: NO.

Long one: You don't need ANY but the one you were ALREADY given:
http://syslinux.zyto..._driver_for_DOS

I'll try to translate it for you :

eltorito.sys behaves EXACTLY as ANY standard CD driver for DOS, like oakcdrom.sys, vide-cdd.sys, etc.

If you want to make it more difficult than needed, you can:

• READ the eltorito.sys page:
  http://www.nu2.nu/eltorito/
• understand that eltorito.sys is a derivative of diskemu, linked allright in the above page:
  http://www.nu2.nu/diskemu/
• READ this page, until you get to:
  

  Gary found the following solution:
  1.Boot the CD-Rom in El-Torito no-emulation mode. This allows us to read the entire CD using extended BIOS calls, on all systems.
  ....
  4. This Dos boot image loads the eltorito.sys CD-Rom driver and Dos CD-Rom extensions (mscdex.exe) to access the CD.

Wonko

[sambul61]

Sorry, I modified my previous post without seen yours. Here we go again (where CD_MOUNT=SHCDX33E.COM):

:ISOMOUNT
@echo off
ECHO.

rem INPUT Enter name of ISO file: /
rem LH DEVLOAD SHSUCDHD.EXE /F:[?]%ANS%
rem SET CD_MOUNT=%CD_MOUNT% /D:*SHSU-CDH /L:O

LH DEVLOAD ELTORITO.SYS /D:ELTOR001
SET CD_MOUNT=%CD_MOUNT% /D:*ELTOR001 /L:O
echo.
WBAT BOX " ^ Do you want to mount more ISO files? ^ ",Yes,No #2,10
IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 GOTO ISOMOUNT
:END

So far in VMWare only Linux based boot ISO's are mounted with their content readable, when connected as CDs. Will try Eltorito now. Thanks for ongoing support!

Edited by sambul61, 23 November 2010 - 09:33 PM.

[sambul61]

Just wanted to update: got "any" ISOs connected as CDs to VMWare mounted and readable after booting from the FDD, except ISOs with Grub4DOS menu.lst present in root of the ISO - those aren't readable. No lack so far mounting ISOs directly as files from the FDD. But I tried just a couple so far. These both drivers appear to be quite limited in what kind of ISO they can mount. Typical error: ~ "Can't find CD" or "Wrong file for driver".

Just tried QEMU for the 1-st time. Seems like a nice free tool, very fast and lightweight compare to VMWare. But gives more errors when loading drivers. Will try to mount ISOs under it with the FDD and see what happen.

Edited by sambul61, 24 November 2010 - 01:49 AM.

[Wonko the Sane]

Am I missing something?

Let's see if numbering the questions I can have proper answers....

These talks between deaf people are unnerving.

• Which are the "BOTH" drivers?
  I thought only eltorito.sys was involved in the test.
• Are you running "pure" Qemu or Qemu Manager?:
  http://www.davereyn.co.uk/download.htm
• Why using SHSUCDHD.EXE?
• Which tool (and with which parameters) are you using to create the .iso's?
• Again with the multiple .iso obsession?
  I was trying to have you test SHSUCDX.EXE + eltorito.sys with ONLY one .iso (the "host" or "outer" one).
• Why can't you start with simple things before going on to complex (and seemingly not working) ones?

Wonko

[sambul61]

Hi Wonko!

Thanks for the link to QEMU Manager! Will try it, may be it fixes (does it?) the QEMU for Win 0.13.0 error, making impossible to use HDD images under DOS (with the XDMA driver used):

XDMA V3.3, 2-15-2006
BAD UltraDMA controller; XDMA not loaded!

It seems to be attributed (or was then) to this cause. Waiting for Takeda (current maintainer) to clarify the issue and / or suggest a different driver (that would require extra effort to make changes to the FDD, as one thing always depends on the other).

Two ISO drivers in my above .bat file? To find the one which can mount the ISO, another driver can't.
"SHSUCDHD Emulates one or more CD-ROMs using image files" (from its Readme). Here is a more generic .bat file:

:ISOMOUNT1
@echo off
ECHO.
WBAT BOX " ^ Load ISO driver for DOS/Linux? ^ ",Dos,Lin #1,10
IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 GOTO ISOMOUNT3
:ISOMOUNT2
DEVLOAD /V ELTORITO.SYS /D:?ELTOR001
SHCDX33E.COM /D:?ELTOR001 /I
GOTO LOOP
:ISOMOUNT3
INPUT Enter name of ISO file: /
DEVLOAD /V SHSUCDHD.EXE /F:?%ANS%
SHCDX33E.COM /D:?SHSU-CDH /I
echo.
:LOOP
WBAT BOX " ^ Do you want to mount more ISO files? ^ ",Yes,No #2,10
IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 GOTO ISOMOUNT1
SHCDX33E /V
:END


The ISOs I tested were small size (the main criteria given no access to HDs in QEMU and other limitations), bootable via IsoLinux or FreeDOS. I didn't try to mount ISO's booted via Grub4DOS - should I? I'd use MagicISO to edit ISOs (not sure what they're created with), but can try any other tool suggested. This however would severely limit in practice usability of the solution found. The ISO params: ISO9660, ISO Level 1 (DOS), Joliet, created by UltraISO, use ISO9660 for Joliet, convert to uppercase (from Magic ISO file Properties).

I'm not that deaf as you seems to think (do you?), and try to follow your advice the best I can under the circumstances. For now I don't use the Host ISO @ ALL. Just boot FreeDOS FDD directly to QEMO...and it doesn't mount any ISOs unfortunately despite "working" examples offered. May be YOU can find ANY ISO that you're able to mount after starting from a FreeDOS FDD (in QEMO ), and I would be glad to download it and re-test. How about this proposition?

Edited by sambul61, 24 November 2010 - 06:28 PM.