DOS ain't dead - p7zip 4.65 for FreeDOS

Rugxulo

Usono,
16.04.2009, 17:48

p7zip 4.65 for FreeDOS (Announce)

I recently compiled p7zip 4.65 packaged in FreeDOS-specific format with FD-related patch. The original p7zip 4.65 was released on February 14, 2009 by myspace on SourceForge.

Website: http://sourceforge.net/projects/p7zip
Website#2: http://sourceforge.net/projects/sevenzip

Download: http://rugxulo.googlepages.com/7zip465x.zip (1.6 MB)
http://rugxulo.googlepages.com/7zip465s.zip (5.6 MB)

Changes: http://sourceforge.net/project/shownotes.php?group_id=111810&release_id=661066

Berlin, Germany,
16.04.2009, 21:54

@ Rugxulo

p7zip 4.65 for FreeDOS

Post reply

> Download: http://rugxulo.googlepages.com/7zip465x.zip (1.6 MB)
> http://rugxulo.googlepages.com/7zip465s.zip (5.6 MB)

Why did you name the files 7zip...? The project is still called p7zip.

---
Forum admin

Rugxulo

Usono,
16.04.2009, 22:10

@ rr

p7zip 4.65 for FreeDOS

Post reply

> > Download: http://rugxulo.googlepages.com/7zip465x.zip (1.6 MB)
> > http://rugxulo.googlepages.com/7zip465s.zip (5.6 MB)
>
> Why did you name the files 7zip...? The project is still called
> p7zip.

The current file (4.55) that is available on the FDUPDATE site is in 7ZIP.ZIP. And the ones from official FreeDOS 1.0 are 7ZIPX.ZIP and 7ZIPS.ZIP. So to make it clear that it's not the same one as those (and can easily be renamed), I chose 7ZIP465X.ZIP and 7ZIP465X.ZIP. No, I didn't call it p7zip because that wouldn't fit in 8.3. Besides, technically speaking, it shouldn't confuse anybody who knows that this is the DOS/DJGPP compile of the POSIX port (since HX uses the Win32 one).

P.S. p7zip actually compiles to "7za" or "7zr" or "7z", not "p7zip" etc. And yet I did rename the binary files "p7zip.exe", "p7zipr.exe" for clarity.

DOS386

22.05.2009, 08:12
(edited by DOS386, 23.05.2009, 02:23)

@ Rugxulo

p7zip 4.65 for FreeDOS | Ibiblio has 4.61 only

Post reply

> I recently compiled p7zip 4.65 packaged in FreeDOS

:-)

Ibiblio NOT updated:

http://freedos.sourceforge.net/cgi-bin/lsm.cgi?mode=lsm&lsm=util/7zip.lsm (says 4.65)

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/ (has 4.61)

Or get my all-in-one package:

http://freefile.kristopherw.us/uploads/temp/ip7v4d65.zi7 (9.8 MiB)

