mee@ucscb.UCSC.EDU (Kevin Kahl) (03/28/90)
It seems that 4DOS version 3.0 has a new bug. I wrote a device driver that is in two parts. These are the commands that I used (in a batch file under 4DOS v2.2) to concatenate the to files into one: copy /b password.bin+password.txt password.sys The resulting file does not include everything! "password.bin" is 859 bytes in length. "password.txt" is 4000 bytes. The resulting "password.sys" is only 4083 bytes, though. Under 4DOS 2.2, the resulting length was 4859 (as it should be). Upon further investigation, I found that the 84th byte in "password.bin" is a EOF character, but the "/b" directive should have caused 4DOS to ignore this. Watch out for this problem! Before I discovered the bug, my device driver file crashed my system because not all of the code was there! I will try to alert JP Software of this problem. -Kevin Kahl mee@ucscb.ucsc.edu
LC.YRS@forsythe.stanford.edu (Richard Stanton) (03/28/90)
In article <2143@darkstar.ucsc.edu>, mee@ucscb.UCSC.EDU (Kevin Kahl) writes: >It seems that 4DOS version 3.0 has a new bug. I wrote a device driver that >is in two parts. These are the commands that I used (in a batch file under >4DOS v2.2) to concatenate the to files into one: > > copy /b password.bin+password.txt password.sys > >The resulting file does not include everything! "password.bin" is 859 bytes >in length. "password.txt" is 4000 bytes. The resulting "password.sys" is >only 4083 bytes, though. Under 4DOS 2.2, the resulting length was 4859 (as >it should be). Upon further investigation, I found that the 84th byte in >"password.bin" is a EOF character, but the "/b" directive should have >caused 4DOS to ignore this. > I don't know if this solves the problem, but if you look at the 4DOS help for the COPY command, it shows /A and /B being used AFTER at least one file name. According to the description, these affect the preceding filename and any succeeding filenames until the next /A or /B flag. What happens if you try copy password.bin+ /B password.txt password.sys I agree that this is rather clumsy looking, even if it works. Richard Stanton pstanton@gsb-what.stanford.edu
jrwsnsr@nmtsun.nmt.edu (Jonathan R. Watts) (03/28/90)
In article <2143@darkstar.ucsc.edu>, mee@ucscb.UCSC.EDU (Kevin Kahl) writes: > It seems that 4DOS version 3.0 has a new bug. I wrote a device driver that > is in two parts. These are the commands that I used (in a batch file under > 4DOS v2.2) to concatenate the to files into one: > > copy /b password.bin+password.txt password.sys > > The resulting file does not include everything! "password.bin" is 859 bytes > in length. "password.txt" is 4000 bytes. The resulting "password.sys" is > only 4083 bytes, though. Under 4DOS 2.2, the resulting length was 4859 (as > it should be). Upon further investigation, I found that the 84th byte in > "password.bin" is a EOF character, but the "/b" directive should have > caused 4DOS to ignore this. Have you tried putting the /B after the list of concatenated files? As in: copy password.bin+password.txt /b password.sys I remember reading in the update file for 3.0 that the /a and /b parameter interpretation was altered somehow. According the help on copy, what you did SHOULD work, but oh well. Try it the above way. - Jonathan Watts jrwsnsr@jupiter.nmt.edu (Internet address)
richard@calvin.spp.cornell.edu (Richard Brittain) (03/28/90)
In article <2143@darkstar.ucsc.edu> mee@ucscb.UCSC.EDU (Kevin Kahl) writes: >It seems that 4DOS version 3.0 has a new bug. I wrote a device driver that >is in two parts. These are the commands that I used (in a batch file under >4DOS v2.2) to concatenate the to files into one: > > copy /b password.bin+password.txt password.sys > >The resulting file does not include everything! I played with this some, and found that: copy /b src1+src2 target only src2 treated binary - as above copy /b src1+src2 target /b both files treated as binary copy src1+src2 target /b both files treated as ascii copy src1 src2 target appends as if +, src2 treated as binary The actual specification for "copy" is so confusing (IMHO) that it's difficult to see which lines are in error Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard