On 10/14/2012 12:22 PM, Bernd Blaauw wrote:
>   From what I've noticed it's a big binary, likely due to including
> wattcp and perhaps also a decompressor.

Indeed, FDNPKG includes everything - a UNZIP decompressor, the WatTCP 
stack, and a simple HTTP downloader.

> I've not experimented with it,
> got stuck reading the little amount of documentation that's present.

Could you please tell me what you had problems with? Maybe I could add 
some info into the readme file.. I though FDNPKG is trivial to use, but 
my view might be flawed on this.

> I'm surprised Mike didn't bring up the suggestion of making it
> MTCP-compatible and thus perhaps also smaller.

In fact, I was wondering about building FDNPKG networking against the 
mTCP stack, and I think mTCP is a very good piece of code. But I got 
troubles compiling mTCP in DOS (seems to be related to the fact that the 
commands used by the Makefile are much longer than what the DOS shell 
interpreter allows), and using WatTCP was simply the 'easy way' to go.. 
Also, I am used to GCC, therefore using DJGPP sounded easier to me 
(dunno if mTCP could be compiled on DJGPP). mTCP definitely lacks a 
'ready to go' DOS binary object (along with a .h header file) that could 
be linked without the hassle of compiling it first - I believe this 
could make it much more 'sexy' to developers.

> Installing from local *.zip implies the ability to run the program
> without a package driver present. Not everyone has a network interface
> card, and even if they do, there aren't always packet drivers or shims
> available. Easy alternative would be adding a public domain or
> opensource dummy shim so local use is possible.

This is a problem that I never though about. I understand that you are 
telling that when no packet driver is present, FDNPKG doesn't run at all 
- this is probably caused by a check that WatTCP performs, to check if 
there is a packet driver loaded.. In such case, adding a 'fake' packet 
driver would indeed solve the problem. I will also look into FDNPKG to 
see if maybe I am not calling WatTCP initialization a bit to early 
(would be nicer to be able to use FDNPKG without WatTCP *and* without 
any fake packet driver workaround).

> Can a directory be specified? Creating a local config file with
> loc1 = x:\cdrom\loc1
> loc2 = x:\cdrom\loc2
> (etc..)
> seems easy enough to do from a batchfile.

No, there is no such possibility. 'repositories' are only online HTTP 
repositories. For local files, one would have to call FDNPKG and provide 
directly the path to the zip file.

> I'm curious also. Emulated cards in emulators are the least of worries.
> Connecting virtual network cards to real networks seems like a horrible
> configuration issue.

See my previous post. I wouldn't call it a 'horrible configuration 
issue', but it requires maybe some minimal in-depth knowledge about 
networking in Linux.. It's not as easy as it could be (like in 
VirtualBox, where there is a single checkbox to check, and the 
hypervizor is taking care of all the system stuff to make it working).


Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
Freedos-user mailing list

Reply via email to