Porting code from unix

[LdaXy]

I'm attempting to port a header file for a program that was designed for a Unix environment. i'm'; aware of the type defined variables like s16, u8 and such, but is their anything else i need to know about Unix C? not to familiar with it. thanks.

sample portion of the code

/*===========================================================================*
 *      Useful MACRO
 *===========================================================================*/
#define	guZFixLookAt(lp)	\
        { (lp)->l[1].l.col[1] = (lp)->l[1].l.colc[1] = 0x00; }

#if	(defined(_LANGUAGE_C)||defined(_LANGUAGE_C_PLUS_PLUS))
/*------------------------------------------------------------------------*/
/* ZMath: Vertex structure format */

/*-----------------------------------------------------*/
#define	ZSIZE_VSRC	6

typedef	struct	{  s16	x,y,z;		} zVtxSrc;

/*-----------------------------------------------------*/
#define	ZSIZE_VDEST	16

typedef	struct	{
  s16	sx, sy;
  s32	invw;
  s16	xi, yi;
  u8	cc;
  u8	fog;
  s16	wi;
} zVtxDest;

[Moschops]

Depending on the standard that the original coder coded to, you might be able to get away with very little work. Valid C code is valid C code, regardless of whether it's on *nix or Win32. The issues generally arise when libraries are available on one system and not the other.

If the code you're porting is self-contained or relies on headers & libraries available on both systems, you're laughing. What in the *nix code cannot be carried straight onto the Win32 system?

[LdaXy]

in the first few files i've looked at, nothing seems to be platform specific, except a few _LANGUAGE_C_PLUS_PLUS and _LANGUAGE_C macros. i was just curios if *nix had a diffrent way of implementation than windows.

[Moschops]

It's common to assume when coding for *nix that you can rely on POSIX compatibility; if you have a root through the header files #included in this *nix code, you should see pretty quickly if it relies on anything special.

[Ancient Dragon]

Microsoft compilers do not define s16, s32, or u8 so you would have to typedef them yourself if you want to use their compiler. I think the best compiler for you would be Code::Blocks and MinGW compiler, which is supported on by *nix and MS-Windows. MinGW compiler has already ported most *nix libraries to MS-Windows.

>>It's common to assume when coding for *nix that you can rely on POSIX compatibility;
MS-Windows is not POSIX compatible.

[LdaXy]

ancient dragon, is it not safe to assume the following?

s16 = short
s32 = int
s64 = long

and so forth. instead of using a cross compiler to interpret the code, could you not just use the defined values for windows C, and if need be, the type definitions in "windows.h"? of course it would mean rewriting part of the code itself, but I don't have a problem doing that.

i don't know much about *nix coding, so i may not be right on this.

[Ancient Dragon]

>>is it not safe to assume the following?

No. You could typedef s16 = long if you want to.

>>could you not just use the defined values for windows C, and if need be, the type definitions in "windows.h"

No because windows.h does not define those either.

>> instead of using a cross compiler
Code::Blocks is not a cross compiler. It won't generate code for another computer architecture. AFAIK Code::Blocks is only supported on PCs with IBM/compatible processors.

[Moschops]

>>It's common to assume when coding for *nix that you can rely on POSIX compatibility;
MS-Windows is not POSIX compatible.

That's kind of the point, but we can always use more explicitness :)