Mail Archives: opendos/1997/04/18/02:29:33
Once upon a time (on 17 Apr 97 at 23:04) Lorier said:
> >> 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)
Exactly. I'd vote to patch the current tools to deal with the various FAT
file systems and leave the other systems to their native tools (most of them
would be ported to OS using DJGPP).
> >> 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) :)
;-) But it's not *that* easy. While there is no way in developing the FAT
standard(s), we have to support them - otherwise OpenDOS looses its power and
impact. And to be superior to M$ we have to *improve* the existing FAT
support to eliminate the possible problems their OSes have. And I expect that
FAT will die slowly anyway! ;-) But until then let's support it the best
possible
> >> 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 :)
Hmm... it's not that difficult as you think. It just requires 1/3 more work
and much more caution when writing memory/low level access code. I think that
I will develop it for i386+ firstly (since it requires more caution and
work than with 808x code) and then add the 808x compatibility pieces. After
all, XT/AT machines are not *that* popular these days ;-)
> >> 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 :)
Don't get me wrong here. I think DJGPP should be the primary OD compiler - I
love it and I use it all the time for "big" apps, it's definitely the best on
the market. But there's also an open question of 16-bit compilers - why don't
we use either Linux BCC (I hear it compiles and works on DOS) and/or LCC? As
to assemblers, we have a choice here: NASM, A86, GAS, AS86 (if someone ports
it to DOS, of course) and probably some more I don't know about. GNU provides
us with virtually every compiler for every language out there.
==================================================
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 -