quote: Original post by Anonymous Poster

Atually, Windows 9x is a new operating system, with backwards compatibility for DOS. It rewrites the old DOS files completely, and uses 32-bit code instead of 16-bit. In fact, there is almost zero DOS code left in Windows NT and Windows 2000.

Windows 3.x are drivers on top of DOS. Windows 95 and above are a complete new operating system.

Too much hype here -- Windows 95 is essentially a re-written 3.x with a host of new features and standards. If you don't believe me, go into MSDOS.SYS and either add or change the line:

BootGUI=0

Then it'll only boot to DOS, without starting Windows 95. Keyword: starting! DOS 7.00 is essentially only DOS 6.22 with support for long filenames. Where do people get the idea that the DOS utilities (like EDIT.EXE, SMARTDRV.EXE, COMMAND.COM, etc.) run with 32-bit multi-tasking code? They don't. Windows just provides its own "extender" in the form of a new memory model and slightly different EXE format for programs that run in Windows. Also note: try running a Windows program from a DOS-only boot as prescribed above. What do you get then? A message saying that it only runs under Windows.

Windows 98 and Windows 98 Second Edition are just improvements and bug fixes for Windows 95. MS took a big leap away with Windows 2000, though.

quote: Original post by Anonymous Poster

Programmers complain about Windows because DOS is much faster, and since it isn't multi-tasking, it won't pull the processor off to do another job, giving your game less time to do stuff like calculations and rendering the screen.

They complain because they're ignorant and lazy. They don't want to learn complex tasks like putting a window on the screen and using abstract libs like DX, all the while not realizing that they would spend more time learning a new set of libraries for each game. Pathetic.

quote: Original post by Anonymous Poster

And I'm not sure if they all like the idea of making everything "more abstract" anyway; many programmers prefer to work closer to the macine. Again, making programming more abstract also slows the programs down.

Wrong. Adding abstraction speeds things up. Why this apparent contradiction? Because it allows greater freedom to the hardware manufacturers. More freedom = faster speed increases. They don't have to worry about making it work with so many different programs by creating several drivers, custom libs, and workarounds for each product. As long as it complies with Windows standards, it works. Abstraction, when learned properly, allows you to focus on your particular task as completely as possible. Like it or not, human brains use abstraction all the time and function best when using abstraction. Abstraction is defined as the picking out of important details and leaving the unnecessary ones. As such, it hardly serves to slow things down. How can you slow down program code by thinking more logically?

quote: Original post by DQuadros

It looks to me that

1) Most Windows games don't use the Windows UI
2) Even if you write a "DOS game" it will end up running under Windows, as PC are sold with Windows pre-installed
3) If the user like the game he will start it through a shortcut at the desktop, not typing commands in a DOS Box

So, to the user, it won't matter if its a "DOS" or "Windows" game. This is a developer decision.

Wrong. You forgot to mention compatibility, support, and development time (which matters to users because of support). Better coding results in better programs, which results in more user satisfaction.

quote: Original post by DQuadros

What is the difference betweem a "DOS" and a "Windows" game when you are running it under Windows? Since Windows/386 (that is, even before Windows 3.0), DOS programs run in a VM (Virtual Machine), so Windows is actually looking over your shoulder (and interfering) while you mess up with the hardware - so you will still get a performance hit (when compared to a "bare DOS" environment.

Someone finally made an intelligent argument for DOS -- something about the Windows DOS VM. In case you didn't know, ALL of my DOS games run much faster from a Windows DOS box (meaning: in the VM) than from a pure DOS boot (outside the VM). Why? Abstraction provides faster drivers. No, I'm not going insane. The bus-mastering drivers used by the VM load things from disk as much as 10x as fast in most of my games. Video and sound processes on my PCI-based machine run almost concurrently (while the code to put send the data does not). However, the code to send data to the sound card is trivial compared to the processing of that sound data that the sound card does.

Look at a prime example of DOS abstraction: the Sound Blaster API. Write a game for the Sound Blaster 16 and you now have almost sound universal support. The only difference between the DOS model was its archaic (and poorly designed) device model, memory model, CPU model, etc. For those of you who want to run DOS games in Windows 9x, there are NUMEROUS switches that control such things as available memory, hotkeys, halting the VM for that app when switching back to Windows, disallowing the screen saver, hogging the CPU, etc. Almost anything that Windows provides that might interrupt or slow the DOS program can be disabled.

quote: Original post by abe_bcs

I definitely agree with masterboy. DOS is a hellava lot cooler, and faster. It's got freedom, man. In windows, for every method you code, you have to check if some other ding-dang program is covering your face. Sure, windows has a lot of standardization(everything's M$ , but anyone can write a similar kind of lib for DOS. The main reason most people get pissed off with DOS is it's lack of a GUI. Any reasonably talented programmer can make one, and one to suit the application, with all kinds of new and cool controls, titlebars below, minimize boxes to the left... And don't say that windows is standardized. I'm sure a user wouldn't mind this 'de-standarditarion' if it helps him use that particular App.

Someone else said you can make interfaces for DOS programs that behave like Windows. First argument: re-creating something for each individual program that someone else already did is stupid. Second argument: you can't change DOS itself by adding a GUI, but you can give it a shell. However, you'd just be re-creating Windows. If something else has been written for you, use it. Windows already has a functional GUI, and as I challenged before, anything useful you can do in DOS, you can also do in Windows, and better.

I'm sorry, but de-standardization is an ignorant concept. Ignorant of the market, the trends, and programming in general. Standards are the only way multiple programmers work together. Also, the whole idea of Windows was to enable users to simply choose the "documents" or tasks they want, as apposed to having to choose and learn a new program and new style. Users don't care if it has a custom GUI!! All they want to do is get their work done.

quote: Original post by Blah!
DOS is good. You have to learn how to things manualy.
In my computer class at school they make us work in DOS because they want us to learn how to do things ourself.

If they had any sense, they'd use console apps instead, and then teach how the hardware works with diagrams. Everything you learn in DOS -- all the neat tricks -- have to be unlearned before you can try Windows because of the different memory model and multi-tasking and sharing of resources, etc. All of those thing you learn in DOS only serve to hinder coding in Windows.

Forgive me for saying so, but most DOS code looks like someone fell asleep on the keyboard. Honestly, some people think that functions were faster if their names were shortened to as few letters as possible! DOS is dying. Very, very, very fast. As a development platform, it is dead.



People seem to have the misconception that DOS is simple and Windows is complex. In reality, it's the other way around. The only difficult thing in moving from DOS to Windows is the elimination of stupid (or just ignorant) programming practices. Poor commenting. Taking over the whole computer. Depending on "tricks" that are better termed stupid-undocumented-dependencies-that-tie-the-code-down. Each new DOS program imposes more of a burden on the compatibility of DOS as a whole. You see, under DOS, people didn't have to write good code to sell their product. As long as it worked, no matter if it went 10,000 lines without a single comment, it sold.

Instead of learning to use Windows, they opt for the "simple" days of DOS! They spend their days chuckling about all the poor Windows programmers who have to learn the Windows API to code programs, all the while they calmly create the equivalent of the Windows libraries without multi-tasking. How ignorant! Windows 9x, was, after all is said and done, just a large abstraction layer for DOS.




- null_pointer
Sabre Multimedia


Edited by - null_pointer on 3/30/00 8:22:56 AM

So as we have seen here there are many advants/deadvants to windows/dos programming. This null dude talked about (dos)programmers being lazy, bacause of complex tasks. Look in the mirrir and see the lazy windows programmer letting windows take care of every thing. Programming his luxurius C++, automaticaly compiling it into cpu opcodes. And I''ll show you an example of how ''fast'' direct x is. Just to prove my point I deassembled a part of the direct x ddraw

functions, look at this:
Xor al,al ;these are not refferenced
add al,04 ;to by jmp, loop, ect
wich in c equals:
var_x = 0;
var_x = var_x + 4;

Now I mean this is how ''good'' direct x is.
Now I must say there are also ways inbetween windows and dos boxes, like dpmi or win assembly. And with the exception of some video cards all hardware pretty much support one or more standard(s).

And to all the people out there: Carpe Diem

My point was that DOS is harder to work with.
And dont say this isnt true. Ask anyone who has made a game with DOS and Windows and ask them wich is easier. Im sure they''ll say Windows. Cuz they dont have to worry about drivers.

BTW: Im in high-school, we dont have programming courses, just how to use a computer course that i took so I wouldnt have to actualle learn a 4 language over the 3 that I already know.

Regarding the course: we learn to use DOS then we move to Win3.1 then to Win9x

I think that Null_Pointer knows what he''s talking about. I mean, who would write a huge post and flame a whole bunch of people if they didn''t know what they were talking about?

As for my opinion on DOS, I liked DOS because you didn''t have to do what Windows wanted you to do first, register your window and set of the message handler, etc., and then get to your code. But, I also had a hard time in DOS since DOS didn''t do any of the technical hardware overhead for you. In Windows, not only do you have a huge library of functions and pre-typed code (woohoo ), but its almost trivial to communicate with the hardware since Windows takes care of (most of) the techy details (and takes away some of the control you had in DOS).
All in all, DOS is dead. Its been dead for a while. Go to a (modern) computer software store, and just TRY to find a program made for DOS. Didn''t find one? Just what I thought...

Heh. I''m going to add to an already bloated thread. It will be short though.

I agree with Null Pointer on everything except that I do think DOS is an easier platform to _start_ C or C++ programming in. This may be because that''s path I took and had to ''un-learn'' a lot of stuff when I moved to Win32. However, I still have this opinion. MS code is BUTT-UGLY. Why must every type be in caps??? Its like going to a chat line with a bunch of 10 years olds obsessed with caps lock. And don''t get me start on Hungarian notation (I know it has to practical value, but its annoying as hell).

Main reasons I think DOS sucks:

1. segmented memory model. You want something ''hardcore'' use Linux. It is actually 32-bit and none of this dumbass segment-offset BS.

2. shared code. I never did get terribly proficient in all the DOS tricks and stuff, and I may be wrong in this statement, but to my knowledge DOS offers nothing in the way of a standardized .dll solution.

To people who like DOS because you have to do everything yourself.. If you really want to, use Windows and do everything yourself. No one is forcing you to use windows common dialogs, etc.

Just my $0.02.




I guess this is where most people put a famous quote...
"Everything is funnier with monkey''s" - Unknown

hey, you guys! i just started learning windows progging about a month ago. b4 that i thought "EEW, Windows!!", but now that i''ve actually written a program, i don''t want to touch a dos program again! it''s really awesome to me how structured and organized programming for windows is. no matter what(as far as i''ve seen), everything is consistent, like you have this: Function (LPTYPE lpType); you don''t see this: fnmyFunction (MYtype *type); if you understand what i''m saying... everythings the same. and, there''s also the fact that windows is probably the most popular OS available. on top of that, working in Visual Studio is just plain Fun!
jake.

quote: Original post by Mr Master

So as we have seen here there are many advants/deadvants to windows/dos programming. This null dude talked about (dos)programmers being lazy, bacause of complex tasks. Look in the mirrir and see the lazy windows programmer letting windows take care of every thing. Programming his luxurius C++, automaticaly compiling it into cpu opcodes.

Nah, not all DOS programmers are lazy -- just all the ones I''ve seen. As for complex tasks, I said that those tasks are a direct result of their own attitudes. I see examples of poor coding all the time. I hate wading through all the tutorials of code that looks like this:


int strm = _fopen("myfile.dat", "a+");
unsigned char buf[256];
_fread(strm, buf, 256);
_fclose(strm);



That may be easy for you to read, when you know what a stream is, but for a newbie that''s a waste of their time. I only have all the tutorials on the Internet to back me up. Find a DOS tutorial that includes code that is well commented and the variables and functions are written in plain English. It''s only laziness that keeps people from writing:

fopen()

instead of:

CreateFile()


and:

char buf[256];

instead of:

char pBuffer[256];


(Note that I used a Windows function called CreateFile -- the name just happened to be readable, but CreateFile is not a suitable replacement for _fopen() in every circumstance.)


(If you want a real example of how powerful and easy to read my library will be, look at this:


String szName; // sz means string, Name tells its use
szName = "John"; // overloads the = operator to do the same thing

// Store the name of John''s friend
String szFriendsName; // sz means string, FriendsName is cryptic, so we include more comments

// Now, create a file to store the names
File flDataFile("Name.DAT"); //fl means file, DataFile tells what it stores

// (could you guess what the "Name.DAT" parameter was for?)

// Now, write the strings to the file.
// Note that you can still tell their types without
// remembering their declarations -- sz denotes
// string, and fl denotes a file.
flDataFile.Write(szName);
flDataFile.Write(szFriendsName);

// The file will go out of scope -- when it does, it
// will close itself automatically.



and I consider that easier to read than the standard libs. I''m not posting this here to brag -- I just want to know which you like better? What if you had to find the problem in someone else''s code? Which would you like to check? Even my mom, who doesn''t use computers at all, let alone programming, could tell what my code did. Try that trick with the standard libs!)

Microsoft realized a long time ago that it''s silly to try and maintain code like the previous examples that I listed as bad. When you have hundreds of people working on the same code, and you can''t depend that the same people who wrote it will even be available next year, you MUST write readable code. Also, if they expect people to use their API, it must be readable. Why would I expect anyone to use the C library? I try to avoid it when possible, but as the only standard way to write my library, I''m going to have to use it. The C library is powerful. It''s flexible. It''s poorly written. (I should have quit while I was ahead ) Note that I am not condemning the C language, just its library. C++ has an equally hard to read library, and C++ is my language of choice. So don''t get offended about C.

There is a HUGE difference between being lazy and being stupid. Being lazy is not coding properly and not asking for help when you need it. Being stupid is re-creating code that someone else has created, simply because of STUBBORN PRIDE. Software is so complex nowadays that it''s asinine to try to do it all yourself. That is no different for games. So, to cope with it, DOS programmers use a complex maze of drivers and libs that other people wrote. How is it any different from Windows coding, really? The only difference I can see is standards. But even DOS programmers work with standards -- remember SoundBlaster? Windows is just a powerful collection of standards, with OS-level support, driver-level support, and API-level support.

What I was saying is that DOS programmers tend (read: tend) to have animosity towards Windows programmers, as evidenced by your reply and several others. If you think something is an easier way to do the same task, do it! Don''t start moaning about people who "have it easy" when they just decided it was worth their time to code Windows. That kind of moaning is just a pathetic waste of time.

Also, if you have no way of proving that DOS is better (and you don''t know enough about Windows to prove it), why post anything about it? This is turning out to be another of those "silly posts" where no one discusses things rationally. I wasn''t trying to flame other people -- just correct some gross misconceptions and silly prejudices that have no factual basis. Please post facts, people.




- null_pointer
Sabre Multimedia

Much as I hate to respond a troll like that..... here goes!

DOS isn''t dead, but should be for a large number of reasons.

First of all, its not even a truly 32-bit operating system. If you want to access memory outside of the first 1 Mb (and the last 384k of that is hard to get to!) you need to use a DOS Extender, such as DOS4GW or the one DJGPP ships with. You could of course run your DOS program under Windows, but it will then have all of the slowdown of a preemptively multitasking OS (and one that has to waste cycles switching mode switching, too, since Win9x still has some 16-bit components). Dos Extenders are basically a nasty hack!

Secondly, hardware support. Yes, in the old days if you wanted a driver for a piece of hardware you got in touch with the manufacturer. Have you any idea just how many people with non-Creative Labs soundcards were unable to listen to sound effects in games? How many people played games exclusively in 320x200x256 colours because either a) drivers were not available for a particular game (even with scitech''s VESA emulator - another wonderfully slow hack!), or b) drivers are hard to use. Most users really don''t know much about computers - and DEFINITELY don''t want to have to learn in order to entertain themselves. Windows does a simply marvelous job of providing a common interface through which to access today''s accelerated hardware. Yes, its still driver-based, but this is relativley transparent to the user. Still, you''d be amazed how many people I''ve met who still play [or played - I usually help them] Quake II without 3D acceleration because it doesn''t autodetect all OpenGL support properly!

Next, who really wants to go back to the massive support headache that was DOS - and the perception that its a platform exclusively for geeks. Frankly, figuring out how to free up that last 100k of conventional memory so that you can play Wing Commander is not fun. People don''t like utilities like QEMM, memmaker, etc. Yeah, Quarterdeck made a lot of money with QEMM - but the product bombed the minute Win9x became available... if people don''t absolutely have to use things like that, they will steer clear of them.

Next, networking support. DOS-based networking sucks, pure and simple. Sure, you can run your DOS program in a window and hope that its socket implementation works with the Windows one (good luck with the details!) - but once again you are relying on something that isn''t DOS being there. Does anyone really want to go back to having to load 4-5 drivers just to use IPX on a LAN, and then finding out that you can''t talk to the other people on the LAN because you have different versions of the packet driver? Or carefully loading them all, and then finding out that you don''t have enough conventional memory to run Duke Nukem anyway - even though you have 128 Mb of RAM in the computer as a whole????

Finally, DOS should die because it has a nonreentrant kernel and some DOS calls can completely kill a multitasking kernel [or force the kernel to kill the DOS VM, in the case of WinNT, OS/2, and if you are lucky Win9x].

Okay, so programming for the Windows platform isn''t quite as easy as it is to hack something together with DJGPP. From the point of view of learning to program [something a lot of people need to do before they even think about touching DirectX], you can compile pretty decent console mode apps with VC++, Borland C++, and probably CodeWarrior and LCC (haven''t checked the last 2). Console apps really are all you need for learning the important stuff - pointers, memory handling, strings, structure, class organization, basic data types, and all of the other things that if you don''t know, you shouldn''t be writing games. Once you''ve got through the learner-programming stage (and believe me, this means a LOT more than "hello world"), Windows programming really isn''t very hard at all. If you can read enough to figure out how to implement a binary tree, you can read enough to figure out how to copy the SDK examples and start drawing in DirectDraw - and for that matter, Direct3D. Yeah, you have a little more awkwardness than might be liked (although COM is pretty amazing when you need it, and the Windows message loop system can be amazingly flexible sometimes), but its really not that big a step.

Is Windows slower than DOS? Depends upon what you are trying to do. Since hardware accelerated polygon filling drivers weren''t available for my video card under DOS (last I checked), and Nvidia only give out register access details under strict NDA, I wrote a software based landscape demo (in DJGPP) similar to the one in the "using Direct3D for isometric engines" article. It averaged 5 fps with every tile gouraud shaded and textured. Using Direct3D acceleration brought that up to a steady 90. Could I have achieved 90 under DOS? Probably. Would my wonderfully accerlated TNT2 code worked on a Voodoo 3? Nope, not unless I''d taken the time to write Voodoo 3 code. Which might leave the ATI graphics guy out of luck if I forget that ATI exist (something I''m prone to doing!). With Windows, I carefully craft my main game loop (largely using a template for the rest of the program), and with a bit of careful planning I have code that works on almost any graphics cards that complies with a base driver standard. Write once, run in several places. [And yes, I know that there was a nasty bug in the tile demo I mentioned.... it could bring a machine down because of my odd quitting method. Live and learn. I''ve made mistakes like that on every platform I''ve tried!].

Personally, I wish MS would ditch WinME and drop the 16/32 bit thunking kernel (Win9x is 16/32 bit, largely because DOS won''t die) completely. Windows NT and Win2000 are thousands of times more stable (for the same reason Linux is - they have sane memory/resource models, and solid kernel design).

As for Linux, BeOS, et al..... they are all good Operating Systems. Programming for any of the *nix clones can be easier than programming for Win32 (even Win64!), although Linux needs a lot of work in terms of user friendliness before it will be in enough homes to be worth supporting commercially as an entertainment platform. I love it for servers! .

Many huzza''s to Bracket.

I could not have said that any better.



I would also like to add that DOS has always been a horrible Operating System, even when it was considered ''Top of The Line''

DOS was designed by a company to use as just a simple crap OS. It was NOT meant for games, or anything in real life for that matter.

===============================================
"Tell brave deeds of war."
Then they recounted tales, -- "There were stern stands And bitter runs for glory."

Ah, I think there were braver deeds.

DOS is a good Operating System, but since the majority of the population is too stupid to be able to deal the command-line-system, Microsoft invented an "improved-DOS", supporting the window-technique.
Windows is a very unstable system (even good old DOS is more stable! It nearly never crashed!), but has some big advantages, too. For example the availability of DirectX. Of course someone can say, the great Allegro collection by Shawn Hargreaves is as good as DirectX. I absolutely agree with you!
But since more and more users have windows, (and windows doesn't support old dos applications), DOS is getting more and more unimportant. I think this is a sad development, since I have been programming in DOS for about 5 years (and I think a person who uses the comp should be able to use it even with command-line-system, or let it be!
I don't think that DOS-programming is more complicated than Windows-programming, it's (to my mind) even the other way round...
To put it in a nutshell, I thank god that an alternative OS is present: Linux. Thus the programmers heaven!
It is very stable and crashes never-seldom! It also has a window-based-technique, but the disadvantage is: It takes quite a long time, until the system runs. But when it does...
If anyone had the choice between dos, windows and linux, I would recommend Linux.

I have been programming in Turbo Pascal for 5 years. I also have experiences with Delphi, Turbo Assembler and C++.


Edited by - Indeterminatus on 4/2/00 9:39:59 AM