Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

Thread: Alt+Letter key problm in win32 console

  1. #11


    My current plan is to allocate each line independently, so if it is a line with 5 bytes on it, I'm going to allocate 7 bytes for it, the first 2 are the line length and the remaining 5 hold the characters. I know for DOS this would consume 16 bytes because DOS allocates in 16 byte chunks with the first 4 bytes being used for a pointer to manage the allocation. So ask for 7 or 12, it will consume 16. Each line will be a memory allocation form the heap which seems crazy if you have thousands of lines, but a necessary evil unless I can come up with a better idea. Line editing is easy. I'm going with a 4094 byte maximum line length unless to push it to 8K. When editing a line, that line is copied into a local 4K buffer and edited. When we are done, I will allocate a new line to hold the modified line, delete the old line, and update the pointer for that line to point to the new one. Deleting or inserting a line I just do a movmem on the pointers to the lines moving them all up or down. It will refuse to work with a file that has lines longer than it supports.

  2. #12
    Join Date
    May 2009
    Blog Entries


    It has been a long time since I last wrote a line editor but that seems likely to be very slow when inserting text into a line or splitting a line into two.

  3. #13


    Inserting into a line would pay the penalty when leaving that line, but not during line editing. Splitting a line in two does involve moving pointers in memory in that 64K block, but I'm not sure there is a better way unless I moved to a linked list type of thing and that would use yet more memory...

  4. #14


    I found that the overall best compromises come with a flat memory model: a file in memory as a single continuous string of characters including carriage return characters.

    I used to always have a single separate line for editing which would be inserted into the flat file upon the cursor leaving the line. But my latest editor works much better. I have an invisible character which I call a "deleted character". The flat file is edited directly, and when a character is inserted, 19 more "deleted characters" are inserted. So further typing just replaces those deleted characters until they are depleted, and then 20 more are inserted. This causes a delay at the beginning of and occasionally during typing, as the file is spread to insert the deleted characters. I find this very tolerable, whereas I do not find tolerable the delay when leaving a line. This is because when I'm typing, I'm always going ahead (and the keyboard buffer is filling) whilst the delay happens. This doesn't interrupt my train of thought like the delay after typing does, partly because cursor movement is always delay-free.

    It works very well with a 40k file in a stock C64; it should work very, very well on a modern "PC".

    The one caveat is that I found it not feasible to track line numbers. I can seek for a line number but never know what line the cursor is on after that. Of course, this will be very feasible on a GHz machine. Cursor column tracking works very well.

    Line length is infinitely variable and always efficient: a line can be one character or 40k characters (my self-imposed memory limit). No memory is ever wasted on this. Memory can get very fragmented if lots of characters are deleted. But I have a way to detect high fragmentation and then defragment the file (by removing all the deleted characters).

  5. #15


    I appreciate the good memory allocation ideas KC9UDX - I'm just about done creating a WIN32 getch equivalent that uses ReadConsoleInput instead and will be able to try some of your ideas!

  6. #16


    Good luck! Please let us know how it goes.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts