DOS ain't dead

2008-06-13: p7zip (7-Zip) 4.58
2008-06-11: ELinks browser
2008-06-04: Links browser
2008-06-13: mencoder.exe
2008-06-13: mplayer.exe
2008-06-05: mutt emailer
2008-06-10: Wget file downloader

Some descriptions:
http://mik.dyndns.org/dos-stuff/

All binaries:
http://mik.dyndns.org/dos-stuff/bin/

Source / diffs:
http://mik.dyndns.org/dos-stuff/src/

> 2008-06-13: p7zip (7-Zip) 4.58

Cool! Hopefully it too is faster than previous versions. Oh, and from the looks of it, the 7zsfx.con and main 7za.exe files are much smaller:

bin/7zcon.sfx  187,175       (193,416)         Jun,13,2008  02:16:30p
bin/7zCon.sfx  485,704       (487,060)         Mar,27,2008  06:06:34p

bin/7za.exe    414,453       (420,560)         Jun,13,2008  02:16:04p
bin/7za.exe    728,984       (730,296)         Mar,27,2008  05:58:28p

Time to benchmark it to see how fast it is!

> Time to benchmark it to see how fast it is!

[ Vista ] - Mon 06/16/2008 >p7zip457 b -md20

7-Zip (A) 4.57  Copyright (c) 1999-2007 Igor Pavlov  2007-12-06
p7zip Version 4.57 (locale=C,Utf16=off,HugeFiles=off,1 CPU)

RAM size:     128 MB,  # CPU hardware threads:   1
RAM usage:     16 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

18:    1142    98   1018   1018  |    12652   100   1230   1233
19:    1047   100    938    938  |    12812   100   1263   1263
20:     998   101    900    909  |    12775   100   1276   1276
----------------------------------------------------------------
Avr:          100    952    955               100   1257   1257
Tot:          100   1104   1106

[ Vista ] - Mon 06/16/2008 >p7zip b -md20

7-Zip (A)  4.58 beta  Copyright (c) 1999-2008 Igor Pavlov  2008-05-05
p7zip Version 4.58 (locale=C,Utf16=off,HugeFiles=off,1 CPU)

RAM size:     128 MB,  # CPU hardware threads:   1
RAM usage:     16 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

18:    1185   102   1013   1055  |    13317   100   1135   1135
19:    1175   101   1029   1053  |    13546   100   1166   1169
20:    1098   100   1001   1001  |    13966   100   1218   1221
----------------------------------------------------------------
Avr:          101   1015   1036               100   1173   1175
Tot:          100   1094   1106

EDIT: Here's what his optimization flags were (apparently):

OPTFLAGS=-O3 -mtune=i586

First of all, "-mtune=pentium" is default anyways (see "gcc -v"). Secondly, most computers these days are 686-ish, so for wide distribution, that may? be preferable (although separate compiles would be ideal). Thirdly, "-fomit-frame-pointer" sometimes helps a noticeable bit. Fourthly, it seems that compiling via "-mtune=i686" is actually a lot faster (in most cases) than i386, i486, i586 (usually slowest), don't ask me why ... GNU bias towards newer chips? Easier to optimize for??

---
Know your limits.h

> 2008-06-10: Wget file downloader

Anyone got it working ? Me not

> 2008-06-13: p7zip (7-Zip) 4.58
> the 7zsfx.con and main 7za.exe files are much smaller

NO. Seems you got frauded by UPX --ultra-extreme-brutal again, real plain size is 1.2 MiB

BTW, Mik this time used the PMODE/DGJ stub ...

> Time to benchmark it to see how fast it is
> [ Vista ] - Mon 06/16/2008 >p7zip b -md20

Since I'm the only one who has DOS:



Igor's one works ...
Mik's one works without HDPMI32
Mik's one brews a PF with HDPMI32 ... seems to have a mallicious pointer ... unusable, no need for time /t for now

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

> > 2008-06-13: p7zip (7-Zip) 4.58
> > the 7zsfx.con and main 7za.exe files are much smaller

