gvanem
rdebug by Ken Yap
I was looking for an open-source telnet server for DOS, and found a mention of rdebug on watt-32.net (added around May-June 2003):
A simple server that allows telnet clients to remotely read, write and dump memory on target. Done by Ken Yap.
This repository also mentions rdebug:
https://github.com/gvanem/Watt-32/blob/c8ace0d75e77c804249c650e031e057763e3c060/bin/dj_all.mak#L9
But I can't find any source code. Was it ever released? Where can I find it? Hopefully, Ken himself (@retiredfeline) still has it.
I'm sorry, I don't know what I did with it. It's been about 20 years ago after all. I seem to remember the idea was to be able to peek and poke into memory remotely. I don't even remember if it worked properly so I probably deleted it when I gave up working on DOS software around 2008.
I've just added the bin/suck and bin/rdebug code: https://github.com/gvanem/Watt-32/commit/50fdbcc65bd4a96b0c314f35e0ca76f47b8ae9b5
No idea if they work
No idea if they work
I'll get around to testing it if @tpimh dosen't beat me to it.
~~Did someone test before me? d2363d5d13ac714db54071ee0261407c6bfb02f4 seems to suggest so~~
Looks like there's no Watcom makefile for suck or rdebug currently. I'll have to look into making one. In the meantime. I'll test makefile.dj
I got both rdebug.exe and suck32.exe to build and run on the DJGPP builds within DOSBOX-X. Janky and with plenty of warnings, but running never the less.
Does this mean the issue is resolved?
Does this mean the issue is resolved?
Probably, but it would be nice if you (?) described how to run djgpp inside DOSBOX-X. It never worked for me.
I am using Open Watcom v2, and currently struggling to build Watt-32. I was able to build most of the object files with MODEL=s, but now I think I have completely broken my setup.
Also, I was able to successfully cross-compile on 64-bit Linux host for 16-bit DOS target (built PDCurses with minimal changes to makefiles and some simple programs in C), but this approach seems problematic for Watt-32 as it heavily relies on the binaries in "utils".
I was able to rebuild wc_err under DOS with Open Watcom, but not mkmake. Probably, I can also build native Linux versions of these tools for cross-compilation (or just use the DOS versions, since they are only needed once).
I will try to switch to djgpp and see if I can build rdebug with it, but my ultimate goal is a 16-bit DOS telnet server.
@gvanem
Go to Main -> Configuration tool -> AUTOEXEC.BAT and edit it to look similar to
@echo off
mount C /media/b/VM/DOSBOX-X/
C:
set dosdir=C:\DOS
set path=%path%;%dosdir%\BIN
%dosdir%\DRIVERS\CRYNWR\NE2000.COM 0x60
@echo on
The most important lines being mount C, set path=%dosdir%\BIN and set dosdir
Don't forget to hit Save... to make these changes permanent
Pull down SvarDOS packages crynwr, pkg, pkgnet, djgpp, djgpp_bn, djgpp_gc, djgpp_mk and nasm from http://svardos.org/?p=repo
.svp is just .zip and can be extracted as such by your native OS
After installing crynwr, pkg and pkgnet it's possible to use pkgnet and pkg to pull the rest in from DOSBOX-X itself.
Create a batch script with a name like %dosdir%\bin\djgpp.bat
MODE CON COLS=132 LINES=60
set DJGPP=C:\DOS\DEVEL\DJGPP\DJGPP.ENV
set PATH=%PATH%;C:\DOS\DEVEL\DJGPP\BIN;C:\DOS\DEVEL\NASM
Run that script then do a gcc -v to check everything is working.
Note: Some djgpp makefiles in watt-32 blindly call rm. Since it was just a smoke test I commented out these lines.
@tpimh
Unfortunately src/configur.bat and src/configur.sh are not equals. You might want to do the same as described above to take advantage of the pre-compiled binaries for DOS but instead of downloading djgpp packages, download ow and make %dosdir%\bin\watcom.bat look like:
MODE CON COLS=132 LINES=60
SET PATH=%dosdir%\DEVEL\OW\BINW;%PATH%
SET INCLUDE=%dosdir%\DEVEL\OW\H;%INCLUDE%
SET WATCOM=%dosdir%\DEVEL\OW
SET EDPATH=%dosdir%\DEVEL\OW\EDDAT
SET WIPFC=%dosdir%\DEVEL\OW\WIPFC
set DOS4G=QUIET
Run that script then do a wcl and wcl386 to check everything is working.
Heh, so much interest in retro software.
Before you get too carried away, note that I did not describe it as a telnet server. Rather, it's a server that can be connected to by a telnet client. This is trivial, you just listen on a TCP port (for TELNET 21 but could be any other port) and accept a TCP connection. Even a HTTP server can be connected to by a telnet client. Rdebug does all the processing of the input stream internally. I seem to remember I was thinking of using old XT class machines as glorified I/O slaves, using parallel port cards for example. For a true telnet server, you'd have to spawn a command interpreter and pass the stream to that. This wasn't possible in DOS, maybe it is on other platforms now. Then there are the telnet option negotiations.
Anyway best of luck.
@Lethja
Pull down SvarDOS packages crynwr, ...
My Chrome wanted to block all these, but Ill try this. Thanks.
Note: Some djgpp makefiles in watt-32 blindly call rm
I noted that trying to build rdebug32.exe with Djgpp inside latest DosBox-X.
I failed to find such GNU-tools in SvDOS !?
Besides, the Gnu-make in SvDOS is very old; building libwatt.a is difficult; command-line too long, out of environment space etc.
And it does not parse WATT32_ROOT = $(realpath $(WATT_ROOT)) in djcommon.mak. So I'm forced to tweak djcommon.mak.
But I'm on the way with djgpp + NE2000. An issue with the driver; running rdebug32.exe -v gives:
Watt-32 (2.2.11), GNU-C 12.2 (Pent), djgpp 2.05, Sep 6 2025
PKTDRVR: "NE2000", ver 0.11, API ver ?, mode 3
CPU: model: 0, vendor: GenuineIntel, brand: <unknown>
speed: 69.904 MHz (1 CPU core)
Transmitted: pctcp.c (1561), time 00:00:01.295
IP4: 0.0.0.0 -> 255.255.255.255
IHL 20, ver 4, tos 0, len 328, ttl 254, prot UDP, chksum A4BB (ok)
id 0001, ofs 0
UDP: 0.0.0.0 (68) -> 255.255.255.255 (67), sock 0016DAC8
len 308, chksum F7D5 (ok)
300: 0000: 01 01 06 00 25 DE 21 59-00 0C 00 00 00 00 00 00 ....%Þ!Y........
0010: 00 00 00 00 00 00 00 00-00 00 00 00 FF FF FF FF ............ÿÿÿÿ
0020: FF FF 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ÿÿ..............
0030: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0040: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0050: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0080: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0090: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
00E0: 00 00 00 00 00 00 00 00-00 00 00 00 63 82 53 63 ............cSc
00F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0100: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0110: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0120: 00 00 00 00 00 00 00 00-00 00 00 00 ............
** Transmit fault **
A real show-stopper!
See if another Watt-32 program like netpkg pull sved works. This will confirm your DOSBOX-X slirp/pcap configuration is working and make sure that the NE2000 packet driver is loading.
The packet driver is part of my autoexec above but you can run it manually at anytime to. It will output something like this if it ran successfully:
Packet driver software interrupt is 0x60 (96)
Interrupt number 0x9 (9)
I/O port 0x300 (768)
My Ethernet address is 02:A0:04:FE:80:88
NE2000.COM is part of the CRYNWR package.
You might want to do the same as described above to take advantage of the pre-compiled binaries for DOS but instead of downloading djgpp packages, download
ow
I am currently using the latest build of open-watcom-v2 (fork), and SvarDOS ow package seems to be built from the 1.9 source. Anyway, it's easy to have both installed and switch between them with an environment variable. I'll try 1.9 and report if the result is any different from the "bleeding edge".
The packet driver is part of my autoexec above but you can run it manually at anytime to.
With ne2000.com 0x60, all I get is:
This is not valid. But setting realnic = 6 in the [ethernet, pcap] section seems better:
But pkttraf.com 0x60 shows nothing and pkgnet.exe checkup does not work at all. Hanging for a long time before
Error: DNS resolution failed How to fix this?
How to fix this?
I assume you have a Pcap network service installed on Windows and have set the NE2000 backend set to use Pcap explicitly:
...but without knowing your setup, the best I can do is link you to Setting up networking in DOSBox-X.
The silver lining is if pkgnet isn't able to establish a network connection it is a problem with how DOSBOX-X was built or is configured and not Watt-32.
If you're really stuck after exhausting the DOSBOX-X wiki try another pcap application like 86Box or Wireshark to see if Pcap is working at all.
I got further; pkgnet checkup work fine.
Also a ping.exe -s router sends and receives 10 ICMP-packets. But everything freezes at program exit ?!
Also a
ping.exe -s routersends and receives 10 ICMP-packets. But everything freezes at program exit ?!
Everything seems fine on my end with a djgpp build
EDIT: Here's the binary so you can test if it's your build or your DOSBOX-X configuration