I am concerned by this statement from Jack's email: "Take a look at the sources for Microsoft HIMEM or EMM386, as I have…" This is the first I was aware that Jack had reviewed any source code from Microsoft.
If someone has studied the MS-DOS source code, that person should not contribute code to any parts of FreeDOS that intend to replace MS-DOS functionality. When Microsoft released the source code to an earlier version of MS-DOS (March 2014) we mentioned it on our FreeDOS Technotes page <http://www.freedos.org/technotes/> with a note that "If you download and study the MS-DOS source code, you should not contribute code to FreeDOS afterwards. We want to avoid any suggestion that FreeDOS has been 'tainted' by this proprietary code." I have given the same warning in other forums. It is important that we ask this of developers, so that FreeDOS cannot be accused of re-using code or coding concepts from the original MS-DOS source code. I know this seems unfair to some, but we must protect FreeDOS from any accusation that we benefit from proprietary source code. If Jack has reviewed the source code for MS-DOS HIMEM and MS-DOS EMM386, then we should not use any memory manager written by him. I see in the software list that we include these programs from Jack: BASE > UIDE http://www.freedos.org/software/?prog=uide * multi-purpose driver for UDMA, CD/DVD (IDE, no ASPI), disk caching BASE > XMGR http://www.freedos.org/software/?prog=xmgr * providing XMSv3 So we will now need to remove XMGR from the FreeDOS distribution. Jim On Wed, Jan 13, 2016 at 1:23 AM, Eric Auer <e.a...@jpberlin.de> wrote: > > > Jack writes: > > > > Eric, > > Re: your FD-User post about "new BIOS" UltraDMA errors, the post has > "just a few" ERRORS, which you need to correct: > > First, the title of your post, "BIOS with broken UDMA needs DOS disk > driver loaded before JEMMEX", should be changed. Instead of saying > "UDMA" that you and I understand, use the full word "UltraDMA" which > many more people would more-immediately understand. Also, one does > not need to load a DOS disk driver, which might be seen as "any" DOS > driver. One must ABSOLUTELY load a DOS *ULTRADMA* disk driver, as > this "new BIOS" problem applies only to UltraDMA done in "v86" mode! > > > Some mainboards have a BIOS with faulty UDMA in V86 mode support! > > Better to say "Some *new* mainboards have a BIOS with faulty support > for UltraDMA in V86 mode". Better English; and again, you should > replace "UDMA" with the full word "UltraDMA". > > > ... The presence of EMS memory hardware is simulated by moving > > DOS into a V86 task. > > Absolutely NOT TRUE! "V86" mode was created by Intel to provide a > way of (a) running 16-bit programs on 32-bit systems, (B) providing > protection for the system from such programs. EMS hardware is NOT > "simulated" but is REQUIRED to access extended memory, which is the > "E" in EMS! > > > When the BIOS fails to support UDMA (memory block copy and block > > copy between memory and I/O devices) properly in V86, attempts to > > transfer disk data can fail or end up at the wrong places in RAM. > > NOT what Martin Rehak saw! He got "Cold" DOS disk ERRORS, when his > system tried to do UltraDMA output using his new mainboard. He did > NOT indicate what happened to his data, during such I-O transfers -- > Martin got only disk I-O errors from his V6.22 SYSTEM! > > > DOS disk drivers could potentially test if your BIOS is buggy, but > > it will not always be possible to do that without causing a crash. > > In the BEST case, the driver could conclude that no UDMA will work. > > Given Martin's new mainboard, it will NEVER be possible to do such a > test, I guarantee you! Also, if we limit "DOS disk drivers" to the > ones I wrote, assuming "no UltraDMA will work" says the drivers MUST > "call the BIOS" to do such I-O. My drivers were meant for UltraDMA > and have no "PIO mode" code for disks (XDVD2 must have it for CD/DVD > "audio" and other drive commands). Calling the BIOS on such a "new > BIOS" mainboard WILL cause crashes, as the BIOS itself is a PROBLEM! > > > In the WORST case (!), the BIOS itself defaults to UDMA disk access > > and crashes as soon as you enter V86 mode. In that case, you will > > be FORCED to load a driver like XHDD or UIDE before loading JEMMEX > > to protect your BIOS from its own stupidity ... > > Not the worst-case, but the EXPECTED case, as modern BIOS programs > ALL use UltraDMA to improve speed! Also, unless you desire nasty > words from my "good friends" Rugxulo and Hall, I would not mention > XHDD, since it shall remain closed-source and thus unavailable for > use within FreeDOS, also unavailable for archiving on SourceForge. > > > To avoid crashes, it is important to LOAD DISK DRIVERS BEFORE EMM > > (if your BIOS is affected by such bugs). For example, load XHDD in > > your boot process before you load JEMMEX. If you disk driver is > > using XMS (for example as cache) you can of course not use JEMMEX > > as your XMS driver, but have to load a separate XMS driver before > > the cache, as JEMMEX has to be loaded after the disk driver... > > Likely a very "confusing" paragraph, for the average user! Again > I would suggest NOT mentioning XHDD, as it shall never be any part > of FreeDOS. Do try to write "simplified" English so more of your > users will understand what is going on. I target "4th graders", > which some view as insulting. But, I know doing so is NECESSARY! > > > Some drivers can use HMA space provided by XMS drivers (as HIMEM) > if no UMB space (provided by EMM386 and similar) is available ... > > Never heard of any other DOS drivers loading in HMA, except my own. > > > Jack recommends to load HIMEMX then UIDE then JEMMEX: That way, the > > UIDE driver can use the HMA and HIMEMX + UIDE will use circa 3.5 kB > > of low DOS memory together. If you only load UIDE and then JEMMEX, > > UIDE would need 4.5 kB of low DOS memory and would miss early XMS. > > All true, with V6.22 or V7.xx MS-DOS. NOT TRUE when using FreeDOS, > since FreeDOS does not make any HMA available to CONFIG.SYS drivers! > When using FreeDOS, there is NO SUCH THING as "early XMS"! > > > An even more advanced suggestion by Jack is to load XMGR /B instead > > of HIMEMX, then UIDE, then JEMMEX, then XMGR again, but without /B, > > which allows XMGR to regain 2 kB of memory as soon as JEMMEX is on. > > JEMMEX will NOT load if another "XMS manager" driver is loaded! If > XMGR is present, only JEMM386 or another "non-XMS" EMM driver can be > used. XMGR + JEMM386 solves the problem of FreeDOS permitting only > one upper-memory "provider, in this case JEMM386. UMBPCI + JEMM386 > may not be used together, on FreeDOS. That is why I suggested this > CONFIG.SYS "scheme", from my driver README file. But NOTE that it, > too, may not be of much use -- the full UIDE then must load in "low" > DOS memory, since FreeDOS does NOT offer HMA before AUTOEXEC is run! > > > Note that FreeDOS by default does not give drivers access to HMA > > space at all inside config.sys, so you would have to delay those > > driver loads to autoexec - other DOS variants are more flexible. > > What you suggest would be the WORST case of all!! JEMM386/JEMMEX > cannot load on a "new BIOS" mainboard unless an UltraDMA driver is > already loaded. If you delay loading UIDE until AUTOEXEC, and so > have no "EMM" driver during CONFIG.SYS, FreeDOS and most other DOS > systems will REJECT your "DOS=HIGH,UMB" command! The user system > then gets a low-memory-ONLY kernel, having no upper-memory nor HMA > available! An "EMM" driver MUST load during CONFIG.SYS; and now, > due to our "cheap" Taiwanese friends, an UltraDMA driver MUST load > before the "EMM" driver -- unless you want to try a diskette/etc.! > > > PS: When you boot Windows or Linux, the protected mode disk drivers > > of the operating system are usually activated BEFORE any V86 tasks > > get the chance to try to access the disk. This is why the BIOS bug > > can go unnoticed - only DOS will suffer, other systems don't care. > > Try telling THAT to Martin Rehak, who spent a LARGE number of hours > in a vain attempt to get his miserable Win/98 system to "boot"! I > cannot speak for Linux, as I have never used it. What you say may > be true for "larger" Windows systems; but it is NOT true for Win/9X > variants, in which Microsoft "Broke EVERY rule in the book"! Take > a look at the sources for Microsoft HIMEM or EMM386, as I have; and > you will SEE how they created the perfect "Frenkenstein's MONSTER", > then had virtually NO CHOICE but to "abandon" all of that GARBAGE!! > > Jack R. Ellis ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
