Op 20-10-2011 7:27, Jack schreef:
> Note that all of the "bugfix" items listed above are not-long after the
> final update for FD-EMM386, meaning that Japheth likely inherited them,
> from his predecessors. So, FD-EMM386 cannot (A) handle a VCPI switch,
> (B) has DMA-buffer address problems, (C) has VDS function-call problems
> and (D) has EMS-page problems!! Are those enough examples for you??!!
Tom Ehlert and Michael Devore implemented plenty of things in FD-EMM386,
there's plenty of stuff to be thankful for. I'm just glad Japheth saw
the opportunity to improve things even more. Also your drivers work
Just for the record, Japheth also has a slightly improved version of
HIMEM up, renamed to HIMEMX. I don't know if that's enough for people or
if XMGR is a definitive improvement, making HIMEMX (and HIMEM)
> Nor can I expect my own XMGR or UIDE to be "by definition free of bugs"
> since I am not God! "Bugs" are a fact of life with software, but what
> need NOT be a fact is how so many do so little to FIX their bugs!!
Proper testing can be a nightmare, I still have to create a usable
bootdisk(-image), but the trouble is you've got so many configurations.
A default layout is:
-configuration file (config.sys)
-other drivers (EMS for example)
-automation/login script (autoexec.bat)
What I see happening on real machine is XMS driver loaded, then some HMA
message, then a hang before shell is executed. Thus, excluding shell and
autoexec.bat is a good thing. For that, you'd need a config.sys driver
that can pause so previous driver can be excluded.
It gets even more fun when adding things like bootloaders and MEMDISK to
> Then why, Eric, does FreeDOS have JEMM/HIMEMX in its "Base Software"
> list?? Your comment disparages the very system you support!!
As you said lots of software is buggy, I think Japheth's drivers should
be considered default, likely with XMGR replacing HIMEMX though.
For 286 platforms, FDXMS286 (predating HIMEM) is still the only option
to my knowledge.
> Can't say what code JEMM retains or does-not retain. I only
> said it retains "all of EMM386's memory-dection logic", i.e.,
> its METHODS are the same, no-matter what actual CODE it uses.
>> If JEMM mimicks MS, then that could explain why JEMM is harder
>> to tame than FD-EMM for the user as AFAIR, FD-EMM tried to have
>> quite cautious detection :-!
> Can't say there, either, as I avoid FD-EMM386 like the PLAGUE!
JEMM was made more compatible to MS EMM386 indeed, altered from previous
default FreeDOS behaviour. That's not a bad thing. Not necessarily
optimal either, but it seems to work.
> Good luck waiting for one! But, why wait -- Why not recommend
> that users who create "boot" diskettes DO NOT include any "EMM"
> driver in such "boot" activities?? If a "boot" diskette is to
> get a system RUNNING, and maybe copy-over added files to use if
> the system boots from a hard-disk, WHO NEEDS an "EMM" driver in
> a diskette "boot"?? I use UMBPCI/XMGR on my own diskettes and
> have NEVER required an "EMM" driver when they "boot" my system!
Boot configurations without at least an XMS driver can be quite
troublesome as they consume lots and lots of DOS's low memory. The
troublesome part here is you can't automatically exit and reload the
primary shell either to reclaim large parts of memory:
MEM /C /N
echo Uh oh %COMSPEC% eats a lot of low memory..
echo Done freeing memory by swapping to XMS
A master shell program that in a looping way spawns a non-permanent
command.com would be great:
where RUNSHELL would do something like:
exec arg1 arg2 arg3 etc..
4DOS is a bit better with this as it by default swaps to disk, but that
ofcourse won't work if you're in a read-only environment.
My preference would be loading config.sys without any drivers but
instead relying on runtime. The only things sacrificed then are HMA and
UMBs (XMS driver can be loaded runtime, EMS driver also).
> You are BADLY misinformed! Make a copy of Lucho's old "boot"
> diskette (from the COMBOOTF.EXE file on Johnson Lam's website)
> and "boot" from it using Lucho's "Option 5", which is FreeDOS.
> Would you care to GUESS the first message XMGR will give you??
> Something like "NOTE: A20 line found on!", maybe??!! And if
> XMGR is the first actual DRIVER loaded, then what-else BUT the
> FreeDOS kernel is hard-enabling "A20"??!! A "Hairy Thunderer
> or Cosmic Muffin", perhaps??!!
Ah I found this message on my real hardware as well. Not sure if that
was only inside MEMDISK, or also if loading FreeDOS directly from USB
flash disk. It's worth trying with MSDOS indeed (though that will ruin
the USB drive's SYSLINUX bootloader so won't do that for a while).
>> In short, I would be happy about a "force-on" "A20 method".
> Glad to hear that, since your own FreeDOS is already DOING so!
I'm wondering about what JEMMEX does different, as it does work for me,
while others find it trashing their system and/or data.
> So do I, as such calls were defined by Gates& "Flunkies" about
> 20 years ago!
Never underestimate BIOS writers for their spaghetti code. You've got
plenty experience dealing with their effort. And ofcourse
implementations of EEPROM access, ACPI, UEFI's "secure boot", USB
bootability and init speeds prove how bad things are. Another case is
the 'booting from FireWire' (as Apple has) which was never implemented
on PC. Let's hope Thunderbolt interface won't suffer that same fate.
> The kernel already IS doing part of the work! Try ALL of the
> options on Lucho's "boot" diskette"! You will find that only
> MS-DOS and PC-DOS are not hard-enabling "A20", when they load.
> DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard-
> enable "A20".
So some drivers can't cope with buggy BIOS/kernels with regard to A20
(and E820) ?
> To use an old U.S. phrase, "Don't MESS with success!" [and the
> word "mess" is the polite 4-letter word!].
I'll get testing sometime. Building a suitable test environment is
usually also a full day's work.
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
Freedos-user mailing list