Console programs written in C, are they OS independent? Or does it rely on the DOS Architecture? I have convinced myself that their really is no DOS architecture and that DOS is strictly a program that loads other OS independent programs.

I don't think the output files generated (executables) are OS independent. However, you can most likely compile the C coding on any other OS with very little or no modifications.

Example being:

[code]#include <stdio.h>

int main()
{
    printf("Hello, world!\n");
    return 0;
}[/code]
Would compile on any OS with no modifications. However, the output files are strictly for that OS.

DOS doesn't exist for the console.  Don't put those two together.  And more or less, console programs are "OS-dependent".  The Windows OS for instance controls the console window just like any other window, except most applications with non-console windows have their own WinProc functions.  I'd imagine Linux does something similar, but different, if you know what I mean.

[quote author=Mephisto link=topic=9179.msg84702#msg84702 date=1097949595]
DOS doesn't exist for the console.  Don't put those two together.  And more or less, console programs are "OS-dependent".  The Windows OS for instance controls the console window just like any other window, except most applications with non-console windows have their own WinProc functions.  I'd imagine Linux does something similar, but different, if you know what I mean.
[/quote]

Be specific.

Console code is platform-independent, if you use ANSI C/++.

Console binaries are platform-specific.

[quote author=MyndFyre link=topic=9179.msg84754#msg84754 date=1097974004]
[quote author=Mephisto link=topic=9179.msg84702#msg84702 date=1097949595]
DOS doesn't exist for the console.  Don't put those two together.  And more or less, console programs are "OS-dependent".  The Windows OS for instance controls the console window just like any other window, except most applications with non-console windows have their own WinProc functions.  I'd imagine Linux does something similar, but different, if you know what I mean.
[/quote]

Be specific.

Console code is platform-independent, if you use ANSI C/++.

Console binaries are platform-specific.
[/quote]

Regardless of whether the code is platform-specific or not, the actually generated file(s) are not.  They are completely different as to how they operate because the OS determines that AFAIK.  Windows handles the console its own way, and Linux handles its console its way.

[quote author=Mephisto link=topic=9179.msg84803#msg84803 date=1097997282]
Regardless of whether the code is platform-specific or not, the actually generated file(s) are not.  They are completely different as to how they operate because the OS determines that AFAIK.  Windows handles the console its own way, and Linux handles its console its way.
[/quote]

No, Mephisto, it is important to make the distinction.  Atom asked whether a console program was OS-dependent.  The following console program is not OS-dependent as long as it is compiled for the environment that it will be used on:

[code]
#include <iostream>

int main(void);

int main()
{
    cout << "Hello, world!" << endl;
    return 0;
}
[/code]

As a file, called something such as "mycons.cpp", that code can be compiled and run on any platform.

The original question was whether the original program written in C is OS-independent.  The answer to that is yes, at a code level.  The answer to that is no, on a binary level.  In order to answer the question fully, you have to give both answers.  You only gave the binary answer.

I thought he just wanted to know if console programs themselves are OS-dependent or not.  The answer to that is yes, as we established.

[quote author=MyndFyre link=topic=9179.msg84804#msg84804 date=1097998170]
In order to answer the question fully, you have to give both answers.  You only gave the binary answer.
[/quote]
I gave both! :'(

[quote author=Newby link=topic=9179.msg84897#msg84897 date=1098051992]
[quote author=MyndFyre link=topic=9179.msg84804#msg84804 date=1097998170]
In order to answer the question fully, you have to give both answers.  You only gave the binary answer.
[/quote]
I gave both! :'(
[/quote]

Yes you did Newby.  <3  I was talking to Mephisto, who did not.

Sorry I forgot i asked this here. I will restate my question:

I create a 32bit console application and compile and build it. Can this application boot at startup without any form of dos or other os?

I am using Borland and now am beginning to realize that it depends on however the linker is made.

[quote author=Atom link=topic=9179.msg85006#msg85006 date=1098116939]
Sorry I forgot i asked this here. I will restate my question:

I create a 32bit console application and compile and build it. Can this application boot at startup without any form of dos or other os?

I am using Borland and now am beginning to realize that it depends on however the linker is made.
[/quote]

Depending on your compiler and linker, it might be able to boot at startup without any form of dos or other os. It's not likely though. What you call a 32-bit console application is probably a win32 console application, and that will require something that emulates win32 in order to load and run...

Right.  I can't think of a way offhand to jump into protected mode in C++ without using inline assembler (defeating the purpose), and you'd have to emit raw binary instructions as opposed to a PE file, which includes a header and other fun junk that you can't use unless you're in an environment that supports it (i.e. Windows).

Thanks for your help guys.

As said above, the platform you compile/link/build it on is the platform it will run on because the C++ code has nothing to do with the application once it's beyond the compiling stage.  It all has to do with the binary instructions created from the ASM output from your C++ code that were builded to create your application.  This application runs on the system is was built for, most likely Windows in your case.  It would be impossible (unless you had an emulator) to load the application on another operating system that doesn't use the same "program setting architecture" (I don't know the technical term, so please don't flame me for that quoted statement; and the three major OSs: Windows, Linux, Mac all have different ones).  You can however, take that code and re-build it on another OS and then you have that application capable of running on that OS.  However, your code would have to be portable (in other words, ANSI-C++ with no OS-specific code such as Win32 API or anything from the library windows.h, etc.).  Keep in mind though that if you were to build the application on Windows 2000, you could run it on other versions of Windows such as XP, Server 2003, etc.  Though because Windows has two different kernels that are in wide use (though one is dropping in popularity considerably as Microsoft is getting people to switch to the better one, NT), some applications may not run on both kernels, but generally speaking if it's just ANSI-C++ code it should.  When you run into portability issues is when you use APIs and OS-specific code and the such.