> NO. Seems you got frauded by UPX --ultra-extreme-brutal again, real plain size is 1.2 MiB

NO "NO". After unpacking:
7za.exe, v4.57 = 1,872,896K
7za.exe, v4.58 = 1,240,576K
7zCon.sfx, v4.57 = 1,118,208K
7zCon.sfx, v4.58 = 511,488K

> I'm the only one who has DOS

Funny.

> image27.png
etc.

What's a .zi7 file?

> > 2008-06-10: Wget file downloader
>
> Anyone got it working ? Me not

Do I really need to tell you again about posting good error descriptions?

> Mik's one brews a PF with HDPMI32 ... seems to have a mallicious
> pointer ... unusable, no need for time /t for now

Maybe it's a feature and no bug. I think, it's a problem of PMODE/DJ.

---
Forum admin

> > Mik's one brews a PF with HDPMI32 ... seems to have a mallicious
> > pointer ... unusable, no need for time /t for now
>
>
> Maybe it's a feature and no bug. I think, it's a problem of PMODE/DJ.

Feature, bug...
1) 7za.exe for Win runs under DOS with HX.
2) 7za.exe for DOS runs with the supplied extender.
3) In view of 1) and 2), why does it matter if 7za.exe for DOS does not work with an extender that it was not designed to work with. What is lost?
4) Something appears to be gained with PMODE/DJ - smaller binaries. I call that a good deal.

> Igor's one works ...
> Mik's one works without HDPMI32
> Mik's one brews a PF with HDPMI32 ... seems to have a mallicious
> pointer ... unusable, no need for time /t for now

Try "hdpmi32 -m" (disables DPMI 1.0 memory functions)

---
MS-DOS forever!

> > Igor's one works ...
> > Mik's one works without HDPMI32
> > Mik's one brews a PF with HDPMI32 ... seems to have a mallicious
> > pointer ... unusable, no need for time /t for now
>
>
> Try "hdpmi32 -m" (disables DPMI 1.0 memory functions)

You can always remove PMODE/DJ via DJGPP's stubify (to make CWSDPMI default ... although it seems to bork if not using -x) or various other methods (e.g. D3X's stubx -u to make a raw COFF). But I dunno which work best (maybe Kostylev tested various extenders, maybe not). Feel free to suggest others to him.

Steve wrote:

> NO "NO". After unpacking:

OK ... 4.57 was even worse ... nevertheless, Mik's 4.58 is not significantly smaller than most older D**** versions, and still heavily bloated compared to Igor's version.

> 1) 7za.exe for Win runs under DOS with HX.
> 2) 7za.exe for DOS runs with the supplied extender.
> 3) In view of 1) and 2), why does it matter if 7za.exe for DOS does not work

YES. I'm using HPDMI32 resident.

> 4) Something appears to be gained with PMODE/DJ - smaller binaries.

YES. By 8 KiB compared to CWSDPMI, or 22 KiB compared to LOADPEX (not really "available" by now) .

> I call that a good deal.

IMHO NO. Not being able to run on HDPMI32 is a severe fault

> really need to tell you again about posting good error descriptions?

NO. It was not a bug report, just a side note (see shot for 7-ZIP bug report) - it just doesn't find the Internet / IP while Arachne does (DHCP). Nevertheless, 42 DOSsers could have answered about having WGET working in DOS and how (USB modem and satellite connection ? ), nobody did, seems people are more interested about what I'm doing wrong rather than using WGET in DOS

Japheth wrote:

> Try "hdpmi32 -m" (disables DPMI 1.0 memory functions)

Seems to fix it

Rugxulo wrote:

> You can always remove PMODE/DJ via DJGPP's stubify

I know ... WDOSX and D3X could be better ... IIRC D3X doesn't have this bug, at least not with your great PAQ ...

BTW, the "lazy-progress-indicator-bug" seems fixed

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

> Steve wrote:
>
> > NO "NO". After unpacking:
>
> OK ... 4.57 was even worse ... nevertheless, Mik's 4.58 is not
> significantly smaller than most older D**** versions, and still
> heavily bloated compared to Igor's version.

