Mail Archives: opendos/1997/04/18/06:15:14
>> >> 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 >> to
>> 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
>> 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
>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
Yes, *support* them by all means! But don't attempt to add our own little
features, we'll just end up making a bigger mess of the whole bloated thing.
>> >> 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
Er, it's far more difficult than I think?!
>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 ;-)
Are we going to chuck the kernal into ProtoMode? Probably a very good idea,
although it would be less compatable.
Having it compiled to suit your machine would be very nice, It shouldn't be
difficult to have IFDEF's and DEFINEs to make it produce XT/286/386 specific
code.
>> >> 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
>the market. But there's also an open question of 16-bit compilers - why
>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.
NASM sounds populour, I have yet to see it tho.
A86 is Shareware IIRC... GAS I've never heard of, AS86 would be nice, but it
would have to be ported.
- Raw text -