DOS conventional memory

[Jason]

How do you increase the conventional memory and largest
executable program size? Seems like conventional memory
should be related to the RAM in the machine.

 

[Tom Swift]

There is no DOS in Windows XP.

Tom Swift

 

[Walter Hawn]

Contrary to Mr. Swift. DOS is alive and well in XP. It is simply in a
different place and differently implemented.

DOS no longer forces programs to load at 100h. Instead, DOS is loaded
(okay, a DOS emulator that works like DOS, quacks like DOS, and is just as
pretty) wherever XP (or NT5.1, if you prefer) finds handy. You get a
dynamic main memory stack that can be modified using the PIF file property
sheet (create a shortcut for your DOS program, right click, then open
properties). And you can make other environment changes with AUTOEXEC.NT
and CONFIG.NT . In fact, you can have several differing versions of the
configuration files, to customize DOS as you like, for various applications.
You can run (subject to available total memory) several instances of DOS at
the same time. And the XP help files are truly helpful!

From Help and Support:

MS-DOS overview
MS-DOS, the acronym for Microsoft Disk Operating System, is an operating
system with a command-line interface used on personal computers. As with
other operating systems such as OS/2, it translates keyboard input by the
user into operations the computer can perform, it also oversees operations
such as disk input and output, video support, keyboard control, and many
internal functions related to program execution and file maintenance.

You type MS-DOS commands using a command prompt window. To end your MS-DOS
session, type exit in the command prompt window at the blinking cursor.

--
Hope this is helpful,

Walter Hawn

Assoc XPert
Please reply within Newsgroup
email addy is fictitious

 

[Guest]

Actually Tom, XP does have a DOS. The problem is, it not a native mode, but more like an emulation mode that resides on top of the native XP operating system.
This means it's really limited in what it can be used for, and running something really complicated (like a game) is all most impossible with the XP DOS.

As for "DOS conventional memory" Jason, it has nothing do with how much memory you have. Instead it has to do with a limitation of the early MS-DOS. I'm kind of sketchy on the details but here goes any way.

When MS-DOS first came out it had a built in limitation of only being able to access 640 bytes of memory. As far as I know it was felt no one would need more memory then that. When systems with more the 640 bytes of memory started coming out, they built a work around in to MS-DOS that managed the memory, letting MS-DOS access the memory above the first 640 bytes.
At this point the first 640 bytes of memory became know as "conventional memory", and any be on that as expanded, extended, or "high" memory. I think the term depends on which memory manager DOS is using.

The problem is that some DOS programs, either by nature or design, need a set amount of conventional memory to run. In fact some need all most all of it. To do this you need to remove most drivers/programs/threads running in conventional memory, either by closing them, or moving them into high memory. This was fairly easy to do with DOS/3.1 or 95/98 (do able under ME, but much harder). But I'm not sure how you'd go about it under XP, or if it's even do able.

Usually DOS programs needed the high amounts of conventional memory to run sound drivers. Try running the program without enabling sound in the set-up program. Another idea is to dual boot with 95/98, then you could run the program in it's native DOS mode or even use a "boot disk" to re-boot into a DOS "real mode"

Any one with any other ideas?

 

[Tom Swift]

I stand by my original post. Even Mr. Hawn acknowledges that XP includes
only "a DOS emulator that works like DOS". This emulator is not MS-DOS and
does not support many of the features of MS-DOS. The last Microsoft
operating system that was based on MS-DOS was ME.

Tom Swift

 

[Guest]

True Tom, any NT based OS is true 32bit only.
So DOS (16bit) would only be available in an emulation type mode. But does that really matter?

I've played around with emulation a bit, and know that a well written emulator can run anything written to run on the original. It all depends on the capabilities built in to the emulator (and speed needed). I was under the impression that the DOS in XP was built with running only very basic DOS programs in mind.

It seems I might be mistaken. If it's true that XP DOS can "goof" a DOS program into believing any 640 byte address range is a "virtual" DOS conventional memory, that would go a long way to extending XP DOS's capabilities. I can see where there might be a few problems due to driver structure with in the DOS program, but I'm sure that could be worked around as well.

Walter can you supply any links to either a FAQ or a tutorial on editing XP DOS pifs?
I'm well versed in editing "boot" disks and pifs, I just never bothered in XP because I have another old computer to run all my older programs on. So if a DOS program didn't run under XP I just didn't bother going the extra bit, to force it to.

 

[Tom Swift]

Looking back on the posts in this thread, I can see that we're disagreeing
on semantics, and I want to apologize for any confusion I may have caused.
My only point is that XP does not contain a fully functional, configurable
MS-DOS environment.

There is no question that the command line environment of Windows XP
supports many ostensibly DOS commands. And it's also accurate to say that
what XP refers to as 'compatibility mode' could just as well have been
called an emulation mode.

My virtual hat is off to you, Mr. Marlin, for having played around with
emulation. That must be fascinating.

Tom Swift

True Tom, any NT based OS is true 32bit only.
So DOS (16bit) would only be available in an emulation type mode. But does that really matter?

I've played around with emulation a bit, and know that a well written

