• Welcome to Valhalla Legends Archive.
 

Question

Started by Atom, October 16, 2004, 10:13 AM

Previous topic - Next topic

Atom

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 am back! aINC is dead, ThinkTank PRO is alive.
VB, JAVA, ASM, C, its all yummy to me.

Newby

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:

#include <stdio.h>

int main()
{
    printf("Hello, world!\n");
    return 0;
}

Would compile on any OS with no modifications. However, the output files are strictly for that OS.
- Newby

Quote[17:32:45] * xar sets mode: -oooooooooo algorithm ban chris cipher newby stdio TehUser tnarongi|away vursed warz
[17:32:54] * xar sets mode: +o newby
[17:32:58] <xar> new rule
[17:33:02] <xar> me and newby rule all

Quote<TehUser> Man, I can't get Xorg to work properly.  This sucks.
<torque> you should probably kill yourself
<TehUser> I think I will.  Thanks, torque.

Mephisto

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.

MyndFyre

Quote from: Mephisto on October 16, 2004, 12:59 PM
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.

Be specific.

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

Console binaries are platform-specific.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Mephisto

Quote from: MyndFyre on October 16, 2004, 07:46 PM
Quote from: Mephisto on October 16, 2004, 12:59 PM
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.

Be specific.

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

Console binaries are platform-specific.

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.

MyndFyre

Quote from: Mephisto on October 17, 2004, 02:14 AM
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.

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:


#include <iostream>

int main(void);

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


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.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Mephisto

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.

Newby

Quote from: MyndFyre on October 17, 2004, 02:29 AM
In order to answer the question fully, you have to give both answers.  You only gave the binary answer.
I gave both! :'(
- Newby

Quote[17:32:45] * xar sets mode: -oooooooooo algorithm ban chris cipher newby stdio TehUser tnarongi|away vursed warz
[17:32:54] * xar sets mode: +o newby
[17:32:58] <xar> new rule
[17:33:02] <xar> me and newby rule all

Quote<TehUser> Man, I can't get Xorg to work properly.  This sucks.
<torque> you should probably kill yourself
<TehUser> I think I will.  Thanks, torque.

MyndFyre

Quote from: Newby on October 17, 2004, 05:26 PM
Quote from: MyndFyre on October 17, 2004, 02:29 AM
In order to answer the question fully, you have to give both answers.  You only gave the binary answer.
I gave both! :'(

Yes you did Newby.  <3  I was talking to Mephisto, who did not.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Atom

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.
I am back! aINC is dead, ThinkTank PRO is alive.
VB, JAVA, ASM, C, its all yummy to me.

Adron

Quote from: Atom on October 18, 2004, 11:28 AM
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.

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

MyndFyre

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).
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Atom

Thanks for your help guys.
I am back! aINC is dead, ThinkTank PRO is alive.
VB, JAVA, ASM, C, its all yummy to me.

Mephisto

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.