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
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
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
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
* multi-purpose driver for UDMA, CD/DVD (IDE, no ASPI), disk caching
BASE > XMGR
* providing XMSv3
So we will now need to remove XMGR from the FreeDOS distribution.
On Wed, Jan 13, 2016 at 1:23 AM, Eric Auer <e.a...@jpberlin.de> wrote:
> Jack writes:
> 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!
Freedos-user mailing list