Accessing the host ISO from a bootable DOS Floppy image
Posted 24 November 2010 - 11:05 PM
However, when I tried to mount the same ISO via ELTorito.sys after booting to a FreeDOS FDD in VMWare, it failed to mount it every time. Something seems to be missing in the equation. This ISO has the exclusive (!) boot image, ELTorito said to mount in FreeDOS without issues, and it DOS NOT. I looked again in ELtorito "docs" and apparently couldn't find a single word claiming it can mount an ISO image. It was supposed to be used to mount physical CD-ROMs after booting from...whatever.
QEMU Manager works fine, but QEMU itself is in Alpha and has plenty of bugs (not that VMWare doesn't), so using the FDD image in a QEMU WinXP VM gave more headache then usual.
Edited by sambul61, 25 November 2010 - 12:05 AM.
Posted 25 November 2010 - 12:50 AM
Will try the same thing on a physical PC, but it's obvious now, ELTorito can mount CD-type devices that are already recognized by BIOS. Which means, you can boot from an ISO image with a small FDD in its bootsector to DOS, and than have a lot more programs and data accessible on the host ISO you booted, while your hard drives and USB devices may not be accessible. That part get solved.
How to mount the ISO writable, so it can be written data to? I know it sound awkward a bit, given nature of ISO file as a finished CD. But this command works just fine in Ubuntu:
sudo mount -v -o rw,loop,uid=$UID (your image path:name) /media/Virtual
OK, found it for DOS too (not sure if it would allow to add more files to the ISO, presuming an existing file system - which can be created virtual, until the ISO is saved at being dismounted. Or may be it presumes a special ISO made from a writable data CD):
/D driver and drive manipulation
/L drive letter
/C memory usage
/V memory statistics or option information
/~ tilde usage
/R read-only attribute usage
/R - Read-only attribute usage
By default, files on the CD are given the read-only attribute. Should
you wish to remove this attribute, this option will do so. As with /~,
it can be used after installation and it accepts '+' and '-'.
Edited by sambul61, 25 November 2010 - 01:45 AM.
Posted 25 November 2010 - 01:31 AM
title booting FreeDOS from raw image (as harddisk) + FreeDOS installer CD (it'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)
chainloader --force (hd0)+1
But SHSUCDHD method seems to be missing something. May be one way to use it is to map several ISOs with a single Grub4DOS menu entry, and then use SHSUCDHD to pick the one, you need now, without mounting all others as Eltorito does. The problem with Grub4DOS approach is you must pick the ISOs at boot time, can't do it after boot.
That is actually a question: is it possible to map files with Grub4DOS after boot - how? What Grub4DOS files must be present on the DOS FDD for that?
May be OMI gives the key for SHSUCDHD :
SHSUCDHD...........Emulates one or more CD-ROMs using image files
SHSUCDRD...........As above, but the files are copied to memory (XMS)
SHSUDVHD...........Emulates one or more DVD-ROMs using image files
SHSUCDRI............Emulates one CD-ROM by copying it to memory
OMI...........................Create an image from a CD- or DVD-ROM
OMI (Optical Media Image) will create an image file from a CD-ROM, or
multiple files from a DVD-ROM. The image is a direct copy of the CD or
DVD, which can then be used by the above programs and SHSUCDX to access
the CD/DVD, without needing the physical disc.
Edited by sambul61, 25 November 2010 - 02:00 AM.
Posted 25 November 2010 - 11:56 AM
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.
Meaning BOTH that you are NOT deaf (you only play being deaf) and that you are NOT doing the best you can.
You have 8 (eight ) numbered questions.
It is not difficult to give me 8 (eight) corresponding numbered answers.
It took you a few days and countless attempts to get EXACTLY where you could have been had you simply listened.
I find particularly pointless and frustrating to talk to someone who doesn't hear or doesn't want to listen, I really see no point in continuing this kind of non-conversation.
Good luck with your project.
Posted 25 November 2010 - 12:39 PM
Such forums present means for participants to share information. It's up to them to elect whether to take part in any conversation.
Edited by sambul61, 25 November 2010 - 01:39 PM.
Posted 26 November 2010 - 01:44 PM
Despite you omitted regularly answering mine.
Did I miss some of them? (meaning MOST of your answers and a few of your questions)
Can you list the unanswered questions?
We could make a deal , for each of your question I answer, you do EXACTLY what I suggest you in my answer and report, then you answer one of my questions ?
You are anyway welcome.
Posted 26 November 2010 - 06:30 PM
I truly value your input! But of course you know, most ppl come to such forums for a quick fix, they don't expect to be tutored instead of simply getting their questions answered. I get "some" mapped ISO's on the "host" mountable in a VM with eltorito.sys (the difference with real PC is in VM the host ISO is always mounted as a drive by the VM), and SHSUCDHD mounts almost "any" ISO by name on accessible drives. More complete Grub4DOS command set at launch may allow more ISOs to be mounted at once with eltorito, but its a kind of mistery.
That was actually a question: how to move beyond "map /my_iso.iso (0xff) && map --hook" menu command set to make eltorito.sys auto mount more ISO types, and also several at once (not just one per boot regardless of how many suitable for eltorito ISOs are mapped & hooked). To illustrate (after booting a host ISO with Grub4dos):
map --mem /My_FDD.ima (fd0)
map /My_ISO1.iso (0xff)
map --mem /My_ISOn.iso (0xff)
Eltorito mounts only (any) one ISO per boot apart from the host ISO whether all are separately hooked or at once (and only when the host ISO already presented as a drive in VM, which is not the case on a real PC).
I've some "automation" issue though: INPUT and ReadLN utilities are quite old, they don't work well with XMS managers (if anything is new about DOS). So when a .bat below is launched from a file manager, the variable %ANS% remains empty. Any workaround - DOS is VERY remote to me, and I don't want to exit a file manager (to unhook the XMS) prematurely from the .bat (or a command for this is generally unknown).
READLN "Enter name of ISO file: " ans
SHCDX33E /D:?SHSU-CDH /I
Btw, looking at forum stats, do you see how many ppl get interested in this issue resolved? Apparently, ISO is not forgotten in favor of hd.ima .
Edited by sambul61, 26 November 2010 - 07:18 PM.
Posted 26 November 2010 - 11:51 PM
:: This routing can mount ISO images to drive letters after booting to DOS from an ISO "host" :: Add to your DOS pack required programs and drivers. Quit File Manager before running the batch :: If you booted the "host" via Grub4DOS, Linux driver will mount the "host" as a drive :: Linux driver will also mount "some" no-emulation ISOs you mapped in "host's" Grub4DOS menu.lst :: DOS driver will mount by path/name non-mapped ISO images on accessible drives. No LFN allowed :: Mount non-contiguous ISO files to memory with SHSUCDRD that will install SHSU-CDR driver, or defrag @ECHO OFF SET ANS= :ISOMOUNT ECHO. WBAT BOX " ^ Load ISO driver for DOS/Linux? ^ ",Dos,Lin #1,10 IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 GOTO MOUNT2 :MOUNT1 DEVLOAD /V ELTORITO.SYS /D:ELTOR01 SHCDX33E /D:?ELTOR01 /I /R+ GOTO LOOP :MOUNT2 READLN "Enter name of ISO file: " ans SHSUCDHD /F:?%ANS% SHCDX33E /D:?SHSU-CDH /I /R+ rem SHSUCDRD /F:?%ANS% rem SHCDX33E /D:?SHSU-CDR /I /R+ ECHO. :LOOP WBAT BOX " ^ Do you want to mount more ISO images? ^ ",Yes,No #2,10 IF ERRORLEVEL 1 IF NOT ERRORLEVEL 2 GOTO MOUNT1 SET ANS= :END
A couple of problems with the batch still remain. First, you must exit a File Manager before running the batch. Its the result of User Input limitation in DOS (ReadLN). I found that: "User Input programs in DOS can't write the changed variable to the parent environment of the program that started it. They use the system BIOS function (INT 10h) to read the keyboard, and this function call does not support input redirection." Any workarounds?
Second: if a user wants to mount various ISO files at different times, duplicated drives of already mounted ISO's may be added. Its caused by using the CD Redirector SHCDX33E with option "/I" (install multiple times), and it doesn't work otherwise for this task. I know, an extra batch can be created to make some checks, but may be someone will offer an elegant workaround?
Option "/R-" allows to open an ISO as Read / Write, "/R+" - Read Only. More tests are required with Read / Write ops. If there is no access to Hard or USB Drive, and the nested ISO was open to memory from another ISO, after writing to it more files the ISO can be burnt to a CD upon finishing the job or copied over LAN, etc.
You can mount an ISO to memory by using map --mem command with Grub4DOS, or typing an ISO file name to SHSUCDRD driver input (it creates a SHSU-CDR disk) instead of SHSUCDHD driver. More CD/DVD options are available with SHSUCD package by Jason Hood.
Edited by sambul61, 27 November 2010 - 12:43 AM.
Posted 27 November 2010 - 09:32 AM
Sure, you could sue the DOS makers and the READLN programmers.
READLN "Enter name of ISO file: " ans
SHCDX33E /D:?SHSU-CDH /I
What if you get smarter than DOS and do something like what is explained here?:
More generally, it is awkward to have to write the whole .iso name, you could write a small batch that lists .iso files, and shows them on the screen, then use choice or choix or choose to select the one you wish to mount.
WBAT (which you are already using):
Dialog boxes for DOS batch:
menues, buttons, input fields, checkboxes, radio buttons, list selection
Easy handling, no ANSI stuff to deal with - colors are specified by name.
WBAT runs under all Windows versions or plain DOS.
Layout for box with text and control elements - all elements can be freely arranged
Quick box with specifications in the command line
Selection from batch generated lists (e.g. DIR file lists)
Text pages with color attributes
INI file with defaults and preferences
Win NT/2000 compatible handling of variables
Mouse handling is supported in a GUI box as well as in full screen mode. Of course WBAT will also work under plain DOS.
DEMO.BAT supplied with full handling details (instead of a DOC file).
Posted 27 November 2010 - 02:30 PM
Thanks for pointing to that batch. Will try it instead of ReadLn. No need to sue apparently... I made it simple expecting to switch to a required dir in a File Manager (as its usually done while looking for a file), then run ISO.bat to drive the selected ISO from that dir (having set ISO.bat in a File Manager like VC the default program to run .iso files). Since no LNFs allowed (will test that), its not a big deal then to type the file name.
How about my other questions:
1. Any trickery to make ELTorito drive more that just one ISO file per boot (apart from the host iso)? I use only ISOs, ELTorito can drive separately each, but when listed several in Grub4DOS, only one of those ends up driven by Eltorito per boot. Not sure in what order of preference it does the job, but can watch it.
2. That's great to have resolved the ISO mounting question eventually. But what about mounting IMA floppy and HD image files under DOS & FreeDOS? Any drivers for that? I wasn't able to find one. Can you?
3. Any basic way to avoid drive doubles when using SHCDX33E, when user desides to mount various ISO at different times? Any ready-to-go BAT to look at what drives are already mounted, and block the CD Redirector from mounting them again?
Can you provide numbered answers? I'll do exactly what you suggest - I take your deal on that...
Edited by sambul61, 27 November 2010 - 03:10 PM.
Posted 27 November 2010 - 05:40 PM
Edited by sambul61, 27 November 2010 - 05:41 PM.
Posted 27 November 2010 - 06:24 PM
And - still last time I checked - FreeDOS had all the usual devices: CON, NUL, LPT1, AUX, PRN, ...
It is more likely to be a "queer" Ctrl+Z kind of problem:
#1: NO. But as you have seen you can use other drivers of SHSUCD "series" to access more images.
#2: You need NO drivers for floppy or HD images under DOS, BECAUSE:
- supported filesystems FAT12, FAT16 and FAT32 UNLIKE CDFS are supported in the kernel
- floppy devices and HD devices are accessed by BIOS services and NEED NOT an external driver, unlike CDROM drives.
- everything is accessed "natively" through INT13h
#3: Maybe, haven't one handy, but it should be possible to write one .
Posted 27 November 2010 - 08:26 PM
From any ISOs I was trying to mount so far with SHSUCD "series", it failed only on ISOs with long file names. Hence, the simple way to prevent most drive duplications and errors would be to check the file existance in current dir and length of file name once entered, and show a Prompt if the name is not 8.3.
Not sure I understand your explanation about DOS floppy and HD image drivers. Even in Windows one needs VFD or similar to open a floppy image as a drive - despite physical devices are also supported. Is it different in DOS? Whatever, if no driver is needed (I doubt so) to access floppy and HD images under DOS - then how to mount such images under FreeDOS with a drive letter?
Yes, I see your point about booting into RAM a HD image for the same purpose instead of ISO. The ISO image can still be burned to a CD, if there is no way to boot from a hard or usb drive. Anyway, the solution of accessing ISO images after booting to DOS remains the same, whether you booted to DOS an ISO or HD image.
Inspired ( ), I want to make such FreeDOS HD image and restore it onto a thumb drive or a CF card (since I have the CF sitting empty in a USB Card Reader, and its recognized as HD by BIOS). What's the best approach you can suggest to prepare such an image and restore it (or another way to accomplish the same)? Would it be different for a Thumb compare to CF Card? I guess "restore" method is universal in nature...
What's the advantage of using QEMU as opposed to VMWare? I found QEMU to be a bit buggy, and a CPU hog even at idle. But there may be hidden pros I don't know about.
Edited by sambul61, 27 November 2010 - 08:58 PM.
Posted 27 November 2010 - 09:04 PM
Not sure I understand your explanation about DOS floppy image driver. Even in Windows I need VFD or similar to open a floppy image as a drive - despite physical devices are also supported. Is it different in DOS? Whatever, if no driver is needed (I doubt so) to access floppy and HD images under DOS, this is great news! Yet, how to mount such images under FreeDOS with a drive letter?
This is DOS, NOT Windows. (they work DIFFERENTLY)
You map the images in grub4dos.
Grub4dos is "between" BIOS and DOS.
For all DOS knows, since it "trusts" BIOS devices (please read BIOS devices as modified by grub4dos), the image is a "real" device.
I'll try again.
FORGET (temporarily) about images.
Let's talk about "real" hardware:
- can DOS or FreeDOS access a floppy drive (FAT12) WITHOUT ANY driver or extension?
- can DOS or FreeDOS access a hard disk drive (filesystems FAT12, 16 or 32) WITHOUT ANY driver or extension?
- can DOS or FreeDOS access a CD/DVD drive WITHOUT ANY driver or extension?
Now, IF grub4dos mapped devices (for all DOS may know) are EXACTLY the same as "real" ones, can you see the difference between them?
If you don't like QEMU (actually QEMU+QEMU manager) simply don't use it.
If you like VMware, use it.
If you happen to like VirtualBox or Virtual PC, use them instead.
The not so slight difference is that you will have to deal with "custom" HD images (as opposed to "RAW" ones Qemu can use) a - to say the least - "strange" BIOS (as opposed to a very "strict" one), and once you will try Windows - no matter if 9x/Me or NT based - you will find how Qemu emulates "standard" devices, whilst VMWare and most other VM's need specific drivers.
I won't suggest you ANY "best approach" to create/deploy an image on a CF or a USB flash, simply because there isn't any and because you are still - without having yet grasped the "base concepts" - again taking yet another path.
There are a few tens of possible approaches and tools.
I don't think anyone is best, and even if I knew a "best" one I wouldn't suggest it, because your next post would be something like:
Hah, I don't like that method, I find it awjward, buggy and error prone, this one XXX is better, can you explain why your one should be better?
I'll try to rephrase previous post, to clarify:
"something like" means "this is something that may or may not work for your setup".
The essence of the post amounts to:
Try using WBAT's feature of selecting among a DIR generated list.
Posted 27 November 2010 - 09:59 PM
"Map FDD and HD images in Grub4DOS before booting to DOS, and after you booted, they will open as any other drive (assuming the image is error and fragments free)." Will check it out. If not using Grub4DOS - is there a way to mount FDD and HD images in DOS?
Basically, I indeed didn't know the advantages of QEMU (which needs time to figure out), so not surprising to ask about. As to drivers for VMWare, it also allows to select a device type, and "standard" drivers are included. Or did you mean something different about drivers? I don't say QEMU isn't good, just asked to highlight advantages as part of the suggestion - isn't it natural? I found it very lightweight and simple to setup - this is obvious advantage for a new VM user.
Sorry for being a bit of topic. As to selecting a suitable method for making FreeDOS USB HD image - I still ask for the advice, which will make wheels move a lot faster...for dummies like me.
My working assumption is: format and partition a CF card in FAT, copy all DOS files to it (the content of my ISO), add MBR to the CF...the Grub4dos or standard DOS MBR...and try boot to it. Should I use RMPrep or similar tool to format the CF or Thumb and write MBR to it? Than I can make an image of the drive. Another approach seems to be making an empty raw ima file in QEMU, copying all DOS files from the ISO to it, and adding MBR to the image file - with what tool? Or, can you point to the right thread (not forum section) that exemplifies the exact topic discussed?
Edited by sambul61, 27 November 2010 - 10:59 PM.
Posted 28 November 2010 - 10:55 AM
Yes, of course.
If not using Grub4DOS - is there a way to mount FDD and HD images in DOS?
And still of course, you have a handy, working tested method (grub4dos mapping) and you want ANOTHER one, just to see if you can FAIL at something else .
Go back to the SHSUCDX site, there is NOT only SHSUCDX:
Your "working assumption" has the "wrong" sequence.
When you PARTITION a device, most (please read as 99.99% of apps) WILL:
- write a partition table to the MBR
- write some bootable code to the MBR
- NT systems only write a DISK SIGNATURE to the MBR
When you FORMAT a partition (accessible ONLY after a pointer to it has been created by PARTITIONing above), most (please read 99.99% of apps) will:
- write in the bootsector partition/filesystem DATA
- create the filesystem structure (FAT's or $MFT's etc)
- write some bootable code in the bootsector
- for DOS, if you use the /S switch ALSO copy the system file to the filesystem
So the right order is:
- Add files
The least "custom" or "strange" or "advanced" or "automagically-do-it-all" tools you will use, the better.
Each operating system has it's own tools to partition, format and write the system files, do basic things first, use them basic apps to do them (as opposed to "third party" and "advanced" tools - I seem to remember you mentioned a couple of times Paragon tools, they are EXACTLY what it is NOT recommended, as they may do things that are either un-standard or un-documented.
Should you - by any chance - and just as a one time exception - be willing to actually follow something without introducing all kind of variations, you may try to re-do EXACTLY what is detailed here:
you should probably be able to learn from the examples some of the basics you are apparently missing.
(and NO, it is not "the best", it has never been updated since 2005, but it worked at the time and it still works today )
Posted 28 November 2010 - 06:26 PM
Actually, Jason Hood with his image drivers is one of my favorite coders by now: his code is polished far beyond what ELTorito and Grub4DOS developers demonstrated in some areas like multidisk mount, Extended Partition boot, or in-depth documentation so far. Of course, task complexities are of different scale. I'll check his FDD & HDD DOS image drivers and see what transpired.
We'll look now, what Jaclaz suggested in that Make a USB Thumb post. I'am intrigued, who are these well posted abundantly qualified personalities behind this website - background pls if not secret of course. For some reason I sence a university professor.
Edited by sambul61, 28 November 2010 - 06:37 PM.
Posted 28 November 2010 - 07:09 PM
ElTorito.sys is a driver for El Torito BIOS INT 0x13 extensions. That means that it drives an optical disc drive which has been used to boot the system, or an optical disc drive which BIOS provides availability for regardless of its use during boot. MEMDISK and GRUB4DOS provide at least some of these El Torito extensions, so Eltorito.sys can drive such virtual drives.
... code is polished far beyond what ELTorito and Grub4DOS developers demonstrated in some areas like multidisk mount, Extended Partition boot, or in-depth documentation so far. ...
Jason Hood's fine work works with image files directly. ElTorito.sys drives El Torito drives. GRUB4DOS provides El Torito drives to any INT 0x13-consuming OS (not just DOS). These are all different tasks. I don't understand why your specific needs would be what all of these were aiming to support. I don't believe they were. Your needs seem to be working with image files from within DOS. Jason Hood's work does that.
Posted 28 November 2010 - 07:37 PM
Edited by sambul61, 28 November 2010 - 07:51 PM.
Posted 28 November 2010 - 08:00 PM
No, I don't understand why you'd say something like:
If you look at the title of this thread, understanding will follow. ...
That Jason Hood's fine work meets your needs does not mean that ElTorito.sys and GRUB4DOS code for their specific tasks has "far" lesser a "polish" than his, does it? That this thread's title is "Accessing the host ISO from a bootable DOS Floppy image" does not help me to understand why you'd say that. Sorry. If you are saying that they do not perform their tasks as well as J. Hood's work, please detail why they don't, so they can be fixed/enhanced.
Actually, Jason Hood with his image drivers ... his code is polished far beyond what ELTorito and Grub4DOS developers demonstrated in some areas like multidisk mount, Extended Partition boot, or in-depth documentation so far. ...
... My specific needs may be a lot more narrow than all details of the discussion in this thread. But that's a good sign of quality discussion: it starts from narrow subject with limited scope, and then tries to offer a generalize approach in that subject matter useful for many. That's what usually constitutes challenge for any package, like a bootloader.
Posted 28 November 2010 - 09:36 PM
Why would someone be interested in DOS now in the 1-st place - you may ask? Aren't you talk about nothing?
I get interested in DOS, when my hard drive started showing signs of approaching death, and I needed to use more efficiently some diagnostic tools that work correctly only in DOS. If you go to WD or Seagate site, you'll see how many ppl face similar problems. This single cause was good enough for me to look at working with DOS again. Apparently, many users are still interested in DOS for whatever reason, given the number of readers of these threads just for a few last days. The problems are specified in more details in each of them separately.
Edited by sambul61, 28 November 2010 - 09:38 PM.
Posted 29 November 2010 - 03:44 PM
Hmmm Do we need RAM disk at all in DOS HD scenario - for what purpose, or we don't?
Why don't you make a simple hard disk image and map it to RAM through grub4dos?
It should get C:\ allright and you won't need the DOS RAMDISK driver.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users