Same Executable for Win32 GUI and XWindowSystem possible?

I'm trying to create a really simple one-window application that should update some files via http and want it to run on windows and ubuntu without changing the executable.
Obviously one could use a console application that launches the gui depending on the current system but i wondered if there was a more direct way but could not find any helpful information via google so far.

I know that a win32 program has a WinMain function, however i could not find any information if that was actually the start of the program or if there is a main function inside the part you include with the windows.h that does the initialization and then calls the WinMain so i could create my own main function handing over to the windows main function if the system is windows - trying the Visual Studio Search Function in the dependencies has lead to no results however.

Given that there actually is no main function - is there a way to let the program take WinMain under Windows and main otherwise as the starting point for execution? Or am i trying to work around some basic difference between these builds in the compiler, which won't go away anyway just because of a formal workaround?

Quote:

---

Originally Posted by LokVadnod

I'm trying to create a really simple one-window application that should update some files via http and want it to run on windows and ubuntu without changing the executable.
Obviously one could use a console application that launches the gui depending on the current system but i wondered if there was a more direct way but could not find any helpful information via google so far.

---

Check out WINE on the linux platform... Linux can run some windows programs. All you need to do is make sure your windows program doesn't use anything WINE doesn't support.

Using Wine will obviously solve those problems but then i can as well use a simple widget-library and compile it once for windows and once for the X System and use a command-line program to choose and have one less dependency.

So it certainly is a solution but i would be more interested in actually understanding the problem inside the code and find a real fix for it. Besides i believe wine won't be used to run a program unless you tell it to so i would still need that command-line program to call wine.

If you could do this, do you think WINE would exist?

Code is portable by recompiling the source code for the platform you're interested in.

You can minimise the amount of "per platform" code you have by choosing portable abstractions.
List of widget toolkits - Wikipedia, the free encyclopedia

The executable files themselves are hard wired to the OS you compiled them for.
- If you take a win32 exe file and put it on Unix, it won't recognise the file header as being an executable file.
- All the 'trap' instructions which allow your program to talk to the OS will be different.
- Maybe at the very basic level of individual instructions, you compiled for X86 but the machine is ARM.

WINE solves 1 and 2 by putting a nice wrapper around your program, which understands the format of win32 executables, and it intercepts all the things which get near the OS. But even WINE would not solve the 3rd problem. For that, you would need a full blown emulator.

Quote:

---

Originally Posted by Salem

If you could do this, do you think WINE would exist?

---

Actually i thought that WINE primarily existed because getting the source code is not always an easy task ^^.

Thanks a lot for the reply however - i must have googled for at least 2 hours on this problem by now and just failed to find any definite answer. Sorry if my turning down of the WINE-solution earlier sounded arrogant to you.

There's Always Java. ;)