flat assembler
Message board for the users of flat assembler.

Index > Heap > UPX memory @Rugxulo hogginess | BIG compression thread

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Hmm am a bit confused here. First of all I had no idea KGB archiver was made by Tomasz Shocked

Secondly, PAQ uses neural network compression or what? How can it compress already-compressed .jpegs?
Post 10 Mar 2009, 17:59
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7714
Location: Kraków, Poland
Tomasz Grysztar
Borsuc wrote:
Hmm am a bit confused here. First of all I had no idea KGB archiver was made by Tomasz Shocked
Tomasz is a very common name in Poland, and we have many programmers here, too. So don't be suprised to meet projects made by programmers with this name. Wink

Borsuc wrote:
Secondly, PAQ uses neural network compression or what? How can it compress already-compressed .jpegs?
http://en.wikipedia.org/wiki/JPEG#Lossless_further_compression
Post 10 Mar 2009, 18:04
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Quote:

KGB Archiver 2 team

Author: Tomasz Pawlak


It should probably also list Matt Mahoney (PAQ author).

Tomasz Grysztar wrote:

Tomasz is a very common name in Poland


Blindly assuming it's the same as "Thomas" (right??), it's an extremely common name. One of the 12 Apostles was named Thomas (aka, Didymus, aka "Twin").

Borsuc wrote:

Secondly, PAQ uses neural network compression or what? How can it compress already-compressed .jpegs?


It unpacks 'em, recompresses with a better ratio, and on unpacking undoes all of that (so you don't lose any data or clarity, file remains unchanged). Actually, the JPEG spec does natively support lossless compression (I think), but almost nobody uses that.

Code:
 Directory of c:\Armslurp\temp\moo

03/10/2009  05:58 PM           287,371 test.paq8o8z
03/10/2009  05:58 PM           325,926 test.paq8f
03/10/2009  05:56 PM           410,728 ppmd.7z
03/10/2009  05:56 PM           410,807 bzip2.7z
03/10/2009  05:57 PM           412,318 deflate64.zip
03/10/2009  05:57 PM           412,327 deflate.zip
03/10/2009  05:56 PM           414,838 lzma.7z
05/10/2008  03:44 PM           415,978 IMAG0492.JPG
               9 File(s)      3,213,985 bytes
    
Post 10 Mar 2009, 23:00
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
Your loss. Less floppies to transport, smaller e-mail attachments, etc. etc.


The only losses having a chance to apply here at all are either the JPG quality loss "feature" or the loss of reality failing to notice that JPG is already compressed Very Happy

Quote:
What, you think it goes too far? I agree 7-Zip is better for average / normal files, but otherwise you need something robust!


It's too slow. And, "good" isn't a synonym of "very maximal compression at any cost"

