78 replies to this topic

[was_jaclaz]

What would be the smallest sized hard disk that we can create? 1 MB, I guess, based on mkimg.cmd. We could even gzip it.

The smallest hard disk should be one that has a CHS of 1x64x32 or 1x16x63 (if we follow "known" geometries).
i.e. respectively
1x64x32x512=1,048,576
or
1x16x63x512=516,096

But the question is another, one could use any arbitrary geometry for this, so how small can be a FAT (12 or 16) volume?

Since the good ol' 5.25 floppies were originally 160 Kb, it is possible that a far smaller HD image can be made.

jaclaz

[oriensol]

Tried with a 160K image!

Grub4dos see it as 40/1/8 (C/H/S). Mapped to (hdx,0) as a partition.

Created using imdisk (not worth wasting 63 blocks )

Works fine in explorer. Visible in Disk Management, but cannot be manipulated, probably because of mapping as a partition instead of as a hard disk.

Gzipped size, 916 bytes. Size on disk, 1024 bytes.

Uses disk.sys.

Need a good name for this

Hope this is good enough.

[was_jaclaz]

Gzipped size, 916 bytes. Size on disk, 1024 bytes.

You are WASTING 108 bytes!



More seriously, one should find a way to map it (instead of a Drive letter) to either "nothing" or to a Folder on the "main" NTFS filesystem (if only NTFS is used).



jaclaz

[oriensol]

@jaclaz,

Bytes wasted are because I am creating a README.TXT inside saying "This is a dummy disk created to keep disk.sys alive when used without a hard disk attached"

[was_jaclaz]

@jaclaz,

Bytes wasted are because I am creating a README.TXT inside saying "This is a dummy disk created to keep disk.sys alive when used without a hard disk attached"

OK, but thinking a bit more about the matter, we don't need an actual filesystem to hook the disk.sys.

The disk.sys is hooked by the disk driver, not by the contents of it (otherwise you would never be able to partition/format a 00ed out disk or image).

Can you try mapping/loading the attached image?



jaclaz

Attached Files

•  dummy.zip   392bytes   390 downloads

[oriensol]

fxscrpt/TheHive,

?

TheHive, can you check this?

@jaclaz,

I added the readme.txt so that if a user starts wondering what this new drive is, he/she will at least understand why it came about. For that I had to make the filesystem. I understand you are thinking of just having a(n uninitialized) disk partition.

[was_jaclaz]

I added the readme.txt so that if a user starts wondering what this new drive is, he/she will at least understand why it came about. For that I had to make the filesystem. I understand you are thinking of just having a(n uninitialized) disk partition.

Yep, so it might even NOT get a drive letter.

jaclaz

[Lancelot]

oriensol

lets continue with mid-way approach

2 main options for the tinyhdd, 1st with your way (formatted, added txt), 2nd jaclaz way (no format, no drive letter, No woman no cry). I feel 1st way will be nice for new users and 2nd way maybe preferred by advanced users who knows what is going on All ways to Mumbai and hopefully everybody happy

[oriensol]

Why do we really need two ways? I feel Jaclaz's way is fine by this logic:

1. If the user is NOT advanced he/she won't even know/notice that this dummy disk/partition exists, since we won't even have/use a drive letter
2. If the user is advanced, he/she can understand why it is there. And Jaclaz has put in the text inside the image for someone who opens it with, say Tinyhexer

We probably need a good name for the image file.

Edit: How about needthis.img for a name?

[was_jaclaz]

Following the "other" approach.

A "less-than-floppy" (as opposed to "superfloppy" ) image, size uncompressed 17,408 bytes!

Made with fsz and mkdosfs.exe:
http://www1.mager.org/mkdosfs/

fsz dummytest.img 17480
mkdosfs -n DUMMY_DISK -s 1 -S 512 -f 1 -h 1 -F 12 -r 16 -R 1 J: 34

But I guess that manually we can do even (slightly) better.



jaclaz

Attached Files

•  dummytest.zip   372bytes   363 downloads

[was_jaclaz]

It seems like the limit is actually 4,096 bytes.

