Eric Auer schrieb:
> Hi again,
> 
> recently I had an off-list discussion about the
> possibility of booting DOS from NTFS... This
> leads to the question, how happy are you with
> the existing solutions?

Unhappy.

> - you can boot DOS from FAT, then load NTFS4DOS
>   which is read/write, free for personal use:
>   www.free-av.de/de/tools/11/avira_ntfs4dos_personal.html
>   Some "auto threat analysis" tells me it will be 120k ;-)
>   www.browserdefender.com/de/file/859899/site/free-av.com/
> 
> - you can boot a MEMDISK from NTFS using GRUB4DOS
>   which apparently can read NTFS directly... This
>   is ca 190k. My Linux GRUB has no NTFS, stage2 is
>   ca 120k and stage1.5 is ca 10k per filesystem??
>   The NTFS-read part of GRUB4DOS might be 10-100k?
> 
> - maybe you can use the NTFS-file-reader of GRUB4DOS
>   after booting DOS? I believe PXEBOOT allows similar?
> 
> - you can port the Linux NTFS driver to DOS. As the
>   Linux version takes ca 105k plus a Linux kernel,
>   a DOS version will probably be as big as NTFS4DOS
>   so it would make sense to make it a JEMM JLM...?

This is not an existing solution, it's a possible one. About format (jlm
or not see below).

> - you can write a combination of MEMDISK and SHSUFDRV
>   and GRUB4DOS which somehow keeps a small FAT disk
>   image in a flat file on your NTFS filesystem, R/W??

Not this but this brings me an other idea.

The image (hd or floppy) support of grub4dos is good. But the annoying
part is that changes written to the image will be only in memory and not
written back to the image, if written back to the image this would
improve this a lot.

> - you can boot from CD, DVD, SD, USB stick or similar
>   and then load NTFS4DOS or any other driver... ;-)

This ntfs4dos is not optimal, it's proprietary, has an annoying
nagscreen, full version can be no longer bought, needs to much
conventional memory.

In addition, like suggested long time before:
a command in config.sys to include another configfile and to phrase it
like normal config.sys would help a lot and for sure also wouldn't be to
hard to implement?

> So, which methods have you tried so far? Did they work?
> 
> Eric

> PS: We cannot put NTFS _into_ the kernel. Our kernel is
> 40 kB compressed at the moment. As it drops boot parts
> after init, it is 10 kB low plus 40 kB HMA later. The
> HMA is max 64 kB. NTFS r/w might triple all sizes ;-)
> You cannot load files on NTFS before loading NTFS drivers,
> unless you put a LILOish sector number list into a loader?

I think it's time to add the possibility to boot kernel.sys using
parameters (like you can also do with linux kernel).

NTFS doesn't need to be inside the kernel, it can be an loadable module
(loading on request by parameter). As driver format a hybrid
realmode/umb and jemm would be fine (two builds). Jemm only has the
disadventage that you would break compatibility to all non-emm386
compatible stuff.

-mr

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to