How does one test for the end of a file ( I've been programming C for the last couple years and have totally forgotten how to do this in Masm :( ) . Thanks.......
Try ReadFile with a test if bytes read == bytes requested.
You can keep a count of how many bytes you've read (in total), and compare that against the file-size.
Or, keep reading until NumberOfBytesRead is zero (while ReadFile still returns true.)
Ok , thanks for the information! Is there actually something at the end of the file that corresponds to a "end of file" character , or is that completely a high level language abstraction? Thanks.
No EOF character if you use something like InputFile macro this simply returns a 0 terminated file you can test for with cmp al, 0
The file system holds the length/extent of the file as part of the metadata, it is not visible within the file.
The character 26 , 0x1A, Ctrl-Z, EOF has been used as an End-Of-File marker in some older systems (like CP/M) where the allocation granularity is greater than 1 byte (128)
Hi cman,
You can use the C run-time functions in your asm code to read a text file.
Quote from: clive on June 13, 2010, 05:20:48 PM
The file system holds the length/extent of the file as part of the metadata, it is not visible within the file.
The character 26 , 0x1A, Ctrl-Z, EOF has been used as an End-Of-File marker in some older systems (like CP/M) where the allocation granularity is greater than 1 byte (128)
If you use COPY in Command Prompt (DOS window) to concatenate several files, you will get a Ctrl-Z at the end of the target file. If you then concatenate several of these files to a third file, it will strip the Ctrl-Zs from the source files, but still add a trailing Ctrl-Z on the new target file. Just copying a single file to another file will not add the Ctrl-Z.
if you specify them as binary files (/b), it will not add the ctrl-Z
copy file1/b+file2 file3
Quote from: dedndave on June 13, 2010, 10:49:04 PM
if you specify them as binary files (/b), it will not add the ctrl-Z
copy file1/b+file2 file3
Thank you, Dave.
Interesting that the help file "/?" does not mention that, but then again, this is Microsoft documentation.
Quote from: KeepingRealBusy on June 13, 2010, 08:52:13 PM
If you use COPY in Command Prompt (DOS window) to concatenate several files, you will get a Ctrl-Z at the end of the target file. If you then concatenate several of these files to a third file, it will strip the Ctrl-Zs from the source files, but still add a trailing Ctrl-Z on the new target file. Just copying a single file to another file will not add the Ctrl-Z.
And it will terminate on the first Ctrl-Z character it encounters, which might prove to be particularly problematic. Not that you can combine two Excel sheets into one using this method, so it's mainly a text file concatenating tool.
they do mention it
but what they fail to mention is that the default mode is ascii
they also don't say a lot about what binary and ascii modes actually mean - lol
i think older versions of the help text might be more informative in this regard (like DOS or win98)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Dave>copy /?
Copies one or more files to another location.
COPY [/D] [/V] [/N] [/Y | /-Y] [/Z] [/A | /B ] source [/A | /B]
[+ source [/A | /B] [+ ...]] [destination [/A | /B]]
source Specifies the file or files to be copied.
/A Indicates an ASCII text file.
/B Indicates a binary file.
/D Allow the destination file to be created decrypted
destination Specifies the directory and/or filename for the new file(s).
/V Verifies that new files are written correctly.
/N Uses short filename, if available, when copying a file with a
non-8dot3 name.
/Y Suppresses prompting to confirm you want to overwrite an
existing destination file.
/-Y Causes prompting to confirm you want to overwrite an
existing destination file.
/Z Copies networked files in restartable mode.
The switch /Y may be preset in the COPYCMD environment variable.
This may be overridden with /-Y on the command line. Default is
to prompt on overwrites unless COPY command is being executed from
within a batch script.
To append files, specify a single file for destination, but multiple files
for source (using wildcards or file1+file2+file3 format).
Quote from: jj2007 on June 12, 2010, 09:27:27 PM
Try ReadFile with a test if bytes read == bytes requested.
Quote from: Tedd on June 13, 2010, 11:30:05 AM
You can keep a count of how many bytes you've read (in total), and compare that against the file-size.
That is indeed the proper way to do it. The test
.if bytes read < bytes requested then shout eof works fine if you want to emulate the EOF() thing, but Tedd's advice is more "planning oriented" than the rude "oops I hit the end".
Here's the DOS 6.22 help for copy (from the command 'help copy').
The 'copy /?' command is basically the same as dave posted, just missing /D /N and /Z
In MASM using standard Windows API calls you do as JJ mentioned, get the file length and don't try and read past it. If its a file small enough to be read into memory, allocate enough to read the whole file into memory and treat the allocat3eed memory in the normal manner, read and write to any part of the address space but don't go past the end.
Quote from: cman on June 13, 2010, 04:00:47 PM
Ok , thanks for the information! Is there actually something at the end of the file that corresponds to a "end of file" character , or is that completely a high level language abstraction? Thanks.
It's a
file format "abstraction". All files are binary, but some can be interpreted as text files. By definition, every byte in a binary file can have any byte value. This includes carriage return, line feed, "end-of-file", and zero-byte "characters".
A text file can be ASCII, ISO-7, or some form of Unicode. Depending on the software/hardware platform you're using, the text can vary as to how files and lines are terminated. The most obvious example is the difference between Linux/Unix and Windows text files. If you transfer files between your Windows system and a Linux web host, you need to be aware of the existence of the difference.
BTW, there is no standard EOF character. The value 0x1A (SUB, ctl-Z), which is recognized by some WIndows programs and libraries, is a legacy of the CP/M system. I have seen 0x19 (EM, ctl-Y) and 0x04 (EOT, ctl-D) used as EOF characters on ASCII-based systems.