The DOS version is a port. Things happen in porting. Let us know when you can do it BeTTeR.

> > 1) 7za.exe for Win runs under DOS with HX.
> > 2) 7za.exe for DOS runs with the supplied extender.
> > 3) In view of 1) and 2), why does it matter if 7za.exe for DOS does not
> work
>
> YES. I'm using HPDMI32 resident.

Then use 7za-Win. End of problem.

> > 4) Something appears to be gained with PMODE/DJ - smaller binaries.
>
> YES. By 8 KiB compared to CWSDPMI, or 22 KiB compared to LOADPEX (not
> really "available" by now) .

Every little bit helps.

> > I call that a good deal.
>
> IMHO NO. Not being able to run on HDPMI32 is a severe fault

You still haven't explained why it's necessary to run the DOS version with HDPMI32, when, I repeat, the Win version works with it.

> it just doesn't find the Internet / IP while Arachne does (DHCP).

RTFM: http://www.gnu.org/software/wget/manual/

> Nevertheless, 42 DOSsers could have answered

Is it the duty of all of us here to investigate your problems before you report them, so as to be ready to give you immediate answers?

> about having WGET working in DOS and how (USB modem and satellite connection?

Hardware should be invisible to Wget. Check your packet driver and its configuration.

> seems people are more interested about what I'm doing wrong rather than using WGET in DOS

That might be true.

> OK ... 4.57 was even worse ... nevertheless, Mik's 4.58 is not
> significantly smaller than most older D**** versions, and still
> heavily bloated compared to Igor's version.

Yes, that's the trouble with standard DJGPP. Mik's version has to carry all code, which exceeds standard DOS functionality, in one binary. Igor's version has Windows/HX DLLs for that.

> YES. I'm using HPDMI32 resident.

Anybody else?

> > I call that a good deal.
>
> IMHO NO. Not being able to run on HDPMI32 is a severe fault

1) Who else is using HDPMI32 as a TSR?
2) Then please report this to Michael Kostylev directly. It won't change, if you only report that here.

> > really need to tell you again about posting good error descriptions?
>
> NO. It was not a bug report, just a side note (see shot for 7-ZIP bug
> report) - it just doesn't find the Internet / IP while Arachne does
> (DHCP). Nevertheless, 42 DOSsers could have answered about having
> WGET working in DOS and how (USB modem and satellite connection ?
> ), nobody did, seems people are more interested about what I'm doing wrong
> rather than using WGET in DOS

It works for me via a NAT DSL router. But this "via" doesn't really matter, because Wget's internal TCP/IP stack (Watt-32) only sees the packet driver.

---
Forum admin

> > YES. I'm using HPDMI32 resident.
>
> Then use 7za-Win. End of problem.

It's almost certainly a bug, although it's disclosed under certain conditions only. And it's a DOS program. So IMO it is perfectly valid issue to be discussed in this forum.

> You still haven't explained why it's necessary to run the DOS version with
> HDPMI32, when, I repeat, the Win version works with it.

see my note above.

> Is it the duty of all of us here to investigate your problems before you
> report them, so as to be ready to give you immediate answers?

If you aren't interested, then please just ignore this thread!

---
MS-DOS forever!

> Anybody else?

Yes.

> 1) Who else is using HDPMI32 as a TSR?

It doesn't matter at all how many people use this feature.

> 2) Then please report this to Michael Kostylev directly. It won't change,
> if you only report that here.

Please explain why you regard this issue as non-suitable for this forum. It's probably a bug in the program or in HDPMI.

---
MS-DOS forever!

> > Anybody else?
>
> Yes.

Perfectly.

> > 1) Who else is using HDPMI32 as a TSR?
>
> It doesn't matter at all how many people use this feature.

Why does this not matter here? You declined one of DOS386's bug reports, because it only affects FASM hand crafted binaries.

> > 2) Then please report this to Michael Kostylev directly. It won't
> change,
> > if you only report that here.
>
> Please explain why you regard this issue as non-suitable for this forum.

