DOS ain't dead

Rugxulo Usono, 25.10.2007, 06:58	GCC 4.2.2 for DJGPP released (Announce) Post reply
	Andris Pavenis has released a DOS compile of GCC (and GPP, GFOR, OBJC, GNAT/ADA) 4.2.2 for DJGPP on 23 October 2007. Website (download): http://short.stop.home.att.net/dl/djgpp.htm Announcement: (news://comp.os.msdos.djgpp via Google Groups) Changes: http://gcc.gnu.org/gcc-4.2/changes.html

RayeR

CZ,
25.10.2007, 10:54

@ Rugxulo

GCC 4.2.2 for DJGPP released

Post reply

Yeah I'm going to test. I would like to know if -masm=intel will work on my sources I tried unsuccessfully before on 4.1.2

---
DOS gives me freedom to unlimited HW access.

RayeR

CZ,
26.10.2007, 02:28

@ RayeR

GCC 4.2.2 for DJGPP released

Post reply

> Yeah I'm going to test. I would like to know if -masm=intel will work on my
> sources I tried unsuccesfully before on 4.1.2

Hm, bug is still present

gdtdump.c: In function 'main': gdtdump.c:283: internal compiler error: in print_operand, at config/i386/i386.c: 7961 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.

---
DOS gives me freedom to unlimited HW access.

Berlin, Germany,
26.10.2007, 11:19

@ RayeR

GCC 4.2.2 for DJGPP released

Post reply

> Hm, bug is still present

If you hand out your source code, some might be able to reproduce your problem.

---
Forum admin

RayeR

CZ,
27.10.2007, 01:54

@ rr

GCC 4.2.2 for DJGPP released

Post reply

> > Hm, bug is still present
>
> If you hand out your source code, some might be able to reproduce your
> problem.

OK, I cut the code as possible, try to compile this: gcc -S x.c -masm=intel

#include <stdlib.h> #include <stdio.h> typedef struct { unsigned long offset; // 32-bit offset unsigned short selector; // 16-bit selector } __attribute__((packed)) PM_FAR_POINTER; int exec_ring0_code(unsigned long code_address, unsigned long ecx, unsigned long *eax, unsigned long *edx) { PM_FAR_POINTER callgate_ptr; asm __volatile__ ( "lcall *%5\n" : "=a"(*eax), "=d"(*edx) : "a"(*eax), "c"(ecx), "d"(*edx), "m" (callgate_ptr) : "memory" ); return(0); }

result is:

x.c: In function 'exec_ring0_code': x.c:19: internal compiler error: in print_operand, at config/i386/i386.c:7961 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Assemler output x.S stops at line
lcall *

when I compile with gcc -S x.c only it compile all without error
and mentioned line looks this:
lcall *-6(%ebp)

---
DOS gives me freedom to unlimited HW access.

RayeR

CZ,
27.10.2007, 03:07

@ RayeR

GCC 4.2.2 for DJGPP released

Post reply

Ou,
I was noticed that this bug is currently fixed in GCC 4.3.0 so I'll have to wait for new DJGPP GCC port...

---
DOS gives me freedom to unlimited HW access.

Rugxulo Usono, 27.10.2007, 14:26 @ RayeR	GCC 4.2.2 for DJGPP released Post reply
	> Ou, > I was noticed that this bug is currently fixed in GCC 4.3.0 so I'll have > to wait for new DJGPP GCC port... I also verified this with my local copy of DJGPP (all 2.04-compiled, Binutils 2.17, GCC 4.2.2). And BTW, it doesn't have any problems if you omit -masm=intel, so just forget that option for now.

RayeR

CZ,
28.10.2007, 23:17

@ Rugxulo

GCC 4.2.2 for DJGPP released

Post reply

> I also verified this with my local copy of DJGPP (all 2.04-compiled,
> Binutils 2.17, GCC 4.2.2). And BTW, it doesn't have any problems if you
> omit -masm=intel, so just forget that option for now. ;-)

Yes AT&T output work, but for me is more readable classic syntax. Someone other at bugzilla explained that gcc has problem with pointer type for structure for mams syntax.

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
30.10.2007, 05:42

@ RayeR

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

Post reply

