[Freedos-devel] OpenWatcom 1.9 for DOS -- smaller DOS-only .7z package

[Rugxulo]

Hi,
(cc'ing freedos-devel since they may be interested)

Okay, I finally made a DOS-only .7z for OpenWatcom 1.9. (Only a year
after their release and two years since 1.8 .7z, heh.)

http://www.openwatcom.org/index.php/C_Compilers_Release_Changes

(Note that I don't know why they say "by default DOS LFN support is
enabled", that's false, in my experience. It only seemed to work in
16-bit code when using /d__WATCOM_LFN__ . The compiler proper doesn't
support it!)

It's only 7 MB (compressed), approx. 45 MB unpacked (not counting FAT
cluster waste), about 1500 files! It's "full", everything for DOS
(host and target, C and C++, 16-bit and 32-bit, runtime sources,
examples, help files). And yes, I actually tested it (DOSEMU ftw!), so
it works. ;-) It needs approx. 16 MB to unpack, but that should be
minimal enough for anyone these days. (Besides, use p7zip or 7zdecode
via DJGPP + CWSDPMI and you can swap 'til the cows come home.) I
assume this is more pleasant than downloading 80 MB .EXE installer
(see iBiblio) which you don't need, esp. for those who still have
dialup or slow connections (or minimalists, heh).

https://sites.google.com/site/rugxulo/ow19dos.7z?attredirects=0&d=1

This is really only a temporary spot since I don't have anywhere
better to put it. I don't promise I'll keep it here forever! :-)
Feel free to mirror it somewhere else. (Apparently RapidShare requires
"free" registration nowadays, ugh. So annoying.)

I am! :)
I am late, but definitely interested.
I have downloaded the package, and I see it has lots of things inside
(not just pure DOS stuff).
I was wondering if you had come across the smallest ever OpenWatcom
1.9 for DOS compatible distribution.

[Edwin Rhodes]

Hello I am trying to find watcom tcpip drivers and utils to connect a 286
running dos 5 to the internet I have an 3c509 card packet driver and neeed
watcom tcp where can I get watcom tcp? Thanks ed

[Rugxulo]

Hi, quick reply, (others know way more than I do here),

Post by Edwin Rhodes
Hello I am trying to find watcom tcpip drivers and utils to connect a 286
running dos 5 to the internet I have an 3c509 card packet driver and neeed
watcom tcp where can I get watcom tcp? Thanks ed

I guess you mean WATTCP here (and not something else, mTCP ??):

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/wattcps.zip
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/pkgs/wattcpx.zip

But also be sure to check this out (still being developed! GPL! Mike
is a member of this list!) because it actually compiles with
OpenWatcom. ;-)

http://code.google.com/p/mtcp/

[Bernd Blaauw]

Post by Rugxulo
Hi, quick reply, (others know way more than I do here),

http://www.crynwr.com/

should do the trick for packet drivers.


Loading method:
* find correct packet driver for your network interface card
* load it (usually type its name, sometimes specific options required)
* create configuration file for WATTCP32 or MTCP
* set configuration variable pointing to this file's directory.
* optionally run a DHCP client program to gain IP address from your
router or ISP
* Run internet using program.

Have fun experimenting with MTCP on your machine :)

I've got no experience with DOSPPP (phoneline modem program) whatsoever.
Already had ADSL/Cable connection when experimenting with DOS + internet :)

[Michael B. Brutman]

Thanks for the plugs for mTCP - I am buried in work and away from email
for a good part of the day.

There are a lot more WATTCP apps out there because WATTCP has been
around a lot longer, and there is a benefit to that long term
stability. I think that I have covered the more popular applications in
mTCP so far, with the exception of htget or wget. If you can think of
others let me know.

Also, Ulrich has done a great job putting together a FreeDOS networking
sampler (http://lazybrowndog.net/freedos/virtualbox/) for anybody who
needs to try it out or look at configuration files for help. It
includes WATTCP and mTCP apps. (mTCP has been updated a few times since
that was created, but it is close enough.)


Mike

[François Revol]

Post by Michael B. Brutman
Thanks for the plugs for mTCP - I am buried in work and away from email
for a good part of the day.
There are a lot more WATTCP apps out there because WATTCP has been
around a lot longer, and there is a benefit to that long term
stability. I think that I have covered the more popular applications in
mTCP so far, with the exception of htget or wget. If you can think of
others let me know.

Any of those two supports IPv6 ? So FreeDOS can survive the IPcalypse :D

François.

[Bernd Blaauw]

Post by François Revol
Any of those two supports IPv6 ? So FreeDOS can survive the IPcalypse :D

Don't think so.

Stuff I can think of which is missing:
1) WGET/CURL
2) WOL-client to wake up machines in the network by sending magic packet
3) IP v6
4) Jumboframes (9000 bytes I think it was?) as MTU

As for the usual rhetoric: "it's opensource, patches welcome, fix it
yourself if you want more" hehe :)
Or wait till Michael has time and sees use in adding these things.

As FTP.EXE is a DOS program, and DOS is singletasking anyway, I wonder
if it uses as big a buffer as it can possibly get (for simplicity's
sake, all available conventional memory, not bothering with XMS/EMS etc
as it's a 8086 app) and use it in a beneficial way to speed things up.
Or maybe it might be limited to a partial buffer, or not benefit from
going over a specific buffer size.

[Rugxulo]

Hi,

Post by Bernd Blaauw

Post by François Revol
Any of those two supports IPv6 ? So FreeDOS can survive the IPcalypse :D

Don't think so.
1) WGET/CURL

I guess you mean Mike plans to write something like this one day. We
do already have a port of WGET (via DJGPP), but I've not heavily
tested it. (Or did you mean one with IPv6 support?? Dunno ...)

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/wget/

[Bernd Blaauw]

Post by Rugxulo
I guess you mean Mike plans to write something like this one day. We
do already have a port of WGET (via DJGPP), but I've not heavily
tested it. (Or did you mean one with IPv6 support?? Dunno ...)
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/wget/

Ooh thanks for that one mate!
Thought everything was still stuck at 1.8 like in FreeDOS 1.0, I'll
update the package on my CD.

But yeah ment Mike's version. The existing DJGPP versions are rather
huge (1.8 at 400KB, your linked zip at 800KB). That's not helping a "hey
let's boot from floppy, configure internet access and install from
downloaded/mounted ISO file"

I wonder if your Watcom package can be converted into a self-hosting
bootable compiling platform. Gives me something to mess around with,
trying to get that working.

[Rugxulo]

Hi,

Post by Bernd Blaauw

Post by Rugxulo
I guess you mean Mike plans to write something like this one day. We
do already have a port of WGET (via DJGPP), but I've not heavily
tested it. (Or did you mean one with IPv6 support?? Dunno ...)
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/wget/

But yeah ment Mike's version. The existing DJGPP versions are rather
huge (1.8 at 400KB, your linked zip at 800KB).

UPX it. Or just rebuild it (I've not tried), esp. with "smaller" DJGPP
2.03p2. Check the linker map, it should tell you where the biggest .o
files are. But yes, DJGPP's libc leaves a lot to be desired in small
size. (--gc-sections doesn't work for COFF.) Might be better to
rebuild (if possible, probably unlikely due to POSIX crud) with
OpenWatcom.

BTW, somebody mentioned HTGET, which we have also (though I haven't tried it):

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/htget/

I also can't help but wonder if something like w3m would build. Bah,
too curious for my own good. ;-)

Post by Bernd Blaauw
That's not helping a "hey
let's boot from floppy, configure internet access and install from
downloaded/mounted ISO file"

Floppies just don't hold enough. Add to that the fact that they fail
semi-frequently, and you have a lose/lose combination which makes
everybody hate them (and soon they will be officially obsolete, ugh).

Post by Bernd Blaauw
I wonder if your Watcom package can be converted into a self-hosting
bootable compiling platform. Gives me something to mess around with,
trying to get that working.

Well, you need FreeCOM buildable too, and I don't see any new releases
with Bart's patches (guess it's in SVN?). Other than that, it just
depends on what else you need.

[François Revol]

Post by Rugxulo

Post by Bernd Blaauw
That's not helping a "hey
let's boot from floppy, configure internet access and install from
downloaded/mounted ISO file"

Floppies just don't hold enough. Add to that the fact that they fail
semi-frequently, and you have a lose/lose combination which makes
everybody hate them (and soon they will be officially obsolete, ugh).

http://www.torlus.com/floppy/

François.

[Rugxulo]

Hi,

Post by François Revol

Post by Rugxulo

Post by Bernd Blaauw
That's not helping a "hey
let's boot from floppy, configure internet access and install from
downloaded/mounted ISO file"

Floppies just don't hold enough. Add to that the fact that they fail
semi-frequently, and you have a lose/lose combination which makes
everybody hate them (and soon they will be officially obsolete, ugh).

http://www.torlus.com/floppy/

Good to know (SD card reader / USB floppy emulator hardware), but
there's still probably some drawbacks.

I've got a USB floppy drive, and it works with FreeDOS, but other
non-BIOS-using OSes need special drivers for it (e.g. Minix3 won't
work). Even WinXP I think only supports 1.44 MB (and not
overformatted) re: USB floppy. But I did read that latest Haiku (BeOS
clone) alpha supports USB floppy drives now. ;-)