Please find in the attachment two examples of such a small image, a "normal" FAT12 image with 2,048 bytes free (but with TWO FAT's) and a "hacked" FAT12 with (hear, hear ) 2,560 bytes free!
(I used just one FAT copy ).

The empty images compress to 248 and 246 bytes respectively, using gzip -9.



jaclaz

Attached Files

•  SmallestFAT.zip   688bytes   376 downloads

[Lancelot]

Please find in the attachment two examples of such a small image, a "normal" FAT12 image with 2,048 bytes free (but with TWO FAT's) and a "hacked" FAT12 with (hear, hear ) 2,560 bytes free!
(I used just one FAT copy ).

All works nice

[fxscrpt]

sorry if i'm wrong but i think
fixing disk.sys unload issue by
firadisk is breaking a butterfly on a wheel.

i like firadisk and when thinking about firadisk i like to think big:
modern , fast ramdisk , drive letter assigned ,
big enough for modelram and pagefile!
(i'm sure it will be possible in the very near future)

let's collect information about disk.sys unload issue:

- it exist only for xp build's
(why? if someone can tell me , i will give him/her 10 thanks)

- real pc's not affected
- quemu not affected (we can add hdd.img)
- virtual box not affected (we can add vdi or vmdk image)
- vmware not affected (we can add vmdk image)

If issues reported by TheHive can be fixed,
there is no need for a second fix.


Peter

[pscEx]

sorry if i'm wrong but i think
fixing disk.sys unload issue by
firadisk is breaking a butterfly on a wheel.

i like firadisk and when thinking about firadisk i like to think big:
modern , fast ramdisk , drive letter assigned ,
big enough for modelram and pagefile!
(i'm sure it will be possible in the very near future)

let's collect information about disk.sys unload issue:

- it exist only for xp build's
(why? if someone can tell me , i will give him/her 10 thanks)

- real pc's not affected
- quemu not affected (we can add hdd.img)
- virtual box not affected (we can add vdi or vmdk image)
- vmware not affected (we can add vmdk image)

If issues reported by TheHive can be fixed,
there is no need for a second fix.


Peter

In the first view "I did not understand nothing" ( I hope you interprete the slang statement correctly, and not assume that I understood EVERYTHING)
For me (in first reaction) your post has been the reply to my last post.

Then I saw that it has nothing to do with the VMWare issue.

@fxscrpt (or Admins): Can you please export the VMWare posts to a separate topic?

As soon as this is done, I'll upload my 'universal solution'.

Peter

[fxscrpt]

In the first view "I did not understand nothing" ( I hope you interprete the slang statement correctly, and not assume that I understood EVERYTHING)

I know waht you mean

For me (in first reaction) your post has been the reply to my last post.
Then I saw that it has nothing to do with the VMWare issue.

you are right, has nothing to do with the VMWare issue.

@fxscrpt (or Admins): Can you please export the VMWare posts to a separate topic?

i dont know how to do that

Peter

[was_jaclaz]

SERVICE POST:


VMware thingies moved here:
http://www.boot-land...?showtopic=9292

jaclaz

[pscEx]

SERVICE POST:


VMware thingies moved here:
http://www.boot-land...?showtopic=9292

jaclaz

Moved three non-VMWare posts back here

Peter

[TheHive]

Might want to remove and replace the two scripts from the NativeEx Project
USBDummyDisk.Script
USBSupport.Script

and replace them with

vUSBDummyDisk.Script
RemovableDevicesCombo.script

[oriensol]

@TheHive,

Are you addressing psc?

[pscEx]

@TheHive,

Are you addressing psc?

Message already arrived!

But I'm currently querying. E.g. no 'RemovableDevicesCombo.script' topic exists, and I'm searching and reading the different posts containing this item.
And no 'vUSBDummyDisk.Script' topic exists, and I'm searching and reading the different posts containing this item.

That will take a while ...
Maybe somebody writes a new topic containing 'RemovableDevicesCombo.script' and 'vUSBDummyDisk.Script' replacing '???' ...

Peter

[Lancelot]

no 'RemovableDevicesCombo.script' topic exists

You are right, Mainly It is the combination of 3 existant scripts. All work done by fxscrpt, as a result we removed usb_keyboard_mouse_hotplug.script, IEEE1394.Script, USBSupport.Script from livexp server and added RemovableDevicesCombo.script at 2009-09-13.

If a topic required, better fxscrpt opens it

And no 'vUSBDummyDisk.Script' topic exists

You are at the topic . When there was USBSupport.Script oriensol requested to have dummy driver script executed after USBSupport.Script so it is renamed vUSBDummyDisk.Script at 2009-09-08 (Keeping title the same), till than vUSBDummyDisk.Script is on LiveXP server. In order not to mix things with the projects that already have USBSupport.Script I guess better to have v letter at the begining. (besides I dont know if script still works with old USBSupport.Script)

[oriensol]

@Peter (psc)

Lancelot is absolutely right.

As to working with old USBSupport, the new vUSBDummyDisk checks for RemovableDevicesCombo, so it won't work with the old USBSupport.

Hope this helps.

[pscEx]

Now the 'new' files are on nativeEx server

Peter

[TheHive]

[TheHive]

vUSBDummyDisk checks for RemovableDevicesCombo
The vUSBDummyDisk.Script Gui Description needs and update.

From
Script Depends on USB Mass Storage Devices script
to
Script Depends on RemovableDevicesCombo




I think the MountStor.script is need to be added to NativeEx,
to make the three scripts work well. I forgot to mention it before. Reading the vUSBDummyDisk description reminded me that it is needed to make it right.