Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!news.funet.fi!uwasa.fi!ts From: ts@uwasa.fi (Timo Salmi LASK) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: **** WANTED **** BINARY FILE COPY PROGRAM Message-ID: <1990Sep23.061359.632@uwasa.fi> Date: 23 Sep 90 06:13:59 GMT References: <90263.114424POTELLE@MAINE.BITNET> <1007@gistdev.gist.com> Organization: University of Vaasa Lines: 63 In article <1007@gistdev.gist.com> flint@gistdev.gist.com (Flint Pellett) writes: > > I may decide to write this in a couple days, as I've wanted to be able to > grab small parts like version strings (that are in fixed byte locations) > out of binary data files before. If you (or some other kind netter) do, I would be very interested to consider it for chyde.uwasa.fi anonymous ftp archives for general download. If you kindly email it uuencoded to me I'll be happy to take look at it. The package should include documentation, and may I suggest that you include your "Soapbox". It is interesting and educational. I like it. > > I wish people would give more thought to the command line syntax though: > your example is a bad design for command line syntax, because it makes the > program unuseable in a pipe for no good reason. Why force the user to read > from one file into another file when you don't have to do so?) Here is a > similar but much more useable syntax: > > chop -s -e -b inputfile I agree with your points. Just as a way of discussion, I make the following observations. You have a strong Unix background. I deduce this from the use of -switch character and the whole concept of pipes. May I suggest using / as (perhaps alternative) switch indicator if you write a program for this MsDos audience. > where everything defaults: -s defaults to 0 (start of file), -e to > end-of-file, -b (the buffer size used during copies) to some value like > 8192 (I don't know what the best default would be here, but I would guess > a fairly large multiple of both 512 and 1024 would be best.) That depends which activity of the program is critical. Sometimes 4096 is enough (that is making the buffer larger won't mean a significant additional speedup). If reading and writing are the main functions in the program (as in this one), the optimum heap for the buffer is the entire 64Kb. I know this from my own program writing. > A lot of utilities seem to want to force you to read and write to files. > Even worse, some of them don't let you specify the files on the command > line, they mess with the screen display to put up a whole menu just for > the purpose of letting you enter the file names: this makes those utilities > a LOT less useful, sometimes even making them useless. (For example, an > Yes, mostly agreed (and in the case of this binary extractor, completely agreed), but also put things in a perspective. Many, or at least some programs around today originate from programs written under operating systems with different traditions than Unix. For example programs that have their origins in VAX/VMS, or some esoteric OSses, simply cannot use piping, since they do not have real piping inbuilt in them at all. It also depends on the nature of the utility. I have hard time of imagining, say, for example, a completely switch / pipedriven PCTOOLS 6.0. ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun