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
