Re: [Freedos-devel] watcom tcp
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 jmich...@yahoo.com j...@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. From: Bernd Blaauw bbla...@home.nl To: freedos-devel@lists.sourceforge.net Sent: Wednesday, July 6, 2011 4:27 AM Subject: Re: [Freedos-devel] watcom tcp Op 6-7-2011 6:22, Steve Nickolas schreef: On Tue, 5 Jul 2011, Jim Michaels wrote: 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
they are available here. http://www.rahul.net/dkaufman/index.html From: Bernd Blaauw bbla...@home.nl To: freedos-devel@lists.sourceforge.net Sent: Wednesday, July 6, 2011 4:02 PM Subject: Re: [Freedos-devel] watcom tcp Op 3-7-2011 4:26, Michael B. Brutman schreef: 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 ... 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 bbla...@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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
cURL has no problem with ftp:// it handles LOTS of protocols From: Michael B. Brutman mbbrut...@brutman.com To: freedos-devel@lists.sourceforge.net Sent: Wednesday, July 6, 2011 4:32 PM Subject: Re: [Freedos-devel] watcom tcp On 7/6/2011 6:02 PM, Bernd Blaauw wrote: 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) 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. 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. 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 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Hi, On 7/8/11, Jim Michaels jmich...@yahoo.com wrote: 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/ -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Hi Bernd, 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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
On Thu, 7 Jul 2011, Bernd Blaauw wrote: 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. 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 7-7-2011 15:37, Steve Nickolas schreef: On Thu, 7 Jul 2011, Bernd Blaauw wrote: 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. 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. -uso. Bernd -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 6-7-2011 6:22, Steve Nickolas schreef: On Tue, 5 Jul 2011, Jim Michaels wrote: 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 3-7-2011 4:26, Michael B. Brutman schreef: 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 ... 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 bbla...@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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
On 7/6/2011 6:02 PM, Bernd Blaauw wrote: 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) 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. 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. 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 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 7-7-2011 1:32, Michael B. Brutman schreef: 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 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. 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. 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. 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. 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. 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% 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 -- 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
Re: [Freedos-devel] watcom tcp
Hi, On 7/2/11, Bernd Blaauw bbla...@home.nl wrote: Op 3-7-2011 2:59, Rugxulo schreef: 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. ;-) 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). 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Le mardi 05 juillet 2011 à 03:23 -0500, Rugxulo a écrit : 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Hi, On 7/5/11, François Revol re...@free.fr wrote: Le mardi 05 juillet 2011 à 03:23 -0500, Rugxulo a écrit : 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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Le mardi 05 juillet 2011 à 15:17 -0500, Rugxulo a écrit : 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
DOS version of cURL can be obtained from http://www.rahul.net/dkaufman/index.html From: Bernd Blaauw bbla...@home.nl To: freedos-devel@lists.sourceforge.net Sent: Saturday, July 2, 2011 5:42 PM Subject: Re: [Freedos-devel] watcom tcp Op 3-7-2011 1:54, François Revol schreef: 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
how on earth shall I expect to build a bootable ISO image with mkisofs? From: Rugxulo rugx...@gmail.com To: freedos-devel@lists.sourceforge.net Sent: Tuesday, July 5, 2011 1:23 AM Subject: Re: [Freedos-devel] watcom tcp Hi, On 7/2/11, Bernd Blaauw bbla...@home.nl wrote: Op 3-7-2011 2:59, Rugxulo schreef: 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. ;-) 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). 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
On Tue, 5 Jul 2011, Jim Michaels wrote: 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/ -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Le samedi 02 juillet 2011 à 09:32 -0500, Michael B. Brutman a écrit : 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 3-7-2011 1:54, François Revol schreef: 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. -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Hi, On Sat, Jul 2, 2011 at 7:42 PM, Bernd Blaauw bbla...@home.nl wrote: Op 3-7-2011 1:54, François Revol schreef: 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 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/ -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
On 7/2/2011 7:42 PM, Bernd Blaauw wrote: Op 3-7-2011 1:54, François Revol schreef: 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. [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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 3-7-2011 3:03, Michael B. Brutman schreef: [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) [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. [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.. 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? 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 -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Hi, quick reply, (others know way more than I do here), On Fri, Jul 1, 2011 at 4:49 PM, Edwin Rhodes edwin_rho...@hotmail.com wrote: 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/ -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] watcom tcp
Op 1-7-2011 23:53, Rugxulo schreef: 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 :) -- 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