Where did I write it is "non-suitable"? I just gave him a good advice. see below

> It's probably a bug in the program or in HDPMI.

That's exactly the point! Are you sure Michael Kostylev reads this forum? I'm not.

---
Forum admin

> > It doesn't matter at all how many people use this feature.
>
> Why does this not matter here? You declined one of DOS386's bug reports,
> because it only affects FASM hand crafted binaries.

Comparing apples and pears. I refused to "fix" the bug because it's a lot of work for virtually nothing. However, to be able to decide whether the bug reported by DOS386 is a bug in the 7zip port or in HDPMI, it doesn't matter how many people install HDPMI permanently.

> > It's probably a bug in the program or in HDPMI.
>
> That's exactly the point! Are you sure Michael Kostylev reads this forum?
> I'm not.

That also doesn't matter and isn't "exactly the point". Even if there would be no author at all or the software just available as binary would be an acceptable argument. We still can discuss it, there might exist workarounds, configuration changes and other stuff which could help ...

---
MS-DOS forever!

> > > It doesn't matter at all how many people use this feature.
> >
> > Why does this not matter here? You declined one of DOS386's bug
> reports,
> > because it only affects FASM hand crafted binaries.
>
> Comparing apples and pears. I refused to "fix" the bug because it's a lot
> of work for virtually nothing.

Making or fixing the DOS port for two users affected is also "a lot of work for virtually nothing", because, as already pointed out, the Win32 binary works very well on HX.

> However, to be able to decide whether the
> bug reported by DOS386 is a bug in the 7zip port or in HDPMI, it doesn't
> matter how many people install HDPMI permanently.

That's correct, but I think, you know, what I meant.

> > > It's probably a bug in the program or in HDPMI.
> >
> > That's exactly the point! Are you sure Michael Kostylev reads this
> forum?
> > I'm not.
>
> That also doesn't matter and isn't "exactly the point". Even if there
> would be no author at all or the software just available as binary would
> be an acceptable argument. We still can discuss it, there might exist
> workarounds, configuration changes and other stuff which could help ...

Good luck!

---
Forum admin

> > However, to be able to decide whether the
> > bug reported by DOS386 is a bug in the 7zip port or in HDPMI, it
> doesn't
> > matter how many people install HDPMI permanently.
>
> That's correct, but I think, you know, what I meant.

I have no idea what's the idea behind your postings in this thread, so no, I have to assume I don't know what you meant.

> > That also doesn't matter and isn't "exactly the point". Even if there
> > would be no author at all or the software just available as binary
> would
> > be an acceptable argument. We still can discuss it, there might exist
> > workarounds, configuration changes and other stuff which could help ...
>
> Good luck!

Ok, Good luck ... for what? I gave just an example that discussion may be useful if the author/source is not available and what happens 100,000 times a day if users discuss Windows bugs and oddities at various places.

---
MS-DOS forever!

> > > YES. I'm using HPDMI32 resident.
> >
> > Then use 7za-Win. End of problem.
>
> It's almost certainly a bug, although it's disclosed under certain
> conditions only. And it's a DOS program. So IMO it is perfectly valid
> issue to be discussed in this forum.

OK, a bug - but where? I wouldn't assume it's in HDPMI32. I've seen error messages similar to the one DOS386 showed, in DOS progs running under Windows. Some progs are fussy about which DPMI providers they will work with. How much time do you want to spend making HDPMI32 compatible with every other existing provider?

> > You still haven't explained why it's necessary to run the DOS version with
> > HDPMI32, when, I repeat, the Win version works with it.
>
> see my note above.

I'm just tryong to help you avoid unrewarding labor.

> > Is it the duty of all of us here to investigate your problems before you
> > report them, so as to be ready to give you immediate answers?
>
> If you aren't interested, then please just ignore this thread!

But I am interested!

rr wrote:

> It works for me via a NAT DSL router. But this "via" doesn't really
> matter, because Wget's internal TCP/IP stack (Watt-32) only sees
> the packet driver.

OK ... is DHCP used in your connection ?

> > YES. I'm using HPDMI32 resident.
> Anybody else?

