X-Authentication-Warning: delorie.com: mail set sender to opendos-bounces using -f From: shadow AT shadowgard DOT com To: opendos AT delorie DOT com Date: Sun, 30 Nov 2003 17:46:08 -0800 Subject: RE: several technical problems Message-ID: <3FCA2CE0.2845.10FE3A6F@localhost> References: <3FC852ED DOT 28215 DOT 9D331A3 AT localhost> In-reply-to: X-mailer: Pegasus Mail for Windows (v4.02) Reply-To: opendos AT delorie DOT com On 30 Nov 2003 at 12:42, DONALD PEDDER wrote: > > What exactly happens if you try to enable multitasking > > (DEVICE=EMM386.EXE MULTI [...] then load TASKMGR without /S)? > > I haven't tried that - I'll give it a go tonight. I'm just used to the > task-switcher, so maybe this is a better way to go. > > > > Please read about ANSI and PROMPT in DOSBOOK. > > I've tried to find it before, but couldn't see what I was looking for. > Maybe it was a bit obscure? I'll have another look. Look up ANSI.SYS > > The programs that run in (8086-compatible) Real Mode of CPU can use > > extended memory only as a swap space (to move some data/code back and > > forth between lower 640 Kb and extended memory), but of course only if > > given program has such a feature built-in. > > Other than bitcom and DR-DOS stuff (e.g. the editor), the only programs > I'm running are ones I've written myself. How do I build that in? (perhaps > that's a question for the FPC list) Depends on the compiler. Trying looking up "overlays" (I know that was what Turbo Pascal used). > > There are also programs which run in Protected Mode (either 16-bit, on > > 80286 and above, or 32-bit, on 80386 and above), which can use all > > memory directly. But they are different programs. > > I've never written programs that directly access memory. I just write > the high-level code and let the OS take care of the particulars (that's > what it's for after all). In the sense he's using "directly" *all* your programs have done so. But only conventional RAM. > I seem to remember a few DR-DOS sources were made available a while > back - was the editor one of them? There are a lot of text edior sources available. > > Some information about minimum memory requirements is stored in EXE file > > header, > > How do I look at that? Is there a special editor or something? If I do > a "type" on it all I see is garbage. You need to look at a hex dump of it. Try DEBUG. Even then you'd need some reference materials to make sense of the header info. > How much memory would I need to run the editor? At the moment I do > "type filename|more" to look up stuff on my computer while online, but > obviously the editor is a more convenient method to use. If you aren't actually *editing* the file, using an editor to just read the file contents is *massive* overkill. Try finding a copy of LIST. It's a program for letting you display files and scroll them them. Similar fiunctionality is built into 4DOS's LIST command. > > > This says I have 46Mb available via XMS - how do I make the programs > > > use that? > > > > You don't. Unless they are written to use it, they *can't*. > > Since I'm writing my own programs, I can. :-) The question is how? By using whatever facilities the compiler has for storing data in that part of RAM, and for swapping code to there. Since you'll be running in "real" mode, you can't directly execute code in XMS RAM. So you have to swap unused procedures and functions to there. Part of the trick with the older compilers I'm familiar with was making sure that you grouped code modules such that you didn't have ones that depended on each other in the same "swap group" (ie stuff that got swapped into the same chunk of conventional RAM). > > Well, that's one of the problems. Working with DOS at this level is > > *inherently* "technical". > > I'm more software than hardware. I can explain to you how a computer > works, but if you put one in front of me to work on, it's just a disk and > a bunch of wires to me. :-) Like with cars - I can tell you about 2 stroke > vs. 4 stroke, how turbo-charging works, etc., but if my car's broken down > I wouldn't know where to start (other than looking for loose wires, which > was precisely my problem racing last week, only the loose wire wasn't in > the engine bay - it was under the back of the car at the fuel pump, and > wasn't found until after my first race :-( ). Technical in the sense that you have to know what "conventional", "upper", "high", "extended", "expanded", XMS, and maybe other types of RAM are. And how they get accessed by the CPU and programs (including what drivers may be required for them to be available). > > Desqview or Taskmgr effectively create separate "640k" (minus > > drivers)areas for each task. > > So how do I make taskmgr do that (given that it's apparently not doing > that at the moment)? Go from task-switching to multi-tasking? Dunno, I had already been using DV before I got into DR-DOS. Wasn't worth learning TaskMgr. And I was switching to OS/2 anyway. I would have completed the switch ages ago except I ran into some snages with getting IPX, TCP/IP and the comm ports to all work at the same time on the OS/2 box. -- Leonard Erickson (aka shadow) shadow at krypton dot rain dot com