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
James Marlin said:
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"
