Mail Archives: opendos/1997/04/16/16:14:16
On Wed, 16 Apr 1997, Mark Habersack wrote:
> We don't have to worry about that IMHO. I suppose that what's going to happen
> is that OpenDOS will have several installable drivers for several supported
> file systems. Since FAT32 is not really FAT we used to know and love ;-) we
> don't have to bother with this kind of compatibility. Introducing support for
> *all* file systems in the FS utilities doesn't make sense - the user will
> probably use one, at most two, file systems at a time. Therefore we should
> rather gorup similar file systems and create common support for all these.
> Such a solution in case of original, and fairly compatible, DOS file systems
> would include FAT12, FAT16, VFAT with all variations of these supported by
> all the OSes we're interested in. That way the software doesn't get too
> complicated and everything becomes much easier.
Agreed. FAT32 isn't much of interest. For the tools, we'd need dynamically
linkable libraries...
> I agree. If we are to modify anything, let's modify something we can control.
> I was thinking about using the "reserved" dirent spots for storing link
> information. It would be fairly easy to create support for unix-like links
> on the FAT system. And we all know advantages of symbolic links!
Would extremely interesting! Both LFN and symlinks!
> Yes. I'm writing the software in NASM to make it the smallest possible. It
> will hook int 0x21 to provide support for the VFAT LFN extended functions (it
> *will not* fake Windows95 is there - programs which rely on this fact to
> check for LFN support are buggy - they should detect LFN support by looking
> at the return value from any of LFN extended functions) and also will hook
> int 0x2F to provide several custom interfaces.
If you're using DPMS, no need to smash your head making it smaller! Of
course, as small as possible is a good thing, but today (if you're spare
in your use of the standard libraries) good C compilers compiles to about
the same size as assembler programs (ok, a bit bigger, but not that
much)... Apart from this, great idea!
> I am also thinking about writing a .SYS driver to mount Linux ex2fs
> partitions. I have already d/loaded ex2tools and some other packages and I'm
> trying to build a library of ex2fs access functions. I would appreciate any
> help in this task - it takes much time to create a library of such functions,
> especially when it is going to be used from an assembler program. The library
> may be written in C, that's not a problem, but it has to be portable among
> compilers and it cannot use the standard C libraries - they *all* rely on
> startup code which is not going to work in an asm proggy.
Doing this in assembler is not right, IMHO... If you use DPMS to save
memory, size is not all that important... I'd simply suggest you use DJGPP
and program straight C. Avoiding the standard C library is not a bad idea
if possible...
Get the Linux latest sources... The 2.1.something...
Pierre Phaneuf
- Raw text -