> > I also verified this with my local copy of DJGPP (all 2.04-compiled,
> > Binutils 2.17, GCC 4.2.2). And BTW, it doesn't have any problems if you
> > omit -masm=intel, so just forget that option for now. ;-)
>
> Yes AT&T output work, but for me is more readable classic syntax. Someone
> other at bugzilla explained that gcc has problem with pointer type for
> structure for masm syntax.

You could always use Yasm -p gas -f coff if you need to assemble the GAS output. It may not work without a little tweaking, though, but much better than nothing.

BTW, is it just me or is GCC / DJGPP much slower now? I tested 2.95, 3.44, and latest 4.2.2 etc, but despite the claims that 4.x.x is 30% faster for C++, I find that's not necessarily true. (Also, my AMD64 seems to run 3.4.4 slower, e.g. compiling TDE, than my P4 but 4.2.2 is faster on the AMD64, go figure.) Just curious about your experience if you ever decide to test it. ;-)

I wonder if it's just because it's configured to support so many non-C languages or just natural evolution (entropy) or what. I halfway want to build my own tweaked GCC/DJGPP, but that's probably a pain I should avoid (for now). :-P

RayeR

CZ,
30.10.2007, 13:09

@ Rugxulo

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

Post reply

> BTW, is it just me or is GCC / DJGPP much slower now? I tested 2.95, 3.44,
> and latest 4.2.2 etc, but despite the claims that 4.x.x is 30% faster for

Do you mean compile time, not compile code speed?
I don't feel any significant speed changes on my machine. Can you give simple example which I can reproduce in my djgpp? I have some packed DJGPP archives since I started with version 2.7.2 (huh, very old) so I can compare it against newer (sorely have 2.95.x, 3.3.x). Compiling speed may be affected be many thinks, from cpu speed, memory amount to filesystem speed, fragmentation, caching, DOS file i/o performance...

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
31.10.2007, 00:26

@ RayeR

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

Post reply

> Do you mean compile time, not compile code speed?

Yes.

> I don't feel any significant speed changes on my machine. Can you give
> simple example which I can reproduce in my djgpp? I have some packed DJGPP
> archives since I started with version 2.7.2 (huh, very old) so I can
> compare it against newer (sorely have 2.95.x, 3.3.x). Compiling speed may
> be affected be many thinks, from cpu speed, memory amount to filesystem
> speed, fragmentation, caching, DOS file i/o performance...

Well, grab my small setup of 2.95.3 (unpacks to 6 MB, not huge) and try compiling TDE using Eric's tiny runtime timer tool. Then please tell me your experience. I've tested three PCs, but the older GCC the faster it compiles. (And yes, I know -O2 is going to be slower than -O1 or obviously -O0.)

A normal "runtime make" of TDE 5.1v on my P166 (DJGPP 2.03p2, GCC 3.4.4) takes 4 mins on DR-DOS 7.03 using JEMMEX (but 30secs more if using the default DR-EMM386 or even DR-HIMEM, strangely). This is using the default makefile without any changes.

On this AMD Athlon64x2 1.7 Ghz, using GCC 4.2.2 (DJGPP 2.04 beta) and Make 3.80 (2.04 compile), it takes 1 min. 4 secs. And that's a fair amount slower than either 3.4.4 (37 secs) or 2.95.3 (13 secs), both using DJGPP 2.03p2. Obviously, some optimizations in GCC have been improved as well as it's support for extra languages too. I'm just saying, it ain't that super duper fast. ;-)

EDIT: I forgot, 2.95.3 needs "-mcpu" instead of "-mtune" in the makefile. But everything else is the same.

Rugxulo

Usono,
31.10.2007, 09:31

@ Rugxulo

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

Post reply

> A normal "runtime make" of TDE 5.1v on my P166 (DJGPP 2.03p2, GCC 3.4.4)
> takes 4 mins on DR-DOS 7.03 using JEMMEX (but 30secs more if using the
> default DR-EMM386 or even DR-HIMEM, strangely). This is using the default
> makefile without any changes.

I decided to defragment my P166, but I think I made it worse (6 mins!), so I'm using a tweaked defragment setting (full w/ file reorder). That's going to take a while, though, but I need to test again as soon as it's finished.

