PDA

View Full Version : real mode dos & win dos



scott27349
04-09-2002, 09:03 PM
this might be a stupid question, but what is the differance in real mode dos and windows dos? i have a piece of hardware that wont do anything in windows dos, you have to boot to real mode dos at startup to get it to work. is there anyway to build a program to make it work in windows dos?

Shiro
04-10-2002, 12:28 PM
I don't know which compiler you are using. But aren't there compilers switches which must be turned on, or perhaps there are some libraries that you need to link with?

Sunny
04-10-2002, 09:20 PM
I think, and this may be true, as I heard from someone else too, that in a windows dos box, the shell creates a virtual DOS machine. So, I think it's an enhanced version of dos, or a sort of emulation. Let's not forget, microsoft wrote both enviornments. One thing is certain however, if you are programming in a dos BOX under windows you also get access to LFN support, and i think it works in protected mode ( DPMI )instead of real time like under real DOS. Anyways, good thing you asked. I weas getting curious about it too...

Stef

VirtualAce
04-11-2002, 04:50 AM
LFN support has nothing to do with whether or not you are in Windows or not. It is just that DOS 6.22 DIR command does not show LFN. The LFN is already encoded within the DIRENTRY structure so whether you are in Windows or DOS, it is always there. You could write pure DOS code that displayed the LFNs.

The main difference between Windows and DOS is that Windows is a 32-bit protected mode muli-tasking environment and DOS is a 16-bit single task environment (for the most part). DOS will not function in protected mode. So if you pop the computer into protected mode you are essentially turning off DOS. In order to make common DOS calls and/or BIOS interrupts, DMA programming, etc., you need to use a DPMI (DOS Protected Mode Interface) server.

But even in a DOS shell you are essentially running in a semi-virtual 8086 mode which means that the same limitations placed upon you in pure DOS are also present within a DOS box. There are several other things I have noticed about running inside of a DOS box rather than pure DOS. It is possible to get away with wild pointers to a certain degree and you will get faster memory access under Windows than in DOS. I've tested this out on code that absolutely crashes in DOS, but does not within a DOS box.
For instance, it is possible to do a read() from within an interrupt handler in DOS box, but not in pure DOS. Pure DOS will re-enter itself and crash. DOS boxes will allow the program to continue functioning. This is probably because you are going through a virtual DOS mechanism which is taking care of the re-entry problems. Only a guess, but I do know that my sound code will work flawlessly in DOS box, but not in pure DOS.

There are several other differences but most are far too lengthy to discuss here.

xds4lx
04-11-2002, 09:16 AM
Only a guess, but I do know that my sound code will work flawlessly in DOS box, but not in pure DOS.

Sounds like bad software engineering to me (no offense or anything).

Imperito
04-11-2002, 11:43 AM
I would be interested to know why some programs will not run in a windows DOS box, they detect the presence of windows and require that the computer be restarted in DOS mode. There are very few such programs, as they obviously have the huge drawback of requiring a restart in DOS mode, but I have seen one or two that do.

These aren't new programs, the two I have encountered (a tabulation app and a game called cannon fodder) came out about six or seven years ago, but they refused to work under windows. Does anyone know what pure DOS gives you that win DOS does not?

