Multi format support is not the worst idea in the world. Open up freedos more I say whether it's tsr and or native
Because freedos doesn't have ext2/3 support as such I had planned to add the support into aura gui either way. Support doesn't mean you have to use it but it allows other users to do things that you may not. On 01/10/2015 12:22 pm, "Rugxulo" <rugx...@gmail.com> wrote: > Hi, > > I don't wish to discourage you (much), but as mentioned, exFAT is > probably the worst idea in the world. > > I mean, come on, VFAT is *still* patented for two more years (even > though MS doesn't active rely on it [since XP prefers NTFS] or boot > from it [since Vista] anymore). We don't even have *that* (in the > kernel)! > > On Wed, Sep 30, 2015 at 10:56 AM, Joe Forster/STA <s...@c64.rulez.org> > wrote: > > > > You really stirred me up with this exFAT discussion and Eric gave me a > great > > idea with requesting LTOOLS. I connected the two, I delved into it and > spent > > most of the last five days with implementing an exFAT file system > processor. > > It is _very_ exciting! > > LTOOLS never seemed to work very well for me. Maybe it's my setup. > Maybe I need to look closer. But I think it would be wiser to clean > that up, port it, fix it, enhance it, etc. rather than messing with an > entirely new file system. ext2 is well-documented and used. Honestly, > putting full ext2 support in the FreeDOS kernel itself is hard, but > it's not impossible. It would be better to focus on that, IMO. (Maybe > some ancient Linux 2.0 [sic] sources would be easier to read/port than > newer ones??) > > Eric? Here's a small (GPLv2!) Turbo Pascal tool that one guy wrote > (years ago), loosely inspired by LTOOLS: > > http://tothpaul.free.fr/zip/LINUX.ZIP > > (Or maybe we should focus on something else like HPFS, which is > already well-supported in various *nix clones, is patent free, old but > still better than FAT, etc. There are incomplete drivers for DOS for > that, but I've never used them. I'd have to search my email archives > for the URLs.) > > > I have _not_ looked into any existing source, the software is written > from > > scratch, according to the contents of a virtual disk image (created and > > filled with data under Windows 7 running in VirtualBox) and reverse > > engineering documentations at: > > The above source is barely 600 lines (not counting blanks). I've not > tested it, so maybe it's crap. But it certainly gives me more hope > than exFAT (although clearly you're no slouch, but we cannot afford to > waste time on legalese, it's just too stupid). > > > Currently it has the following limitations: > > - it's written in C (not assembly), too big; > > - there will probably be a couple of nasty tricks to handle integers > larger > > than 32 bits in DOS (LBA48 support). > > Below you mention BC++. Why not OpenWatcom? Doesn't it already have > "long long" support for 16-bit DOS target?? AFAIK, yes. > > > Its nice features are: > > - it's written in C (not assembly) ;-) , should be portable; > > - it compiles under both Borland C++ (DOS, 16 bit) and MinGW/gcc > (Windows, > > 32 bit), without errors or warnings (all gcc warnings enabled) > > C is preferred overall (obviously for the kernel), but there is no > heavy reason to totally ignore Pascal (which you've already mentioned > you're familiar with). > > > I plan to release it, with full source, as soon as it can read files, a > > piece of standalone software (DOS and Windows) in the style of LTOOLS: > > (If you'd like to help or are interested, E-mail me.) I'm not sure about > licensing, as I > > was previously planning to donate _all_ my software into the public > domain, > > but I've been seduced here to go for GPL instead. ;-) > > I don't think you can (legally) GPL this at all. For instance, GPL > forbids requiring an NDA, and patents similarly make things almost > useless for the end user (to modify and redistribute, etc). > > I really don't want to whine here. I guarantee that I'm not much help, > which is why I tried to stay out of this discussion. But some things > just aren't going to work (IMO). > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
------------------------------------------------------------------------------
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
