Mail Archives: opendos/2003/11/30/21:01:25
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
- Raw text -