The real point is I think I'm one of the last to care about floppies.
:-( Soon floppy images will really only be usable for emulators
(which is better than nothing, but it's still annoying).

P.S. I've noticed some people here (Bernd?) talking about 360 kb
floppies as if they intend to (try to) support it for FreeDOS 1.1. I
don't know, you can do whatever you want, but I honestly don't know of
many people with anything less than 1.44 MB anymore. Anyways, Jim Hall
has already indicated that floppies aren't interesting to him (both he
and I agree they're almost dead, sadly), so I'm not sure he thinks
it's worth wasting our time. (I just like making self-contained
floppies for certain purposes, heh, e.g. that old Christmas Wolf4GW /
Wolf4SDL one). Probably better / easier to just make a script to build
one from scratch by downloading the appropriate tools first or just
only publish bootup / config files.)

Anyways ....

[François Revol]

Post by Rugxulo

Post by François Revol
http://www.torlus.com/floppy/

Good to know (SD card reader / USB floppy emulator hardware), but
there's still probably some drawbacks.
I've got a USB floppy drive, and it works with FreeDOS, but other
non-BIOS-using OSes need special drivers for it (e.g. Minix3 won't

That's the thing, it emulates the floppy *drive* and its signals, not
the controller, and plugs in on the shuggart interface.

It just presents floppy image files from the SD card as real floppies to
the FD controllers.

François.

[Jim Michaels]

how on earth shall I expect to build a bootable ISO image with mkisofs?

 

________________________________
Sent: Tuesday, July 5, 2011 1:23 AM
Subject: Re: [Freedos-devel] watcom tcp
Hi,

Post by Bernd Blaauw

Post by Rugxulo
I guess you mean Mike plans to write something like this one day. We
do already have a port of WGET (via DJGPP), but I've not heavily
tested it. (Or did you mean one with IPv6 support?? Dunno ...)
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/wget/

But yeah ment Mike's version. The existing DJGPP versions are rather
huge (1.8 at 400KB, your linked zip at 800KB).

UPX it. Or just rebuild it (I've not tried), esp. with "smaller" DJGPP
2.03p2. Check the linker map, it should tell you where the biggest .o
files are. But yes, DJGPP's libc leaves a lot to be desired in small
size. (--gc-sections doesn't work for COFF.) Might be better to
rebuild (if possible, probably unlikely due to POSIX crud) with
OpenWatcom.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/net/htget/
I also can't help but wonder if something like w3m would build. Bah,
too curious for my own good.  ;-)

Post by Bernd Blaauw
That's not helping a "hey
let's boot from floppy, configure internet access and install from
downloaded/mounted ISO file"

Floppies just don't hold enough. Add to that the fact that they fail
semi-frequently, and you have a lose/lose combination which makes
everybody hate them (and soon they will be officially obsolete, ugh).

Post by Bernd Blaauw
I wonder if your Watcom package can be converted into a self-hosting
bootable compiling platform. Gives me something to mess around with,
trying to get that working.

Well, you need FreeCOM buildable too, and I don't see any new releases
with Bart's patches (guess it's in SVN?). Other than that, it just
depends on what else you need.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Steve Nickolas]

Post by Jim Michaels
how on earth shall I expect to build a bootable ISO image with mkisofs?

Put a boot floppy image in the folder and use
mkisofs -b filename.144 -o filename.iso path/

[Bernd Blaauw]

Post by Steve Nickolas

Post by Jim Michaels
how on earth shall I expect to build a bootable ISO image with mkisofs?

Put a boot floppy image in the folder and use
mkisofs -b filename.144 -o filename.iso path/

And isolinux as bootloader, instead of direct floppy emulation:

mkisofs -boot-info-table -no-emul-boot -b isolinux/isolinux.bin -o
C:\MAKEISO\SHELL\ISOLINUX\FDBOOTCD.ISO C:\MAKEISO\CONTENTS

I'd recommend to download some FreeDOS ISO to analyse directory layout
and file contents :)

C:\MAKEISO (final ISO might end up here)
C:\MAKEISO\SHELL (autorun.inf goes here)
C:\MAKEISO\SHELL\ISOLINUX (1st ISO might end up here, also
isolinux.bin/isolinux.cfg, fdboot.img)
C:\MAKEISO\CONTENTS (autorun.inf, setup.bat etc)
C:\MAKEISO\CONTENTS\FREEDOS (FreeDOS stuff)
C:\MAKEISO\CONTENTS\ISOLINUX (isolinux.bin/isolinux.cfg, also fdboot.img)


Basically you can make it as complex as you like:
* easiest: direct floppy emulation (as Steve showed)
* harder: isolinux bootable ISO image (FreeDOS 1.0 for example)
* complex: FreeDOS 1.1 double ISO
* hard: adding Syslinux menu's, utilities, modules etc

I've yet to analyse PartedMagic ISO to see how they manage to get such a
nice bootmenu.

[Jim Michaels]

there is a freedos (actually available to all as just a library for other compilers) library called TurboVision.
If you remember Central Point Software's stuff and Borland's compiler, this came from Borland's compiler.
has buttons, movable, closable windows, controls, etc. and you can make your own custom controls.
I happen to have documentation on TurboVision, but that's not much help on using the library because it's very poorly documented.
it is an old C++ framework based on classes I think.
the library is usually nameed tv-something.

 
-----------------------------------------------------
Jim Michaels
***@yahoo.com
***@JimsComputerRepairandWebDesign.com
http://JimsComputerRepairandWebDesign.com
http://JesusnJim.com (my personal site, has software)
-------
Computer memory/disk size measurements:
[KB KiB] [MB MiB] [GB GiB] [TB TiB]
[10^3B=1,000B=1KB][2^10B=1,024B=1KiB]
[10^6B=1,000,000B=1MB][2^20B=1,048,576B=1MiB]
[10^9B=1,000,000,000B=1GB][2^30B=1,073,741,824B=1GiB]
[10^12B=1,000,000,000,000B=1TB][2^40B=1,099,511,627,776B=1TiB]
Note: disk size is measured in MB, GB, or TB, not in MiB, GiB, or TiB.  computer memory (RAM) is measured in MiB and GiB.

________________________________
Sent: Wednesday, July 6, 2011 4:27 AM
Subject: Re: [Freedos-devel] watcom tcp

Post by Steve Nickolas

Post by Jim Michaels
how on earth shall I expect to build a bootable ISO image with mkisofs?

Put a boot floppy image in the folder and use
    mkisofs -b filename.144 -o filename.iso path/

mkisofs -boot-info-table -no-emul-boot -b isolinux/isolinux.bin -o
C:\MAKEISO\SHELL\ISOLINUX\FDBOOTCD.ISO C:\MAKEISO\CONTENTS
I'd recommend to download some FreeDOS ISO to analyse directory layout
and file contents :)
C:\MAKEISO (final ISO might end up here)
C:\MAKEISO\SHELL (autorun.inf goes here)
C:\MAKEISO\SHELL\ISOLINUX (1st ISO might end up here, also
isolinux.bin/isolinux.cfg, fdboot.img)
C:\MAKEISO\CONTENTS (autorun.inf, setup.bat etc)
C:\MAKEISO\CONTENTS\FREEDOS (FreeDOS stuff)
C:\MAKEISO\CONTENTS\ISOLINUX (isolinux.bin/isolinux.cfg, also fdboot.img)
* easiest: direct floppy emulation (as Steve showed)
* harder: isolinux bootable ISO image (FreeDOS 1.0 for example)
* complex: FreeDOS 1.1 double ISO
* hard: adding Syslinux menu's, utilities, modules etc
I've yet to analyse PartedMagic ISO to see how they manage to get such a
nice bootmenu.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Michael B. Brutman]

Post by Bernd Blaauw

Post by François Revol
Any of those two supports IPv6 ? So FreeDOS can survive the IPcalypse :D

Don't think so.
1) WGET/CURL
2) WOL-client to wake up machines in the network by sending magic packet
3) IP v6
4) Jumboframes (9000 bytes I think it was?) as MTU
As for the usual rhetoric: "it's opensource, patches welcome, fix it
yourself if you want more" hehe :)
Or wait till Michael has time and sees use in adding these things.
As FTP.EXE is a DOS program, and DOS is singletasking anyway, I wonder
if it uses as big a buffer as it can possibly get (for simplicity's
sake, all available conventional memory, not bothering with XMS/EMS etc
as it's a 8086 app) and use it in a beneficial way to speed things up.
Or maybe it might be limited to a partial buffer, or not benefit from
going over a specific buffer size.

[1] A fully featured wget will be difficult to get into the memory
space. I have plans for a simple version that does not recurse, does
not support Unicode, etc.

[2] WOL-client. Pretty easy, but seems to be of limited use.

[3] IPv6 - this is very feasible. I started looking at it a few years
ago but did not start coding because IPv6 is not widespread enough for
me to test effectively. (I have my own network, but I'm waiting for
broader ISP support.) With IPv6 we will survive the IPocalypse. :-) [
François - loved that! ]

