67 replies to this topic

[betrand]

Hi.

Is there a way to mount a folder (say, on CDRom) as a drive, in ram.
And for example have this folder appear, from a Dos image, as a drive.



The goal, being to have easy access to the files of the folder while in windows,
not stored in an Iso.

In Grub4dos, btw.

[steve6375]

Under what OS? When you say DOS image do you mean when booted as MS-DOS or FreeDOS so you can access the CD-ROM contents without needing a CD-ROM driver?

[betrand]

Hi Steve

Yep. Under Dos. Either MsDos7.1, or Freedos. Mostly use Msdos7.1, though, as Dos.
And yep, to avoid driver.

Grub4dos>load folder as hd32, boot Dos image.



edit: yeah, 'booted from' an image.

[betrand]

Let's be more precise.
But here what I think might help achive my goal,

idea:
Like Dos Xmsdsk.
And like Chenall's copy/fat with grub4dos.

[Wonko the Sane]

Hmmm.
Check this:
http://reboot.pro/9916/
It may contain (or completely fail to) something you could use.


Wonko

[steve6375]

Sorry, 2 more Q's -
1 what do you boot to grub4dos from - the CD you want to map as another drive, or some other device?
2 Could this 'CD' that you want to access from DOS be an ISO file (e.g. boot from USB drive or internal hdd, map iso as drive, boot to DOS image)

[betrand]

Sorry, 2 more Q's -
1 what do you boot to grub4dos from - the CD you want to map as another drive, or some other device?
2 Could this 'CD' that you want to access from DOS be an ISO file (e.g. boot from USB drive or internal hdd, map iso as drive, boot to DOS image)

Hi Steve,

Sorry, I'm in an internet caf, so I'm not too often about.

1. Boot off CD. For eg, Grldr CD. Or Can be from grub floppy from HD, or grub Usb Drive (fat). For the scenario let's focus on "From CD".
On the same CD there might be a Dos image, and a folder with utilities.
2. No, an actual drive. An actual storage CD.

Let's be more precise.
But here what I think might help achive my goal,

idea:
Like Dos Xmsdsk.
And like Chenall's copy/fat with grub4dos.

xmsdsk: I don't mean using Xmsdsk from grub, nor from Dos. Just the simplicity.
This might just be done by mapping --mem an area in Ram. Using offsets.
Chenall's copy/Fat, I think can only copy to root of drive. I assume it can copy a file from its path.

Hi Wonko

Hmmm.
Check this:
http://reboot.pro/9916/
It may contain (or completely fail to) something you could use.

Yeah, I like the idea.

I was thinking about something similar, a while back, not using isos though.
An ntldr topic about the copy mechanism, to boot images directly (from drive, not in RAM).

I was thinking about booting images from their offset addresses using a "custom MBR.


Coming back to this here topic, and also thinking of the link you gave, would there be a tool to get the offset of a file on
a drive, ie offset of a (contiguous) img. ?



Otherwise, I could have the folder zipped, copy the zip to a map --mem (offsetxxx) drive, and unzip to another ram-drive.
Zip being more 'common' than iso (in everyday use).


I like the
copy /b isohdr + floppy.img = floppy.iso. (in link)

[Wonko the Sane]

Coming back to this here topic, and also thinking of the link you gave, would there be a tool to get the offset of a file on
a drive, ie offset of a (contiguous) img. ?

For FAT it is relatively easy to read the FAT, but you may find something useful here:
http://www.partition...m/utilities.htm

For NTFS see here:
http://reboot.pro/15086/page__st__25

For ISO/CDFS, see here:
http://reboot.pro/12406/


Wonko

[betrand]

Hi, thanks.

Before I go any further, is there a way from grub4dos to map --mem a number of cluster starting at an offset, which are resident on a drive?
For the moment focusing on a fat Fs.

chainloader