Probably no, but this is an old hat

> 1) Who else is using HDPMI32 as a TSR?

see above

> 2) Then please report this to Michael

Maybe ...

Steve wrote:

> RTFM: http://www.gnu.org/software/wget/manual/

No DOS-specific stuff

> Hardware should be invisible to Wget. Check your packet
> driver and its configuration.

Arachne is happy with it

> Is it the duty of all of us here to investigate your problems before

F.O.

> But I am interested!

In trolling :-&

BTW, I found out that patching WDOSX or D3X into Mik's port doesn't help - very same bug persists

Any good docs on Packet drivers around ? I have no idea how they work

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

> OK, a bug - but where? I wouldn't assume it's in HDPMI32. I've seen error
> messages similar to the one DOS386 showed, in DOS progs running under
> Windows. Some progs are fussy about which DPMI providers they will work
> with. How much time do you want to spend making HDPMI32 compatible with
> every other existing provider?

What's supposed to be a "provider" in this context? There are no workarounds implemented in hdpmi to make it run with buggy DPMI clients. Your question is incomprehensible to me, sorry.

> I'm just tryong to help you avoid unrewarding labor.

Thanks, very much appreciated. But please, do help others as well, don't concentrate all your energy on me!

---
MS-DOS forever!

> > That's correct, but I think, you know, what I meant.
>
> I have no idea what's the idea behind your postings in this thread, so no,
> I have to assume I don't know what you meant.

I meant, that it would be a good idea to also report this incompatibility to Michael directly. I did not "forbid" discussing this issue here, although IMHO it's probably a waste of time.

> > > That also doesn't matter and isn't "exactly the point". Even if there
> > > would be no author at all or the software just available as binary
> > would
> > > be an acceptable argument. We still can discuss it, there might exist
> > > workarounds, configuration changes and other stuff which could help
> ...
> >
> > Good luck!
>
> Ok, Good luck ... for what?

For discussing, of course. You wrote "we", so I took the right to assume, that you were talking about DOS386 and your own person, because I'm not interested in such a discussion, although "we" might have included me and others too.

> I gave just an example that discussion may be
> useful if the author/source is not available and what happens 100,000
> times a day if users discuss Windows bugs and oddities at various places.

I see, but Michael and p7zip's source code are available.

---
Forum admin

> rr wrote:
>
> > It works for me via a NAT DSL router. But this "via" doesn't really
> > matter, because Wget's internal TCP/IP stack (Watt-32) only sees
> > the packet driver.
>
> OK ... is DHCP used in your connection ?

Yes.

> > 2) Then please report this to Michael
>
> Maybe ...

Is this the same non-committal "maybe" as for creating the Bochs bug report?

> Steve wrote:
>
> > RTFM: http://www.gnu.org/software/wget/manual/
>
> No DOS-specific stuff

Because it's not required.

> > Hardware should be invisible to Wget. Check your packet
> > driver and its configuration.
>
> Arachne is happy with it

If this is a bug report now, then please reveal more details, if you're really interested in a solution!

> Any good docs on Packet drivers around ? I have no idea how they work
>

http://www.crynwr.com/?!

---
Forum admin

> that it would be a good idea to also report this
> incompatibility to Michael directly.

YES. More tests needed.

4.33 Blair 1'491'968 NO BUG
4.42 Blair 1'553'920 BUG
4.58 Mik   1'240'576 BUG

1. Mik's 4.58 port is indeed a bit smaller
2. I'm getting the same bug with Blair's 4.42 also

> Is this the same non-committal "maybe" as for creating the Bochs bug

YES. More tests needed, see above (anyone is free to help).

> http://www.crynwr.com/

From 1989 If anyone has more (DOS specific ?) please post.

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

> > http://www.crynwr.com/
>
> From 1989 If anyone has more (DOS specific ?) please post.

What do you need more? There is no more information, because packet drivers are usually easier to use than MS TCP/IP + NDIS2 stuff. You still don't post a detailed error description, so I guess, you're not interested in a solution. Bye.

---
Forum admin