> On this AMD Athlon64x2 1.7 Ghz, using GCC 4.2.2 (DJGPP 2.04 beta) and Make
> 3.80 (2.04 compile), it takes 1 min. 4 secs. And that's a fair amount
> slower than either 3.4.4 (37 secs) or 2.95.3 (13 secs), both using DJGPP
> 2.03p2. Obviously, some optimizations in GCC have been improved as well as
> it's support for extra languages too. I'm just saying, it ain't that super
> duper fast. ;-)
>
> EDIT: I forgot, 2.95.3 needs "-mcpu" instead of "-mtune" in the makefile.
> But everything else is the same.

Okay, I think I solved part of the issue, and it's not that big a shock (but still surprising): UPX. I tested it on my aunts' P4, and that's what clued me off. Unpack the .EXEs and try again: upx -d /djgpp/.../*.exe. After this, my AMD64x2 (using GCC 4.2.2) only took 49 secs to compile TDE 5.1v. See, they only started packing everything fairly recently (after the UPX 1.25 djgpp/coff bug was fixed).

Just FYI in case anyone needs to compile anything huge with DJGPP or whatever: unpack the .EXEs first, it's faster that way.

lucho

31.10.2007, 10:08

@ Rugxulo

UPX

Post reply

> Okay, I think I solved part of the issue, and it's not that big a shock
> (but still surprising): UPX. I tested it on my aunts' P4, and that's what
> clued me off. Unpack the .EXEs and try again: upx -d
> /djgpp/.../*.exe. After this, my AMD64x2 (using GCC 4.2.2) only took
> 49 secs to compile TDE 5.1v. See, they only started packing everything
> fairly recently (after the UPX 1.25 djgpp/coff bug was fixed).

As fas as I know, the UPX default NRV algorithm has a very fast unpacking, so the delay it causes should be unnoticeable even on slow machines. The new LZMA method unpacks very slowly though. Perhaps the executables are packed with it?

RayeR

CZ,
31.10.2007, 12:15

@ lucho

UPX

Post reply

> As fas as I know, the UPX default NRV algorithm has a very fast unpacking,
> so the delay it causes should be unnoticeable even on slow machines. The
> new LZMA method unpacks very slowly though. Perhaps the executables are
> packed with it?

Yeah, UPX came in my mind too. I'm big fan of UPX and UPXed everything that was possible (also 1/2 of windows, etc.). On faster system (say some PII/PIII) I belive it's faster to load e.g. 1/3 of original exe file size and decompress it fast insteal loading big exe from relative slow HDD. As Lucho wrote NRV should decompress very fast and if it was not changed in last UPX the default algo is NRV (you need special option to enable LZMA). But I don't know how GCC 4.2.2 package was compressed. Is possible to alalyze compressed exe soume way to tell what compress was used? If it was LZMA the solution is repack it with NRV.
I'll try some bench later at evening.

---
DOS gives me freedom to unlimited HW access.

Berlin, Germany,
31.10.2007, 17:12

@ RayeR

UPX

Post reply

> But I don't know how GCC 4.2.2 package was compressed. Is possible to
> alalyze compressed exe soume way to tell what compress was used? If it was
> LZMA the solution is repack it with NRV.

I found this now:
upx --file-info gcc.exe

which produces:
gcc.exe [i386-dos32.djgpp2.coff, djgpp2/coff] 110636 bytes, compressed by UPX 14, method 14, level 10, filter 0x49/0x0a

available compression methods in "upx-3.01-src.tar\upx-3.01-src\src\conf.h" are:
#define M_NRV2B_LE32 2 #define M_NRV2B_8 3 #define M_NRV2B_LE16 4 #define M_NRV2D_LE32 5 #define M_NRV2D_8 6 #define M_NRV2D_LE16 7 #define M_NRV2E_LE32 8 #define M_NRV2E_8 9 #define M_NRV2E_LE16 10 //#define M_CL1B_LE32 11 //#define M_CL1B_8 12 //#define M_CL1B_LE16 13 #define M_LZMA 14 #define M_DEFLATE 15 /* zlib */

This underpins Lucho's message.

---
Forum admin

RayeR

CZ,
01.11.2007, 02:27

@ RayeR

UPX - gcc - benchmark

Post reply

> I'll try some bench later at evening.