[4] Jumboframes - unlikely. That's a packet driver issue and none of
the packet drivers support jumbo frames. I can change the maximum frame
size fairly easily (it is a #define) but without packet driver support
it is moot. (Some of the newer cards have packet drivers with source
code available, so maybe it is not so bad.)

There are other issues with jumbo frames. We might be able to support
them, but getting the performance out of them will be close to
impossible with the way packet drivers work. If you hardware can do
jumbo frames it might be a better candidate for a small Linux.


FTP uses buffer sizes around 8KB in size, and it is adjustable with an
environment variable. 1KB was too small. 4KB was far better. 16 and
32KB give marginal improvements. I chose 8KB as a compromise. (Look at
the docs for the environment variables.)


Mike

[Bernd Blaauw]

Post by Michael B. Brutman
[1] A fully featured wget will be difficult to get into the memory
space. I have plans for a simple version that does not recurse, does
not support Unicode, etc.

Ah good news.
Basicly FTP.EXE already suffices, except for the following:
* FTP-only, no http/https
* requires entering commands or external script as input
* no renaming for storing (www.mysite.com/somelongfilename.zip -->
c:\short.zip)

Post by Michael B. Brutman
[2] WOL-client. Pretty easy, but seems to be of limited use.

It's limited indeed, like starting up a fileserver to store files or
retrieve backups. Still has its uses occasionally.

Post by Michael B. Brutman
[3] IPv6 - this is very feasible. I started looking at it a few years
ago but did not start coding because IPv6 is not widespread enough for
me to test effectively. (I have my own network, but I'm waiting for
broader ISP support.) With IPv6 we will survive the IPocalypse. :-) [
François - loved that! ]

Testing IPv6 isn't that easy indeed. Native stuff, tunnels, fallbacks.
Ouch..

Post by Michael B. Brutman
There are other issues with jumbo frames. We might be able to support
them, but getting the performance out of them will be close to
impossible with the way packet drivers work. If you hardware can do
jumbo frames it might be a better candidate for a small Linux.

ah good to know. So, is the application or the packet driver responsible
for setting speeds in DOS btw?

Post by Michael B. Brutman
FTP uses buffer sizes around 8KB in size, and it is adjustable with an
environment variable. 1KB was too small. 4KB was far better. 16 and
32KB give marginal improvements. I chose 8KB as a compromise. (Look at
the docs for the environment variables.)

I've not looked at sourcecode yet. Currently busy with
1) Update script to recreate ISO from bootdisk/bootcd + optional
modifications, preferably without touching physical disks.
2) Getting the startup script to mount CD/ISO/RAM properly
3) Avoiding file corruption

[Michael B. Brutman]

Post by Bernd Blaauw
Ah good news.
* FTP-only, no http/https
* requires entering commands or external script as input
* no renaming for storing (www.mysite.com/somelongfilename.zip -->
c:\short.zip)

mTCP FTP does support this. The full syntax for the get command is:

get <server_file> [<local_name>]

And for the put command:

put <local_name> [<server_file>]

The second parameter is optional and allows you to do the rename. This
is similar to Unix command line clients.

Post by Bernd Blaauw

Post by Michael B. Brutman
There are other issues with jumbo frames. We might be able to support
them, but getting the performance out of them will be close to
impossible with the way packet drivers work. If you hardware can do
jumbo frames it might be a better candidate for a small Linux.

ah good to know. So, is the application or the packet driver responsible
for setting speeds in DOS btw?

I think a better way to put it is that the packet driver design was not
intended for 100Mb or Gigabit speed, and that the packet driver design
becomes a limiting factor.

For each packet you send you need to cause a software interrupt. For
each packet received you need to take two software interrupts in
addition to any hardware interrupts. For receiving packets a more
advanced design would take the initial interrupt and then poll for a
little bit to see if there were other packets to process, and for
sending packets you would point to a list of buffer descriptors and just
use one interrupt.

On a low end Pentium system I've been able to get about 50% of the full
line speed on a 100Mb PCI adapter. That system should have been able to
saturate the line ...



Mike

[Bernd Blaauw]

Post by Michael B. Brutman
The second parameter is optional and allows you to do the rename. This
is similar to Unix command line clients.

Tested tonight, works like a charm :)
Confusingly, I've now got trouble getting WGET working, as I had the
intention of downloading from fastest server I could find, using
1) FireFox 5 browser (win32, on Windows 7 Ultimate x64, Q6600 CPU)
2) WGET (WATTCP, FreeDOS 1.1, PCNTPK, VMware Workstation 7.1)
3) FTP (MTCP, FreeDOS 1.1, PCNTPK, VMware Workstation 7.1)

Starting with Ibiblio wasn't so smart, ended up below 300KB in all cases.

Post by Michael B. Brutman
On a low end Pentium system I've been able to get about 50% of the full
line speed on a 100Mb PCI adapter. That system should have been able to
saturate the line ...

ftp://ftp.xs4all.nl/pub/test/10mb.bin :
1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription)
2) N/A , WGET not working
3) 500Kbyte/second ( around 4Mbit/s)

Trying to get FTP.EXE working with WGET syntax is funny.
Limitation: servername has "//" prepended to it which ftp.exe doesn't like.

Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter
(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).

Request:
* FTP accepting "//" in front of a servername
* DHCP starting MTCP.CFG writes on a newline
* DHCP: different errorlevels for various situations instead of
errorlevel 1 on all errors? aka "how to determine if packet driver still
needs to be loaded"

Bernd

-- download.bat/wget.bat --


@echo off
goto begin

:begin
rem No way yet to handle "server/dir/file -o filename"
for %%x in ( 1 2 3 4 5 6 7 8 9 ) do if not "%%%x"=="" echo arg%%x: %%%x
if "%1"=="-o" goto output
if "%1"=="ftp:" goto next
rem help/error/instruction message
goto error

:output
rem get rid of "-o" in "-o filename server/dir/file"
shift
if "%1"=="ftp:" goto begin
rem -o was followed by filename (no path allowed, just 8.3 filename)
set out=%1
rem get rid of filename as well
shift
goto begin

:next
rem get rid of "ftp:" meaning you end up with "servername/dir/filename"
shift
if "%out%"=="" set out=out.bin
if exist %out% del %out%
if exist tmp.txt del tmp.txt
echo Time to write a nice script
echo anonymous> tmp.txt
rem Yay contact e-mail annex awesome spam filter
echo ***@gmail.com>> tmp.txt
echo binary>> tmp.txt
echo xfermode passive>> tmp.txt
echo get %2%3%4%5%6%7%8%9 %out%>> tmp.txt
rem FTP accepting/stripping "//" before a ftp server name would be
convenient.
rem allowing "FTP %1 < tmp.txt"
ftp ftp.xs4all.nl < tmp.txt
goto succes

:succes
echo File downloaded and written to local disk as %out%
set out=
goto end

:error
echo Please start download URL with: ftp://
echo (e.g. ftp://ftp.xs4all.nl/pub/test/10mb.bin)
goto end

:end
echo Program finished

[Michael B. Brutman]

Post by Bernd Blaauw
1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription)
2) N/A , WGET not working
3) 500Kbyte/second ( around 4Mbit/s)

mTCP FTP compares poorly to the native stack and FireFox there, but FTP
is working in a very limited environment:

* The TCP/IP socket receive buffer is tiny compared to the native
network stack
* You are doing filesystem writes 8KB at a time
* You have a small virtualization penalty
* The packet interface wasn't designed for high performance; every
incoming packet requires a hardware interrupt and two software
interrupts

But for older machines, it is more than adequate. I'll try a few tests
here - I also test under VMware, VirtualBox, and DOSBox but I never
thought to compare the performance to the native TCP/IP stack.

Did you set the MTU size to 1500 in the configuration file? If you did
not, that will dramatically improve the speed.

Post by Bernd Blaauw
Trying to get FTP.EXE working with WGET syntax is funny.
Limitation: servername has "//" prepended to it which ftp.exe doesn't like.

That funny URI syntax was grafted on. What exact URI are you using?
Are you adding "ftp://" or just "//" ?

Post by Bernd Blaauw
Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter
(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).

Can you explain this in more detail? If you were missing a proper CR/LF
at the end of a line then the C runtime would not have recognized the
start of the next line, and that line would be effectively lost. This
happens if you use an editor that doesn't use the CR/LF convention. (I
often make this mistake when using VI under Cygwin.)

I could recognize both CR/LF and LF in the parsing code to improve
things when you are in a mixed environment. But all of the code that
reads the configuration file would have to change too, not just DHCP.
That really has the flavor of a user error.

