If you are even considering doing this in SH script, then you should give serious consideration to Python which is already portable.

• Port early and frequently
• Encapsulate non portable code. (Don t spread too many #ifdefs all over your code - rather create functions implemented separately for each OS in separate source files.
• Be very strict with data types (use long short in structs/classes and not int)
• I.e. switch on the highest warning level and resolve all warnings.

You can use platform-dependent ifdef-include pragmas and as strict types as possible. GLib has some nice ones defined which could be used on nearly every platform or architecture.

A shell script only option is not a viable alternative as on Windows platforms, there s no Bourne shell, Bash or KSH by default, and unfortunately PowerShell seems to be rare on XP machines. But you can create both a traditional batch file and a Bourne shell script.

But as others said, it s easier if you use a higher level language that s platform independent. And why wouldn t you? :)

I would recommand using ANSI-C and Lua (an embeddable small script interpreter). Try to use this with the basic required C functions you need.

You need to port and test often. If you work one year on unix and then try to switch it will be much harder, because often the best porting solution is a different design which is implemented on all platforms.

Windows can t run sh scripts directly, you need to use cygwin for that. So if you really want to run on vanilla Windows, you better use C. Stick to C89 and be careful. If you use any system calls, stick to POSIX ones and you should find them or equivalents on Windows. Windows also has a pretty comprehensive Berkeley sockets-alike library, so you can use that too within reason.

You re still going to have to do some #ifdefing.

You ll end up compiling it with MinGW if you make it a Windows task, if you stray too far into the UNIX den, you ll have to make it a cygwin binary instead, which has some baggage associated with it.

If it is not an option to add something that is inherently portable like python, ruby, perl, java etc. then your best option is probably to use ANSI C. One reason for C s initial popularity was it s (relatively good) portability. That said, anything that is closely tied to the OS, such as graphics, networking, etc are much less portable in C than in something like Python. You should strive to make "wrappers" for OS specific functions and keep those partitioned off from the main code. This way when it comes time to port it over, you re rewriting the wrappers, and everything else should compile without many issues.

All that said, it is a LOT easier to write something in Python and have it work everywhere. Plus it is more "fun" to write. So if you can avoid "interactive unix" in the future, do so.