DOS ain't dead

For first - sorry for my ugly english.

I have 486-class system (mentioned here if interested) based on some kind of embedded chipset and aimed mainly to various embedded and industrial purposes.

Short tech specs:
Advantech PCA-6740 ISA SBC (single board computer) as motherboard.
STPC Elite 133Mhz (Cyrix Cx486 core based SoC cpu+chipset, 66mhz FSB, 2x multiplier).
32mb SDRAM onboard mem (66 / 100mhz).
SMI LynxEM+ SM712G 4mb PCI bus integrated video.
Raltek RTL8139C onboard LAN.
Award/Phoenix Bios v6.0 bios.

It suits for my hobby tasks quite well - it cold, silent and very reliable. I do not want to change it to something else. It have some quirks with DMA and integrated video but eventually I have got used to them or found ways to workaround some of it.

But not all, unfortunatelly. Main issue is still unsolved.

I will try to formulate it short like this: it lockups with every (which i know and tried) piece of *NIX network software ported to DOS with DJGPP and dated before late 2002. Confused? Mmm, i too.

Now a little longer and informative.

What software i tried:
Links browser.
CURL.
WGET.
BSFLite (AIM/ICQ client).
BinkD (TCP/IP driven FTN mailer).

What do they have in common? All of them is console network utilities and all of them not DOS native software, but ported. And ported from some Unix/BSD environment, if I'm not mistaken. And all of them ported to DOS by DJGPP suite, again, if I'm not mistaken. And all of them use WATTCP/WATT-32 API for network functionality in DOS environment.

Every utility mentioned above lockups on this mobo without any error messages right after run. In various versions of pure DOS (with rtspkt packet driver), in Windows 9X DOS box (with NDIS3PKT driver). Ofcourse i tried many software configurations and clean boot million times and digged all bios setting.

Some thoughts.
WGET v1.82. Oldest ported to DOS version which i found. And it - SURPRISINGLY - works just fine. In pure DOS and Win9X DOS box. It dated by late 2002. Later version which i tried lockups too. Such older ports (dated around 2002) of another mentioned software i just didn't found for further testing.
7zip. Another ported to DOS proggy. And again it DJGPP driven. All tested versions (including most recent) just works. Because... it is not a network software.
Arachne browser. All version include last 1.97GPL (dated 2013) works flawlessy. But it native DOS program, not ported from *NIX.

In what way i should dig now? Find/request sources of that problematic ports from it authors and try to recompile with some obsolete DJGPP versions?

I'm a not programmer. And i didn't write any line of code in my life unfortunatelly. This is pure mystical craft for me.

Nevertheless i guess DJGPP is the main issue in that.

Any thoughts? Really hope for your help, guys.
Thanks.

Nice board. Hard to sat what's wrong, there maybe a million of reasons of some incompatability between BIOS, Cyrix SoC HW, packet driver, CWSDPMI, DJGPP...
The WATTCP library got some fixes/updates recent years, I have last one from 2016. Did you tried links 2.17 announced some posts below?
Maybe you could try to run the same OS+driver+app setup on a different PC with similar Realtek NIC if it will work. I used RTL8029 and now RTL8111 and networking works well for me, except some problem in new Quake2DOS release that is crashing and I cannot figure why - something has changed since 2016 release I used before...

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

> Did you tried links 2.17 announced some posts below?

Yeah, make sure you've tried Links 2.17 and Wget 1.19. BTW, does mTCP work for you? What about picoSNTP? (I'm no networking guru, but you can also try some of the other programs in FreeDOS' Networking section.) Dillo used to work fairly well, Curl not so much, never messed with Lynx in recent years, but there's a fairly recent DJGPP port of that (lx289b.zip), too.

Privet!
Hard to say where can be the problem. My first idea - some unsupported instruction in the used network library (Watt32) for your CPU.
Maybe I am wrong but I thought that newer builds of Watt32 are compiled for 686+ processors with instructions like CMOVxx.
But I am even not sure whether your processor (STPC Elite 133Mhz), although marked as i80486 compatible, knows the new 486 instructions like BSWAP or XADD.

But maybe I am wrong and the problem is elsewhere. First - try more DJGPP+Watt32 programs. I uploaded the testing binaries for Watt32
here

As a next step try to replace the default DPMI server to an alternative.
The easiest is the use the HDPMI32 server from the HX-DOS package by Japheth.
(commandline is HDPMI32 -r)
After loading such DPMI server try to run your problematic binaries again.

---
DOS-u-akbar!

Saluton! Bonvenon!

> Hard to say where can be the problem. My first idea - some unsupported
> instruction in the used network library (Watt32) for your CPU.

Maybe CPUID fails or is misdetected? Certainly people are sloppy about that, esp. for (old) non-AMD and non-Intel cpus. EDIT: Try Eric Auer's CPULEVEL tool (very small but useful).

> Maybe I am wrong but I thought that newer builds of Watt32 are compiled for
> 686+ processors with instructions like CMOVxx.

I certainly hope not, it probably wouldn't speed up much! (EDIT: Is that intentional? Have you heard that from Juan or others? I'd consider anything DJGPP compiled as 686+ as almost a bug.)

> But I am even not sure whether your processor (STPC Elite 133Mhz), although
> marked as i80486 compatible, knows the new 486 instructions like BSWAP or
> XADD.

I seriously doubt it's using those particular instructions, esp. if compiled by GCC.

> But maybe I am wrong and the problem is elsewhere. First - try more
> DJGPP+Watt32 programs. I uploaded the testing binaries for Watt32
> here

Why not just point him to DJGPP's /current/v2tk/wat3222br6.zip? Although all it has is ping.exe and tcpinfo.exe (not much).

FYI: http://www.watt-32.net/

> As a next step try to replace the default DPMI server to an alternative.
> The easiest is the use the HDPMI32 server from the HX-DOS package by
> Japheth.
> (commandline is HDPMI32 -r)
> After loading such DPMI server try to run your problematic binaries again.

Which version, 2.18-pre?

P.S. I do seriously want to (weakly try to) rebuild Wget one of these days, for other reasons, but it's not something I feel super comfortable doing, so I haven't bothered (yet).

> Privet!
> Hard to say where can be the problem. My first idea - some unsupported
> instruction in the used network library (Watt32) for your CPU.

Yes it may be such kind of problem. If I remember well some version(s) of GCC had a problem that it emmited 686 insctuction even when it was commanded to compile for older CPU. Nowday nobody cares about CPUs with insctruction set less than 686 and it will get worse. Maybe you could try some debugging tool to find on what instruction it's failing.
EDIT: A quick look in IDA to LINKS.EXE doesn't show any occurence of mentioned instructions. Maybe it can be checked under DOSbox if it will run, set cputype=486 in config.

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