Hi!
4-Авг-2006 21:17 [EMAIL PROTECTED] (Japheth) wrote to
freedos-user@lists.sourceforge.net:
>> J> (apparently gives problems with extended keys).
>> Which ones?
J> As you possibly know, by reading port 60h you send the keyboard controller an
J> "interrupt acknowledged" signal, so it can send the next byte. On real
J> hardware this takes some time (some microseconds at least), but qemu is
J> unable
J> to emulate this slight delay.
You mean "does not emulates delay" (not "unable")?
J> So everytime the keyboard controller has to
J> send
J> more than 1 byte (as it is the case with the extended keys for example), qemu
J> will get confused if port 60h is read unnecessarily and send the next byte
J> too
J> fast.
? _How_ it confused? Also, your patch doesn't solves issue (which you
try to explain) in case, if extended key pressed together with Ctrl-Alt.
Ie., even if problem exist, then you fix for it incomplete.
>> I think, not "not hurt" - this "must have" modification. Because
>> original code lost all previous flags and enables interrupts on exit (which
>> may be undesirable by caller).
J> Yes, aggreed, but most likely you will not find a real-life application where
J> this is indeed a problem.
:) As I already say in some previous post: low probability for bug
makes it "less critical", but not makes it "not-bug".
>> PS: There are more changes, which I not mention, and which are not
>> commented. For example,
J> You promised not to mention them, so why do you nevertheless?
"Promised"?! Where I promise such thing?!
>> what does DebugBreak? (Letters "swat" suggest, that
>> this relates to 386SWAT debugger?)
J> yes I wanted to call 386swat on exceptions - if it was loaded
386swat specific? Or this is more generic and applicable for other
debuggers? If first, then, I suggest, this code shouldn't be present in
production code (release) - not in executable (see how Michael excludes
CheckBlockIntegrity or even not in source.
>> Then, you change "map" from "1.75M" to
>> "1.5M" - by which reasons? I suggest, this may have bad effect, because
>> Michael found (though, as always, not comment) some issues, which relate to
>> size of preallocated memory.
J> IMO this is a safe optimization,
Ie., this is only optimization, not fix for something?
J> at least since recently because the address
J> context is switched now to the host for the VCPI memory functions - this is
J> part of the main issue.
I remain this question up to Michael, because I myself not understand
anything there, even with your comment.
>> Also, you add some deals with "client stack" -
>> no comments what wrong with original code.
J> But this is the main issue. Please read my explanation in Bugzilla.
Now I read bugzilla entry. But only because Eric sends URL for this...
>> You replace some code by "clts" -
>> is it code optimization (reduction) or something more?
J> Just an optimization.
Then Michael may object against this. :( At least, in FreeDOS
pre-release state. :)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
