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 <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
