Mail Archives: opendos/1997/04/17/05:26:09
Once upon a time (on 16 Apr 97 at 16:08) Pierre Phaneuf said:
> > 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...
True. We only need to decide on the DLL format we chose.
> > 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!
That's the idea!
> > 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!
The reason I'm writing it in asm is easy: I don't want to use any commercial
16-bit compilers. NASM is free, and available for everyone. I cannot use
DJGPP 'coz it's i386+ bound and besides it works in protected mode which is a
great pain in fast access to hard disk (and I need direct access to disk
structures). BTW. I was thinking whether I can program the driver using i386+
instructions? After all DOS is an 8086+ OS and not i386+! What do you think?
> > 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...
Again, that's not the size what matters. And I cannot use DJGPP for the same
reason as stated above.
> Get the Linux latest sources... The 2.1.something...
Got sources for 2.0.0 - has anything important changed in ext2fs and VFAT
drivers?
==================================================
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of
reasons why.
Yesterday starts tommorow, tommorow starts today
And the problems seem to be we're picking up the
pieces of a ricochet...
- Raw text -