grub> help chainloader
chainloader: chainloader [--force] [--load-segment=LS] [--load offset=LO]
 [--load-length=LL] [--skip-length=SL] [--boot-cs=CS] [--boot-ip=IP]
 [--ebx=EBX] [--edx=EDX] [--sdi] [--disable-a20] FILE
    Load the chain-loader FILE. If --force is specified, then load it
    forcibly, whether the boot loader signature is present or not. LS:LO
    specifies the load address other than 0000:7C00. LL specifies the
    length of the boot image(between 512 and 640k). CS:IP specifies the
    address where the boot image will gain control. EBX/EDX specifies the
    EBX/EDX register value when the boot image gets control. Use --sdi if
    FILE is a System Deployment Image, which is of the Windows XP RAM boot
    file format. Use --disable-a20 if you wish to turn off A20 when
    transferring control to the boot image. SL specifies length in bytes at
    the beginning of the image to be skipped when loading.

Perticularly

LL specifies the
    length of the boot image(between 512 and 640k).

and

SL specifies length in bytes at
    the beginning of the image to be skipped when loading.

Thanks

[cdob]

is there a way from grub4dos to map --mem a number of cluster starting at an offset, which are resident on a drive?

Compare http://reboot.pro/9916/

map --mem (hd0,0)123+1000 (hd32)

[Wonko the Sane]

Not a number of cluster, but a number of sector, yes.

In the thread you were already pointed to:
http://reboot.pro/9916/
here:
http://reboot.pro/9916/page__st__26
and following.

When you write (example):

map --mem (hd0) (hd1)

what you are actually issuing is:

map --mem (hd0) <OFFSET=0>+<length=whole HD0 size> (hd1)

The example cdob just posted means "map into memory 1000 sectors starting at offset 123 on first hard disk's first partition as hard disk 32"

map ( with -mem or otherwise) has nothing to do with chainloader


Wonko

[betrand]

Hi Cdob and Wonko,

In the thread you were already pointed to

and

Compare http://reboot.pro/9916/

And

map ( with -mem or otherwise) has nothing to do with chainloader ../public/style_emoticons/default/dubbio.gif

Hehe, thanks.
Grrwish I had more time! (I will blame it on that!)

[betrand]

For the tests, I need to make a small Fat32 drive. I wanna go fat32, even though my main machine can't format fat32(XP).
What is the smallest size for a Fat32 image? Using the VERY GOOD Mbrbatch Mkimg!
I did 20M, fat32format.exe (48kb)(google):"too smaall".


And the Xp fat format, what fat is it?

And the winimage Win95 and Dos622?



Thanks.

[Wonko the Sane]

For the tests, I need to make a small Fat32 drive. I wanna go fat32, even though my main machine can't format fat32(XP).
What is the smallest size for a Fat32 image? Using the VERY GOOD Mbrbatch Mkimg!
I did 20M, fat32format.exe (48kb)(google):"too smaall".


And the Xp fat format, what fat is it?

And the winimage Win95 and Dos622?



Thanks.

WHICH in the above are:

• questions
• statements
• random guesses
• nonsense

??


Please take some time in deciding which is which and try posting again, also, unlike telegrams, you don't pay a fee per word, try writing full sentences with a subject, a verb, an object, etc., please.

Generally speaking, you first learn about the characteristics, specifications and features (and drawbacks) of various filesystems, THEN you decide which one may be more suitable to your project.
You seem to have chosen FAT32 because it "sounds" better in French (and in Urdu ) than "NTFS" or"FAT16", before having even the faintest idea which are their features.





Wonko

[betrand]

Hi,
Maybe I should post on Twitter, @reboot.
Especially

I did 20M, fat32format.exe (48kb)(google):"too smaall".

, that would fit!

Ok,
I settled for Fat32, cause it sounds cool.
I also decided on it because it sounds more common, on Usb drives, or as alternative to NtFS.
I didn't choose NtFS for its proprietary FS, and the write delay (watever it's called).
I chose Fat32 rather than FAT12, 16, for the use of Msdos7.1. ( I thought it 'prefered' Fat32).
I also chose Fat32 because I had to choose one.