Post by Bernd Blaauw
* FTP accepting "//" in front of a servername
* DHCP starting MTCP.CFG writes on a newline
* DHCP: different errorlevels for various situations instead of
errorlevel 1 on all errors? aka "how to determine if packet driver still
needs to be loaded"
Bernd

For the first request I think that I have to look for either "ftp://" or
just "//" to be correct. The second request might be considered a user
error. And for the third I will definitely put that on the todo list;
the error messages already indicate if the packet driver is not loaded
but I can set errorlevel too.


Mike

[Bernd Blaauw]

Post by Michael B. Brutman
mTCP FTP compares poorly to the native stack and FireFox there, but FTP
* The TCP/IP socket receive buffer is tiny compared to the native
network stack
* You are doing filesystem writes 8KB at a time
* You have a small virtualization penalty
* The packet interface wasn't designed for high performance; every
incoming packet requires a hardware interrupt and two software
interrupts

I'm happy with whatever I can get. My real hardware has an Nvidia
chipset network driver for which no packet drivers exist, so sticking to
virtual machines. I wonder if any PCI (or even PCI-express or onboard)
network cards still support packet drivers.

8KB filesystem writes? odd. So it's:
1) download/transfer 8KB (8KB transfer buffer)
2) halt download, dump transfer buffer to disk and clear it
3) continue downloading.

Easier at least compared to having a 8KB transfer buffer plus a 'huge'
receive buffer (nearly size of all of machine's conventional memory, a
multiple of 8KB?) followed by only clearing the buffer if it's full or a
file has been downloaded completely (whichever comes first). Your single
buffer might be more efficient compared to transfer buffer plus receive
buffer.

Or perhaps I should stay silent hehe, failed miserably while learning
about OSI layers and TCP/IP.

Post by Michael B. Brutman
But for older machines, it is more than adequate. I'll try a few tests
here - I also test under VMware, VirtualBox, and DOSBox but I never
thought to compare the performance to the native TCP/IP stack.

It's more than adequate indeed, I'm not complaining hehe. Only wanted to
start out by eliminating slow servers as potential bottleneck. The
listed ftp://ftp.xs4all.nl/pub/test/10mb.bin should be same for everyone
as it's intended by that ISP for speedtest purposes.

Post by Michael B. Brutman
Did you set the MTU size to 1500 in the configuration file? If you did
not, that will dramatically improve the speed.

Yep, did so.

Post by Michael B. Brutman
That funny URI syntax was grafted on. What exact URI are you using? Are
you adding "ftp://" or just "//" ?

FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments
at the "/" level. See the "FOR LOOP" in my batchfile, with batchfile
called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin

resulting in:
ftp.exe //ftp.xs4all.nl
(on which it chokes, not knowing how to handle //).

Basicly there are 2 options:
1) find a way to strip the prepending "//" before feeding to FTP
2) allow FTP to accept them and strip it themselves, requiring code changes.

Post by Michael B. Brutman

Post by Bernd Blaauw
Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter
(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).

Can you explain this in more detail? If you were missing a proper CR/LF
at the end of a line then the C runtime would not have recognized the
start of the next line, and that line would be effectively lost. This
happens if you use an editor that doesn't use the CR/LF convention. (I
often make this mistake when using VI under Cygwin.)

Using mostly NOTEPAD in Windows, or ECHO bla > output.txt in DOS.
DHCP writes everything on newlines (as expected) except the first line
it writes (ip address). I don't know if there's any solution except
maybe writing a space, then start on newline. Best case you get an empty
line in between, worst case no empty line but still working.

Post by Michael B. Brutman
I could recognize both CR/LF and LF in the parsing code to improve
things when you are in a mixed environment. But all of the code that
reads the configuration file would have to change too, not just DHCP.
That really has the flavor of a user error.

Yeah easier to have a batchfile do ECHO PACKETINT 0x60 > %mtcpcfg%

Post by Michael B. Brutman
For the first request I think that I have to look for either "ftp://" or
just "//" to be correct. The second request might be considered a user
error. And for the third I will definitely put that on the todo list;
the error messages already indicate if the packet driver is not loaded
but I can set errorlevel too.

I don't mind if it's // or ftp.exe you look for, all it results in is me
having to do either:
* "FTP %1%2 < input.txt" (in case of checking for ftp://)
* "FTP %2 < input.txt" (in case of checking for //)

For DHCP I can imagine various errorlevels for different reasons:
* missing MTCPCFG variable
* MTCPCFG variable points to non-existing file
* missing PACKETINT keyword in file
* unable to write to MTCPCFG file (yay hidden/readonly)
* packetdriver not loaded yet
* static config found in MTCPCFG file
* time out (no DHCP server found)
* what else? invalid MTU size?

Bernd

[Eric Auer]

Hi Bernd,

Post by Bernd Blaauw
I'm happy with whatever I can get. My real hardware has an Nvidia
chipset network driver for which no packet drivers exist, so sticking to
virtual machines. I wonder if any PCI (or even PCI-express or onboard)
network cards still support packet drivers.

You probably can still find many RTL8139 PCI cards almost for free
in second hand shops. Also, there are NDIS wrappers and ODI drivers
for example for at least older nFORCE MCP chipsets and I think you
could use them with generic NDIS or ODI to packet wrapper drivers.
Search for example for NDIS_452 or for NVODI (ca 2001 to 2005).

Eric

[Michael B. Brutman]

Post by Bernd Blaauw

Post by Michael B. Brutman
mTCP FTP compares poorly to the native stack and FireFox there, but FTP
* The TCP/IP socket receive buffer is tiny compared to the native
network stack
* You are doing filesystem writes 8KB at a time
* You have a small virtualization penalty
* The packet interface wasn't designed for high performance; every
incoming packet requires a hardware interrupt and two software
interrupts

I'm happy with whatever I can get. My real hardware has an Nvidia
chipset network driver for which no packet drivers exist, so sticking to
virtual machines. I wonder if any PCI (or even PCI-express or onboard)
network cards still support packet drivers.
1) download/transfer 8KB (8KB transfer buffer)
2) halt download, dump transfer buffer to disk and clear it
3) continue downloading.

Not so odd. All comm code fills buffers and then processes the
buffers. Unless you have a multi-core system you are always halting the
processing of TCP/IP protocol handling to do your disk writes. Modern
OSes with DMA support hide some of that by letting the DMA controller of
the disk (and possibly the Ethernet controller if so equipped) do the
byte copying work. But in the absence of DMA the host CPU does
everything, and does it in a single threaded manner.

Post by Bernd Blaauw
Easier at least compared to having a 8KB transfer buffer plus a 'huge'
receive buffer (nearly size of all of machine's conventional memory, a
multiple of 8KB?) followed by only clearing the buffer if it's full or a
file has been downloaded completely (whichever comes first). Your single
buffer might be more efficient compared to transfer buffer plus receive
buffer.
Or perhaps I should stay silent hehe, failed miserably while learning
about OSI layers and TCP/IP.

I suspect that the Intel chipsets on PCI-X cards will work; their PCI
chipset cards had working packet drivers and from a software standpoint
PCI-X is identical to PCI. On the wiki at the Google project page I
have three different PCI cards listed that are known to work. (And I'd
like to hear about more.)

In this environment we are entirely single threaded, except for the
hardware buffering that happens on the Ethernet card. To receive a
packet the path looks like this:

- the card receives and buffers the frame from the wire
- the card signals a hardware interrupt
- the packet driver responds and either interrogates the card or copies
the contents of the frame
- the packet driver makes an upcall to the TCP/IP code
- the TCP/IP code either provides a buffer or says 'no room'
- the packet driver makes a second upcall to let the TCP/IP code know
the frame is copied
- the interrupt ends and the interrupted code resumes
- the packet must now go through IP and TCP protocol processing

The buffering scheme works at three levels:

- Raw packet buffers (20 at 1514 bytes)
- TCP receive buffering (8KB)
- File read/write chunk size (8KB)

Raw packet buffers are used by the packet driver directly. They are the
critical resource; if you run out of those you start dropping frames
coming in from the wire. TCP buffering is designed to pull data from
those packet buffers as quickly as possible so that they may be
recycled. (In the case where you have a lot of small incoming packets
that is really critical because every incoming packet is allocated 1514
bytes whether it needs it or not.) The TCP buffer is organized as a
ring buffer so it is more space efficient.

The application reads from the TCP buffer and writes to the filesystem.
All of this is still single threaded and for most systems the bottle
neck is the disk access time, not the copying of data from multiple
buffers. At a minimum all reads and writes to the filesystem should be
done in multiples of 512 bytes; anything less requires DOS to do a
read/modify/write as it writes data to the blocks of the filesystem.
1KB reads and writes were very inefficient to do - after some
experimenting I found that 8KB was good. 16 or 32KB are marginally better.