SMurf
04-12-2002, 04:50 AM
I think that was something to do with when Windows 95 first came out, it let certain DOS operations which would completely crash it occur (not bad programming as such, just in situations such as Win95A + DOS game requiring access to soundcard = blue screen of joviality). In detecting the OS, the savvy DOS programmer could prevent this from happening. If you turn off Windows detection on a DOS program that uses it on Win98 it usually works relatively OK (unless something reeeeeally funny's going on). ;)

I liken Windows DOS limitations to that of running EMM386 in the background in the old pre-Win9x days. Some games in particular were very highly optimised and cheated with hardware access at almost every point and just getting away with it in real mode. However, when EMM386 was running, BOOM! System Halted :p. The bottom line:- DOS shells (the old ones at least) will make you do things the hard way. :rolleyes:

VirtualAce
04-13-2002, 01:59 AM
Only a guess, but I do know that my sound code will work flawlessly in DOS box, but not in pure DOS.



Not true.

What I think is happening is that Windows is allowing my code to be re-entrant, but DOS is not. Take that one read() out of my interrupt handler and everything functions ok.

Also the sound card requires 4 resets under DOS box to work and play sound, where under DOS the one reset will suffice and everything works. The solution to the real mode problem is to use an EMS buffer. The DMA cannot transfer data to/from anything above 1024MB. So what you have to do is allocate either an XMS buffer or EMS buffer and pass the physical address of that buffer to the DMA. Your code then, on interception of the hardware interrupt from the sound card, transfers the pre-loaded data from XMS or EMS to the page frame in the HMA or in the case of XMS to a frame below 640KB or the base RAM area. This is why all programs that use the sound card require some memory manager, even in protected mode, whether it be through XMS, EMS, or through the DPMI to gain access to memory under 1024MB.

So it is the read that is crashing my code. As for the DMA and sound card reset problem, I have no idea why this happens under a Windows DOS box but not pure DOS. But Windows is allowing the read() to take place and is handling the re-entrancy issues in such a way that the code functions perfectly.

But this is an example of how older DOS games can work and not work in a Windows DOS box. Most, if not all, retail DOS games tell you in their readme files to run the game in pure DOS only. This is because it is hard to predict what the virtual DOS machine will do inside of Windows. After all, it is not pure DOS it is emulated to 'look' and 'act' like DOS, but it is not pure DOS.

VirtualAce
04-13-2002, 02:00 AM
Sounds like bad software engineering to me (no offense or anything).


This is the quote that I mean to insert in my previous post.

Sunny
04-17-2002, 10:53 AM
So, wait, you're saying LFN is available in reeal dos??? Well...that would certainly come in nicely ... Only, i'm not sure how to get access to it... If you know about this, you probably know also if there are any lybraries... Speak up man, plz... I need to know...This is GREAT!! :D
I mean...anwy... thanks for telling me about..


Stef

BTW: I didn't mean to say that LFN was the difference...But anwy, it doesn't matter.

Discover the X[COLOR=blue]Blue enviornment.
Looking for alternatives to Windows for programmers.
http://www.angelfire.com/my/bahairomania/freegui.html

toaster
04-26-2002, 09:05 PM
interesting, I can't seem to make my Win32 console apps run under pure dos mode.

is Borland the only good compiler out there that makes DOS, not MS-DOS, compatible programs?

I'm currently using Visual C++ 6.0 under 98 right now.

Sunny
05-08-2002, 09:38 PM
At least Borland is cross-platform. And it's sometimes very tricky doing asm under windows Dos boxes.
This is just memoires from my experiences...:P

stef

fubar
05-10-2002, 06:30 PM
Sounds like bad software engineering to me (no offense or anything).

hmmm.....software engineering.....yes i can do that :D

Sunny
05-18-2002, 08:43 AM
Good enlightenment.
Thanks for the update, bubba.

btw,remember tha Shell we were all enthuziast about writing?
I haven't given up on the project. In fact, i'm still looking for people to help out.


Discover the XBlue:
http://www.angelfire.com/my/bahairomania/freegui.html

sean
06-08-2002, 07:47 PM
I don't know any of thje specifics, but Windows DOS is just meant to look like DOS. It's system is completely different. The environment causes problems for programs that use Real DOS-exclusive features. It would be like getting you to breath on Venus.

Unregistered
06-08-2002, 08:26 PM
The Windows DOS shell is just an emulated DOS, but it is so close to the original that I've never, repeat never, had any problem using assembly language or anything else. The only problems I've had are directyl related to hardware - in fact memory access is faster in a DOS box than in pure DOS.

If you don't believe me, fire up your favorite text editor and scroll down in both pure DOS and DOS shell. The DOS shell will run faster. So, in reality, your apps (if you still code apps for DOS) will run much faster in a DOS shell.

Also the DMA problem is directly related to how Windows is managing me messing around directly with the hardware. The DMA chip does not properly reset under a Windows shell so you must reset it 4 times. In pure DOS this is not a problem and its not related to my programming. Some DOS games wont even run in a DOS shell (Crusader and Crusader:No Regret for examples). This is because most DOS32 games load a sound driver into memory prior to running. Often times these drivers don't quite act the same in DOS shell as they do in pure DOS. So really your best bet is to code for Windows and not DOS. Personally, I despise Windows programming and about all I can take is enough to do DirectX and Direct3D.

Programming games and apps in DOS was usually very low-level and hardware specific so attempting to do this today on hardware designed to run under Windows is quite a daunting task. Best bet is to move to the Windows platform and come join the dark side :)

To quote Andre Lamothe - "...the dark side always seems to have the best technology."

Believe it or not you can setup a small Win32 shell in DirectX and basically write your graphics program or game just like you were inside of a DOS32 shell - with a couple of minor differences - but you can gain access to the video memory, or a pointer to it, if need be.

You can do this in DirectX:

videobuffer[y*320+x]=color;

But in DirectX it looks more like this:

videobuffer[y+x*mempitch]=color;

Same principle. Not to mention that in DirectX page flipping is trivial (not so in DOS) and you can use the hardware blitter easily (DOS takes some special low level interaction witht the hardware for this and is not guranteed to work with every card). Take my advice Sunny and move to Windows and DirectX - you'll never look back - I've made the move to the dark side if you will and trust me, it's really not that bad. I still code in DOS just to tinker around but for serious stuff I use Win32 or DirectX.

