UNIX and Linux Applications

Hi, I am new to this forum and I hope I am posting the thread in the right forum.

I have a huge C program running perfectly fine in 64 bit UNIX systems (runs for 5000 iterations). I want the same results while running in WINDOWS.

My current systems supports Windows 7 Professional 32 bit version. I made some changes to my makefile and ran it from command line in WINDOWS. Though the code runs, the results seem weird. I get 1.#IND (Indeterminate) and very huge floating point results in WINDOWS system. I use "double" in UNIX but the same datatype creates some problem in WINDOWS.

I would like to know if the problem is using 32 bit version and so should I shift to 64 bit version of WINDOWS to have the same compatibility?
What changes should I make to the datatypes if at all?

Thanks for your patience.

The differences are due to the compiler and its limitations/freedoms in a given architecture.

If the compiler is modern try using long double datatypes instead of double.

And porting code from UNIX to Windows is often very painful, so don't feel like it is just happening to you.

Thanks for the reply.

Do you think I can get any documentation to overcome these compatibility issues?

Also, I have the latest version of GCC, 4.5.2 and I view the same results (crap) with double and long double.

Surprisingly, I did not get any NaN errors in UNIX on dividing by zero but got the IND and INF errors in Windows.

You can't just blindly substitute things and hope that'll fix it, if anything that'll make it worse -- these things matter. You need to track down where the problem is originating, which may have nothing to do with the calculations themselves but the things that feed values into them. It may be assuming certain things to be certain sizes when the variable types are actually totally different sizes on 32-bit machines.

Try compiling with -Wall and investigating all warnings, especially ones about truncated values.

@ Corona,

Absolutely. Thanks for the reply. I also have one specific question if I should try out things in 64 bit Windows.
Do you think migrating from 64 bit Unix machine to 32 bit Windows could create problems?

It's not because it's 64-bit UNIX and 32-bit Windows. It's because certain things may have depended on certain types being certain sizes, and when you change architecture, they may change. Similar problems can be had moving from 32-bit windows to 64-bit UNIX, 32-bit UNIX to 64-bit Windows, 32-bit UNIX to 64-bit UNIX, 64-bit UNIX to 32-bit UNIX, 32-bit Windows to 64-bit Windows, and 64-bit Windows to 32-bit Windows.

It's not a Windows vs UNIX thing, it's from programmers that were either sloppy or didn't know better.

A 64-bit Windows environment is still radically different from most 64-bit UNIX(lp64?) environments, presumably because Microsoft just had to be different but to track down the problems, track them down, don't just blindly mess around with it.

Lol. Thanks for the reply.

I figured out the exact line of my huge code, as to where the NaN is generated. It appears to be QNaN and is propagating throughout the code. On performing a pointer arithmetic on that line, for example, "x = x + (y*z)" where x, y and z are generated as 0 in a particular iteration. And x = 0 + (0*0) gives me a NaN. From the searches I performed on the web, there is nothing which says 0*0 gives NaN and it cannot be, obviously. One possibility is infinity*0 gives NaN but when I printed 'y' and 'z', they are indeed 0.

Also, I did the same print's in my UNIX machine, and 0 + (0*0) gives 0.
Any suggestions over this? Does this imply there is any BUG in the code?

Thanks!