The buffer sizes generally are not larger because larger does not make
that much of a difference in the performance of the filesystem writes
and does have a negative impact on buffering. Long writes delay TCP
protocol processing, causing incoming buffers to run low and delaying
the sending of ACK packets for the received data. The major opportunity
for improving performance is to send the ACK for the packet as quickly
as possible, right after TCP goes through protocol processing but before
the application tries to read the receive buffer and empty it. Getting
that ACK out early keeps the flow of data constant and hides some of the
latency the 'receive data/write data' cycle that is occurring.

Another optimization I could make to this would be to have the FTP
application handle the raw packet buffers directly. TCP would continue
to do protocol processing, but instead of copying the data to a TCP
receive buffer it would just give FTP the raw packets and let FTP do the
copying. This was the original design and the first netcat code used
this technique. The technique removes some memcpy overhead, but the
largest overhead comes from the filesystem write. It made the end
application code (FTP) more complex and error prone, and had a nasty
habit of starving the packet driver for buffers if the disk write was
too large.

Most of my testing is on lower-end machines, like a 386-40 and the
various 8088 machines that I have. The performance of memcpy is far
better on the newer processors due to pipeline efficiency and levels of
caching. (Even the 386-40 has a 128K L2 cache.) Disk becomes the major
bottleneck on the faster machines.

Post by Bernd Blaauw

Post by Michael B. Brutman
But for older machines, it is more than adequate. I'll try a few tests
here - I also test under VMware, VirtualBox, and DOSBox but I never
thought to compare the performance to the native TCP/IP stack.

It's more than adequate indeed, I'm not complaining hehe. Only wanted to
start out by eliminating slow servers as potential bottleneck. The
listed ftp://ftp.xs4all.nl/pub/test/10mb.bin should be same for everyone
as it's intended by that ISP for speedtest purposes.

Just for comparison, on my local network here the AMD 80386-40 clone
with an NE2000 adapter on a 10Mb segment is connected to a Pentium 233
running Fedora 2. My FTP receive speed on this network is 506KB/sec,
which is similar to what you are reporting for your virtual machine. My
Pentium 133 running with a PCI Ethernet card receives at 1950KB/sec,
which is almost four times faster than what you are reporting. Your VM
might be adding unnecessary overhead.


Mike

[Rugxulo]

Hi,
(yes, I tried trimming the quote, but it almost all seems vaguely
relevant, ugh)

At risk of embarrassing myself (again) by showing my ignorance ...

Mike, you said this: "Disk becomes the major bottleneck on the faster
machines."

Doesn't FTP know the filesize of file-to-be-downloaded ahead of time?
If so, then perhaps you can try Eric's idea:

* create/open, seek to end-1 (in the empty output file), write a
single byte, close, reopen

This apparently avoids having to update the FAT over and over again
redundantly. See the following thread for some examples (esp. nidud's
comment about Doszip: "This reduced the compression time from 455 to
180 sec.").

http://www.bttr-software.de/forum/board_entry.php?id=8862#p8879

I may be seriously off-base here (no surprise), but I felt I should
mention it "just in case"!

Post by Michael B. Brutman

Post by Bernd Blaauw

Post by Michael B. Brutman
mTCP FTP compares poorly to the native stack and FireFox there, but FTP
* The TCP/IP socket receive buffer is tiny compared to the native
network stack
* You are doing filesystem writes 8KB at a time
* You have a small virtualization penalty
* The packet interface wasn't designed for high performance; every
incoming packet requires a hardware interrupt and two software
interrupts

1) download/transfer 8KB (8KB transfer buffer)
2) halt download, dump transfer buffer to disk and clear it
3) continue downloading.

Not so odd. All comm code fills buffers and then processes the
buffers. Unless you have a multi-core system you are always halting the
processing of TCP/IP protocol handling to do your disk writes. Modern
OSes with DMA support hide some of that by letting the DMA controller of
the disk (and possibly the Ethernet controller if so equipped) do the
byte copying work. But in the absence of DMA the host CPU does
everything, and does it in a single threaded manner.

Post by Bernd Blaauw
Easier at least compared to having a 8KB transfer buffer plus a 'huge'
receive buffer (nearly size of all of machine's conventional memory, a
multiple of 8KB?) followed by only clearing the buffer if it's full or a
file has been downloaded completely (whichever comes first). Your single
buffer might be more efficient compared to transfer buffer plus receive
buffer.

In this environment we are entirely single threaded, except for the
hardware buffering that happens on the Ethernet card. To receive a
- the card receives and buffers the frame from the wire
- the card signals a hardware interrupt
- the packet driver responds and either interrogates the card or copies
the contents of the frame
- the packet driver makes an upcall to the TCP/IP code
- the TCP/IP code either provides a buffer or says 'no room'
- the packet driver makes a second upcall to let the TCP/IP code know
the frame is copied
- the interrupt ends and the interrupted code resumes
- the packet must now go through IP and TCP protocol processing
- Raw packet buffers (20 at 1514 bytes)
- TCP receive buffering (8KB)
- File read/write chunk size (8KB)
Raw packet buffers are used by the packet driver directly. They are the
critical resource; if you run out of those you start dropping frames
coming in from the wire. TCP buffering is designed to pull data from
those packet buffers as quickly as possible so that they may be
recycled. (In the case where you have a lot of small incoming packets
that is really critical because every incoming packet is allocated 1514
bytes whether it needs it or not.) The TCP buffer is organized as a
ring buffer so it is more space efficient.
The application reads from the TCP buffer and writes to the filesystem.
All of this is still single threaded and for most systems the bottle
neck is the disk access time, not the copying of data from multiple
buffers. At a minimum all reads and writes to the filesystem should be
done in multiples of 512 bytes; anything less requires DOS to do a
read/modify/write as it writes data to the blocks of the filesystem.
1KB reads and writes were very inefficient to do - after some
experimenting I found that 8KB was good. 16 or 32KB are marginally better.
The buffer sizes generally are not larger because larger does not make
that much of a difference in the performance of the filesystem writes
and does have a negative impact on buffering. Long writes delay TCP
protocol processing, causing incoming buffers to run low and delaying
the sending of ACK packets for the received data. The major opportunity
for improving performance is to send the ACK for the packet as quickly
as possible, right after TCP goes through protocol processing but before
the application tries to read the receive buffer and empty it. Getting
that ACK out early keeps the flow of data constant and hides some of the
latency the 'receive data/write data' cycle that is occurring.
Another optimization I could make to this would be to have the FTP
application handle the raw packet buffers directly. TCP would continue
to do protocol processing, but instead of copying the data to a TCP
receive buffer it would just give FTP the raw packets and let FTP do the
copying. This was the original design and the first netcat code used
this technique. The technique removes some memcpy overhead, but the
largest overhead comes from the filesystem write. It made the end
application code (FTP) more complex and error prone, and had a nasty
habit of starving the packet driver for buffers if the disk write was
too large.
Most of my testing is on lower-end machines, like a 386-40 and the
various 8088 machines that I have. The performance of memcpy is far
better on the newer processors due to pipeline efficiency and levels of
caching. (Even the 386-40 has a 128K L2 cache.) Disk becomes the major
bottleneck on the faster machines.

[Michael B. Brutman]

Post by Rugxulo
Hi,
(yes, I tried trimming the quote, but it almost all seems vaguely
relevant, ugh)
At risk of embarrassing myself (again) by showing my ignorance ...
Mike, you said this: "Disk becomes the major bottleneck on the faster
machines."
Doesn't FTP know the filesize of file-to-be-downloaded ahead of time?
* create/open, seek to end-1 (in the empty output file), write a
single byte, close, reopen
This apparently avoids having to update the FAT over and over again
redundantly. See the following thread for some examples (esp. nidud's
comment about Doszip: "This reduced the compression time from 455 to
180 sec.").
http://www.bttr-software.de/forum/board_entry.php?id=8862#p8879
I may be seriously off-base here (no surprise), but I felt I should
mention it "just in case"!

Interesting, and probably part of the reason why 8KB writes were much
more efficient than 1KB writes. Since DOS is adjusting the FAT each
time the file grows there is more work to do for the smaller block sizes.

The mTCP client does not query the file size before starting a download;
it requires another command to be inserted before the GET, kind of the
way that PORT and PASV commands are inserted. It's an involved change,
but if it has the potential to make the disk writes faster I'd be happy
to try it.

(I'll see if it makes a noticeable difference first by receiving to a
file that is already created and is at the right size. In theory that
transfer will happen faster than if the file is not created yet.)

For error recovery you would not want to leave a full sized by half
written file laying around. It looks like chsize is the right way to
truncate the file to the correct size after the TCP socket is closed.


Mike

[Bernd Blaauw]

Post by Michael B. Brutman
Most of my testing is on lower-end machines, like a 386-40 and the
various 8088 machines that I have. The performance of memcpy is far
better on the newer processors due to pipeline efficiency and levels of
caching. (Even the 386-40 has a 128K L2 cache.) Disk becomes the major
bottleneck on the faster machines.

As FTP.exe doesn't occupy entire conventional memory anyway (though not
all machines have 512KB/640KB) maybe a ramdisk in conventional memory is
possible. I don't know any software besides TDSK being able to do so
though. My own testing sometimes involves a solid state disk, other
times a ramdrive. Bye latencies :)

