Eric, > FD-EMM386 is very outdated, yes. But when it was still maintained, > updates were often tested by a number of users. With JEMM, it is > more like "here is an update, enjoy".
I can sympathize with Japheth re: testing JEMM, as I have the same problem testing UIDE: Very FEW who DESIRE to "test" our drivers!! >> I have reviewed Japheth's "Changelog", I believe much of what he >> had to do changing FD-EMM386 to JEMM386 are "Flat-Ass DISASTERS" >> [in FD-EMM386] and I shall continue to AVOID using FD-EMM386... > > Thanks for taking the time to read the changelog, can you give some > examples of bad FD-EMM386 bugs which were fixed by JEMM? "Ask, and Ye shall receive!", from the ChangeLog on the "JEMM" page at <www.japheth.de> -- >> 03/27/2007 >> bugfix: free EMS pages not always reported correctly. >> bugfix: translation DMA for 16-bit controller (channels 4-7) didn't >> work. >> >> 03/02/2007 bugfix: XMS function 11h (free UMB) always returned an error. >> >> 10/07/2006 bugfix: allocating a EMS block with zero pages (int 67h, >> ah=5Ah, bx=0) returned with AH=0, but did not return a valid DX handle. >> >> 09/30/2006 >> bugfix: VDS functions 03, 04, 07 and 08 may have failed if bit 1 of DX >> was set (request to copy in/out of DMA buffer) and registers BX,CX >> were <> 0. >> bugfix: 1 kB of DMA buffer may have been inaccessible. >> bugfix: releasing a DMA buffer of size < 1 kB always failed. >> >> 09/06/2006 bugfix: writing to "ROM" page FF000 if ALTBOOT wasn't set >> caused a crash. >> >> 08/25/2006 bugfix: unsupported VDS functions caused a debug display, >> which didn't work and may have caused corruption of monitor data. >> >> 08/23/2006 bugfix: DMA buffer is ensured to begin on a 64 kB physical >> address boundary. >> >> 08/17/2006 bugfix: in VCPI protected mode entry switch to host stack >> before context is switched. 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??!! > Of course there are zero JEMM bugs fixed by FD-EMM386, but that does > not mean that JEMM is by definition free of bugs. 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!! > I do believe Alain when he says that he did have data loss with the > latter - which may not be due to bugs at all, maybe it is just that > JEMM makes it easier for the users to shoot their own foot. Then why, Eric, does FreeDOS have JEMM/HIMEMX in its "Base Software" list?? Your comment disparages the very system you support!! >> ... I absolutely REFUSE using "old EMM386" by Gates & Co. ... > > Nobody suggested to use the EMM386 by MS ... Glad to hear THAT, since neither do I!! >> ... I also want NOTHING to do with FD-EMM386 and anyone who >> wonders why can read the Revision Notes for JEMM386 ... > > Examples please ... See above, or read the JEMM ChangeLog yourself if you want more. >> ... It does not help when Alain says that his customers have >> burning computers with JEMM and you say you get nightmares >> from FD-EMM386 ... There must be something in which BOTH >> Alain and you are right, and finding that would help to >> convince Alain to trust JEMM and help to improve it. I get NO nightmares from FD-EMM386, since I have never USED it! On working to improve JEMM386, I like it as-is, I trust Japheth to make it better using HIS judgement, and I admit to NOT being enough of a protected-mode programmer to test it properly. We are all "specialists" in software, and my "specialty" is device drivers and caching, not protected-mode! >> Re: JEMM386/JEMMEX failing on some systems, this is likely >> due to "modern" address spaces that the JEMM drivers can't >> detect. But Japheth once told me that he CHOSE to retain >> all of EMM386's memory-detection logic, so his drivers are >> "compatible" with what Gates & Co.'s [never updated] TRASH > > How can JEMM retain code from MS EMM, I would rather assume > it retains FD-EMM code? 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! > You know my conclusion - EMM drivers are just not suited for > one size fits all boot disks. But this is a pity and I would > be happy if some EMM driver could eventually prove me wrong. 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! >> Finally, it is a bit "LATE in the game!" to be thinking of >> new schemes for handling the "A20" line. My own XMGR has >> exactly 4 methods: >>(A) IGNORE "A20" if it is found "enabled" when XMGR loads >> i.e. the DOS kernel turns it on forever. > > If you mean FreeDOS: No the kernel does NOT turn on the A20, > it asks the XMS driver to do that. But it would be NICE if > the driver could explicitly switch A20 ON and THEN does not > touch it any more ... 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??!! > In short, I would be happy about a "force-on" "A20 method". Glad to hear that, since your own FreeDOS is already DOING so! >> (B) Use keyboard-port logic if /PN was given. >> (C) Use port 92h i.e. IBM PS/2 logic if /PA was given. >> (D) "Ask the BIOS" if port 92h logic is there, if neither >> /PA nor /PN is given. > > Fair enough. I hope the BIOS is reliable for the detection. So do I, as such calls were defined by Gates & "Flunkies" about 20 years ago! >> XMGR doesn't handle the usually-ignored BIOS calls ... > > What makes you think they are usually ignored? Would the BIOS > not at least ANNOUNCE that they are ignored, detection-wise? Knowing the "children" on that island in the South China Sea who write BIOS programs, I doubt any BIOS would make such an announcement. "C" is the "top language" for their masters, who are all "cheap" anyway, thus TRAINEES get most BIOS work since it tends to be "Horror of HORRORS" ASSEMBLY-language!! Why do I say such calls are usually ignored? Because XMGR has NEVER supported them, and no one has ever "complained" to me that the "A20" BIOS calls SHOULD be supported! One more "nice idea" by Gates & Co. that I expect nobody uses! > In any case, BIOS calls tend to do (B) or (C) anyway, just in > a slower way, so you are right to ignore those calls, and the > ancient stuff as well, of course :-) Of course! >> So, why don't we just leave current "A20" handling as-is?? > > See above. Or maybe the KERNEL could do part of the work ... 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". To use an old U.S. phrase, "Don't MESS with success!" [and the word "mess" is the polite 4-letter word!]. > Note that my suggestion is NOT related to Alain's "I had > vague problems and think A20 changes help". It is more > my GENERAL suggestion - namely that we should stop switching > around a dusty rusty address gate line. Let's just make SURE > at boot that the gate is OPEN, then keep it like that. As an > OPTION for the command line of any XMS driver, for example ... I disagree. MS-DOS and PC-DOS have good reason for NOT hard- enabling "A20" that the other kernel designers have forgotten. There ARE still a few programs which use their OWN enables and disables of "A20", and those programs FAIL if the line MAY NOT be switched-off or switched-on! I do not recall exactly what programs they are, but I DO recall that the LOADFIX program in MS-DOS and Windows specifically "remedies" one such problem! Given that, I am NOT in favor of adding such a hard-enable for "A20" in my XMGR driver. If other XMS managers offer such an option, I hope their users "Know what they are doing!" if they use that option!! [And "Know what they are doing" has become just as problematical as some of the "A20" issues themselves!]. Jack R. Ellis ------------------------------------------------------------------------------ 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@Ciosco 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
