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 
pretty well.

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) 
completely redundant.

> 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)
-XMS driver
-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 
the picture.

> 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:

@echo off
echo Uh oh %COMSPEC% eats a lot of low memory..
%comspec% /reload
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:
@echo off
goto loop
exec arg1 arg2 arg3 etc..
goto loop

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!].

haha :)

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

Reply via email to