real mode dos & win dos

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?

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?

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

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.

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).

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?

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 . The bottom line:- DOS shells (the old ones at least) will make you do things the hard way.

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.

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

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

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!!
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

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.

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

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

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

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

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.