I can see it all now. No longer will future generations have to put up with the sad litany, "When I was your age, I had to walk two miles through the snow ...." Instead, kids will be hearing something like, "Well, when I was your age, I only had 64K of memory to work with." And instead of "Tell me, what did you do in the war, Dad?" parents will be asked "Tell me Dad, what was it like to write programs in 256K of memory?"
Yes, having only 64K (or even 256K for that matter) of memory is pretty much a thing of the past, although veterans of the PC wars (those guys with the hint of gray in their hair and the melancholy smile on their face) still reminisce about the good old days of limited memory, slow CPUs, and 8-inch disk drives.
What's particularly interesting about the current memory situation is that even though the problem of limited memory has --to some degree --gone away, the problems of efficiently using whatever memory is available remains. What with larger, more complex programs, TSRs, and a host of other constraints (don't forget that OS/2 requires nearly 2 Mbytes just to boot!), memory management problems haven't even begun to go away. And therein lies one of the reasons we're taking a look at memory management this month.
Two of our articles --"More Memory for DOS Exec" and "SWAP" --take different approaches to a similar problem: how to swap programs in and out of expanded memory (or disk) so that you can free up main memory to use more than one program at a time. In the first of these articles, Kim Kokkonen shares with us some of the actual techniques he uses in the development of his TurboPower tools, proving that he's a good writer, as well as a good programmer.
Two other of this month's articles --"Demand Page Virtual Memory" and "Advanced 80386 Memory Management" --also look at similar topics. In the first instance, Kent Dahlgren examines the general subject of demand page memory and discusses how different CPUs handle paging. In the second, Neal Margulis looks in depth at demand paging on the 80386.
These won't be the only articles we'll be running that discuss the problem of memory management. The topic is too important to simply touch on and forget.
The last time we asked for articles was in October and we heard from a lot of you who had all kinds of good ideas for articles. You've already seen some of those articles in print and you'll see more in the next few months. But don't let up. If you have an idea for an article, get it (the idea or the article) to us.
What kind of articles are we looking for? Well, how about one that discusses your approach to memory management. What kind of articles would you like to see in the magazine? What kind of articles would be useful to you? If you have a useful utility or technique, you can bet that other readers would find it just as useful.
The editorial calendar for the rest of the year looks like this: May, Structured Languages; June, Operating Systems; July, Graphics; August, the Annual C Issue; September, Modeling and Simulation; October, Telecommunications; November, Parallel Processing; and December, Object-Oriented Programming. While we're looking for articles on these subjects, we'll consider just about any task-specific, code-intensive article. If you miss one of our deadlines (say you have a graphics article but don't get it done in time for our July issue), don't worry. If it's good, we'll run it at anytime.
If you have any ideas for articles on any of the above topics --or others --give Kent, Mike, or me a call at 415-366-3600, or drop us a note at DDJ, 501 Galveston Drive, Redwood City, CA 94063. We can also be reached on CompuServe (#76704,50), MCI Mail ("DDJ"), or BIX ("jerickson"). We'll look forward to hearing from you and publishing your articles over the coming months.
Copyright © 1989, Dr. Dobb's Journal