And, also, Fat 16 (eg Freedos) being less common. But a question being, why is Fat12 used? I mean, what for?
Xp bootfloppy, I think, is Fat12? You don't have to answer, they're just questions one might ask.
(If I settle for One format for the test, I'll be happy enough)


Thus, probably all

random guesses

.

I shall, I think, settle for the fat xp uses to format a drive.


At the moment, though, I am just wondering, really,
if I need that much for the test:

A question, When one uses a map --mem

map --mem (hd0) + (hd1)

would the FAT (File Allocation Table) be recreated?
Like Grub4dos recreating, I think, a Mbr based on HD when mapping, would it recreate the files' 'database'?


Thanks
Edit, btw, for clarity, and for laughs,

I did 20M, fat32format.exe (48kb)(google):"too smaall".

means: I did a 20M image, tried to format it with Fat32format.exe which I found on Google (or'you can google it if you want'),
it's 48.0kb. But the program said, "the drive is too small for Fat32".

[Wonko the Sane]

means: I did a 20M image, tried to format it with Fat32format.exe which I found on Google (or'you can google it if you want'),
it's 48.0kb. But the program said, "the drive is too small for Fat32".

And this is of course because you did not document yourself BEFORE choosing FAT32.
http://technet.micro...y/cc940351.aspx
http://www.pcguide.c...artSizes-c.html


BTW, if the intended use is XP (or later) AND USB stick, AND size < 1 or 2 Gb it is the most foolish choice you could make.
http://www.msfn.org/...d-on-usb-stick/

OT, but not much, FAT12 size limit is NOT really-really 16,736,256 bytes on recent MS OS:
http://www.msfn.org/...oppy-emulation/
http://www.msfn.org/...d-their-images/

When you do:

map --mem (hd0)  (hd1)

(NO + sign in the middle) you copy INTEGRALLY (hd0) to memory and map it in BIOS as (hd1) or second hard disk.
Obviously INTEGRALLY includes the FAT table(s).


Wonko

[betrand]

As usual, thanks for the answers.

About the Fat, Reading.

About the

A question, When one uses a map --mem


map --mem (hd0) + (hd1)
would the FAT (File Allocation Table) be recreated?

,
TYPO!
Double typo too .
What was meant was

map --mem (hd0) + (hd1)

dunno HOW that + from there got to (hd0) + (hd1). ??

And it is not even what I meant .
Re. When one [code=auto:0]map --mem +if the offset start and length define the location of a folder/file on a drive, will this folder file appear in the mapped drive?IE, would Grub4dos recreate a FAT?Was the question I was asking, before re-reading the Grub4dos map --mem a drive, recreates a Mbr based on partition table.

If mapping a disk image of a partition without a MBR to memory, it can be mapped as a (hd) device as the MBR will be created within Grub4dos - based on the partition data.

I basically thought Grub4dos would, understand ,'hmm this seems to be be a file, let's tell the user there is a file there'.

But, knowing it probably won't, I see approx the next stage. If I can be @rsed, that is.


Thanks.

[cdob]

would Grub4dos recreate a FAT?

No, Grub4dos dosn't recreate a FAT. It uses a existing FAT at mapping.

recreates a Mbr based on partition table.

Yes, a partition table entry is created, if it's necessary.

Chenall created a FAT module to manipulate files.
http://chenall.net/post/grub4dos_fat/
DMPS is a example http://code.google.c.../downloads/list

Idea:
create a disk in RAM, format as FAT, copy files to this disk.
No, I don't have a working example myself.

[Wonko the Sane]

And it is not even what I meant .
Re. When one [code=auto:0]map --mem +if the offset start and length define the location of a folder/file on a drive, will this folder file appear in the mapped drive?IE, would Grub4dos recreate a FAT?Was the question I was asking, before re-reading the Grub4dos map --mem a drive, recreates a Mbr based on partition table.I basically thought Grub4dos would, understand ,'hmm this seems to be be a file, let's tell the user there is a file there'.But, knowing it probably won't, I see approx the next stage. If I can be @rsed, that is.

You are still vey confused.The general syntax is:

map --mem <source> <target>

map --mem (hd0) (hd31)

or

map --mem /mydisk.img (hd31)

will simply COPY the source to memory AND map the the memory area where the source was copied as target, because BOTH source and target are the SAME "kind of objects" i.e., respectively a WHOLE hard disk or a hard disk image as source and a WHOLE hard disk as target. (each one has a MBR as first sector)

map --mem (fd0) (fd1)

or

map --mem /myfloppy.ima (fd1)

behaves the same, because source and target are the same kind of objects (floppy disk or floppy disk images, each one has a PBR as first sector)map --mem (hd0,0) (fd1)There is a SPECIAL case which is:map (hd0,0)+1 (fd0)Check against README_GRUB4DOS:

Emulates HD partition C: as floppy drive A: and boot win98 from C: map --read-only (hd0,0)+1 (fd0) chainloader (hd0,0)+1 rootnoverify (hd0) bootIn the above example, (hd0,0) is drive C: with win98 on it. After win98boot complete, you will find that A: contains all files of C:, and ifyou delete files in A:, the files in C: will also disappear.At the map command line, the notation (hdm,n)+1 is interpreted torepresent the whole partition (hdm,n), not just the first sector of thepartition.

which still behaves the same, because source and target are the same kind of object (floppy/superfloppy or Disk partition/volume - each one has a PBR as first sector)And another SPECIAL case which is:map --in-situ (hd0,4)+1 (hd31)see:

********************************************************************************* About the new map option --in-situ *********************************************************************************--in-situ is used with hard drive images or hardrive partitions. With anin-situ map, we can typically use a logical partition as a primary partition.In-situ map is a whole drive map. It only virtualize the partition table andthe number of hidden sectors in the BPB of the DOS Boot Record.While disk emulation may encounter various problems with win9x, the in-situ mapworks fine with win9x.Note that --in-situ will not change the real partition table.Example:map --in-situ (hd0,4)+1 (hd0)

In this case source's first sector is a PBR BUT target first sector must be a MBR, which is then simulated by grub4dos.NO filesystem (not "FAT", FAT table(s) is/are part of the filesystem, that includes bootsector/PBR, reserved sectors, FAT(s) and in the case of FAT12/16, reserved space for ROOT entries) is created or harmed in these processes.


Wonko

[betrand]

Hi,

You are still vey confused.

, This is driving me crazy! Each time I paste something in codebox, it comes out jumbled.

When one map --mem +

?

Should've been
map --mem (hd0) + (hd1) see next post.
and

[s]map --mem (hd0) + (hd1)[/s]

see next post. Is that possible?
(and is it going to come out as I typed?) no.
@Wonko, yeah, source-target, I know. Thanks for wanting to clear it though. The above I hope explains what I meant.

@Cdob,

Idea:
create a disk in RAM, format as FAT, copy files to this disk.
No, I don't have a working example myself.

Yeah, I was going to ask, at some point, if creating an empty ramdrive with grub4dos was possible -out of the box.
Thanks, & thanks for the links. I'd already seen the Fat copy tool,

Chenall's copy/Fat, I think can only copy to root of drive. I assume it can copy a file from its path.

Otherwise, I could have the folder zipped, copy the zip to a map --mem (offsetxxx) drive, and unzip to another ram-drive.
Zip being more 'common' than iso (in everyday use).

No, I don't have a working example myself.

Dpms

, always good to see an unknown Iso.


@wonko,

--in-situ

, mhm! interesting. Interesting name, mostly, for me. "Sounds cool!"


SO. Do you guys know if it's possible to create a blank formatted (or not) drive out of the box with Grub4dos?
By saying map this area of memory as say, floppy, CHS, FAT FS.

But the main idea being.
For the test:
1 container drive image. (hd-like)
1 Dos boot floppy
1 bootsector and FAT(.bin, .file, .whatever) [edit: of a second floppy]
After that the files of a second floppy (whose bootsector is the latter) are on the main drive image. The files are in the same order, an Hex-copy.

The floppy images must be same FS as main drive, to, I assume, avoid overlapping FSs.
The FAT of the main drive would list the files of second floppy, as well as a Bootsector and fat. bin.
The files of the floppy are now accessible from windows.
Grub4dos would have to map the offsets from bootsectorfat.bin to end of last file (on main drive), and map thae length as a drive.
Therefore we have a bs, a FAT, and files. In RAM.


It looks more like a proof of concept. Might be useful.
Fun.


Ok, see yas.

[betrand]

Arf! Keeps doing it!

map --mem (hd0) + (hd1)

NO!
map --mem (hd0) offset= start of BSsandFAT.bin length=length of a drive, floppy for eg. (fd0)

[Wonko the Sane]

We are clearly speaking a different language.

You cannot come back asking the same question that has been answered to SEVERAL times in this same thread.

map --mem (hd0) <OFFSET=start of a file/folder>+<length of file folder> (hd1)

is completely ABSURD.

map --mem (hd0) <OFFSET=start of a file/folder>+<length of file> (hd1)

will have as result:
to COPY the file to memory and to map the file as second hard disk.


IF (and only IF) the source file is a valid image of a hard disk, the (hd1) will be accessible by the OS with "standard methods".

SO. Do you guys know if it's possible to create a blank formatted (or not) drive out of the box with Grub4dos?
By saying map this area of memory as say, floppy, CHS, FAT.

Yes.
http://homepage.ntlw...no-answers.html
(meaning that we do know if it's possible or not, though "floppy, CHS, FAT" represents a meaningless list of different things "media type, addressing media, undefined filesystem between FAT12, FAT16, FAT32 and exFAT)

But the main idea being.
For the test:
1 container drive image. (hd-like)
1 Dos boot floppy
1 bootsector and FAT(.bin, .file, .whatever)
After that the files of a second floppy (whose bootsector is the latter) are on the main drive image. The files are in the same order, an Hex-copy.

The floppy images must be same FS as main drive, to, I assume, avoid overlapping FSs.
The FAT of the main drive would list the files of second floppy, as well as a Bootsector and fat. bin.
The files of the floppy are now accessible from windows.
Grub4dos would have to map the offsets from bootsectorfat.bin to end of last file (on main drive), and map thae length as a drive.
Therefore we have a bs, a FAT, and files. In RAM.


It looks more like a proof of concept. Might be useful.

It looks more something completely UNunderstandable, at least to me, something like a random generator of geek text may produce, there is NOT a single line that makes sense together with the previous or the following one

Please try to expand on the idea, explain what EACH thing is, like "fat .bin", "bootsectorfat.bin", "FAT(.bin, .file, .whatever)".

Are you - by any chance - talking about something like OFS?
http://reboot.pro/2887/
Check the floppy teaser:
http://reboot.pro/2887/page__st__14


Wonko

[steve6375]

You said that the aim was to copy files from a cd to a virtual drive which DOS could understand. I don't see a CD anywhere in this?
Maybe you should state your objective more clearly?

For instance, you could burn a grub4dos bootable CD which contained on it a .img file which was a hdd disk image, grub4dos could load and map it to memory and then boot to a DOS image which should then be able to access the virtual hdd.
Just what are you trying to achieve? There is usually more than one way to skin a cat!

[betrand]

I'll try to explain again.

I want to be able to access files on a stick, for whatever reason. I want to be able to view these files from within windows (NT).
But these files would usually be stored in an img. For, now just probably proof of concept, maybe a use in future, I want not to use an image mounting tool from within Windows, but still view the files.
These files will, therefore be referenced in the FAT of the stick.
I still want these files to be 'stored in an image'. I.e, be part of the whole stick (in the stick's FAT), but also be referenced as being part of an image.
Let's say a 2.88 floppy image. I will therefore have a bootsector of an image, and a FAT referencing the files for that image.
The bootsector and FAT of the image will be stored on the BSandFAT.bin file. After that file, on the Usb stick, the files of the 2.88 image, in the same order as they are referenced in both FATs.

Then to tell Grub4dos to map the sectors from the start of BSandFAT.bin for a length of 2.88M. Therefore the mapped area would be the representation of a floppy image.

Je vous remercie, et a bientot .

PS, quote:"geek". Yeah. This thing is going that direction.



Edit: @ Steve, thanks, always for input. I started CD, but I'm 'more used to talking FAT' than CDFS, so I decided to 'go FAT'.

[steve6375]

Sorry but I am not inclined to help on a 'proof of concept' project that has no practical application and that you have no use for. You keep moving the goal posts so i'm off to the showers!