Gruess Gott,

On Mon, Mar 9, 2020 at 5:59 AM Eric Auer <e.a...@jpberlin.de> wrote:
>
> > As far as I'm concerned, UIDE [sic] died in 2015.
>
> Another reason to switch to UHDD and UDVD2.

I meant that I'm only personally aware of the 2015 "drivers" (long ago
abandoned). I was not directly informed of the later "ad hoc" early
2019 update of one, lonely file (UHDD.SYS). So I don't know the
difference because I only ever ran UIDE.SYS (which apparently is
defective or at least designed differently, according to you).

Who even takes credit for the 2019 update? Certainly it can't be the
original developer, can it? He still maintains his closed source
variant (last updated in November 2019), for zero practical advantage.
Why have so many competing variations (market segmentation??)?

> You do know that the 2019 version *does* include full sources
> of UDVD2, UHDD, UIDE and XMGR, I hope.

AFAIK, the developer is aware of and has elsewhere fixed known bugs in
RDISK and XMGR. But none of those fixes were propagated back to the
2015 version (UIDE, aka not XIDE) for FreeDOS on iBiblio. Why is that?

> Replying to my list, you ask for more exact descriptions of the
> improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:
>
> Better performance: UHDD 10% faster with read-ahead than UIDE.

Were these two designed differently? Or is this only in hindsight,
i.e. some 2019-era bugfix of older 2015 code? Why have two separate
versions that behave differently? (There could be a good reason, I
just don't know why exactly.)

> Because UHDD (and UDVD2, in spite of being "old")

"Old" is fine when it works. I'm not complaining about age but moreso
bugs, regressions, restrictions, licensing, redistribution. Also,
having too many subvariants and releases is confusing. It shouldn't be
so fragmented.

> recognize more drives as DMA/UDMA compatible, without false
>  positives, they give much better performance in those cases
> compared to situations where UIDE fails to detect the DMA support.
> This can mean up to several *times* faster in EMM386 context, as
> a BIOS would rarely bother to call the VDMA API to support
> fast protected mode or VM86 disks on DMA and rather use PIO.

I was under the impression that most EMM386s were unreliable on newer
hardware. So I don't try to use them too much. (Then again, CSM is
basically dead, so who cares.)

Yes, Japheth has updated JEMM386 a few times in recent months. Is that
the one you're referring to, or do you refer to other (much older,
more limited, buggier) vendors? Which ones have been tested in recent
years with these drivers? But even with JEMM we have several versions
(5.78, 5.79, 5.80-pre1) and subvariants (e.g. jemmex or jemm386). I'm
not complaining, we're lucky to have it, it's just a lot for people to
test (but most people don't). So I haven't tried it lately.

> > How is that even possible? Too many versions, too many
> > (alleged) bug fixes! Ridiculous!
>
> Being too annoyed to look at the new version will not make
> the new version worse. That is just your personal opinion.

Is UIDE.SYS completely irrelevant in lieu of UHDD.SYS + UDVD2.SYS?
Seriously, do you know? Is there literally any reason anymore to use
UIDE.SYS? Were they just designed differently, or is this only a
result of UHDD.SYS being "fixed" in early 2019??

> PS: The drivers are deliberately freeware with sources without
> giving a specific license as the author is against fine print.

FreeDOS, by design, has always favored free/libre or "open source".

* http://wiki.freedos.org/wiki/index.php/Open_source_software
* https://sourceforge.net/p/forge/documentation/userfaq/#free
* https://www.gnu.org/philosophy/free-sw.en.html

Going closed source for unjust reasons for zero practical advantage is
user hostile and the exact kind of thing that the GPL was designed to
avoid. No amount of partial updates and pretend lip service can change
that. He made a choice, based upon nothing, despite correction and
proof, but instead still keeps punishing end users, for literally no
gain. What a waste of time.


_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to