There is not enough information to provide any kind of help.

DOS application needs to write text files to a specific directory. Files are created, but they are all empty

Many things can go wrong on your side, it's not possible to tell without more info, or better - the source of minimum example reproducing the problem.

konc wrote on 2024-10-09, 12:27:

There is not enough information to provide any kind of help.

vstrakh wrote on 2024-10-09, 16:44:

Many things can go wrong on your side, it's not possible to tell without more info, or better - the source of minimum example reproducing the problem.

at least you tried ...

strange how on many forums there are these very short requests (amusingly this example shortened even further when prompted for *more* detail.. 😀 )

I've seen it so many times and am never sure what the requesters are expecting, it's like you could answer "press Ctrl-x and then capital P three times and it will work" and get "ok" in response, just very odd !

Remember that all text files must terminate in one or more 0x1A characters and be multiples of 128 bytes in size.

Errius wrote on 2024-10-14, 12:48:

Remember that all text files must terminate in one or more 0x1A characters and be multiples of 128 bytes in size.

That's some weird spec.
It could have been a case for a certain environment, idk, like some editor based on screens (e.g. old Forth implementations, or some Basic), but this is not something true for DOS or a text files in general. Even if some software api's might react on 0x1A as end of file marker when opening the file for reading in a text mode - at best missing the 0x1A would mess up the reading loop, but not the ability to write the files, as stated in the question.

I was joking. That's how things were done in CP/M and DOS 1.0 days.

ETA: some examples of such files

Found the 128 byte requirement relevant to CP/M, the directory entry for the file specified the length of the file in 128-byte records (the echo of 128-byte sectors on 8" disks?), and the CP/M version 2.2 and below didn't store the number of bytes in the last 128-byte record. It makes perfect sense to pad the last 128-byte record with EOF symbol then 😀

The DOS 1.0 FCB structure is built with similar patterns in mind, tracking access to the file in blocks of 128-bytes by default, but it seems it's more of an abstraction there. The block size may be changed, and the FCB has the 4-byte field specifying the length of the file in bytes, so the alignment should be irrelevant? I guess the FCB and also the Pascal's way of handing 'untyped' files was designed specifically to support this 'normal' (at the time) flow - 128-byte records by default, but can be changed when you 'reset()' the file.

In the 80s, it was common for text editors for DOS to add the 0x1A byte at the end of file - I recall eg. Norton Editor behaving like that.

You can also create a text file by "copy con filename", then finish the input with Ctrl-Z - it should also add the 0x1A byte.

Yes, DOS was created with CP/M compatibility in mind...

so that wasn't a wasted thread in the end 😀 hope the op came back and learnt something!