I am getting VERY TIRED of responding to FALSE problems about my
Last month, an entire thread on this forum was labelled "Problem
with UIDE", when that actually was FALSE! The problem was only
a device-driver conflict, and it took several posts here to note
UIDE was being run WITH some unknown CD-ROM "boot" driver! And
after all that, the thread CONTINUED to use the heading "Problem
with UIDE", which it WAS NOT!!
In that thread, near its end, we also have the post noting --
> I managed to make a Boot CD that works almost in all machines.
> The only one that is not working is "Virtual PC 2007". It
> locks uppun execution of JEMM386 from a CD image. XMGR is
> used because it is required by UIDE.
That is totally FALSE! UIDE does NOT specifically demand using
XMGR and will run just fine with MS-DOS HIMEM, Japheth's HIMEMX,
or any other correctly written "XMS manager" driver. UIDE only
requires that SOME driver -- it DOES NOT care which one! -- sets
up the necessary XMS memory for UIDE to use as its cache!!
And today, I note the following new post, in the same thread now
labelled "Re: [Freedos-user] Problem with XMGR (was: UIDE)" --
> On one machine I got a strange XMGR problem:
> On first try, XMGR (with /B) reports "cannot determine A20 method"
> and does not load, repeating it immediately (without /B) it loads
> with "A20 allways on". Sorry, these are aproximate messages, the
> machine is 2 hours from here and another person was there. I did
> this double load, by singlestepping and saying "No" to jemm386.
> On the same machine Himem.exe worka just fine, using "A20 allways
As anyone can see in the XMGR.ASM source file, NONE of the above
messages will be displayed by XMGR, as none of them EXIST in its
source! XMGR is also written to use (A) no "A20 line" handling
if it sees "A20" already on at load-time, (B) IBM PS/2 "Port 92"
handling of "A20", or (C) old-style "Keyboard port" handling for
the "A20" line as its normal default.
XMGR will never -- I say again, NEVER! -- display that it cannot
determine which method to use for handling the "A20" line! One
of the above 3 methods is ALWAYS present, on today's PC systems!
The many "strange" schemes for handling "A20" (which made MS-DOS
HIMEM.SYS end up over 30K bytes long!) are long since "obsolete"
and no-longer in use, as far as I know. And "as far as I know"
is pretty good, since there have been FEW (legitimate!) problems
with XMGR for a long time!
XMGR can display "NOTE: A20 line found on!", if that is so when
the driver loads. But, it CANNOT display "A20 allways on", and
the use or non-use of its /B switch does NOT affect which method
for handling "A20" will be used. Obviously, the PC system does
not change, between XMGR'S "boot" and its final loading in upper
memory, so it is FOOLISH to think that /B could have any effect!
If the message "cannot determine A20 method" is being displayed,
I quite strongly suggest that it is coming from SOMEWHERE ELSE!!
Maybe, that other system "2 hours away" was in fact using MS-DOS
HIMEM at that time, since as I recall HIMEM could display such a
message, if all its miserable 30K of init logic "gets confused"!
Or, maybe some other program or driver -- but NOT XMGR!!
I am SORRY, if people don't like hearing all this from me -- But
there are those who need to be A BIT MORE POSITIVE re: problems,
before they so-quickly RUSH to call them "Problem with UIDE", or
"Problem with XMGR", or problem with anything BUT their own lack
of reliable-and-true information ABOUT their problems!!!
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
Freedos-user mailing list