Post by Michael B. Brutman
Just for comparison, on my local network here the AMD 80386-40 clone
with an NE2000 adapter on a 10Mb segment is connected to a Pentium 233
running Fedora 2. My FTP receive speed on this network is 506KB/sec,
which is similar to what you are reporting for your virtual machine. My
Pentium 133 running with a PCI Ethernet card receives at 1950KB/sec,
which is almost four times faster than what you are reporting. Your VM
might be adding unnecessary overhead.

Yeah I'm not sure what's causing that, maybe the default emulated NIC is
an AMD 10mb/s card. I'm sure there's some also the possibility of an
emulated intel card, just need to find out how to configure it.
Not tried physical machine (no packet drivers, and officially there's no
freely distributable NDIS/ODI files required to get a network card's
NDIS/ODI drivers working followed by a shim/wrapper).
Not tried local network either yet, my router has some internal storage
and a few USB2 ports for adding drives.

[Michael B. Brutman]

Just for grins I did a little speed testing comparing mTCP running in a
VM to native FTP under Windows XP. Here are the results:

File size: 32MB
Source: Linux 2.6.x running on a Pentium 233, local 100Mb/sec connection

Windows XP command line FTP client: ~8950KB/sec
LFTP running under Cygwin: ~8850KB/sec
mTCP, VMWare 3.13, PCNet emulation, standard buffer sizes: ~3950KB/sec
mTCP, VMWare 3.13, PCNet emulation, max buffer sizes: ~6826KB/sec


So the maximum buffer size settings do improve performance quite a bit.
I need to go back and test my older/slower machines to see if they see
similar results. Performance characteristics have changed since I set
those buffer sizes and some tweaking to the defaults might be
appropriate. (All of this can be set from the configuration file today,
so no new code is needed.)



Mike

[Bernd Blaauw]

Post by Michael B. Brutman
Windows XP command line FTP client: ~8950KB/sec
LFTP running under Cygwin: ~8850KB/sec
mTCP, VMWare 3.13, PCNet emulation, standard buffer sizes: ~3950KB/sec
mTCP, VMWare 3.13, PCNet emulation, max buffer sizes: ~6826KB/sec

Odd that my download sucks then at 500KB/s. Ah well, must be some local
issue in Windows, VMware or the machine itself.

Post by Michael B. Brutman
So the maximum buffer size settings do improve performance quite a bit.
I need to go back and test my older/slower machines to see if they see
similar results. Performance characteristics have changed since I set
those buffer sizes and some tweaking to the defaults might be
appropriate. (All of this can be set from the configuration file today,
so no new code is needed.)

Could you list a short version of your buffer settings in that file
please? I settled for MTU 1500 and that was it.

Goodluck testing old machine behaviour :)

[Eric Auer]

Hi Bernd,

Post by Bernd Blaauw
My own testing sometimes involves a solid state disk, other
times a ramdrive. Bye latencies :)

SSD have a quite noticeable per-write latency. The reason why
you do not notice it with Windows or Linux is that those may
use NCQ (queueing of concurrent disk I/O activities) and will
often use larger blocks... The latency only grows a bit while
blocks grow a lot, so writing e.g. the FAT or directory meta
data in units of 512 bytes without pooling can be still slow
in operating systems like DOS depending on your caching :-)

Eric

[Bernd Blaauw]

Mike

Mike,

do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.

I'm pretty sure the compression program itself is 386+ or 586+,
but compressed executables should be 8086+ if used with proper options.
(upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe


Ultimate Packer for eXecutables
Copyright (C) 1996 - 2010
UPX 3.07d Markus Oberhumer, Laszlo Molnar & John Reiser

File size Ratio Format Name
-------------------- ------ ----------- -----------
51974 -> 32191 61.94% dos/exe dhcp.exe
39372 -> 25975 65.97% dos/exe dnstest.exe
102256 -> 56758 55.51% dos/exe ftp.exe
111996 -> 58321 52.07% dos/exe ftpsrv.exe
87044 -> 48833 56.10% dos/exe ircjr.exe
76430 -> 44563 58.31% dos/exe nc.exe
40092 -> 26488 66.07% dos/exe ping.exe
41660 -> 27319 65.58% dos/exe sntp.exe
69230 -> 40488 58.48% dos/exe spdtest.exe
86730 -> 48854 56.33% dos/exe telnet.exe
-------------------- ------ ----------- -----------

[Michael B. Brutman]

Post by Bernd Blaauw

Mike

Mike,
do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.
I'm pretty sure the compression program itself is 386+ or 586+,
but compressed executables should be 8086+ if used with proper options.
(upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2010
UPX 3.07d Markus Oberhumer, Laszlo Molnar& John Reiser
File size Ratio Format Name
-------------------- ------ ----------- -----------
51974 -> 32191 61.94% dos/exe dhcp.exe
39372 -> 25975 65.97% dos/exe dnstest.exe
102256 -> 56758 55.51% dos/exe ftp.exe
111996 -> 58321 52.07% dos/exe ftpsrv.exe
87044 -> 48833 56.10% dos/exe ircjr.exe
76430 -> 44563 58.31% dos/exe nc.exe
40092 -> 26488 66.07% dos/exe ping.exe
41660 -> 27319 65.58% dos/exe sntp.exe
69230 -> 40488 58.48% dos/exe spdtest.exe
86730 -> 48854 56.33% dos/exe telnet.exe
-------------------- ------ ----------- -----------

That looks very promising - I will test it out. I imagine that
decompression time on the smaller machines is a little longer, but that
is offset by that much less disk I/O. And the smaller machines are
often tight on storage.



Mike

[Rugxulo]

Hi,

Post by Michael B. Brutman

Post by Bernd Blaauw

Mike

Mike,
do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.

That looks very promising - I will test it out. I imagine that
decompression time on the smaller machines is a little longer, but that
is offset by that much less disk I/O. And the smaller machines are
often tight on storage.

Of course, you're right, the only way to know is to test. However, I'm
skeptical; it probably won't be painless.

Anyways, just from (barely related) experience, I found that my old
486 was only really slow (with LZMA) on really big DJGPP .EXE files
(several MB), other smaller utils didn't show any obvious slowdown. So
be sure to try with "--ultra-brute --lzma --8086" as well as "--best
--8086" or even "--ultra-brute --8086". (Or perhaps "--ultra-brutman",
heheheh.)

[Michael B. Brutman]

Post by Bernd Blaauw
Mike,
do you have any experience using UPX (executable file compressor) on
your programs? I'm wondering if
1) programs still load properly for you on 8086
2) smaller disksize + in-memory-decryption faster than loading entire file.
I'm pretty sure the compression program itself is 386+ or 586+,
but compressed executables should be 8086+ if used with proper options.
(upx.sf.net ) , upx --best --8086 c:\mtcp\*.exe
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2010
UPX 3.07d Markus Oberhumer, Laszlo Molnar& John Reiser
File size Ratio Format Name
-------------------- ------ ----------- -----------
51974 -> 32191 61.94% dos/exe dhcp.exe
39372 -> 25975 65.97% dos/exe dnstest.exe
102256 -> 56758 55.51% dos/exe ftp.exe
111996 -> 58321 52.07% dos/exe ftpsrv.exe
87044 -> 48833 56.10% dos/exe ircjr.exe
76430 -> 44563 58.31% dos/exe nc.exe
40092 -> 26488 66.07% dos/exe ping.exe
41660 -> 27319 65.58% dos/exe sntp.exe
69230 -> 40488 58.48% dos/exe spdtest.exe
86730 -> 48854 56.33% dos/exe telnet.exe
-------------------- ------ ----------- -----------

I tested UPX on one of the slowest machines that I have that has a hard
drive. On a PCjr with a NEC V20 and XT-IDE adapter UPX compressed
executables worked, but they took noticeably longer to start up:

FTPSRV: original was 2 seconds, with UPX is 5 seconds
PING: original was 1 second, with UPX is 2 seconds

The V20 makes the machine a little faster than a standard 8088 based
machine. The XT-IDE adapter is slow as far as hard drive controllers
go; on a real XT the delay would be more pronounced because the
controller is far better. But on an 80286 or better I'm sure that the
difference is not noticeable.

I think that most people are running on faster hardware with plenty of
storage space, so this is interesting but probably not worth making part
of the build process. (Is my instinct correct here? I think I'm one of
the few nut jobs on 8088 based hardware, because it's fun!)

On a slightly off topic note, I need to learn to build FreeDOS. I
suspect it doesn't like my PCjr and I'm going to have to fix that. :-)


Mike

[Rugxulo]

Hi,

