Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
picoTCP: a modern, open-source TCP/IP stack for DOS
139 views
Skip to first unread message
Mateusz Viste
Nov 19, 2015, 2:00:18 PM11/19/15
to
Hello group,
I write this message to share a little news about what I was doing in my
spare time these last two months: porting picoTCP to DOS.
picoTCP is a modern, dual-stack, open-source TCP/IP stack. It has been
created by the good people at Intelligent Systems (Altran), primarily as
a stack designed for embedded computing (hence hardware with very
limited horse power). It is backed by a well established corporation and
it's actively maintained.
I played with the stack for some times now, and ended up building an
entire DOS compatibility layer around it. A few patches were required to
the stack, a few days of development, many hours of debugging - but here
it is - the first public release of picoTCP for DOS!
http://picotcp4dos.sourceforge.net
The project contains three major parts:
- ipcfg: a little tool that allows to configure networking on your DOS
machine (IP, DNS, etc). No, it's not a text file - I wanted to avoid the
complexity of parsing a text file, and opted for a binary configuration
file that is manipulated via ipcfg. It's much more flexible that a text
config file, while being much easier/faster to load at runtime.
- ping: no need to explain, I guess... my ping tool for DOS, based on
picoTCP - crucial when it comes to testing your networking
- an OpenWatcom library package (openwatcom, large memory model) - this
is for the fellow developers that would like to use the DOS version of
picoTCP inside their network-enabled, 16-bit DOS programs. I integrated
a packet driver schim, a DOS-compatible timer, as well as the whole IP
configuration logic, so it is now a simple (2 functions!) public API
that allows to load picoTCP, use it, and unload it.
*** Short how-to ***
1. Download picotcp4dos and unzip it on your drive
2. Set the location where the config file will be stored, for example:
SET PICOTCP=C:\PICOTCP.DAT
3. Bind picoTCP to the interrupt vector of your packet driver, example:
ipcfg int 60
4. Configure your IP settings using ipcfg, or use DHCP (ipcfg dhcp)
enjoy!
Mateusz
I write this message to share a little news about what I was doing in my
spare time these last two months: porting picoTCP to DOS.
picoTCP is a modern, dual-stack, open-source TCP/IP stack. It has been
created by the good people at Intelligent Systems (Altran), primarily as
a stack designed for embedded computing (hence hardware with very
limited horse power). It is backed by a well established corporation and
it's actively maintained.
I played with the stack for some times now, and ended up building an
entire DOS compatibility layer around it. A few patches were required to
the stack, a few days of development, many hours of debugging - but here
it is - the first public release of picoTCP for DOS!
http://picotcp4dos.sourceforge.net
The project contains three major parts:
- ipcfg: a little tool that allows to configure networking on your DOS
machine (IP, DNS, etc). No, it's not a text file - I wanted to avoid the
complexity of parsing a text file, and opted for a binary configuration
file that is manipulated via ipcfg. It's much more flexible that a text
config file, while being much easier/faster to load at runtime.
- ping: no need to explain, I guess... my ping tool for DOS, based on
picoTCP - crucial when it comes to testing your networking
- an OpenWatcom library package (openwatcom, large memory model) - this
is for the fellow developers that would like to use the DOS version of
picoTCP inside their network-enabled, 16-bit DOS programs. I integrated
a packet driver schim, a DOS-compatible timer, as well as the whole IP
configuration logic, so it is now a simple (2 functions!) public API
that allows to load picoTCP, use it, and unload it.
*** Short how-to ***
1. Download picotcp4dos and unzip it on your drive
2. Set the location where the config file will be stored, for example:
SET PICOTCP=C:\PICOTCP.DAT
3. Bind picoTCP to the interrupt vector of your packet driver, example:
ipcfg int 60
4. Configure your IP settings using ipcfg, or use DHCP (ipcfg dhcp)
enjoy!
Mateusz
Computer Nerd Kev
Nov 20, 2015, 6:24:16 PM11/20/15
to
In comp.os.msdos.misc Mateusz Viste <mateusz.viste@localhost> wrote:
> Hello group,
>
> I write this message to share a little news about what I was doing in my
> spare time these last two months: porting picoTCP to DOS.
Interesting, though I don't have any projects to use it with
> Hello group,
>
> I write this message to share a little news about what I was doing in my
> spare time these last two months: porting picoTCP to DOS.
myself.
Perhaps you could see about adding it to the FreeDOS Wiki page
about DOS TCP/IP stacks:
http://freedos.sourceforge.net/wiki/index.php/TCP-IP
Might also be useful to put on your website some comparisons
between your project and some of the other ones.
--
__ __
#_ < |\| |< _#
Rod Pemberton
Nov 21, 2015, 12:51:22 AM11/21/15
to
Does it also compile as 32-bit DPMI for OpenWatcom and DJGPP?
Did you post about this to comp.os.msdos.djgpp or
openwatcom.users.c_cpp groups? I don't see any ...
What about a post to the "DOS ain't dead!" forum?
http://www.bttr-software.de/forum/forum.php
Change of topic: HimemX
It seems you picked up the HimemX project.
http://sourceforge.net/projects/himemx/
Some people are asking about your updates to HimemX here:
http://www.bttr-software.de/forum/forum_entry.php?id=14511
Rugxulo helped me post an updated version for E820.
Unfortunately, it has a bug. The version you have
on sourceforge is missing the bug fix I posted.
It won't support /MAX=4194304 (4GB) but will support
lower values. The code needs one instruction added
to the "clamp e820 ..." section in himemx.asm.
I posted the fix here. See the ";FIX" line:
https://groups.google.com/d/msg/comp.os.msdos.djgpp/P3MfmAyCH9M/56TH52lUA5QJ
Usenet msg-id: <ksi3s6$iv2$1...@speranza.aioe.org>
I'd appreciate it if you corrected that. I thought
Rugxulo fixed that for me, but apparently he didn't.
Rod Pemberton
--
How to kill Facebook. Tell a bunch of fourth graders that
only old people use Facebook. Wait eight years.
Mateusz Viste
Nov 21, 2015, 2:19:38 AM11/21/15
to
On 21/11/2015 06:51, Rod Pemberton wrote:
> Does this only compile for 16-bit OpenWatcom?
Yes.
> Does this only compile for 16-bit OpenWatcom?
> Does it also compile as 32-bit DPMI for OpenWatcom and DJGPP?
picoTCP also compatible with DJGPP. I started with openWatcom because if
was both easier on some integration aspects, but my work will steadily
continue: adding IPv6, speed optimizations, DJGPP... Stay tuned.
> Did you post about this to comp.os.msdos.djgpp or
> openwatcom.users.c_cpp groups? I don't see any ...
a group unknown to my NNTP gateway.
I do not have an account there. I did, however, post it on Vogons. Hope
the information will spread on its own now :)
Mateusz
Mateusz Viste
Nov 21, 2015, 2:20:08 AM11/21/15
to
On 21/11/2015 06:51, Rod Pemberton wrote:
"picked up" might be a big word - I just created a sourceforge project,
centralized all the bits I could find laying around into a structured
source code repo, applied the "informal" patches that were floating
since a few years and published a binary release.
> Some people are asking about your updates to HimemX here:
> http://www.bttr-software.de/forum/forum_entry.php?id=14511
sake of PR.
> It won't support /MAX=4194304 (4GB) but will support
> lower values. The code needs one instruction added
> to the "clamp e820 ..." section in himemx.asm.
>
> I posted the fix here. See the ";FIX" line:
> https://groups.google.com/d/msg/comp.os.msdos.djgpp/P3MfmAyCH9M/56TH52lUA5QJ
release this weekend.
Since you are the author of significant fixes to HimemX, would you like
to participate in the "HimemX revival" project on sourceforge? You'd
have a direct write access to svn then.
cheers,
Mateusz
Mateusz Viste
Nov 21, 2015, 10:16:49 AM11/21/15
to
Hi Rod,
I looked at your patch. If I understand it right, what you do is
basically that you convert kilobytes from the /MAX parameter to bytes
first (shl 10), and then you subtract one byte. So at the end of the
day, when the user wants to clamp e820 at 8K, HimemX will in fact 'lie',
and clamp at 8191 bytes (ie. 8K - 1 byte).
The advantage is that the user can clamp at 4G now (which will be in
fact 4G - 1 byte).
Am I getting this right?
If so, then maybe would there be a cleaner way to solve the eax overflow
at 4G issue? Also, what if the user would want to clamp at 0K? In such
corner case, HimemX would clamp at 4G - 1 instead, which might be
considered a bug.
What about, say, replacing your one line fix by something like that?
--- himemx.asm (revision 29)
+++ himemx.asm (working copy)
@@ -3660,7 +3660,11 @@
mov eax,[_xms_max]
or eax,eax
je @@e820_loop ; no maximum XMS set
- shl eax,10
+ shl eax,9
+ shl eax,1 ; of guaranteed to change only on 1 shifts
+ jno @@overflow4g ; no overflow, so clamping on != 4G
+ dec eax ; sub 1 from eax, hence switch it to 4G-1
+ @@overflow4g:
cmp esi,eax
jbe @@e820_loop ; at or below maximum
It still makes HimemX lie in this specific situation, but at least it's
limited to only this one single situation when user wants to clamp at
exactly 4G, instead of lying all the time (and it solved the "clamp to
0" case).
Mateusz
I looked at your patch. If I understand it right, what you do is
basically that you convert kilobytes from the /MAX parameter to bytes
first (shl 10), and then you subtract one byte. So at the end of the
day, when the user wants to clamp e820 at 8K, HimemX will in fact 'lie',
and clamp at 8191 bytes (ie. 8K - 1 byte).
The advantage is that the user can clamp at 4G now (which will be in
fact 4G - 1 byte).
Am I getting this right?
If so, then maybe would there be a cleaner way to solve the eax overflow
at 4G issue? Also, what if the user would want to clamp at 0K? In such
corner case, HimemX would clamp at 4G - 1 instead, which might be
considered a bug.
What about, say, replacing your one line fix by something like that?
--- himemx.asm (revision 29)
+++ himemx.asm (working copy)
@@ -3660,7 +3660,11 @@
mov eax,[_xms_max]
or eax,eax
je @@e820_loop ; no maximum XMS set
- shl eax,10
+ shl eax,9
+ shl eax,1 ; of guaranteed to change only on 1 shifts
+ jno @@overflow4g ; no overflow, so clamping on != 4G
+ dec eax ; sub 1 from eax, hence switch it to 4G-1
+ @@overflow4g:
cmp esi,eax
jbe @@e820_loop ; at or below maximum
It still makes HimemX lie in this specific situation, but at least it's
limited to only this one single situation when user wants to clamp at
exactly 4G, instead of lying all the time (and it solved the "clamp to
0" case).
Mateusz
Rod Pemberton
Nov 21, 2015, 5:12:45 PM11/21/15
to
On Sat, 21 Nov 2015 02:20:08 -0500, Mateusz Viste <mateusz.viste@localhost> wrote:
> Since you are the author of significant fixes to HimemX, would you like
> to participate in the "HimemX revival" project on sourceforge? You'd
> have a direct write access to svn then.
>
I don't currently have anything else to contribute. I haven't needed
> Since you are the author of significant fixes to HimemX, would you like
> to participate in the "HimemX revival" project on sourceforge? You'd
> have a direct write access to svn then.
>
anything else so far. But, if I do come up with something, I'll let
you know. If I pick it back up again, I'll start with your updated
version.
The only things I had considered doing were:
1) converting sources to old NASM v0.98.39
2) eliminating non-E820 memory detection code
#1 was to ensure that it could _always_ be compiled and worked on since
Japheth's updates to OpenWatcom's WASM caused some assembly failures.
E820h has been around since the mid 1990's (1996 ACPI). #2 would require
a device driver or TSR to emulate E820 on older machines. I'm not sure
this is worth doing. The idea was to reduce the size of HIMEMX slightly
for DOS computers after 1996 since E820h support is now widespread.
Rod Pemberton
Nov 21, 2015, 5:12:51 PM11/21/15
to
On Sat, 21 Nov 2015 10:16:48 -0500, Mateusz Viste <mateusz.viste@localhost> wrote:
> I looked at your patch. If I understand it right, what you do is
> basically that you convert kilobytes from the /MAX parameter to bytes
> first (shl 10), and then you subtract one byte. So at the end of the
> day, when the user wants to clamp e820 at 8K, HimemX will in fact 'lie',
> and clamp at 8191 bytes (ie. 8K - 1 byte).
>
> The advantage is that the user can clamp at 4G now (which will be in
> fact 4G - 1 byte).
>
> Am I getting this right?
Probably ... IIRC, 4GB wouldn't fit the 32-bit integer.
> I looked at your patch. If I understand it right, what you do is
> basically that you convert kilobytes from the /MAX parameter to bytes
> first (shl 10), and then you subtract one byte. So at the end of the
> day, when the user wants to clamp e820 at 8K, HimemX will in fact 'lie',
> and clamp at 8191 bytes (ie. 8K - 1 byte).
>
> The advantage is that the user can clamp at 4G now (which will be in
> fact 4G - 1 byte).
>
> Am I getting this right?
I haven't looked at the code in years and don't recall how any of it works.
> If so, then maybe would there be a cleaner way to solve the eax overflow
> at 4G issue?
> Also, what if the user would want to clamp at 0K? In such
> corner case, HimemX would clamp at 4G - 1 instead, which might be
> considered a bug.
> What about, say, replacing your one line fix by something like that?
>
> --- himemx.asm (revision 29)
> +++ himemx.asm (working copy)
> @@ -3660,7 +3660,11 @@
> mov eax,[_xms_max]
> or eax,eax
> je @@e820_loop ; no maximum XMS set
> - shl eax,10
> + shl eax,9
> + shl eax,1 ; of guaranteed to change only on 1 shifts
> + jno @@overflow4g ; no overflow, so clamping on != 4G
> + dec eax ; sub 1 from eax, hence switch it to 4G-1
> + @@overflow4g:
> cmp esi,eax
> jbe @@e820_loop ; at or below maximum
I can't ever remember how overflow (OF) gets set. So, I'm not sure
if the use of OF here is correct ...
x86 Shift SAL/SAR/SHL/SHR
http://qcd.phys.cmu.edu/QCDcluster/intel/vtune/reference/vc283.htm
That seems to indicate OF is MSB for SHR, but OF is XOR of CF and
MSB for SHL or SAL. Is that what you want here? I.e., won't that
cause other values near 4GB to set OF also?
What about comparing eax with 4194304 (400000h) prior to the shift
and conditionally decrementing eax prior to the shift?
> It still makes HimemX lie in this specific situation, but at least it's
> limited to only this one single situation when user wants to clamp at
> exactly 4G, instead of lying all the time (and it solved the "clamp to
> 0" case).
FYI, I know some of the code can't addresses over 4GB, e.g., E820h
segments with addresses above 4GB. The original HIMEMX had no support
for values bigger than 32-bits in size. I have no plans or use for
supporting more memory. That would probably require a rewrite of
the internal data and related code.
0 new messages