So go purchase a book like Tricks of the Windows Game Programming Gurus or something similar and make the move to DirectX - or buy a book on Win32 programming and dive in. Windows is very complex but thankfully it does not require that you know the entire API before you can use it.

If you want some more information, contact me via PM on this board. Just imagines being able to develop programs that had sound, GUI, great graphics, speed, stability, worked on nearly ever Intel/AMD config, and hid most of the low-level stuff from you so that you could concentrate on the task at hand instead of all the nitty gritty stuff.

VirtualAce
06-08-2002, 08:30 PM
Once again Bubba forgets to log in.

:D

sean
06-09-2002, 08:51 AM
there's still programs that require pure DOS environments. I know QBasic is one of them. At least the old versions. I'm not sure exactly why but my theory is on page 1

VirtualAce
06-09-2002, 03:56 PM
Incorrect.

QBasic will work inside of a DOS shell as well as VB DOS, C++, NASM/MASM/TASM, and DJGPP must be ran in a DOS shell. Even the old BASICA will work in a DOS shell.

Games, however, normally require pure DOS usually because of the sound driver they load into memory.

sean
06-09-2002, 06:57 PM
Incorrect.

At least I've got a version that came free with Windows 3.11 - that explicitly specifies not to run it in a shell. I agree that for the most part they're the same, but there are minor differences (like available RAM usage) that anyone doing some serious DOS programming might need to be aware of.

Powerfull Army
07-08-2002, 04:51 PM
YES!:
Finally someone is talking about true/win DOS.I need a compiler that will compile true-DOS REAL BAD.It's EXTREMELY FRUSTRATING(:mad: :mad: :mad: ) to have to search so hard just to write simple old true-DOS programs,after all,Windows was origionaly supose to be but an utility anyway.can anyone tell me of a compiler that will compile true-dos(hopefully free:D and very hopefully...on this site:D :D ).Please say you do,it would solve a lingreing,simple and frustrating problem i've had for a long time:(

Unregistered
08-10-2002, 04:55 AM
Hi, something very weird just happened to me today. I successfully compiled a simple program using MingW today but when I try to run it in dos shell (under win2k sp1), it crashes with message:

Instruction at "0Xxxxxxxxx" referenced memory at "0X00000000". The memory could not be "read".

I copied the program to an NT workstation and ran it in shell and it crashed with:

Exception: access violation (0xc0000005), Address: 0Xxxxxxxxx

Anyone knows if this is a DOS shell problem or a win2k/winNT problem in general?

Powerfull Army
08-10-2002, 12:45 PM
the 'Dark side' is right.Windows messes everything up.Viruses would be imposible to create if it wasnt for the Windows registry.So many mangled drivers and uncustomization that very soon you realize that you computer has been stolen by microsoft."Do not attempt to adjust the software on your computer.We are under complete control.We can make your screen jump,or fade or go black and still get praise,due to our expert brainwashing."

Fordy
08-10-2002, 06:07 PM
Originally posted by Powerfull Army
the 'Dark side' is right.Windows messes everything up.Viruses would be imposible to create if it wasnt for the Windows registry.

Ugh.....not really.....The concept of a virus predates windows by quite a while......if all viruses were linked to the registry then virus killing would be a doddle...


Originally posted by Powerfull Army
So many mangled drivers and uncustomization that very soon you realize that you computer has been stolen by microsoft."Do not attempt to adjust the software on your computer.We are under complete control.We can make your screen jump,or fade or go black and still get praise,due to our expert brainwashing."


Hmm...dont tell me....linux fiend right? :)

kevinalm
08-10-2002, 10:55 PM
Getting back to the original topic, real mode dos and a dos box in win 95 and later are two very different things. Real mode dos is basically a 16 bit 8086 compatability os and a dos box is a 32 bit protected mode emulation of a 16 os. The trouble is that Bill Gates dosn't believe in protected mode superuser status for users and that means that a dos box cannot properly access hardware directly. Old dos 6.22 era games in particular tended to directly manipulate hardware in order to boost performance. Sound cards have real problems in a dos box.

scott27349
08-19-2002, 06:12 AM
i dont think you can run dos under any nt based os. something to do with memory managment

moi
08-19-2002, 06:15 AM
Originally posted by Unregistered
Hi, something very weird just happened to me today. I successfully compiled a simple program using MingW today but when I try to run it in dos shell (under win2k sp1), it crashes with message:

Instruction at "0Xxxxxxxxx" referenced memory at "0X00000000". The memory could not be "read".

I copied the program to an NT workstation and ran it in shell and it crashed with:

Exception: access violation (0xc0000005), Address: 0Xxxxxxxxx

Anyone knows if this is a DOS shell problem or a win2k/winNT problem in general?

your program sucks; it is trying to read memory that is not its.