Hi, On Fri, Jul 5, 2013 at 10:11 AM, Matej Horvat <matej.hor...@guest.arnes.si> wrote: > On Fri, 05 Jul 2013 15:29:18 +0200, Rugxulo <rugx...@gmail.com> wrote: > >> 0.82 is the "stable" version (preferred by Eric Auer) and the only one >> on SourceForge, but 0.84 is somewhat preferred by others (at least >> me). 0.82 doesn't support LFNs, that was a later addition (by Blair >> Campbell?, also added DESCRIPT.ION support). > > The version I use is "0.84-pre2 XMS_Swap", simply because it's included in > the official FreeDOS 1.0 and 1.1 distributions.
Yes, but I'm not sure it's considered fully stable over 0.82, even. I mean, there's a reason that 0.82 wasn't completely put out to pasture (AFAIK). > Well, FreeCOM is the default, so maybe /LFN should be the default. But SFN is the default since LFNs are still patented (and moreso nobody has added any patches to support them in the kernel proper). So it doesn't make sense unless you have an LFN driver loaded all the time anyways (e.g. DOSLFN). Yes, I know, "obviously". Then again, I don't guess it would majorly hurt anything in either case. (Keep in mind that LFNs slow file accesses down a lot. I don't hate them, but I do avoid them whenever possible.) > I think LFNFOR and LFNFOR COMPLETE should be off by default because many > programs don't support LFNs. (My own GENPKGLS doesn't, because it uses > OpenWatcom's fopen.) OpenWatcom 1.9 has "partial" LFN support, at least for 16-bit targets. "wcl -D__WATCOM_LFN__" or such, can't remember. (Blair was involved with that too, but I guess he never finished. Hence why the actual compiler itself doesn't support LFNs. Most people with a DOS preference can live without LFNs. I know, irrelevant to the issue at hand, but I'm just saying ... it's low priority for most people, apparently. >> It's not fully translated to OpenWatcom yet, IIRC. Bart did some work >> a year or two ago, but he never finished. So it's buggy. The official >> compiler that works is Turbo C (or whatever variant). So, for now, I >> would suggest sticking with that, if you can. > > OK, maybe I'll get Turbo C and try that. You still need SUPPL, which may? be annoying to compile. Here's a binary version of that library: https://sites.google.com/site/rugxulo/suppl.zip?attredirects=0 ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
