Hi!
5-Июл-2004 18:40 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
>> Michael, what about testing edition of EMM386 (which fills last para
>>of included area by specific values)?
MD> Probably better handled by a stand-alone program which directly allocates
MD> and writes to UMB's rather than pumping up the resident size of EMM386 for
MD> limited testing at startup.
I think, much easier, faster and better to add small routine into
EMM386 (which will fill last para before returning "Largest UMB" segment)
than write:
- big, full-featured driver, which should:
- installed before EMM386;
- trap EMM386 installation and before control returns to DOS (if this
possible at all!), should reinsert itself into XMM chain.
MD> Stand-alone app is more flexible and provides
MD> much easier debugging for any problems uncovered.
Me need neither "more flexible" nor "easier debugging", me need only
prove that previous code works incorrectly.
>> Also, now you may not replace A000 starting limit by A001 (and even
>>join this memory area to base memory). With older kernels version users may
>>use A001 explicitly to overcome its bugs.
MD> I will not change the A000 to A001 code since I didn't write it, the code
MD> is not part of anything I've worked on,
Ok, accept this as "request for feature".
MD> and it's closely tied to the kernel operation.
This is not so. Kernel itself not touched by this. Of course, if you
add code, which will join new segment to base memory (marked by 0:410 word),
as this does MS-EMM386, then this require to modify MCB chain also (though,
not neccessary), but this _not_ "tied to the kernel operation" (unless you
mean some bugs in kernel, which will not allow to see the positive effect).
BTW, I test with MS-EMM386 - now joining video memory to base memory works
perfectly.
MD> Given the ongoing state of affairs between those who originally
MD> wrote that code and yourself,
? Which "that code" and who "originally wrote"?
MD> plus past remarks here from others, I'm
MD> uncertain of the chances of modifying EMM386 to match your wishes,
Ie. you "uncertain" that mimic MS-EMM386 and cloning all its features
is right way?
MD> but if you think it appropriate
Yes, I think so.
MD> I'd recommend asking Tom Ehlert or any of the
MD> other original authors (whomever they might be) about making the change. I
MD> already have enough stress in my life rather than get in the middle of that
MD> debate -- or anywhere within ten miles of it.
Unfortunately, I doubt that tom will spend his time to even hear my
proposals. He even rejects idea of adding VCPI some time ago, before you
gets this question into your hands. :(
>> Also, EMM386 doesn't support RAM option. This was "surprised" me when I
>>test both MS-EMM386 and your EMM386. And this causes question from user
>>(which ask me directly in email about this).
MD> RAM is an obsolete option that the I= and X= options perform much more
MD> efficiently and with greater flexibility.
I _know_ that making UMBs with MS-EMM386 I should use RAM option. When
I use this option with your EMM386, I was wonder why I not get the UMBs.
MD> Most people still using RAM
MD> probably don't understand what they are doing with EMM386 very well and
MD> either are failing to fully utilize free UMB space or are exposing
MD> themselves to a greater risk of UMB conflicts.
But if they are don't know/understand the UMBs making logic (and don't
know what I= should do and which addresses there should be present), then
they should be losed the UMBs? Unfriendly point of view. :(
MD> It necessary, RAM can be completely emulated within the command line parser
MD> via internal mapping to I= and X= options. It wouldn't take a lot of time
MD> to implement.
Yes, it worth of adding emulation, especially because this adds
compatavility.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
