Message-Id: <199704180625.IAA23437@math.amu.edu.pl> Comments: Authenticated sender is From: "Mark Habersack" Organization: PPP (Pesticide Powered Pumpkins) To: Lorier Date: Fri, 18 Apr 1997 08:27:03 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Usage of directory entries Reply-to: grendel AT hoth DOT amu DOT edu DOT pl CC: pierre AT tycho DOT com, opendos-developer AT delorie DOT com In-reply-to: Precedence: bulk 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...