If you just need some pointers for how to handle the text, then consider:
You are going to need three things: some way to insert/replace characters, some way to move around, and some way to draw then interesting part. Once you've solved those, rest is going to be pretty easy. (edit: "easy" as in design-by-solving-bugs)
No matter how you keep track of the text, it's pretty easy to move back and forward one character at a time. For up and down movement, you could keep each line in memory separately, with say linked list of the lines. That'll allow you insert more lines (or delete some) easily. So moving down, you find the next line.
You then need to be able to jump at the correct position on the next line. Easiest thing would be to use something like STL vector -- that is autoresizing array. Inserting in the middle of a line will be pretty expensive this way, but you could assume most lines aren't very long, and just copy the rest of the line forward.
You could then make it more efficient by taking advantage of the fact that most of the time user types more than one character at a time, and keep the last sequential insert in a separate buffer, and special case your display code to check when it hits that part. You can do the same (by using some sort of skip <start,end>) for deletions, and compact the line any time user moves around or saves or whatever.
Or if you want to go even fancier, make your lines become ropes: you keep a list of "segments" which basicly contain two pointers (or one pointer and a length) to the actual string which is stored elsewhere. To insert, you split the segment into two smaller segments, and add a third segment into a fresh buffer in the middle (which should obviously be resizeable in itself). Similarly deletions now simply become nothing but segment modifications.
Ropes will also make it relatively inexpensive to keep track of the previous state, which'll allow you to add unlimited undo if you want pretty easily. And you can make special segments which contain information like "this part of the file on disc" if you don't want to keep the whole file in memory but in a temporary swap file. This'll allow you to edit any size of files (well any size that filesystem can support). Probably not worth it for the first version, but...
There are other possibilities ofcourse. You might want to periodically compact your ropes, or maybe keep only the current line as a rope, though this'll make undo a bit trickier to implement.
Anyway.... with some sane representation in memory, which allows you to access particular lines, you can then keep a number (or pointer if you use list of lines) to top-most visible line (or some variation, doesn't really matter). This allows you to redraw screen starting from that line, until you hit the bottom of screen. If you want to allow horizontal scrolling, then you need to skip stuff on every line until the current horizontal scrolling position. If you instead scroll one line at a time, you only do this on current line. If you want to overflow, then just handle overflow like you would for a console, and it'll work as long as you make sure to scroll (that is, move topmost line forward) before your cursor falls out from the bottom.
You can implement partial redraws for line inserts/deletes quite easily.. for single line even easier. But if you manage to manage your text in a sane way, this stuff will be pretty easy to figure out later.
Since you probably don't want to overflow midword (but instead of previous space if possible), you might find yourself constantly calculating how many "display lines" a given "logical line" takes. This is easily solved by realizing that lines length only changes when it's contents change, so you can cache this information in each line's "header". This'll btw make it possible to deal with variable-widths fonts pretty fast, though it's probably not very relevant here.
Now, if you can't handle linked lists and/or variable sized arrays because your memory manager is lacking, then you will have to fix that first, because writing a half-way decent text-editor without some sort of dynamic memory allocation is more or less impossible. Consider either malloc/free or some sort of a garbage collector a requirement.
mm...
That's about it, I guess...
) because I know a lot of what's happening behind the scenes.