> I think XDMA belongs in "Util" since it doesn't try to duplicate 
> functionality in MS-DOS.  We made an exception with UDMA and UDMA2, 
> though .. and I guess I'm open to discussion about moving XDMA into 
> "Base" as well.

I think neither belongs to BASE. Instead, it would be very good to
stop doing mini-distros which contain only BASE all the time. People
who want other categories still have to download every single package
or have to use beta 8 (!). If this turns out to be not possible (not
enough people who have time to ZIP up packages in FreeDOS directory
structure to make them ready for inclusion in the distro), I would
STILL not make *DMA drivers BASE, but just include them anyway ;-).
I mean: Have at least a "BASE plus the most useful packages of the
other categories" distro in that case.

Finally, as far as I understand, the Jack-versions are not overly
great anyway: Jack started UDMA, and Lucho worked (together with
Jack, I guess) on UDMA2, which has priority on being not only small
but also reliable. XDMA seems to be just a stripped down version of
UDMA with LESS sanity checks. Nothing that I would recommend to use.

About the Jack-version of SHSUCDX: Jason has completely stuffed his
SHSUCDX with macros, which means that you need a new and 32bit
version of NASM to compile it at all (16bit has not enough RAM...)
and that you have to use -O3 or better -O9 optimize option for NASM,
because non-optimizing NASM mode gets so confused by the macros that
you get a broken (double size) binary. As Jason thinks it is still
okay that way, but Jack does not, Jack created a SHSUCDX version by
just resolving and removing ALL macros (as far as I understand).
Apart from that, both versions are very similar. The Jason-version
has some unused buffers in the TSR, which Jack optimized away, but
that is more or less the only problem with the Jason-binary. Source-
wise, the Jack-version is hard to read because of the complete
removal of macros (automatic resolving, I assume) and the Jason-
version is hard to read because of the heavy use of macros.

So I personally would not recommend XDMA, and I have problems to
decide whether the Jack- or the Jason-SHSUCDX is the better one.

More talking about split programs, by the way: EDIT 0.7c should be
better than 0.82 in most aspects at the moment, please let me know
if EDIT 0.7c is worse than 0.82 in any important way... MEM 1.7
beta is better than 1.6 as far as I can tell, and MEMA by Arkady
is mostly different but neither better nor worse than MEM, but this
is better explained by Arkady. I most probably have overlooked some
bugs or features in either of the MEMs.

Finally, HIMEM versus FD*XMS*: This is simple, HIMEM is better and
only HIMEM supports EMS/XMS memory pool sharing (as does e.g. MS
HIMEM, it is only that FD*XMS* saves a bit of space by not having
the support). So you would ONLY want to use FD*XMS* if you either
have a 286 (FDXMS286) or want to show some radical style by mixing
drivers without reason ;-). And, by the way, it is GOOD that only
FDXMS286 supports 286. The overhead / development work to get some
combined driver "from 286 to 4 GBytes" would certainly not be worth
the effort given the lack of living 286 PCs today.


PS: News about old PCs, somebody wrote a BIOS for his Sanyo PC
(only contains a boot loader and floppy read drivers in the normal
"BIOS"), recompiled the kernel (DOS_PSP setting, SYS load segment
option and EXEFLAT load segment option were enough :-)) for the
1000:0 load location (after the Tandy-style paged graphics RAM) and
is now able to boot FreeDOS instead of MS DOS 2.11. Does not run
very well yet, though. Incomplete BIOS and maybe some load seg problems.

SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Freedos-user mailing list

Reply via email to