POTELLE@MAINE.BITNET (John A. Potelle) (09/20/90)
This program should be able to copy PARTS of files, given a starting relative address within the source file and a length. Example of a possible command line syntax: chopcopy [-s100 [-l360]] <source-file> <target-file> HEX or DECimal addressess/lengths - I don't care which... Anyone know of such a beast or care to write one ? Thanks for your help... -------------------------------------------------------------------- John A. Potelle | /////| BITNET: POTELLE@MAINE Computer Programmer |///// | Internet: potelle@maine.maine.edu Office of Institutional Studies - University of Maine
ts@uwasa.fi (Timo Salmi LASK) (09/21/90)
In article <90263.114424POTELLE@MAINE.BITNET> POTELLE@MAINE.BITNET (John A. Potelle) writes: >This program should be able to copy PARTS of files, given a starting >relative address within the source file and a length. >Example of a possible command line syntax: >chopcopy [-s100 [-l360]] <source-file> <target-file> >HEX or DECimal addressess/lengths - I don't care which... >Anyone know of such a beast or care to write one ? TSUTLC16.ARC Third set of Utilities, T.Salmi Filename Comment Date Time CRC -------- -------------------------------- ---- ---- --- DIRF.EXE Directory in full, recursive 07-02-89 09:48:20 A074 DIRINFO.EXE Directory information of a disk 06-16-89 15:36:08 C51A DOUBLES.EXE Find double file names on a disk 10-16-89 22:55:48 5438 DTEDIF.EXE Difference between two dates 07-02-89 13:12:10 6DFE HIDDEN.EXE Find all hidden files on disk 06-09-89 23:02:58 3587 READONLY.EXE Find all readonly files on disk 06-09-89 23:00:06 2EC8 --> SPLIT.EXE Split a file into pieces 06-23-89 08:41:50 0EDD TSPROG.INF List of PD programs from T.Salmi 10-16-89 08:30:44 D636 TSUTLC.INF Document 10-16-89 20:05:22 3CFE VAASA.INF Info: Finland, Vaasa, U of Vaasa 06-23-89 08:30:08 88AB WHATDATE.EXE Date +- number of days from now 07-02-89 09:23:08 2190 YES Yes for redirected DOUBLES prog 06-16-89 12:41:44 5BA2 ZEROFILE.EXE Find all empty files on disk 06-09-89 22:55:42 B765 ---- ------ ------ ----- 0013 143530 107789 25% The split.exe program splits a binary (or a text) file into parts which have the number of bytes you give as the parameter. You'll have to do your task in at least two phases, since split.exe does not take both the starting and the ending address as the parameters (only the number of bytes in the split parts). This is thus only an intermediate solution (kludge), and requires some calculations on the user's part. So while this is not exactly the syntax you want, split.exe can be used to achieve the desired extraction. The package is available by anonymous ftp from our site, directory /pc/ts. BTW writing a slow program that does what you want should be trivial. The trick is to make it a relatively fast one. Then another suggestion. Take a closer look at Buerg's /pc/pd2/list75b.zip in case it could be utilized to achieve the same effect (I'm not sure). P.S. I think that we should call this binary extracting rather than binary copying (cf the subject). ................................................................... 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
dsims@uceng.UC.EDU (david l sims) (09/21/90)
ts@uwasa.fi (Timo Salmi LASK) writes: >In article <90263.114424POTELLE@MAINE.BITNET> POTELLE@MAINE.BITNET (John A. Potelle) writes: >>This program should be able to copy PARTS of files, given a starting >>relative address within the source file and a length. >>Example of a possible command line syntax: >>chopcopy [-s100 [-l360]] <source-file> <target-file> >>HEX or DECimal addressess/lengths - I don't care which... >>Anyone know of such a beast or care to write one ? > BTW writing a slow program that does what you want should be >trivial. The trick is to make it a relatively fast one. I agree. Writing a slow program is trivial. Furthermore, a little bit of buffering on the programmer's part will achieve a large speedup (I can't say exactly how much). For those who aren't sure how to buffer their program, one solution is to perform read's and write's in, say, 10000 byte blocks, instead of the usual and simple method of reading and writing one character at a time.
kdq@demott.COM (Kevin D. Quitt) (09/21/90)
In article <6177@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes: > >For those who aren't sure how to buffer their program, one solution is >to perform read's and write's in, say, 10000 byte blocks, instead of the >usual and simple method of reading and writing one character at a time. To perform the fastest file copies, make sure you have buffer space to read an entire track at once. More than that won't speed you up. The best way is to actually figure the hardware sector number of the file and read tracks as much as possible. This, of course, doesn't work if the file isn't contiguous. The BIOS won't read past the end of a track in a single request - it'll break it up into pieces, and you'll lose revs. Reading tracks on a floppy can give you 4 times the speed. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
ts@uwasa.fi (Timo Salmi LASK) (09/21/90)
In article <6177@uceng.UC.EDU> dsims@uceng.UC.EDU (david l sims) writes: >ts@uwasa.fi (Timo Salmi LASK) writes: >>In article <90263.114424POTELLE@MAINE.BITNET> POTELLE@MAINE.BITNET (John A. Potelle) writes: >>>This program should be able to copy PARTS of files, given a starting >>>relative address within the source file and a length. >>>Example of a possible command line syntax: >>>chopcopy [-s100 [-l360]] <source-file> <target-file> > >> BTW writing a slow program that does what you want should be >>trivial. The trick is to make it a relatively fast one. : >For those who aren't sure how to buffer their program, one solution is >to perform read's and write's in, say, 10000 byte blocks, instead of the >usual and simple method of reading and writing one character at a time. My apologies, since I'm again drifting outside the subjects of c.b.i.p.d., but if anyone is interested in knowing more about buffering, I suggest taking a look at O'Brien, Turbo Pascal, The Complete Reference. It includes a very useful, even if complicated, method for buffering binary file I/O. ................................................................... 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
bobmon@iuvax.cs.indiana.edu (RAMontante) (09/22/90)
MSDOS DEBUG will do this, albeit not "conveniently". Give yoyr source file
a name extension that isn't either "com" or "exe", load it into DEBUG, then
1) name a target file:
N target.bin
2) put the desired writing length in the CX register:
RCX
1234
(That was a hex value. Upper bits go into the BX register, if
you need to write more than 0xffff bytes.)
3) write starting at the desired offset in the file:
W 0100
4) quit:
Q
You now have a new file, named "target.bin", that is 0x1234 (4660 decimal)
bytes long and starts at byte 0x100 (256 decimal) of the source file.
Consult your manual for more information.flint@gistdev.gist.com (Flint Pellett) (09/23/90)
POTELLE@MAINE.BITNET (John A. Potelle) writes: >This program should be able to copy PARTS of files, given a starting >relative address within the source file and a length. > >Example of a possible command line syntax: > >chopcopy [-s100 [-l360]] <source-file> <target-file> > >HEX or DECimal addressess/lengths - I don't care which... > >Anyone know of such a beast or care to write one ? > 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. <Mount Soapbox:> 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<start_byte> -e<end_byte> -b<buffer_size> inputfile 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.) If you don't specify the input file, it defaults to stdin for use in a pipe. It always writes to stdout, so if you want the output in a file, just use chop -s# -e# infile > outfile Doing it that way gives you a lot more power: you can send the output anywhere you want. 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 editor which has an option to pipe part of the file being edited out to some command, and then replace that part of the file with the output of the command, can not get any use at all out of a spelling checker utility that insists on erasing the whole display of the file you are editing, switching you out of 132 column mode into some other mode, and then prompting you for the names of the files. If the utility would read stdin and write stdout when no other options are given, it would be useable from within the editor and could then be invoked with a single key.) The proper sequence in a good utility ought to be this: 1. If an input file name is given on the command line, use it. Always write to stdout if you can. 2. If the user entered some option like "-p", (saying "I don't remember the options I need, please prompt me for all of them"), then prompt them for all the info you need, including names of input & output files. 3. Otherwise, read your input from stdin and write your output to stdout, and adopt reasonable defaults for every option not explicitly specified. <Dismount Soapbox> -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (09/23/90)
In article <59873@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >MSDOS DEBUG will do this, albeit not "conveniently". No, it won't. What is needed is a way to copy a Minix boot disk, (or even an MS-DOS boot disk). Debug can write just fine to a file, but I don't know of any way to make it write to a raw device (a floppy drive). What is needed is a clone of the Unix dd program. Example: `dd if=file of=a: bs=1k count=360` -- Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
ts@uwasa.fi (Timo Salmi LASK) (09/23/90)
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. > <Mount Soapbox:> > 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<start_byte> -e<end_byte> -b<buffer_size> 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
16012_3045@uwovax.uwo.ca (Paul Gomme) (09/24/90)
In article <27257@usc.edu>, kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: > In article <59873@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >>MSDOS DEBUG will do this, albeit not "conveniently". > > No, it won't. What is needed is a way to copy a Minix boot disk, (or > even an MS-DOS boot disk). Debug can write just fine to a file, but I > don't know of any way to make it write to a raw device (a floppy drive). Not true. The W(rite) command does just that. The syntax: W[address [drive: record record]] Example: WCS:100 1 37 2B writes out the contents of memory to the disk in drive B:, beginning with the address CS:100. The data written out starts in the disk logical record number 37H and consists of 2BH records. (Taken from my MS-DOS 3.20 manual.) > Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh -------------------------------------------------------------------------- Bitnet: gomme@uwovax.bitnet gomme@uwovax.uwo.ca Internet: gomme@uwo.ca
kdq@demott.COM (Kevin D. Quitt) (09/24/90)
In article <27257@usc.edu> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >In article <59873@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >>MSDOS DEBUG will do this, albeit not "conveniently". > >No, it won't. What is needed is a way to copy a Minix boot disk, (or >even an MS-DOS boot disk). Debug can write just fine to a file, but I >don't know of any way to make it write to a raw device (a floppy drive). >What is needed is a clone of the Unix dd program. >Example: `dd if=file of=a: bs=1k count=360` The debug commands L and W will load and write sectors. L (address) (drive number 0 = A) (starting sector #) (# of sectors) e.g. L cs:100 1 0 1 will load the boot block. W cs:100 1 0 1 will write the boot block -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
kdq@demott.COM (Kevin D. Quitt) (09/24/90)
Forgot to add, besides, what's wrong with diskcopy? It even formats
during the copy?
--
_
Kevin D. Quitt demott!kdq kdq@demott.com
DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266
VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last
96.37% of all statistics are made up.nol2321@dsacg4.dsac.dla.mil (Jim Dunn) (09/27/90)
I have a program called CHOP v3.1, it's very good, (I mailed the previous asker a copy already, don't mail him it again...) How do I send stuff to comp.binaries.ibm.pc, (and please, don't give me another 50 page document... just an address...) :) Jim
ts@uwasa.fi (Timo Salmi) (09/29/90)
Fri 28-Sep-90: Available at chyde.uwasa.fi archives /pc/pd2/chop11.zip by Flint Pellet. For extracting parts from binary files. Some users have asked / discussed such a utility on the news in comp.binaries.ibm.pc.d. ................................................................... 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