Post by Michael B. Brutman
I tested UPX on one of the slowest machines that I have that has a hard
drive. On a PCjr with a NEC V20 and XT-IDE adapter UPX compressed
FTPSRV: original was 2 seconds, with UPX is 5 seconds
PING: original was 1 second, with UPX is 2 seconds

Not too bad, honestly. I think p7zip (several MB) took longer when
using LZMA on my 486 (esp. compared to --best). But it really only
matters for stuff you execute / invoke a lot. I'm not sure people use
PING enough to be a problem. (But perhaps others would be more
sensitive.) YMMV.

Even WinXP has a penalty for UPX'd DJGPP stuff, strangely. So it's not
just slow machines. (And this hurts when compiling, so you have to be
careful of that, and it's been abandoned as default for a while now.)

Post by Michael B. Brutman
The V20 makes the machine a little faster than a standard 8088 based
machine. The XT-IDE adapter is slow as far as hard drive controllers
go; on a real XT the delay would be more pronounced because the
controller is far better. But on an 80286 or better I'm sure that the
difference is not noticeable.

Dunno without testing.

Post by Michael B. Brutman
I think that most people are running on faster hardware with plenty of
storage space, so this is interesting but probably not worth making part
of the build process. (Is my instinct correct here? I think I'm one of
the few nut jobs on 8088 based hardware, because it's fun!)

Yeah, it's interesting but probably not practical. (So what? <g>)

But yeah, there aren't many 8088 gurus / geniuses out there: Trixter,
you, RubberMallet, DeathShadow. That's all I can think of off the top
of my head. (I don't and never had any 808x machines, but it's a
classic, IMHO, so I've often written 8086-only stuff, esp. since it
doesn't hurt much, if at all, on newer machines.)

Post by Michael B. Brutman
On a slightly off topic note, I need to learn to build FreeDOS. I
suspect it doesn't like my PCjr and I'm going to have to fix that. :-)

If you're trying to build _on_ your PCjr, try TC201. The kernel is
actually pretty simple to build, but you'll need NASM (0.98.39 on
SourceForge has a 16-bit binary) and maybe FreeCOM binary as shell
(dunno why). FreeCOM also should build with TC (haven't tried Bart's
OW port in SVN yet). IIRC, my tweaked P166 took 90 secs. to build the
kernel, if that gives you any (very rough) idea of how long it'll
take.

It's been a while, and it's not like I ever needed to rebuild that
stuff a lot, so I can't remember. CONFIG.B -> something something.
Anyways, if you run into trouble, just nag us, and some of us can
help. :-)

[Michael B. Brutman]

Post by Bernd Blaauw
* missing MTCPCFG variable
* MTCPCFG variable points to non-existing file
* missing PACKETINT keyword in file
* unable to write to MTCPCFG file (yay hidden/readonly)
* packetdriver not loaded yet
* static config found in MTCPCFG file
* time out (no DHCP server found)
* what else? invalid MTU size?
Bernd

I have resisted getting too detailed with the errorlevels because I
would need to make them consistent across all of the applications. At
some point I'm not going to control all of the applications, so I won't
be able to enforce it. The user readable error messages are usually
descriptive enough. (I might address this by reserving a block of error
codes for the library, most of which would be used during startup.)

We might have a small misunderstanding about the relationship between
DHCP and the configuration file. All of the mTCP applications think
that they are using a static configuration. They read the configuration
file and use what they find. DHCP is a special case; it is the only
code that will alter the configuration file. This allows me to keep all
of the other code simple while still providing DHCP support; all of the
other code thinks it is using static configuration and DHCP plays along
with that fiction. Therefore, DHCP will usually find a static config in
the file because it wrote the static config there the last time it was
run. (If you are generating the config file each time before calling
DHCP then finding a static config would seem like a reason to stop, but
normally it is not.)



Mike

[Bernd Blaauw]

Post by Michael B. Brutman
I have resisted getting too detailed with the errorlevels because I
would need to make them consistent across all of the applications. At
some point I'm not going to control all of the applications, so I won't
be able to enforce it. The user readable error messages are usually
descriptive enough. (I might address this by reserving a block of error
codes for the library, most of which would be used during startup.)

Ah my interest was purely to DHCP.exe here, once that works all
applications are fine with their semi-static file (except for a "lease
expired, can't run, run DHCP.exe first again or stick to static IP)

Post by Michael B. Brutman
with that fiction. Therefore, DHCP will usually find a static config in
the file because it wrote the static config there the last time it was
run. (If you are generating the config file each time before calling
DHCP then finding a static config would seem like a reason to stop, but
normally it is not.)

Yeah I don't know DHCP.exe's behaviour, was just afraid it would be
spamming the DHCP server everytime I run it, instead of analysing the
configuration file's timestamp + lease.

VMware's DHCP gives 1800 seconds lease (NAT-mode), while my router's
DHCP gives 1 day leases indeed (as does yours).

The tricky situation is a "hey lease is still valid, let's not query".
with meanwhile lease only still being valid like 5 seconds or so.
Trouble ahead :)

[Michael B. Brutman]

Post by Michael B. Brutman
That funny URI syntax was grafted on. What exact URI are you using? Are

Post by Michael B. Brutman
you adding "ftp://" or just "//" ?

FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments
at the "/" level. See the "FOR LOOP" in my batchfile, with batchfile
called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin
ftp.exe //ftp.xs4all.nl
(on which it chokes, not knowing how to handle //).
1) find a way to strip the prepending "//" before feeding to FTP
2) allow FTP to accept them and strip it themselves, requiring code changes.

Ah - I forgot to take the command line parsing into account. What
happened to the "ftp:" before the "//" in this case?

Let me see how this behaves on my other systems before deciding what to
do. I don't want to build in workarounds for strange command line
parsing into the code. A more general solution might be to allow the
parameter to be quoted on the command line so that I can just handle
standard URI syntax.


Mike

[Jim Michaels]

have you tried putting the URL in double quotes?
that *may* prevent the program from treating ftp://blah as 3 maybe 2 arguments (ftp: / /blah or ftp: //blah).  I should think it would be 3.


also, if this is djgpp, you need to turn off globbing because / ? * . [ ] is speclal (this is or almost is a regexp)!  even in msdos, / is special and denotes a command-line switch, so funny things may happen?  only cure I know of, if this is not djgpp (see below because double quotes won't work) is to use double quotes around the URL.



#if defined(__MINGW32__)
/*mingw-w64 toolchain sezero configures
the CRT using --enable-wildcard which enables globbing. To disable it, you
can either add a global to your source, like "int _dowildcard = 0;" or you
can add CRT_noglob.o to your list of objects to be linked.*/

int _dowildcard = 0; /*disable globbing in mingw-w64 sezero toolchain*/
#elif defined(__DJGPP__)
/*http://www.delorie.com/djgpp/v2faq/faq16_2.html*/
char **__crt0_glob_function(char *_argument) {
    return 0; //cause no expansion
}
#endif

________________________________
Sent: Thursday, July 7, 2011 5:13 AM
Subject: Re: [Freedos-devel] mTCP FTP URIs (was: watcom tcp

Post by Michael B. Brutman
That funny URI syntax was grafted on. What exact URI are you using? Are

Post by Michael B. Brutman
you adding "ftp://" or just "//" ?

FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments
at the "/" level. See the "FOR LOOP" in my batchfile, with batchfile
called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin
ftp.exe //ftp.xs4all.nl
(on which it chokes, not knowing how to handle //).
1) find a way to strip the prepending "//" before feeding to FTP
2) allow FTP to accept them and strip it themselves, requiring code changes.

Ah - I forgot to take the command line parsing into account.  What
happened to the "ftp:" before the "//" in this case?
Let me see how this behaves on my other systems before deciding what to
do.  I don't want to build in workarounds for strange command line
parsing into the code.  A more general solution might be to allow the
parameter to be quoted on the command line so that I can just handle
standard URI syntax.
Mike
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Steve Nickolas]

Post by Bernd Blaauw
I'm happy with whatever I can get. My real hardware has an Nvidia
chipset network driver for which no packet drivers exist, so sticking to
virtual machines. I wonder if any PCI (or even PCI-express or onboard)
network cards still support packet drivers.

I think the RTL-8139 chipset does and it's still quite common.

Post by Bernd Blaauw
FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments
at the "/" level. See the "FOR LOOP" in my batchfile, with batchfile
called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin

Sounds like a bug: that should be handled at the program level, not the
shell level.

-uso.

[Bernd Blaauw]

Post by Steve Nickolas
I think the RTL-8139 chipset does and it's still quite common.

And there I was, wanting high-performant low-CPU network cards (with
also packet drivers):
* Intel Gigabit PCI-card (10/100Mbit fallback)
* Intel Gigabit PCI-e card (10/100Mbit fallback)
* Intel 10Gigabit PCI-e card (only 1000mbit fallback, possibly only
jumboframes supported?)

I'm afraid I've got no use for PCI-X cards, my old dual opteron machine
is in the scrapyard.

Post by Steve Nickolas

Post by Bernd Blaauw
FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments
at the "/" level. See the "FOR LOOP" in my batchfile, with batchfile
called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin

Sounds like a bug: that should be handled at the program level, not the
shell level.

I don't know how other shells behave here.
doesn't matter if I do a:
* FOR %x in ( %path% ) do echo %x
* for %x in ( ftp://ftp.xs4all.nl/pub/test/10mb.bin ) do echo %x

I should probably see how MS Command.com and 4DOS parse this.

Post by Steve Nickolas
-uso.

Bernd

[Jim Michaels]

cURL has no problem with ftp:// it handles LOTS of protocols

________________________________
Sent: Wednesday, July 6, 2011 4:32 PM
Subject: Re: [Freedos-devel] watcom tcp

1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription)
2) N/A , WGET not working
3) 500Kbyte/second ( around 4Mbit/s)

mTCP FTP compares poorly to the native stack and FireFox there, but
* The TCP/IP socket receive buffer is tiny compared to the native network stack
* You are doing filesystem writes 8KB at a time
* You have a small virtualization penalty
* The packet interface wasn't designed for high performance; every incoming packet requires a hardware interrupt and two software interrupts

But for older machines, it is more than adequate.  I'll try a few tests here - I also test under VMware, VirtualBox, and DOSBox but I never thought to compare the performance to the native TCP/IP stack.

Did you set the MTU size to 1500 in the configuration file?  If you

did not, that will dramatically improve the speed.

Trying to get FTP.EXE working with WGET syntax is funny.

Limitation: servername has "//" prepended to it which ftp.exe doesn't like.

That funny URI syntax was grafted on.  What exact URI are you

using?  Are you adding "ftp://" or just "//" ?

Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter

(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).

Can you explain this in more detail?  If you were missing a proper

CR/LF at the end of a line then the C runtime would not have
recognized the start of the next line, and that line would be
effectively lost.  This happens if you use an editor that doesn't
use the CR/LF convention.  (I often make this mistake when using VI
under Cygwin.)

I could recognize both CR/LF and LF in the parsing code to improve

things when you are in a mixed environment.  But all of the code
that reads the configuration file would have to change too, not just
DHCP.  That really has the flavor of a user error.
* FTP accepting "//" in front of a servername
* DHCP starting MTCP.CFG writes on a newline
* DHCP: different errorlevels for various situations instead of
errorlevel 1 on all errors? aka "how to determine if packet driver still
needs to be loaded" Bernd

For the first request I think that I have to look for either "ftp://" or just "//" to be correct.  The second request might be considered a user error.  And for the third I will definitely put that on the todo list; the error messages already indicate if the packet driver is not loaded but I can set errorlevel too.
Mike
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Jim Michaels]

they are available here.
http://www.rahul.net/dkaufman/index.html

________________________________
Sent: Wednesday, July 6, 2011 4:02 PM
Subject: Re: [Freedos-devel] watcom tcp

The second parameter is optional and allows you to do the rename.  This
is similar to Unix command line clients.

Tested tonight, works like a charm :)
Confusingly, I've now got trouble getting WGET working, as I had the
intention of downloading from fastest server I could find, using
1) FireFox 5 browser (win32, on Windows 7 Ultimate x64, Q6600 CPU)
2) WGET (WATTCP, FreeDOS 1.1, PCNTPK, VMware Workstation 7.1)
3) FTP (MTCP, FreeDOS 1.1, PCNTPK, VMware Workstation 7.1)
Starting with Ibiblio wasn't so smart, ended up below 300KB in all cases.

On a low end Pentium system I've been able to get about 50% of the full
line speed on a 100Mb PCI adapter.  That system should have been able to
saturate the line ...

1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription)
2) N/A , WGET not working
3) 500Kbyte/second ( around 4Mbit/s)
Trying to get FTP.EXE working with WGET syntax is funny.
Limitation: servername has "//" prepended to it which ftp.exe doesn't like.
Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter
(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).
* FTP accepting "//" in front of a servername
* DHCP starting MTCP.CFG writes on a newline
* DHCP: different errorlevels for various situations instead of
errorlevel 1 on all errors? aka "how to determine if packet driver still
needs to be loaded"
Bernd
-- download.bat/wget.bat --
@echo off
goto begin
:begin
rem No way yet to handle "server/dir/file -o filename"
for %%x in ( 1 2 3 4 5 6 7 8 9 ) do if not "%%%x"=="" echo arg%%x: %%%x
if "%1"=="-o" goto output
if "%1"=="ftp:" goto next
rem help/error/instruction message
goto error
:output
rem get rid of "-o" in "-o filename server/dir/file"
shift
if "%1"=="ftp:" goto begin
rem -o was followed by filename (no path allowed, just 8.3 filename)
set out=%1
rem get rid of filename as well
shift
goto begin
:next
rem get rid of "ftp:" meaning you end up with "servername/dir/filename"
shift
if "%out%"=="" set out=out.bin
if exist %out% del %out%
if exist tmp.txt del tmp.txt
echo Time to write a nice script
echo anonymous> tmp.txt
rem Yay contact e-mail annex awesome spam filter
echo binary>> tmp.txt
echo xfermode passive>> tmp.txt
echo get %2%3%4%5%6%7%8%9 %out%>> tmp.txt
rem FTP accepting/stripping "//" before a ftp server name would be
convenient.
rem allowing "FTP %1 < tmp.txt"
ftp ftp.xs4all.nl < tmp.txt
goto succes
:succes
echo File downloaded and written to local disk as %out%
set out=
goto end
:error
echo Please start download URL with: ftp://
echo (e.g. ftp://ftp.xs4all.nl/pub/test/10mb.bin)
goto end
:end
echo Program finished
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Rugxulo]

Hi,

Post by Jim Michaels
they are available here.
http://www.rahul.net/dkaufman/index.html

I've never used cURL, but apparently latest is 7.21.7. I blindly
wonder if it'll still compile with DJGPP + WATT-32 (too preoccupied to
personally try right now, doh).

Anyways, here's link to srcs for 7.10.5 (cURL it? heh):

ftp://ftp.sunet.se/pub/www/utilities/curl/curl-7.10.5.tar.bz2

Official site is here:

http://curl.haxx.se/

http://curl.haxx.se/download/curl-7.21.7.tar.bz2

Watt-32 (new) homepage seems to be here:

http://home.broadpark.no/~gvanem/

[Jim Michaels]

DOS version of cURL can be obtained from
http://www.rahul.net/dkaufman/index.html

________________________________
Sent: Saturday, July 2, 2011 5:42 PM
Subject: Re: [Freedos-devel] watcom tcp

Post by François Revol
Any of those two supports IPv6 ? So FreeDOS can survive the IPcalypse :D

Don't think so.
1) WGET/CURL
2) WOL-client to wake up machines in the network by sending magic packet
3) IP v6
4) Jumboframes (9000 bytes I think it was?) as MTU
As for the usual rhetoric: "it's opensource, patches welcome, fix it
yourself if you want more" hehe :)
Or wait till Michael has time and sees use in adding these things.
As FTP.EXE is a DOS program, and DOS is singletasking anyway, I wonder
if it uses as big a buffer as it can possibly get (for simplicity's
sake, all available conventional memory, not bothering with XMS/EMS etc
as it's a 8086 app) and use it in a beneficial way to speed things up.
Or maybe it might be limited to a partial buffer, or not benefit from
going over a specific buffer size.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Jim Hall]

Hi,
  (cc'ing freedos-devel since they may be interested)
Okay, I finally made a DOS-only .7z for OpenWatcom 1.9. (Only a year
after their release and two years since 1.8 .7z, heh.)
http://www.openwatcom.org/index.php/C_Compilers_Release_Changes

[...]

It's only 7 MB (compressed), approx. 45 MB unpacked (not counting FAT
cluster waste), about 1500 files! It's "full", everything for DOS
(host and target, C and C++, 16-bit and 32-bit, runtime sources,
examples, help files). And yes, I actually tested it (DOSEMU ftw!), so
it works.  ;-)   It needs approx. 16 MB to unpack, but that should be
minimal enough for anyone these days. (Besides, use p7zip or 7zdecode
via DJGPP + CWSDPMI and you can swap 'til the cows come home.) I
assume this is more pleasant than downloading 80 MB .EXE installer
(see iBiblio) which you don't need, esp. for those who still have
dialup or slow connections (or minimalists, heh).
https://sites.google.com/site/rugxulo/ow19dos.7z?attredirects=0&d=1
This is really only a temporary spot since I don't have anywhere
better to put it. I don't promise I'll keep it here forever!  :-)
Feel free to mirror it somewhere else. (Apparently RapidShare requires
"free" registration nowadays, ugh. So annoying.)

Why not put this on ibiblio, as an alternate download? I only ask that
you rename the file to match the zip file that's already on ibiblio
(open-watcom-c-dos-1.9.7z would be good).


-jh