Hello, 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). cheers, Mateusz ------------------------------------------------------------------------------ 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! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Freedos-user mailing list Freedosemail@example.com https://lists.sourceforge.net/lists/listinfo/freedos-user