It seems to work, even progress indicator for compression :-) OTOH it seems noticably slower that Win32 version via HX, "Extracting BLAH.TAR" appears 1 second before decompression is done instead of 1 second after start :confused: , and the NTLFN-BUG with archive update is of course implemented as well :-(

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
23.05.2009, 02:26

@ DOS386

p7zip 4.65 for FreeDOS | Ibiblio has 4.61 only

Post reply

> Ibiblio NOT updated:
>
> http://freedos.sourceforge.net/cgi-bin/lsm.cgi?mode=lsm&lsm=util/7zip.lsm
> (says 4.65)
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zip/
> (has 4.61)

There aren't a lot of FreeDOS admins anymore, so while I did e-mail them, I didn't press too hard when they didn't update it. Maybe I should be more assertive, but I didn't think it was so crucial (esp. since it's not BASE but UTIL). I guess none of them uses it very much (or at least not enough to need 4.65 instead of 4.61).

> It seems to work, even progress indicator for compression :-) OTOH it
> seems noticably slower that Win32 version via HX, "Extracting BLAH.TAR"
> appears 1 second before decompression is done instead of 1 second after
> start :confused:

I can only guess because of WATT-32 + GNU pth slowing it down (although admittedly MSVC might be better than GCC these days, too).

> and the NTLFN-BUG with archive update is of course
> implemented as well :-(

Yes, I know (sadly), not sure if I have time to even weakly fix it.

DOS386

23.05.2009, 02:40

@ Rugxulo

p7zip 4.65 for FreeDOS | Ibiblio has 4.61 only

Post reply

> There aren't a lot of FreeDOS admins anymore, so while I did e-mail them

Among others SF still says "Kernel - 2036test Last Update: May 21 2006" :-(

> guess none of them uses it very much (or at least not enough
> to need 4.65 instead of 4.61).

4.65 is a stable version and the last one of the 4.xx line, 4.61 is just one of millions of irrelevant historical beta's ...

> I can only guess because of WATT-32 + GNU pth slowing it down (although
> admittedly MSVC might be better than GCC these days, too).

And DGJPP C file I/O library costs 10% ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
23.05.2009, 02:42

@ DOS386

p7zip 4.65 for FreeDOS | Ibiblio has 4.61 only

Post reply

> > There aren't a lot of FreeDOS admins anymore, so while I did e-mail them
>
> Among others SF still says "Kernel - 2036test Last Update: May 21
> 2006" :-(

Well, 2038pre is the latest (unfinished?) "stable" kernel, so they can't update it yet (or won't, anyways).

> > guess none of them uses it very much (or at least not enough
> > to need 4.65 instead of 4.61).
>
> 4.65 is a stable version and the last one of the 4.xx line, 4.61 is just
> one of millions of irrelevant historical beta's ...

The changes between 4.61 and 4.65 were minor. Yes, sure, they should mirror to iBiblio, but it's not high priority.

> > I can only guess because of WATT-32 + GNU pth slowing it down (although
> > admittedly MSVC might be better than GCC these days, too).
>
> And DGJPP C file I/O library costs 10% ...

I don't think it's that bad. Usually it's pretty good performance. (Although WATT-32 is much slower than libsocket, but I don't think the latter works anymore ... at least not for my weak efforts.) But it depends on what the C library was compiled for. You could probably get better performance recompiling the C lib from CVS with latest GCC via -mtune=i686 (2.04 used GCC 3.3.2, I think, while 2.03p2 used 2.8.1, both almost definitely using the default -mtune=pentium, heh).

Rugxulo

Usono,
26.05.2009, 21:46

@ Rugxulo

p7zip 4.65 for FreeDOS (performance)

Post reply

> > > I can only guess because of WATT-32 + GNU pth slowing it down
> (although
> > > admittedly MSVC might be better than GCC these days, too).
> >
> > And DGJPP C file I/O library costs 10% ...
>
> I don't think it's that bad. Usually it's pretty good performance.
> (Although WATT-32 is much slower than libsocket, but I don't think the
> latter works anymore ... at least not for my weak efforts.) But it depends
> on what the C library was compiled for. You could probably get better
> performance recompiling the C lib from CVS with latest GCC via
> -mtune=i686 (2.04 used GCC 3.3.2, I think, while 2.03p2 used 2.8.1,
> both almost definitely using the default -mtune=pentium, heh).

The real problem is relying on sockets (which are only needed for GNU pth using the high-level pthreads API). It's too complex, and I'm too unfamiliar to strip it out myself. This was one advantage to Kostylev's builds, he used FSU Pthreads, which didn't need sockets. However, I'm lucky I was able to build it at all (and my patch should make it 100% possible for anyone to do so).

In particular, IIRC, I compiled 4.65 with -Os (G++ 4.3.2) because it's such a huge bloated program (and -O2 wasn't much faster, if at all, in my testing). 7za got "-mtune=i686" and (for comparison / equality) 7zr got "-mtune=i586". You might (??) get better with latest G++ 4.4.0, but don't count on it.

Rugxulo Usono, 29.05.2009, 02:41 @ DOS386	p7zip 4.65 for FreeDOS \| GCC 4.4.0 -O2 -mtune=i686 Post reply
	> > I can only guess because of WATT-32 + GNU pth slowing it down (although > > admittedly MSVC might be better than GCC these days, too). > > And DGJPP C file I/O library costs 10% ... I still think it's the GNU pth + WATT-32 combo slowing it down, but anyways, tell me if this one runs any significant bit faster for you: http://rugxulo.googlepages.com/p7zip465-dos386.zip

DOS386

05.06.2009, 07:20

@ Rugxulo

p7zip 4.65 for FreeDOS | GCC 4.4.0 -O2 -mtune=i686

Post reply

