Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

p7zip 9.20.1b "testing" (Users)

posted by Rugxulo Homepage, Usono, 05.09.2012, 02:12

> Thank you for your continual efforts. The gcc 4.71 builds are a little
> faster across the board, but a little more bloated also (at least when
> packed with UPX).
-Os isn't always smaller after UPX than -O2, strange but true. But again, I don't know what Khusraw's specific compiler and libc and optimization flags were, so I can't honestly compare.

> The times are best for my Atom with the Atom build
> (surprise!) and on my i7 with the Generic build (huh?)
I assume only 1% or 2% difference. They should probably be fairly similar.

> On extensive testing your 9.20 builds are inferior in one major way to the
> old stable 9.13 build. This may be a limitation of the gcc version, or a 2
> GB/ 4GB bug, but I can't decompress lzma archvies created with a dictionary
> of 1024 MB with your 9.20 builds, but they DID decompress just fine (even
> on my 1 GB Atom) with Krusraw's build of 9.13.
Strange that they worked with his build. Anyways, you can try HX + 7ZA or LZMA (utils) or XZ (utils) even to unpack them, I think. Though why you would use 1 GB dictionary is beyond me (is your data at least that big??).

> Gives a "Can't allocated
> required memory!" error and bombs out. This error occurs even on my i7
> machine which has 32 GB of RAM installed. Some sort of DOS memory
> allocation error in either DJGPP or gcc?
Yikes! HPC? Servers? VMs? Games? :-))

All I can barely guess is it's some limitation or bug. I've encountered some rare errors on my 6 GB machine too. CWSDPMI r7 (via GO32-v2) reports 4 GB free (which is wrong) and thus refuses to swap, assuming it doesn't need to. But it needs to swap for page tables (since so much free RAM is found), which are always in low RAM (CWSDPMI design decision). So some things fail. CWS says DJGPP libc assumes a lot of 2 GB signed stuff, so you may not be able to correctly use more than 2 GB of RAM in most (all?) DJGPP apps except via very very selective use of raw sbrk(), i.e. alloc 1.5 GB x 2. Dunno, never tried that.

I don't remember offhand (would have to check my emails), but eventually CWS just had me binary patch the crt0.S line "shr ecx,8" to use "5" and thus rounds up memory allocations differently, which somehow defeated my particular problem. But I don't know if that'll help you (if only helped me with Seed7 compiled compiler on "chkbig" and "chkset" via "hi chk_all"). You could also try "HDPMI32 -r" first to see if it really is a CWSDPMI r7 bug or not.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum