Yes. Yes. No!. No!

Use mingw32. you will thank yourself later for the switch.

You can develop using DJGPP - if you do this from pure DOS, you will have better chances of catching invalid memory access than you do under Windows. Then when you release your game, simply recompile with MinGW.
MinGW is just as easy (or difficult) to set up as DJGPP is, so if you got that installed installing MinGW should be a breeze.

I recently (about 2 weeks ago) switched from DJGPP to MinGW, because a lot of people couldn't play my games, because they were DOS only! You can download all you need here. I don't know how I found it, but that's everything you need for MinGW! Once you have that, try compiling a few test programs, using the commandline:

gcc file.cpp -o file.exe

If you ever used command line to compile with DJGPP, you'll notice that the commandlines are exactly the same. It's just a different port!
That will compile and link file.cpp into file.exe. When you're ready to make allegro, you'll have to get a DirectX lib thing, but, it says in the allegro docs. (In the \build\ directory.)

Well, MinGW looks really confusing. I definitely want to use allegro, but if I have to get a direct x dll or lib file or header file or something, it just sounds like a big pain in the butt to do on my home computer where I have to get permission from my dad to download anything. And he'll get all confused probably when he's trying to install it, and then I'll have to tell him that I need a direct x thing, and then I'll have to make him download the allegro stuff, and then he'll have to install that. You see what I'm dealing with?

So right now I think I'll just get DJGPP, then when I go back to school I'll download MinGW and port my code over from DJGPP to Windows. Will that be hard?

And also, can I run DJGPP on Windows XP (our schools run XP, my home runs ME so I'll be okay) easily? Do I like have to worry about XP not letting me do somethings?

And here's a question no one will give me a clear answer to:

When I initialize graphics mode, allegro will allocate some memory for the screen, which may be much larger than what is actually visible. Then it warns not to use the global *screen at the same time as create_video_bitmap() because the two may overlap. Well, I'm going to be using a double-bufferring system (I'm am overdrawing some, so I assume that is the fastest method?), and want to shrink the screen down to the physical size of the screen. Then I want to allocate a screen size amount of video memory for the screen_buffer (assuming blitting is being accelerate by hardware) along with the rest of the video memory for my graphics (assuming masked blitting is being accelerated by hardware). How do I do this?

Why not use both?

For my non-commercial work, I do all my coding with Rhide/Djgpp, then take the finished work and compile it using MingW to get the win32 port. Since I spent many years using Borland C++, Rhide's appearance is very familiar to me, and easy to navigate. Then again, Dev-CPP is quickly catching up in terms of ease of use.

Not at all. If you stick to ANSI/Posix commands, you shouldn't have to worry about changing any of the code. Just remember your END_OF_MAIN() tag

Unfortunately, this is very true. An invalid pointer call or out of bounds array access will kill your program instantly under DOS. As inconvenient as this sounds from a end-user standpoint, it's valuable to us dev'rs.

If you've read the Allegro documentation, you'd have known that it provides you a direct link to the downloads, and even includes installation instructions. allegro/docs/build/mingw32.txt

That's not true. Well, not the last part. Windows is quite good at catching invalid memory accesses (what do you think a GPF is?). As good as an OS can be.

I have to agree with Korval. I would have made a point earlier because people say this so often, but I very very rarely see a memory error go unnoticed.

I mostly reserved my statement for three reasons. The first being I have Windows XP, a real operating system, instead of Win98, a fancy shell over DOS. The second is that I use MSVC in debug mode, its debugging DLL does a lot of checking for you and adds "memory fences" around every allocation you make, checking them for modification. The third being that I use MSVC and not mingw, which are different compilers generating different code.

Are you sure? Not all illegal memory accesses trigger GPFs.
I'm with Korval on this one.

No but in MSVC it will always cause an error in the debugging DLL.

I don't see how it can possibly cause a GPF in DOS. No operating system can possibly tell you that's a bug. The memory at the "21st" element can be perfectly fine to write to, no matter what OS you are using. Even if your OS was some ultra-uber OS, it still probably couldn't do anything unless that access crossed the memory boundary of a page, because exceptions will only be thrown with access to invalid pages or pages with readonly bit set in the page table.

We just saw a case with an array in a class, where accessing 1 element out of bounds was fiddling with a BITMAP* member.

err yes that's right. It will detect writes though.

But I usually don't get memory errors anymore. Good use of STL and safer RAII-type methods. Pointers and arrays are evil.

That was happening to me all the time with strings.
I'd have two strings declared one after another.. and if I edit the first one too far (from a badly coded input box), it'd go into the next string. I couldn't stop laughing at first, and I just couldn't figure out why it was doing that.... finally I realized, a few days later after putting up with the bug