Here's my benchmark. I used latest libjpeg 0.6 sources for testing. And I'm very surprised how does it so different even on such fast CPU as C2D is! Thanks to Rugxulo for starting this and others to discover whats going on.
Numbers says it clear (make all):
LZMA: 41s
NRV (--best): 21s
uncompressed: 19s

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
01.11.2007, 02:47

@ RayeR

UPX - gcc - benchmark

Post reply

> Here's my benchmark. I used latest libjpeg 0.6 sources for testing. And
> I'm very surprised how does it so different even on such fast CPU as C2D
> is! Thanks to Rugxulo for starting this and others to discover whats going
> on.
> Numbers says it clear (make all):
> LZMA: 41s
> NRV (--best): 21s
> uncompressed: 19s

As you said, there are many factors that weigh in to all this. I retested my P166, and it seems that on FAT16, it's much slower (at least twice as much!) when unpacked completely. All of my DJGPP 3.4.4 development .EXEs had been packed with various UPX versions (1.25, 2.93, 3.01), but recompressing with --best (3.01) shaved 15 secs. off the compile time for TDE (5:45 now for default makefile w/o modifications on a P166, 32 MB total, 7 MB RAM drive, UIDE 5 MB cache, DR-DOS 7.03, 600+ MB FAT16, DJDEV203 + GCC344 + BNU2161 + MAK3791). So, it does indeed take a lot more time to load from FAT when unpacked.

FYI, LZMA was warned as being slow on "old" machines. You won't notice it on anything recent, but 3.01 "upx -V" (original packed .EXE) takes about 11 secs. on my 486 Sx/25. Since that's annoying, I unpacked it and repacked with -7, and it's much faster (only 3 secs). But on my P166 it's pretty unnoticeable. I think such a huge delay is only for really big .EXEs (e.g. > 1 MB unpacked) since I never noticed on other smaller but more typical .EXEs. I usually prefer size over speed anyways except in rare cases. And I use UPX a lot!!

RayeR

CZ,
01.11.2007, 11:10

@ Rugxulo

UPX - gcc - benchmark

Post reply

I found that NRV/LZMA compression doesn't differ so much, eg. on CC1.EXE the NRV is ~2,5MB and LZMA ~2,3MB (uncompressed ~6MB) but speed difference is much greater. As you proved loading big files on FAT I think best choice is to recompres all to NRV (I did).

---
DOS gives me freedom to unlimited HW access.

Rugxulo Usono, 03.11.2007, 03:32 @ RayeR	UPX - gcc - benchmark -- LZMA can save a lot (sometimes) Post reply
	> I found that NRV/LZMA compression doesn't differ so much, eg. on CC1.EXE > the NRV is ~2,5MB and LZMA ~2,3MB (uncompressed ~6MB) but speed difference > is much greater. As you proved loading big files on FAT I think best choice > is to recompres all to NRV (I did). Sometimes the savings are indeed impressive, though. See here.

RayeR

CZ,
03.11.2007, 11:25

@ Rugxulo

UPX - gcc - benchmark -- LZMA can save a lot (sometimes)

Post reply

> Sometimes the savings are indeed impressive, though. See
> here.

OK, it's quite good. But simply everybody should take in mind if the programm may be called many times in a batch and decide if some saved kB are not worse than slower speed as in case of gcc.

---
DOS gives me freedom to unlimited HW access.

Berlin, Germany,
31.10.2007, 13:11

@ lucho

UPX

Post reply

> As fas as I know, the UPX default NRV algorithm has a very fast unpacking,
> so the delay it causes should be unnoticeable even on slow machines. The
> new LZMA method unpacks very slowly though. Perhaps the executables are
> packed with it?

Andris used "upx --brute". (see gcc422s2.zip\diffs\install.gcc\makepkg.pl) So no LZMA.

---
Forum admin

lucho

31.10.2007, 15:40

@ rr

UPX

Post reply

> > As fas as I know, the UPX default NRV algorithm has a very fast unpacking,
> > so the delay it causes should be unnoticeable even on slow machines. The
> > new LZMA method unpacks very slowly though. Perhaps the executables are
> > packed with it?
>
> Andris used "upx --brute". (see gcc422s2.zip\diffs\install.gcc\makepkg.pl) So no LZMA.