> MinGW better than DJGPP? (I assume that's what you meant.)

YES.

> No, it's not. In particular, MinGW builds won't work in DOS
> without MSVCRT.DLL, which needs a separate license.

True, sucks, still less evil than complete 10 GiB of ...

> Plus, their tmpfile() needs Admin access due to writing to root dir (!),
> which doesn't work by default in Vista.

Funny, probably some (registry) hack could "fix" this "bug" at a cost negligible compared to the wasted efforts trying to keep DGJPP 100% mainstream compliant Very Happy

> really really foolish if I started a new CMD as Admin every time just

100% as Admin all the time Idea

> I've timed it, the DJGPP version is no slower, at least for me.

Funny, in my tests MinGW was faster. Confused

> write you any more online messages, I might actually need a working Internet connection.

True, but it works or could work in DOS also. If not, ask your dealer for a driver. If he fails to provide any, then you simply bought a faulty device, and the only solution is to bring it back and crash it into his face with at least 670'616'630 MPH Shocked

> too hard to find a live CD for that.

At least Idea

Quote:
license and speed are really the "only" reasons for bothering. LZMA SDK version 4.43


But then you should update to LZMA 4.65 ASAP Smile

Quote:
Quote:
The garbage I/O is definitely the very same.

Code:
[ Vista ] - Mon 03/09/2009 >upx -V
upx 3.03
NRV data compression library 0.84
UCL data compression library 1.03
zlib data compression library 1.2.3
LZMA SDK version 4.43
Copyright (C) 1996-2008 Markus Franz Xaver Johannes Oberhumer
    


Nice, but misses the point (see post below) Shocked

Quote:
not be readily apparent, but UPX-UCL lacks NRV. Besides, the obvious way to tell the difference is file name (since I did NOT name my compiles UPX.EXE). Even the file date should tell you something.


YES, but not safe ...
Post 11 Mar 2009, 01:06
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Code:
AX=$3D00 <upxd>
AX=$4E07 <E:\upxd.com>
AX=$4E07 <E:\upxd.exe>
AX=$4B00 <E:\UPXD.EXE>
AX=$3D00 <E:\UPXD.EXE>
AX=$4200 orig=0 dist=$5400
AX=$4200 orig=0 dist=$5400
AX=$4200 orig=0 dist=$6000
AX=$71A0 <E:\>
AX=$71A0 <E:\>
AX=$4300 <--best>
AX=$71A0 <E:\>
AX=$4300 <a.dll>
AX=$4E00 <a.dll>
AX=$71A0 <E:\>
AX=$6000 <a.dll>
AX=$4E00 <e:/a.dll>
AX=$4E00 <e:>
AX=$4E00 <e:>
AX=$4E00 <e:/a.dll>
AX=$4E00 </etc/localtime>
AX=$4E00 </etc>
AX=$4E00 </etc/localtime>
AX=$3D00 </etc/localtime>
AX=$4300 </etc/localtime>
AX=$4E00 </etc/localtime>
AX=$4E00 </etc>
AX=$4E00 </etc/localtime>
AX=$4300 </etc/localtime>
AX=$71A0 <E:\>
AX=$4EB8 </etc/localtime>
AX=$4E00 <./GMT>
AX=$4E00 <.>
AX=$4E00 <./GMT>
AX=$3D00 <./GMT>
AX=$4300 <./GMT>
AX=$4E00 <./GMT>
AX=$4E00 <.>
AX=$4E00 <./GMT>
AX=$4300 <./GMT>
AX=$71A0 <E:\>
AX=$4EB8 <./GMT>
AX=$4E00 <a.dll>
AX=$3D20 <a.dll>
AX=$6000 <a.dll>
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=0
AX=$4E00 <a.upx>
AX=$4E00 <a.upx>
AX=$3D00 <a.upx>
AX=$4300 <a.upx>
AX=$4E00 <a.upx>
AX=$4E00 <a.upx>
AX=$4300 <a.upx>
AX=$71A0 <E:\>
AX=$4EB8 <a.upx>
AX=$4E00 <a.upx>
AX=$4E00 <a.upx>
AX=$71A0 <E:\>
AX=$6000 <a.upx>
AX=$4EC0 <e:/a.upx>
AX=$4E12 <e:/a.upx>
AX=$4E00 <a.upx>
AX=$4E00 <a.upx>
AX=$4E00 <a.upx>
AX=$4300 <a.upx>
AX=$6C00 <a.upx>
AX=$6000 <a.upx>
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0200
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0200
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=$0200
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0178
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0400
AX=$4200 orig=0 dist=$0003'3C00
AX=$4200 orig=0 dist=$0003'4400
AX=$4200 orig=0 dist=$0006'9600
AX=$4200 orig=0 dist=$0006'9C00
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=$0004'6000
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=$0004'6000
AX=$4E00 <a.dll>
AX=$4300 <a.dll>
AX=$4301 <a.dll>
AX=$4300 <a.dll>
AX=$4301 <a.dll>
AX=$4133 <a.dll>
AX=$4300 <a.dll>
AX=$5600 <a.upx>
AX=$4E00 <a.dll>
AX=$4300 <a.dll>
AX=$4301 <a.dll>
AX=$4C00 PANIC !!! (just exit)
    

Code:
AX=$3D00 <upxuc486>
AX=$4E07 <E:\upxuc486.com>
AX=$4E07 <E:\upxuc486.exe>
AX=$4B00 <E:\UPXUC486.EXE>
AX=$3D00 <E:\UPXUC486.EXE>
AX=$4200 orig=0 dist=$0800
AX=$4200 orig=0 dist=$0800
AX=$4200 orig=0 dist=$0A00
AX=$71A0 <E:\>
AX=$71A0 <E:\>
AX=$4300 <--best>
AX=$71A0 <E:\>
AX=$4300 <b.dll>
AX=$4E00 <b.dll>
AX=$71A0 <E:\>
AX=$6000 <b.dll>
AX=$4E00 <e:/b.dll>
AX=$4E00 <e:>
AX=$4E00 <e:>
AX=$4E00 <e:/b.dll>
AX=$4E00 </etc/localtime>
AX=$4E00 </etc/localtime>
AX=$4E00 </etc/localtime>
AX=$3D00 </etc/localtime>
AX=$4300 </etc/localtime>
AX=$4E00 </etc/localtime>
AX=$4E00 </etc/localtime>
AX=$4E00 </etc/localtime>
AX=$4300 </etc/localtime>
AX=$71A0 <E:\>
AX=$4EB8 </etc/localtime>
AX=$4E00 <./GMT>
AX=$4E00 <.>
AX=$4E00 <./GMT>
AX=$3D00 <./GMT>
AX=$4300 <./GMT>
AX=$4E00 <./GMT>
AX=$4E00 <.>
AX=$4E00 <./GMT>
AX=$4300 <./GMT>
AX=$71A0 <E:\>
AX=$4EB8 <./GMT>
AX=$4E00 <b.dll>
AX=$3D20 <b.dll>
AX=$6000 <b.dll>
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=0
AX=$4E00 <b.upx>
AX=$4E00 <b.upx>
AX=$3D00 <b.upx>
AX=$4300 <b.upx>
AX=$4E00 <b.upx>
AX=$4E00 <b.upx>
AX=$4300 <b.upx>
AX=$71A0 <E:\>
AX=$4EB8 <b.upx>
AX=$4E00 <b.upx>
AX=$4E00 <b.upx>
AX=$71A0 <E:\>
AX=$6000 <b.upx>
AX=$4E65 <e:/b.upx>
AX=$4E12 <e:/b.upx>
AX=$4E00 <b.upx>
AX=$4E00 <b.upx>
AX=$4E00 <b.upx>
AX=$4300 <b.upx>
AX=$6C00 <b.upx>
AX=$6000 <b.upx>
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0200
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0200
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=$0080
AX=$4200 orig=0 dist=$0200
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0178
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=0
AX=$4200 orig=0 dist=$0400
AX=$4200 orig=0 dist=$0003'3C00
AX=$4200 orig=0 dist=$0003'4400
AX=$4200 orig=0 dist=$0006'9600
AX=$4200 orig=0 dist=$0006'9C00
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=$0004'7C00
AX=$4201 orig=1 dist=0
AX=$4202 orig=2 dist=0
AX=$4200 orig=0 dist=$0004'7C00
AX=$4E00 <b.dll>
AX=$4300 <b.dll>
AX=$4301 <b.dll>
AX=$4300 <b.dll>
AX=$4301 <b.dll>
AX=$4101 <b.dll>
AX=$4300 <b.dll>
AX=$5600 <b.upx>
AX=$4E00 <b.dll>
AX=$4300 <b.dll>
AX=$4301 <b.dll>
AX=$4C00 PANIC !!! (just exit)
    


Very same for both versions (just count the lines Wink) Isn't it a bit silly ? And what are the file attributes of --best ? Laughing
Post 11 Mar 2009, 01:10
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> http://en.wikipedia.org/wiki/JPEG#Lossless_further_compression

COOL Sad

rugxulo wrote:
Borsuc wrote:

Secondly, PAQ uses neural network compression or what? How can it compress already-compressed .jpegs?

It unpacks 'em, recompresses with a better ratio, and on unpacking undoes all of that


YES, but this severely hurts the definition of losslessity Neutral

Quote:
(so you don't lose any data or clarity, file remains unchanged).


The core of the problem: bitmap only (sufficient ???) or complete file (much more bloated -> shitty compression) ? Shocked

Quote:
Actually, the JPEG spec does natively support lossless compression (I think), but almost nobody uses that.


YES, but 100% different algo (no DCT), and 100% useless, just use PNG. Idea

Quote:

Directory of c:\Armslurp\temp\moo
287,371 test.paq8o8z
325,926 test.paq8f
410,728 ppmd.7z
410,807 bzip2.7z
412,318 deflate64.zip
412,327 deflate.zip
414,838 lzma.7z
415,978 IMAG0492.JPG


So you tested and got it smaller 1.4475 times ?
Post 11 Mar 2009, 01:22
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Tomasz Grysztar wrote:
Tomasz is a very common name in Poland, and we have many programmers here, too. So don't be suprised to meet projects made by programmers with this name. Wink
Haha lol sorry for that Very Happy

Cool, I never would have thought a compressor would decode half of the JPG process (just the lossless part -- huffman part) and re-encode with something else. Seems too "specialized" for that purpose Smile

DOS386 wrote:
YES, but this severely hurts the definition of losslessity Neutral
Not really as it can get back the original JPG when you want it -- so it's still lossless. But it's "specialized" for that, I never would have thought that would apply to some general-purpose compressor Confused

_________________
Previously known as The_Grey_Beast
Post 11 Mar 2009, 22:51
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> Not really as it can get back the original JPG when you want it -- so it's still lossless.

But as I wrote above, this approach introduces the trouble to decide whether it's required to be able to reconstruct losslessly the bitmap only or the complete file (same MD5) - latter requires to re-do the RLE+Huffman+Packaging steps at ther occasion of "decompression".

> But it's "specialized" for that, I never would have thought that would apply to some general-purpose compressor

Obviously we have no longer "general-purpose compressor" then Wink

The most important point is that JPG format is obviously obsolete, what's needed more than such a "reversible JPG lossless recompression" is a new image format offering better efficiency and not suffering from "lossless recompression" issues. Of course one could design a format able to reuse the Subsampling+Blocking+DCT+Quantization steps of JPG compression so all JPG's could be losslessly converted into this new format Smile
Post 12 Mar 2009, 01:26
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:

The only losses having a chance to apply here at all are either the JPG quality loss "feature" or the loss of reality failing to notice that JPG is already compressed Very Happy


It doesn't affect quality at all. Yes, JPG is already compressed, but not necessarily optimally. (My digital camera only outputs to .JPG, and the compression level varies.)

DOS386 wrote:

It's too slow. And, "good" isn't a synonym of "very maximal compression at any cost"


Good things come to those who wait. Patience is a virtue. Face it, ZIP is plenty fast enough, but if you want extreme compression, you have to accept a slowdown. PAQ isn't meant to be mainstream, just experimental.

DOS386 wrote:

> I've timed it, the DJGPP version is no slower, at least for me.

Funny, in my tests MinGW was faster. Confused


Faster than OpenWatcom, yes. DJGPP? No. But its speed may also depend on Windows version too (or your processor or compiler flags, etc).

DOS386 wrote:

> license and speed are really the "only" reasons for bothering. "LZMA SDK version 4.43"

But then you should update to LZMA 4.65 ASAP Smile


They didn't test with anything besides 4.43 mainly (and a little with 4.49). I'm not even sure later versions are a drop-in replacement. Anyways, I found 4.49 slower and even worse compression in my limited testing, so I didn't check too much further, just played it safe with 4.43 ("good enough"). Feel free to recompile if you want, but it may or may not improve as much as you think.
Post 12 Mar 2009, 01:58
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:

Very same for both versions (just count the lines Wink) Isn't it a bit silly ? And what are the file attributes of --best ? Laughing


Sounds like you're saying the speed isn't any different, which isn't true. Of course, I only have limited machines to test, but my 586 build is 12% faster or so on the 586 than the others (I know, big surprise, but sometimes it's not as obvious).

DOS386 wrote:

Quote:

Directory of c:\Armslurp\temp\moo
287,371 test.paq8o8z
325,926 test.paq8f
410,728 ppmd.7z
410,807 bzip2.7z
412,318 deflate64.zip
412,327 deflate.zip
414,838 lzma.7z
415,978 IMAG0492.JPG


So you tested and got it smaller 1.4475 times ?


Yes. But this is a very-lightly compressed .JPG (high quality) I think, so results may vary. Still, nice improvement, no? Wink
Post 12 Mar 2009, 02:04
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
It doesn't affect quality at all.


Who ? PAQ maybe NOT, but JPG itself DOES.

Quote:
Yes, JPG is already compressed, but not necessarily optimally


Indeed.

Quote:
Good things come to those who wait. Patience is a virtue.


Right. Then just wait for my FS and OS kernel (+ video editor+player, audio editor+player, imaging program, FASM fork with no Unreal and no DPMI, 8086 compatible PNG+APNG viewer, FreeBASIC fork desaffiliated from DGJPP, ... ... ... ) Smile

> Faster than OpenWatcom, yes. DJGPP? No.

Maybe DGJPP is even faster than FASM ??? Laughing

> found 4.49 slower and even worse compression in my limited testing

Maybe true, the improvement arrived in 4.58 Smile

The biggest mystery however is why you added packages\upx-ucl\depends.txt (all names carefully lowercased Laughing ) containing just 9 Bytes of "text" ("cwsdpmi" +$0D+$0A) able to hog up to 192 KiB of space (thanks to clustering "technology" Laughing ) Also your version whines about "No DPMI", the official one doesn't ... why not just use D3X Idea ? Only 10 KiB, negligible size compared to your "solution" Laughing

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 12 Mar 2009, 02:09
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:
rugxulo wrote:
It doesn't affect quality at all.


Who ? PAQ maybe NOT, but JPG itself DOES.


I know.

DOS386 wrote:

The biggest mystery however is why you added packages\upx-ucl\depends.txt (all names carefully lowercased Laughing ) containing just 9 Bytes of "text" ("cwsdpmi" +$0D+$0A) able to hog up to 192 KiB of space (thanks to clustering "technology" Laughing ) Also your version whines about "No DPMI", the official one doesn't ... why not just use D3X Idea ? Only 10 KiB, negligible size compared to your "solution" Laughing


I tried to mimic the preferred style of .ZIP used by FreeDOS (even if it's a little odd) for their convenience. I guess DEPENDS.TXT is used by FDPKG?? At least, Blair's old package of UPXX.ZIP used a similar scheme. Obviously, I could've added CWSDPMI, but I'm pretty sure most people already have it (or similar). Besides, adding CWSDPMI to a billion separate packages defeats the point of compression (saving space!). Wink
Post 12 Mar 2009, 23:11
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
Sounds like you're saying the speed isn't any different, which isn't true.


NO. All my complaints referred to garbage I/O, that is exactly the same, not speed (I haven't measured the speed yet, sorry).

Quote:
very-lightly compressed .JPG (high quality) I think, so results may vary. Still, nice improvement, no?


We need a new image format replacing JPG. Idea

Quote:
I tried to mimic the preferred style of .ZIP used by FreeDOS (even if it's a little odd) for their convenience.


Indeed Neutral

Quote:
could've added CWSDPMI, but I'm pretty sure most people already have it (or similar).


Quote:
The limitation appears with or without the use of executable compression, and with or without the use of the DJGPP DPMI servers CWSDPMI (Charles W. Sandmann), CWSDPR0, CWSDSTUB, and PMODE/DJ (which are apparently ignored in any case, in favor of the native Windows DPMI server).


As our friend T.R.N. found out, it is not needed at all Laughing

Quote:
Besides, adding CWSDPMI to a billion separate packages defeats the point of compression (saving space!)


WDOSX or D3X are ways better, and don't hurt solid compression (but FDPKG isn't Sad )

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 13 Mar 2009, 01:06
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:

Quote:
Besides, adding CWSDPMI to a billion separate packages defeats the point of compression (saving space!)


WDOSX or D3X are ways better, and don't hurt solid compression (but FDPKG isn't Sad )


I'll admit CWSDPMI is bigger in size than those, not 100% written in assembly, and supports no MS "true DPMI" extensions nor 16-bit apps, but it's pretty fast anyways, can run in as little as 512k of RAM, supports ring 3 (safer) and seems extremely well tested, doesn't force binding to .EXE, and probably has the best license of any DPMI host.

While I also like WDOSX, it does have a very few annoying lacks / bugs (even beyond those mentioned). I honestly haven't tested D3X as much (which is more limited than either of the above) but haven't seen any major problems there. At least the latter uses NASM. Wink
Post 13 Mar 2009, 09:34
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
admit CWSDPMI is bigger in size than those, not 100% written in assembly


bad Sad

Quote:
and supports no MS "true DPMI" extensions nor 16-bit apps


Same as WDOSX and D3X ...

Quote:
pretty fast anyways


Maybe, as long as it doesn't swap Laughing

Quote:
can run in as little as 512k of RAM


and 512 MiB at most Sad

Quote:
supports ring 3 (safer)


Useful for debugging only ...

Quote:
and seems extremely well tested


inside NTVDM, see above Very Happy

Quote:
doesn't force binding to .EXE


Indeed ...

Quote:
and probably has the best license of any DPMI host.


The very worst one Sad oops no, DOG4/SW (closed) is worst, then CWSDPMI (GPL), all others are BSD or similar Idea
Post 15 Mar 2009, 02:58
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:

Quote:
and [CWSDPMI] supports no MS "true DPMI" extensions nor 16-bit apps


Same as WDOSX and D3X ...


But at least WDOSX support some extended int 21h functions.

DOS386 wrote:

Quote:
can run in as little as 512k of RAM


and 512 MiB at most Sad


r5 can handle 2 GB if you let it swap (even to RAM disk) for page tables. But true, without swapping somewhere, it runs out of low RAM to use for page tables, so 512 MB is max in that case. (I would like to find someone who has actually confirmed HDPMI32 works with > 2 GB of RAM.)

DOS386 wrote:

Quote:
supports ring 3 (safer)


Useful for debugging only ...


Not really. It just works better that way, you can't accidentally crash the system nearly as easily.

DOS386 wrote:

Quote:
doesn't force binding to .EXE


Indeed ...


Well, it works better than PMODE/DJ, that's for sure! (Don't try it with FASMD.)

DOS386 wrote:

Quote:
and probably has the best license of any DPMI host.


The very worst one Sad oops no, DOG4/SW (closed) is worst, then CWSDPMI (GPL), all others are BSD or similar Idea


I think WDOSX and D3X have pretty confusing / non-standard licenses (although I also halfway think WDOSX is either LGPL-complaint or he forgot to update the text ... alas).

GPL is darn good in this case (although CWS' license technically is a bit looser). Actually, I forgot about Causeway (public domain), but I consider that more of an extender since it only(?) works with pure assembly and Watcom LE format.

Actually, what license is HDPMI anyways, "freeware" w/ srcs??? DOS/32A has a pretty reasonable license too, IIRC, but again is less universal and more tied to Watcom.

I need to try (again) to grab MWDPMI from DJGPP's CVS and compile it to test a bit. (Wonder what license it is ... probably GPL.)

P.S. Remember how I mentioned Swallow on BTTR? Laughing Doesn't seem to work on any setup I tried so far. Maybe (maybe) I could recompile some app to work with it, but I'm extremely skeptical at this point.
Post 15 Mar 2009, 05:09
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> But at least WDOSX support some extended int 21h functions.

WATCOM stub only.

> r5 can handle 2 GB if you let it swap (even to RAM disk) for page tables.

I prefer no horrible hacks.

> like to find someone who has actually confirmed HDPMI32 works with > 2 GB of RAM.

Me too ... but we won't get full 4 GiB since HDPMI32 doesn't support PAE hack and we loose some (cca 1 GiB ?) RAM inside the 32-bit physical addressing space because of PCI memory mapped I/O (most notably screen).

> > > supports ring 3 (safer)
> > useful for debugging only ...
> Not really. It just works better that way, you can't accidentally crash the system nearly as easily.

If your release-quality stuff is still buggy Laughing

> I think WDOSX and D3X have pretty confusing / non-standard licenses

BSD-like

> GPL is darn good in this case (although CWS' license technically is a bit looser).

GPL is the most restrictive open source license Laughing PAQ is good GPL is darn good Ring3 is better Laughing

> forgot about Causeway (public domain)

this is the most free one Laughing

> but I consider that more of an extender since it only(?) works with pure assembly and Watcom LE format.

Probably true.

> Actually, what license is HDPMI anyways, "freeware" w/ srcs???

YES.

> DOS/32A has a pretty reasonable license too
> IIRC, but again is less universal

NO. More universal.

> and more tied to Watcom.

Technically YES (but see LE
Laughing), by license NO.

> Remember how I mentioned Swallow on BTTR?

YES. 16-bit extender requiring 80386 ... inherently useless Sad

> Doesn't seem to work on any setup I tried so far.

The time has come to drop it and move on Wink
Post 22 Mar 2009, 01:26
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.