Ie. I want to make a C program, that can run and install itself on both Windows and Linux. Ie. one will adapt if its a Windows system, or install in a different way if its a Linux system.

I don't understand how to do it: also do the standard headers ie. stdio or creation of files, do they work on the logical or kernel level or on the physical level? Or use both?

Ie. I might also want the file to copy only part of itself, ie. the first 6000 bytes or something. Then I might want to adapt to the filesystem. I also might want to control the speed of copying so it doesn't hog all the resources, but still use it on a logical level?

Which brings me to my next question: I want to contain all the data to be copied in one program, then the program would extract the data from that. Sort of like an installer. How do I do this in C, in one program? Also refer to dynamic files: the file isn't created yet, but after it is created, I want to refer to it.

Type the following on the command line to find out what is predefined by the preprocessor itself:

echo | cpp -dM -

These macro's are defined for the specific system you run this on. Among others, you'll see:

#define __unix__ 1
#define unix 1
#define __linux 1
#define __unix 1
#define __linux__ 1
#define linux 1
#define __gnu_linux__ 1

Pick a macro of your choice and do for example:Things defined in stdio.h work (almost) the same way with all ANSI compliant compilers. Of course to open a file in windows for example, you would start the file name with a driver letter like "c:" and use backslashes instead of forward-slashes (linux) in the path for the file name.

What do you mean by "adapt to the filesystem" and "still use it on a logical level"?

Just put that file in you source package. If you want a different file for different OS's, use different file names, and use "#ifdef __linux__" (see above) to use the different file names when compiled on a different OS.

Just create and open it with fopen() from stdio.h. I don't understand the problem you could have with this. Or do I understand your question wrong?

Hko rocks at this.. I was going to write that it should not be possible .

Thanks mate!

Hko is talking about code that be compiled on either a Unix or a Windows machine, which is certainly possible. Natalinasmpf seems to be talking about binary code that can run on either Windows or Linux, which is not at all possible. Actions like file operations, or even printing to stdout, require calls to the operating system. Needless to say, the APIs for Windows and Linux are quite different. I think the best you can do is write code, like hko is saying, that can be compiled on either machine.

Don't know how helpful this is, here is a simple work around. Write the code for windows and see if you can get it working under wine. If you are happy with the portability of source, try to stick to posix. That should help most of the time. To be honest, I did not read your mail. I read HKO's reply. To copy the same file use argv[0]. Don't bother much about speed control. There is an operating system to take care of such stuff. 6000 bytes is not much of data.

Bye,
Sarin

#ifdefs are a really bad idea. avoid whenever possible. instead, try encapsulating platform specific code behind portable interfaces.

For eg.
// portable header (memmap.h)...
void MemoryMapFile( ... )

// win32 implementation (win32_memmap.c)
void MemoryMapFile( ... )
{
CreateFile( ... )
CreateFileMapping( ... )
MapViewOfFile( ... )
}

// linux implementation (win32_memmap.c)
void MemoryMapFile( ... )
{
open( ... )
mmap( ... )
}

Having a binary that can run on both windows and linux systems is possible. Just check out the "dual" app at http://www.deater.net/weave/vmwprod/asm/ . Maybe it could help you?

While it may be possible to do something as simple as write characters to the console using assembly I doubt that interfacing with something more complex like a filesystem will be possible.

Hko has the right idea, your gonna have to compile for the host platform simply becuz they both use different implementations of the standard c runtime library. Linux uses glibc, Windoz uses msvcrt, so, unless you can find a runtime lib that will work across both platforms and can be statically linked, your stuck with two different binaries.

Now the Windoz runtime lib is pretty much ANSI compatible and I have had much success writing code that runs on both platforms AS LONG AS your just using stuff like stdio.h, stdlib.h...etc. Basically if you have to add a -l to link some lib then it's gonna be a little more complicated. Here's a couple links for ya, Mingw32 works fine for the simple stuff, CygWin is for the more complicated ports.

http://www.mingw.org

http://www.cygwin.com

I didnt say it would be easy, the only thing holding you back from writing a complex multi OS program would be the lack of knowledge in the subject.

looks like a crossplatform virus in da makin !!

Presumably the only thing holding me back from inventing a time machine is lack of knowledge of the subject, too.

Or maybe some things are actually impossible?

can anyone tell me why such a program is impossible?

its not impossible, but very difficult. windows executes PE format executables and linux generally executes ELF executables, the header of both is different so you have to write either one or the other. it is however quite easy to teach linux to execute PE executables, the problem is they make OS/library calls that are not present on linux, the idea of wine is to provide these missing calls.

a description of ELF and PE are here

even if you could write a program that operated on both it would be useless on non x86 machines. why not write your program in an interpreted language thats available on both platforms such as python/java.

by shortfuse
While it may be possible to do something as simple as write characters to the console using assembly I doubt that interfacing with something more complex like a filesystem will be possible.

the file was being executed as a .com and therefore should have access to int 0x21 allowing it to make filesystem calls.

That kev82 he's da guru!!

That kev82 he's da guru!!

Jinksys, For me I just don't see why something like that would be worth the trouble. There are plenty of language choices that would make porting much much easier than worrying about one executable so, why put yourself through that kind of pain?