Wrong. I just tested how UPX 3.0 compresses COFF executables with --brute. The result is the same as if I added --lzma explicitly. That is, it assumes --lzma not only with --ulra-brute, but also with --brute. If you use --best instead of --brute, it uses NRV and the executable is larger but then unpacks much faster. For 16-bit executables, --brute and --ultra-brute don't assume --lzma (you must specify it explicitly if you want it), but for 32-bit executables, they do.

So, it's better to replace --brute with --best to avoid LZMA. Adding --nrv2e (default is --nrv2d as far as I know) may reduce file size slightly, but it's still NRV, not LZMA.

You may want to let Andris know this.

Berlin, Germany,
31.10.2007, 15:48

@ lucho

UPX

Post reply

> > Andris used "upx --brute". (see
> gcc422s2.zip\diffs\install.gcc\makepkg.pl) So no LZMA.
>
> Wrong. I just tested how UPX 3.0 compresses COFF executables with --brute.

But only my second part was wrong. ;-)

> The result is the same as if I added --lzma explicitly. That is, it assumes
> --lzma not only with --ulra-brute, but also with --brute. If you use --best

I also noticed that some months ago, but assumed that I just chose a "wrong" target file for my tests. ;-)

> unpacks much faster. For 16-bit executables, --brute and --ultra-brute
> don't assume --lzma (you must specify it explicitly if you want it), but
> for 32-bit executables, they do.

Ah! Thanks for clearing up! :-)

> You may want to let Andris know this.

I'll post a link to this thread to the DJGPP Usenet newsgroup.

---
Forum admin

lucho 31.10.2007, 16:51 @ rr	UPX Post reply
	> But only my second part was wrong. Yes. As the Wethern's Law says, "assumption is the mother of all screwups" > Ah! Thanks for clearing up! You're welcome!

RayeR

CZ,
31.10.2007, 17:47

@ lucho

UPX

Post reply

> Wrong. I just tested how UPX 3.0 compresses COFF executables with --brute.
> The result is the same as if I added --lzma explicitly. That is, it assumes
> --lzma not only with --ulra-brute, but also with --brute. If you use --best
> instead of --brute, it uses NRV and the executable is larger but then
> unpacks much faster.

Thanks for clarification. I use batchfile calling UPX allways with --best. Anyway is possible to detect LZMA from (unknown) EXE?

---
DOS gives me freedom to unlimited HW access.

lucho 31.10.2007, 18:43 @ RayeR	UPX Post reply
	> Thanks for clarification. I use batchfile calling UPX always with --best. > Anyway is possible to detect LZMA from (unknown) EXE? Use the switch that Robert discovered: --file-info; if it says "method 14", it's LZMA.

RayeR

CZ,
01.11.2007, 02:07

@ lucho

UPX

Post reply

> Use the switch that Robert discovered: --file-info; if it says "method
> 14", it's LZMA.

It doesn't work good for me. I uncompressed my GCC (really was LZMA) and recompressed it by --best option but --file-info reports still compression 14. But files are significantly greater so it's NRV. And for older compressed files it doesn't report nothing, probably a new feature.

---
DOS gives me freedom to unlimited HW access.

Berlin, Germany,
01.11.2007, 11:04

@ RayeR

UPX

Post reply

> It doesn't work good for me. I uncompressed my GCC (really was LZMA) and
> recompressed it by --best option but --file-info reports still compression
> 14.

Maybe you have looked at the wrong place? ;-)

C:TMP>upx --file-info gcc.exe Ultimate Packer for eXecutables Copyright (C) 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007 UPX 3.01w Markus Oberhumer, Laszlo Molnar & John Reiser Jul 31st 2007 gcc.exe [i386-dos32.djgpp2.coff, djgpp2/coff] 119120 bytes, compressed by UPX 14, method 2, level 10, filter 0x26/0x0a

Method 2 is "NRV2B_LE32".

---
Forum admin

Rugxulo

Usono,
01.11.2007, 03:33

@ RayeR

UPX

Post reply

> Thanks for clarification. I use batchfile calling UPX allways with --best.
> Anyway is possible to detect LZMA from (unknown) EXE?

AFAIK, only 2.93 and later had LZMA support. So, if you know what UPX version, anything less than that won't have it. BTW, LZMA does indeed improve compression a good amount for DJGPP's .EXEs.