emulator can run anything written to run on the original. It all depends on
the capabilities built in to the emulator (and speed needed). I was under
the impression that the DOS in XP was built with running only very basic DOS
programs in mind.

It seems I might be mistaken. If it's true that XP DOS can "goof" a DOS

program into believing any 640 byte address range is a "virtual" DOS
conventional memory, that would go a long way to extending XP DOS's
capabilities. I can see where there might be a few problems due to driver
structure with in the DOS program, but I'm sure that could be worked around
as well.

Walter can you supply any links to either a FAQ or a tutorial on editing XP DOS pifs?
I'm well versed in editing "boot" disks and pifs, I just never bothered in

XP because I have another old computer to run all my older programs on. So
if a DOS program didn't run under XP I just didn't bother going the extra
bit, to force it to.

 

[Walter Hawn]

Hi James,

The "limitations" on DOS in XP are primarily caused by programmers who used
absolute addressing rather than relative. When programs *had* to load at
100h, absolute memory addresses were possible, but were and are not good
programming practice.

It's true that absolute addressing is faster, since the program doesn't have
to calculate an address every time it's needed, and when a *fast* processor
was 33mhz, every flip-flop counted, so that's why game programmers,
especially, did it absolutely.

Consequently, many DOS games not only won't run properly on XP, but they
often won't run properly on 'real' ms-dos (BTW, the DOS in XP runs the very
same way as the 'old' DOS, except that it loads at any memory location, and
uses the windows system for video and printer output) unless they are the
*first* (and often only) program loaded.

Using the PIF property sheet is very strightforward: Right click on your
DOS program, select 'create shortcut.' Then, right click on the shortcut,
select 'properties.' There's your PIF editing sheet. It's GUI, so select
the (for example) 'memory' tab. The default is 'auto' which clears a buffer
as large as the program requests at initialization. Some call for EMS or
XMS as they load, and XP will handle that as well. Others need explicit
configuration, and the pick boxes let you do that. A very few need to be
run as if under win95, and that is also configured on the PIF sheet, under
"compatibility." Other environmental values and drivers are configured in
AutoExec.NT and Config.NT . You can have a global pair (in
\windows\system32) or you can use any number, customized for each app, with
new names and/or locations by specifying the file on the "Program>advanced"
tab (help and support, search on 'autoexec.nt', for step-by step, if
necessary)

Because DOS can be loaded at any address in XP, any given absolute address
is likely to be smack in the middle of the XP system space, causing crashes.
Many folks see that as a flaw, but Microsoft has never supported absolute
addressing, and constantly warns against it. Space Invaders runs just fine
under XP, and that's the best game ever, so I'm happy.

Actually, I have not found, outside of games, any properly written programs
that won't run under XP DOS. I use WordStar, Alpha4, Borlund's compilers,
DR DOS utilities, and lots of old freeware stuff. The old, and lamented, PC
Tools runs just fine (although they are no longer needed) , Qdos runs and so
does Xtree.

During the beta, MS folks made it clear that they wanted DOS to operate in
XP exactly as you would expect it to. I think they succeeded brilliantly.

Regards,
Walter Hawn

Actually Tom, XP does have a DOS. The problem is, it not a native mode,

but more like an emulation mode that resides on top of the native XP
operating system.

This means it's really limited in what it can be used for, and running

something really complicated (like a game) is all most impossible with the
XP DOS.

As for "DOS conventional memory" Jason, it has nothing do with how much

memory you have. Instead it has to do with a limitation of the early MS-DOS.
I'm kind of sketchy on the details but here goes any way.

When MS-DOS first came out it had a built in limitation of only being able

to access 640 bytes of memory. As far as I know it was felt no one would
need more memory then that. When systems with more the 640 bytes of memory
started coming out, they built a work around in to MS-DOS that managed the
memory, letting MS-DOS access the memory above the first 640 bytes.

At this point the first 640 bytes of memory became know as "conventional

memory", and any be on that as expanded, extended, or "high" memory. I think
the term depends on which memory manager DOS is using.

The problem is that some DOS programs, either by nature or design, need a

set amount of conventional memory to run. In fact some need all most all of
it. To do this you need to remove most drivers/programs/threads running in
conventional memory, either by closing them, or moving them into high
memory. This was fairly easy to do with DOS/3.1 or 95/98 (do able under ME,
but much harder). But I'm not sure how you'd go about it under XP, or if
it's even do able.

Usually DOS programs needed the high amounts of conventional memory to run

sound drivers. Try running the program without enabling sound in the set-up
program. Another idea is to dual boot with 95/98, then you could run the
program in it's native DOS mode or even use a "boot disk" to re-boot into a
DOS "real mode"

 

[Walter Hawn]

Tom,

DOS in XP is 'fully functional and configurable.' The only thing not
allowed is absolute memory addressing -- and that was never supported by
Microsoft, nor by Digital Research. The ability to use it in DOS is an
artifact caused by loading all programs at 100h. Any DOS program that uses
relative addressing (that is, calculates the desired address, rather than
explicitly stating it) should run under XP. I've tried every utility from
MS (6.0) and DR DOS (6.0 & 7.0), except the memory and disk compression
managers (which naturally would conflict w/XP) and they all run under XP.

Regards,
Walter Hawn