Re: [Freedos-user] XDMA, SHSUCDX and other split-version programs

2005-06-19 Thread Jim Hall
Let's keep this thread only for XDMA and SHSUCDX ... please leave 
discussion about Eric's FreeDOS EDIT to the other thread.  Thanks.



[EMAIL PROTECTED] wrote:

Hi!


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.


This is up to the person making the distributions.  There's no "law" 
that states a FreeDOS distribution must include only the software on the 
'Base' list, or that it must use any of the utilities on our software 
list, at all.  I maintain the software list these days, not the FreeDOS 
distributions (and I prefer not to maintain the distros.)


However, I feel it is important to categorize utilities appropriately. 
I try to reserve the 'Base' list for only those programs that reproduce 
the functionality of MS-DOS.  I think we've added only a FEW programs 
that don't replicate MS-DOS behavior, but are otherwise extremely useful 
in a modern DOS.


I think that's how UDMA got on the 'Base' list, for example.  And UDMA2 
(UDMA "devel") was put there because it was supposed to be the "next 
generation" of UDMA.  I decided not to put XDMA on the 'Base' list 
because it was a stripped down derivative of UDMA/UDMA2, not a replacement.




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.


Yeah, I'm not sure what to do with the two SHSUCDX's, either.  As I 
mentioned in my other email: I feel strongly that we should avoid 
duplication on the Software List.


My intuition is that if there isn't a major difference between them 
(i.e. more functionality, better stability, etc.) then it's best to just 
stick with the one that's being actively maintained.  And maybe that 
means we only include Jason's SHSUCDX, since he does seem to be actively 
working on it, and Jack only seems to be releasing a "cleanup" version 
of specific releases of Jason's SHSUCDX.  Of course, Jack has every 
right to release his own hacks against Jason's SHSUCDX, since the 
program was released under a non-specific, open-source, "freeware" 
license that does not take away any freedoms.


I'd like to hear from others to get your opinion: which should stay on 
the FreeDOS software list, and which should be dropped?  Does Jack's 
version have any extra benefits over Jason's original?


Sounds like there isn't a difference in functionality or bugs between 
Jason's and Jack's SHSUCDX.  That may be the deciding factor here.



If there aren't any opinions either way, I think I'll drop Jack's, and 
keep Jason's on the list.


-jh


--
I'm sorry my president's an idiot. I didn't vote for him.


---
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
___
Free

[Freedos-user] XDMA, SHSUCDX and other split-version programs

2005-06-18 Thread eric

Hi!

> 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.

Eric

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
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user