home bbs files messages ]

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