Thread: Windows and Mac C Programming Cross-Compatibility

  1. #1
    Registered User
    Join Date
    Feb 2010
    Location
    UK
    Posts
    8

    Question Windows and Mac C Programming Cross-Compatibility

    Hi,

    I wonder if anyone can advise. I've programmed in C and various other languages for around 4 years now, generally writing programs on the operating system they're for. Recently I wrote an encryption program on a Mac (Spec; Snow Leopard using XCode) which compiled, ran and created a Windows exe correctly, however, when attempting to run the same source files or the exe produced on a Windows machine it just errored.

    I realise this may be an silly question, but is there something that im missing? a cross compatibility patch or extra library needed etc?

    Thank you all for your time and advice,
    Leo

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Most likely your program has a bug in it, which only actually happens on Windows.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  3. #3
    Registered User
    Join Date
    Feb 2010
    Location
    UK
    Posts
    8
    Thank you for your reply, do you know if there is a public list of common issues with cross-compatibility C programming? I've looked but not found anything of any use.

  4. #4
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    I do a lot of cross-platform work and have in the past noticed the following:
    1. If you make a call to any library or system function *not* included in the C++/C ISO spec, you need to abstract that call and write conditional compilation code to work on each platform. Typical areas where this comes into play are thread/process management, communications/socket code, GUI/screen IO, etc.
    2. If you are working with shared libraries/DLLs/etc the code here is *very* different from platform to platform. There is little else to do here other than to learn the ins and outs of each platform. With respect to this particular point, aside from just having very different code, memory is quite different from platform to platform, ie on some platforms the shared object/library/DLL/dynlib shares a stack with the called program, in others it owns its own stack.
    3. If you are not well-versed in this I would suggest grabbing wxWidgets for your target platforms and learning that. wxWidgets is a set of libraries that not only helps one write GUI apps for each platform but also has abstractions built-in for things like threads, DLL management, sockets, etc.

    I cannot speak to the C standard but the C++ standard is making strides to smooth over at least some of these issues such as having a common set of calls for things like thread management and so on but that is a year or so away and then you have to wait for the compiler vendors to "officially" support it. GCC right now can support some of this if you use the right compile switches but it is termed "experimental" which means it could change at any time...
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by Leo2010 View Post
    Thank you for your reply, do you know if there is a public list of common issues with cross-compatibility C programming? I've looked but not found anything of any use.
    Before you suspect a compatibility issue you really should look for plain old bugs. The obvious first step is to fire up a debugger and figure out WHERE the Windows code is crashing. Find the problem and fix it.

    Just because it crashes on Windows but not on Mac doesn't mean you don't have a bug somewhere. Only after ruling out those possibilities should you start looking for a "compatibility" issue (which would indicate that you are probably using a standard function call incorrectly, which itself is a bug)
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by jeffcobb View Post
    I cannot speak to the C standard but the C++ standard is making strides to smooth over at least some of these issues such as having a common set of calls for things like thread management and so on but that is a year or so away and then you have to wait for the compiler vendors to "officially" support it. GCC right now can support some of this if you use the right compile switches but it is termed "experimental" which means it could change at any time...
    Boost has them as well, and is portable to all kinds of platforms.
    With regards to C, though, this just means that there usually are libraries out there that performs these kinds of tasks and are portable (ie works on a big number of popular platforms).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    Registered User
    Join Date
    Feb 2010
    Location
    UK
    Posts
    8
    Hi all, Thank you for your replies and advice - some great information in them. I'll try the ideas and advice you've suggested, just a quick update. On Windows I generally use 'Miracle C' to compile my code, however, I changed to working with 'Dev-C++' which compiles both C and C++ source files. This seems to be able to compiled the programs without errors leading me to believe it is a library problem as suggested.

    Thanks all

  8. #8
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Miracle C is an old and out-dated compiler. Any code it produces cannot be trusted to be standard compatible, so do NOT use it.
    If there is a problem when compiling with Dev-C++, then you might know there is a problem with the actual code if it doesn't work correctly...
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Registered User
    Join Date
    Mar 2009
    Posts
    399
    I think you are missing the point that brewbuck spelled out for you. Both Dev-C++ and Xcode use the same compiler (GCC), so it's no wonder that the code works the same in both of them. If you have a bug in your code that produces undefined behaviour, chances are that one compiler might do what you intended to do while others might not. That can mean everything from an instant crash to silently destroying data or similar.

    In one of my own projects, the code compiled and ran in Linux, Windows and Mac OS X without any problems, but whenever I ran it in Solaris it would core dump when I quit the program. At first I thought it was a bug in the library used in Solaris, but it turns out that my code actually did have a very subtle bug.
    Last edited by Memloop; 02-19-2010 at 05:32 AM.

  10. #10
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > On Windows I generally use 'Miracle C' to compile my code,
    No, miracle-C is a piece of crap that rejects even the most basic of programs.

    > I changed to working with 'Dev-C++' which compiles both C and C++ source files. This seems to be able to compiled the programs without errors
    That's because it's a real compiler, and not some student toy program.

    Just delete it, and expunge it from your memory as ever being a tool you might want to use.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  11. #11
    Make Fortran great again
    Join Date
    Sep 2009
    Posts
    1,413
    I think it's worth mentioning here that Dev-C++ uses an old version of mingw, you should use Code::Blocks instead.

  12. #12
    Registered User
    Join Date
    Feb 2010
    Location
    UK
    Posts
    8
    Hi all,

    Thank you for the advice, everything seems to be working correctly now - so fingers crossed. I am having a bit of a problem with some C code but thats more user error / lack of experience so have created another post.

    Thank you again for your help and advice :-)

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Compiling a program for Mac OSX from a windows computer
    By Jedi Nescioquis in forum Windows Programming
    Replies: 1
    Last Post: 02-13-2009, 03:06 PM
  2. Windows or a Mac
    By AaronHall in forum A Brief History of Cprogramming.com
    Replies: 23
    Last Post: 06-24-2008, 11:09 PM
  3. Mac Os X Vs Windows
    By hermit in forum A Brief History of Cprogramming.com
    Replies: 25
    Last Post: 09-07-2002, 02:29 PM
  4. compiled under windows, work for mac os?
    By Shadow12345 in forum C++ Programming
    Replies: 1
    Last Post: 05-09-2002, 09:55 AM

Tags for this Thread