Anyways, just FYI, I wrote a wimpy semi-useless tool that tells you if a DJGPP .EXE is UPX'd and what version did it. It's not that good, though, since it just looks at the exact same offset in the file (but it seems to consistently work!). It also returns an errorlevel. Don't expect anything fancy, you might even laugh how simple it is! ;-)

Download: djupx.zip

RayeR

CZ,
01.11.2007, 10:49

@ Rugxulo

UPX

Post reply

> Download: djupx.zip

The requested URL /forum/www.geocities.com/snoopimeanie/djupx.zip was not found on this server.

Could you tell me the offset and format of the version? I'l like to add it in my EXEINFO tool. http://www.volny.cz/rayer/programm/programe.htm#EXEINFO

---
DOS gives me freedom to unlimited HW access.

Berlin, Germany,
01.11.2007, 10:58

@ RayeR

UPX

Post reply

> > Download:
> djupx.zip
>
> The requested URL /forum/www.geocities.com/snoopimeanie/djupx.zip was not
> found on this server.

Fixed. Rugxulo forgot "http://".

---
Forum admin

RayeR

CZ,
01.11.2007, 22:18

@ rr

UPX - version detect

Post reply

As I found detecting UPX signature at fixed offset from beginning of exe is not very reliable I have some files in DJGPP with diff. stub size and even relative to COFF image begin it may be at various places. So I decided that would be better to search signature in range coff_start..coff_start+N where N=4096 seems to be reasonable number. Here's my updated EXEINFO 1.1:
http://www.volny.cz/rayer/programm/programe.htm#EXEINFO

---
DOS gives me freedom to unlimited HW access.

Andris

31.10.2007, 19:30

@ lucho

UPX

Post reply

> > Okay, I think I solved part of the issue, and it's not that big a shock
> > (but still surprising): UPX. I tested it on my aunts' P4, and that's
> what
> > clued me off. Unpack the .EXEs and try again: upx -d
> > /djgpp/.../*.exe. After this, my AMD64x2 (using GCC 4.2.2) only
> took
> > 49 secs to compile TDE 5.1v. See, they only started packing everything
> > fairly recently (after the UPX 1.25 djgpp/coff bug was fixed).
>
> As fas as I know, the UPX default NRV algorithm has a very fast unpacking,
> so the delay it causes should be unnoticeable even on slow machines. The
> new LZMA method unpacks very slowly though. Perhaps the executables are
> packed with it?

I did not look in very much details when build it. I used 'upx --brute ...',
as one can see from file gnu/install.gcc/makepkg.pl in gcc422s.zip.

Rugxulo

Usono,
01.11.2007, 03:27

@ Rugxulo

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

Post reply

> I decided to defragment my P166, but I think I made it worse (6 mins!), so
> I'm using a tweaked defragment setting (full w/ file reorder). That's going
> to take a while, though, but I need to test again as soon as it's
> finished.

No difference. I must be thinking of -Os or something, I dunno. So I guess 6 mins. is normal for a P166 *shrug*.

> Just FYI in case anyone needs to compile anything huge with DJGPP or
> whatever: unpack the .EXEs first, it's faster that way.

Okay, I think NTFS 3.0 (e.g. XP or Vista) or maybe the NTVDM might be slower for LZMA-packed DJGPP .EXEs, but for pure FAT, UPX helps a lot in load time (at least in my wimpy test).

P.S. Anybody know how to clear the cache in Windows?

GCC 4.2.2 for DJGPP released (Announce)

GCC 4.2.2 for DJGPP released

GCC 4.2.2 for DJGPP released

GCC 4.2.2 for DJGPP released

GCC 4.2.2 for DJGPP released

GCC 4.2.2 for DJGPP released

GCC 4.2.2 for DJGPP released

GCC 4.2.2 for DJGPP released

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

GCC/DJGPP --masm=intel (plus YASM, GCC speed)

UPX

UPX

UPX

UPX - gcc - benchmark

UPX - gcc - benchmark

UPX - gcc - benchmark

UPX - gcc - benchmark -- LZMA can save a lot (sometimes)

UPX - gcc - benchmark -- LZMA can save a lot (sometimes)

UPX

UPX

UPX

UPX

UPX

UPX

UPX

UPX

UPX

UPX

UPX

UPX - version detect

UPX

GCC/DJGPP --masm=intel (plus YASM, GCC speed)