6

Using the E editor included with IBM PC DOS 7, I can't open a particular plain text file without encountering a "Not enough memory" error. The editor was invoked with the /S switch to make it handle large files (i.e. E.EXE /S FOO.TXT), and E hasn't had problems opening others, both larger and smaller than this one. The file in question has 40320 lines and 1572480 characters, and can be generated by a simple program:

#!/usr/bin/env python3

words = ('one', 'two', 'three', 'four', 'five', 'six', 'seven', 'eight')

def permuts(items):
    if len(items) < 2:
        yield tuple(items)
        return

    for i in range(0, len(items)):
        for rest in permuts((*items[:i], *items[i+1:])):
            yield items[i], *rest

for p in permuts(words):
    print(' '.join(p), end='\r\n')

Note: PC DOS 2000 (it also has E 3.13v) was also tried with the same result. None of the other editors tested, be it MELite (DOS, same configuration), Notepad (Windows) or vi (Linux), has any problem opening or editing this file as plain text. Perhaps someone can shed some light on why E is encountering difficulty with this specific example? In case it's relevant, testing was conducted with PC DOS 7 virtual machines, in both VirtualBox and VMware formats.

Improve this question
22
  • 4
    It might not like so many lines (40320).
    – Brian
    Nov 18 at 14:10
  • 4
    "It might not like so many lines (40320)." Even though I've opened larger files, it didn't occur to me the number of lines might be affecting the editor. When I get back to DOS on Monday, I'll modify the file by joining lines and see if that makes a difference and report the outcome. Either way, thanks very much for the suggestion since I hadn't thought of it :)
    – P. Skelling
    Nov 18 at 14:37
  • 5
    You may find that the maximum number of lines is around 2^15.
    – Thorbjørn Ravn Andersen
    Nov 18 at 17:03
  • 3
    Four bytes pr line in a 64 kb segment and some initial house keeping.
    – Thorbjørn Ravn Andersen
    Nov 20 at 21:29
  • 4
    Four bytes per line sounds very much like it could be a file offset (for up-to-4G files), so you could relatively quickly seek to the start of any given line. Had you the source code, you could store the offset of lines 11, 21, 31, etc, and increase the file size capacity (in terms of line count) tenfold. Of course, looking for line 33, you would then have to seek to line 31 and read, counting newlines. Depends on whether you'd rather have slightly slower but larger files. Or, I could be wrong, my wife and kids will confirm that happens occasionally :-)
    – paxdiablo
    Nov 20 at 22:48

1 Answer 1

Reset to default
1

MS-DOS edit also had trouble with text files as small as a few hundred KB in my experience.

When you think about the technical problems involved, and the difficulty of memory management in DOS it's not at all surprising that there would be problems editing a file that has trouble fitting entirely into the lower memory area with the executable.

And even when it does there are often performance issues later into the file.

When I read old Project Gutenberg texts in DOS I had to use a program that was explicitly a reader so it could reasonably assume it only needed about a screen of the file loaded at a time. (In my case this was integrated in QuickFiler, the MC clone I had on every system)

This works with MELite specifically because the program was designed to make it possible. And with Notepad because Windows has better memory management (and might also have code specifically for this).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .