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: -bootsector -kernel -configuration file (config.sys) -XMS driver -other drivers (EMS for example) -shell -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 MEM /C /N echo Uh oh %COMSPEC% eats a lot of low memory.. DEVLOAD XMGR.SYS %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: SHELLHIGH=C:\RUNSHELL.COM C:\COMMAND.COM where RUNSHELL would do something like: @echo off goto loop :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. http://p.sf.net/sfu/cisco-dev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
