<huh, I thought this went to the developer list, but it didn't. Looks like
it should.>
At 07:48 AM 7/29/2006 +0400, Arkady V.Belousov wrote:
>0. In emm386.c you forget remove one space (in "/ *").
And? It's a comment. Is there another one of those #ifdef 0 type
things? Because I'm not ready to debate the style of embedded comments again.
>1. Bug: wrong handling for clc/stc in some places (they ignored, because
> popf follows, thus caller receives "always success") ...
I found two. They don't appear to matter in the normal course of things,
but if memory got low or ran into partial block allocations, VCPI might run
out of memory prematurely when free areas were available. Okay, that was
worth the entire thread. I'm going to have to nominate you for next
month's FreeDOS Contributor of the Month. What flavor gum you want?
>2. Probably, bug: CF not initialized, although comments say so ("probably"
> because I not found in RBIL spec for INT 67/87) ...
No such spec. It's a FreeDOS-specific redirect of INT 15, function
87h. Anyway, TEST AH,AH clears the carry flag to known state, the STC sets
to known state if error. Everything looks fine to me there.
>3. Bug: missing popf after @@NO_386 ...
Fixed, although I'm not sure a 286 would get there. Does UPX decompressor
run under non-386? If not, the decompression code will stop it first.
>4. Misfeature: UMBfree does not merges free blocks.
Never intended to. I remember the original explanation for this when it
came up (it's not my quote following), and I pretty much agree with it.
Paraphrasing heavily: UMB blocks are usually handled by DOS (i.e. people do
DOS=UMB). Even when they are not, very few applications would allocate and
then deallocate UMBs dynamically, they almost always are allocated at
startup and stay attached to the allocating application (for good
reason). Upgrading the UMB code for merges etc. was therefore considered
an unimportant detail at the time.
I did make the original code a bit more intelligent about splitting
allocation blocks a while back, because there was an application test where
it made a difference, but I never tested an application where merges were
necessary. As I've said for the past many years, my changes to EMM386 and
HIMEM are need-driven, not theory-driven. Show me a real-life application
which suffers, and I'll usually make the change. Otherwise, usually not.
Perhaps you can rewrite the functionality post-1.0 release. It's a good
candidate for detail work.
>5. Probably, bug: CF always =0 after XOR, thus, first CheckBlockIntegrity in
> next code never called ("probably" because I not very understand idea of
> given code - thus, first call to CheckBlockIntegrity may be only
> superfluous code, which may be safely removed) ...
I removed CheckBlockIntegrity code. I'm still not convinced it makes any
difference in the grand scheme of things, but it should make everybody
happier. It served its purpose here during early stage VCPI testing.
>6. Superfluous code (not need to check, if block at [edi] precedes block at
> [esi], because they will be found at next iterations) ...
Not superfluous, per previous explanation. It's a very cheap and quick
short-circuit, "superfluous" code would be totally without any use. You
mean it could have been done better. Yes, it could. I just made it do its
work as quickly as possible and left it at that. Since it's called almost
never relative to internal functions and since it's a few bytes living in
extended memory, optimizations aren't of much use. Literally almost any of
the rest of the code would gain more benefit from
optimizations. I thought you were rewriting that function, anyway.
-------------------------------------------------------------------------
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-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
