Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,449 of 4,675    |
|    Mateusz Viste to All    |
|    Re: text editor basics    |
|    29 Jun 18 09:24:07    |
      From: mateusz@nospicedham.wont.tell              On Thu, 28 Jun 2018 16:52:15 -0700, bilsch01 wrote:       > 1. I believe I must decide on a maximum (MAX) file size it will work       > with. If the user tries to load a larger file (document) I must issue       > an error saying to choose a file less than MAX. I think a good size for       > MAX might be 96k (3 clusters) but that might be too ambitious. NOTE: I       > don't know how much memory I can use before overwriting essential BIOS       > information. OS (text editor included) begins at 0x7e00.              Having a text editor limited to few KiBs of data is extremely painful to       users. Or at least to me.              For reading a file you don't need to load it into memory all at once -       you just need to load enough to fill in the screen (possibly a little       more after and before, to limit the amount of disk accesses.              Editing is more complicated. I can think of two ways to handle it that       wouldn't require loading all the file into memory:              1. remember only the changes that the user did, and re-do them at save       time. This means obviously that the amount of pending changes will be       limited, and once the changes buffer is filled, the user will be asked       for saving the file to continue. This is the approach I used in my hex       editor, uHex (uhex.sf.net). It may or may not be suitable to a text-       editor, though. The amount of changed that one could expect from within a       text editor is much larger than when hex hacking.              2. as soon as the user starts editing the file, copy it into a temporary       area and perform all editions on-disk. Some caching will be required       anyway, so the user do not become crazy seeing his floppy disk writing       stuff at each key press (perhaps simply apply changes when reloading the       screen buffer).              Then of course there is the alternative of keeping the full file in       memory indeed, but reaching for much more memory than you intend to       (Megabytes, not Kilobytes). Requires XMS (if real mode), and 386+.              Mateusz              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca