Mail Archives: opendos/1997/04/17/07:12:23
>> > 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.
Many of the tools are FS specific. things like ChkDsk would function
completely differently for different FS's. We don't want to limit ourselves
to the FAT family of FS's.... we at LEAST want to support ext2, and probably
all the other FS's that Linux supports (At least)
>> > 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!
I think that we should just do ext2 (But I'm subtly biased). Leave FAT for
dead (and Microsoft) :)
>> > 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?
I'd like to see when the opendos sources become avail the ability to compile
for XT/AT/386. XT for example can't use BOUND or ENTER/LEAVE which are nice
to have. a 386 can make use of the faster movsd and other features to get
some more speed out of the OS... it doesn't have to be 32b but having a
second handler that DMPI servers could call that would run in ProtoMode
(thus elimitating the swap from Protected mode) would be a big plus (and
rather difficult to do :)
>> > 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.
Hmm... We definately need a standard set of compilers :)
- Raw text -