> tell me if this one runs any significant bit faster for you

Well, NO, actually both are cca 1.05 times slower than Igor's version, maybe the "new" from 2009-05-29 (how is it different except the increased bloat ?) version is even 1.055 times slower ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
05.06.2009, 07:47

@ DOS386

p7zip 4.65 for FreeDOS | GCC 4.4.0 -O2 -mtune=i686

Post reply

> > tell me if this one runs any significant bit faster for you
>
> Well, NO, actually both are cca 1.05 times slower than Igor's version,
> maybe the "new" from 2009-05-29 (how is it different except the increased
> bloat ?) version is even 1.055 times slower ...

The "new" one is "-mtune=i686 -O2" instead of "-Os", and I recompiled WATT-32 the same way, so in theory it could be faster. (I hate to suspect cache thrashing, like most do, since I have no way of testing that.) I didn't recompile libc, though, too impatient. (Feel free, heh.) It's possible that "-mtune=pentium-m" might speed it up for that specific cpu, but without knowing what to target for most people, I just chose i686 as generic.

For me, the "new" test compile I made does speed it up a small bit:

[ Vista ] - Fri 06/05/2009 >old-p7zip b 7-Zip (A) 4.65 Copyright (c) 1999-2009 Igor Pavlov 2009-02-03 p7zip Version 4.65 (locale=C,Utf16=off,HugeFiles=off,1 CPU) RAM usage: 55 MB, # Benchmark threads: 1 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1009 100 979 982 | 13144 100 1184 1186 ---------------------------------------------------------------- Avr: 100 979 982 100 1184 1186 Tot: 100 1082 1084

[ Vista ] - Fri 06/05/2009 >new-p7zip b 7-Zip (A) 4.65 Copyright (c) 1999-2009 Igor Pavlov 2009-02-03 p7zip Version 4.65 (locale=C,Utf16=off,HugeFiles=off,1 CPU) RAM usage: 55 MB, # Benchmark threads: 1 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1066 100 1034 1037 | 13839 100 1249 1249 ---------------------------------------------------------------- Avr: 100 1034 1037 100 1249 1249 Tot: 100 1142 1143

DOS386

05.06.2009, 08:35

@ Rugxulo

p7zip 4.65 for FreeDOS | GCC 4.4.0 -O2 -mtune=i686

Post reply

> The "new" one is "-mtune=i686 -O2" instead of "-Os"

so highest "mtune" is not that a good idea ...

> For me, the "new" test compile I made does speed it up a small bit:
> [ Vista ] - Fri 06/05/2009 >old-p7zip b

I tested in DOS only :-(

> RAM usage: 55 MB, # Benchmark threads: 1
> KB/s % MIPS MIPS | KB/s % MIPS MIPS

I compresed a file rather than Bench'ing ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
11.06.2009, 04:13

@ DOS386

p7zip 4.65 for FreeDOS | GCC 4.4.0 -O2 -mtune=i686

Post reply

> > The "new" one is "-mtune=i686 -O2" instead of "-Os"
>
> so highest "mtune" is not that a good idea ...

It's not "mtune" that bloats it, but instead the -O2. The "mtune" part is just a codegen helper for maybe a little bit of a speed increase.

> > For me, the "new" test compile I made does speed it up a small bit:
> > [ Vista ] - Fri 06/05/2009 >old-p7zip b
>
> I tested in DOS only :-(

On what chip?

> > RAM usage: 55 MB, # Benchmark threads: 1
> > KB/s % MIPS MIPS | KB/s % MIPS MIPS
>
> I compresed a file rather than Bench'ing ...

Default is 10 iterations of some internal compressing / decompressing "normalized" with a Core 2 results (I think).

Anyways, two comments:

1). p7zip 9.04 beta only compiles without the previous FreeDOS hack of mine. I really need to (try to) find out why it needs such a hack anyways. (Argh.)

2). 7zdec 9.04 from LZMA SDK now includes "x" (extract w/ dirs), which is majorly cool, esp. for my 1-flop DJGPP thingy. Now I don't need no stinkin' tar file. Anyways, I repackaged that, plus I recompiled all my 7zdec builds (minus MOSS which doesn't have mkdir(), which was only included previously for laughs anyways):

7zdec.zip
(DJGPPv1, DJGPPv2, OW18 Win32, OW18 DOS32, EMX, RSXNT, plus sources).