Porting code from Linux to Windows

[lancer6238]

Hi all,

I'm using Visual Studio .NET 2003, and I'm trying to port code I've
written and compiled/run successfully in Linux GCC to Windows.

I'm a newbie when using VS. I've created a new project, and added all
the .c and .h files I have into the project by Project -> Add Existing
Items, then chose all the .c and .h files.

I'm not familiar with how exactly compilers and linkers etc work, but
is there a difference between how VS and gcc compile/link #include
files? My habit of programming in Linux has been to have one main.c
file, and #include all other .h or .c files that I need. Then I would
only compile the main.c file. But in VS, it seems as if the #include
files are not "seen" by the program, because I'm getting errors that
tell me certain structures or variables were not declared, even though
they are in my user-defined header files.

I'm also getting errors like DIR is an undeclared identifier. I've
included , so why can't it recognize DIR?

Thank you.

Regards,
Rayne

 

[Michael Tsang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

I'm using Visual Studio .NET 2003, and I'm trying to port code I've
written and compiled/run successfully in Linux GCC to Windows.

I'm a newbie when using VS. I've created a new project, and added all
the .c and .h files I have into the project by Project -> Add Existing
Items, then chose all the .c and .h files.

I'm not familiar with how exactly compilers and linkers etc work, but
is there a difference between how VS and gcc compile/link #include
files? My habit of programming in Linux has been to have one main.c
file, and #include all other .h or .c files that I need. Then I would
only compile the main.c file. But in VS, it seems as if the #include
files are not "seen" by the program, because I'm getting errors that
tell me certain structures or variables were not declared, even though
they are in my user-defined header files.

Including .c is certainly a poor practice that destroys the benefits of
separate compilation. Here's my practice:

1. Group related function definitions (excluding inline functions) and
object definitions into .c/.cpp files. For classes, all the member function
definitions should be put into a single .cpp file. All functions that are
called from functions only in the same TU should be declared static or put
into unnamed namespace. Include the .h/.hpp file with same name which will
be created in step 2.

2. Put all the non-static function declarations and object declarations
(i.e. extern declarations) from the .c/.cpp file to the .h/.hpp file. Never
put any function/object definitions (except inline functions definitions or
function template definitions) inside. If the extension used is .h, wrap all
the functions and objects which may be called from C code in the following:

#ifdef __cplusplus
extern "C" {
#endif
/* blah */
#ifdef __cplusplus
}
#endif

This wrapper can ensure that the code is called correctly from both C and
C++ TUs. Also, wrap the entire file in an #include guard. Class definitions
must be put in .hpp files. Use forward declarations instead of #including
other headers whenever possible.

3. Write the main function. If you are writing a package which contains many
small utilities, name the file with the main function as
$exe_name.c/$exe_name.cpp where $exe_name is the final executable name. If
the project only produces one executable, naming it main.c/main.cpp is OK. A
header is not needed for the TU containing main function because only main
function and static functions are put in this TU.

4. Compile all .c files into .o files. Then link all .o files needed to form
the final executable(s). The advantage of separate compilation appears
immediately when you change some of the .c files. Only the modified .c files
need to be compiled again.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAksGwUQACgkQG6NzcAXitM+jnQCgjGUtSobSP4vQxZ9riZQRWeWu
SjcAn2yd29p9i0t/2iIDj+37/+nNkTeC
=8zIt
-----END PGP SIGNATURE-----

 

[BGB / cr88192]

Hi all,

I'm using Visual Studio .NET 2003, and I'm trying to port code I've
written and compiled/run successfully in Linux GCC to Windows.

I'm a newbie when using VS. I've created a new project, and added all
the .c and .h files I have into the project by Project -> Add Existing
Items, then chose all the .c and .h files.

I'm not familiar with how exactly compilers and linkers etc work, but
is there a difference between how VS and gcc compile/link #include
files? My habit of programming in Linux has been to have one main.c
file, and #include all other .h or .c files that I need. Then I would
only compile the main.c file. But in VS, it seems as if the #include
files are not "seen" by the program, because I'm getting errors that
tell me certain structures or variables were not declared, even though
they are in my user-defined header files.

not knowing what is going on is a detriment on both Linux and Windows.
each does their own things, and in their own ways, and not knowing what is
going on will come up and bite one from behind...


the "single main.c" strategy, granted, often works of for very small
projects, but it does not scale.
however, how to write code which scales well is a long topic all for itself.

the first step though, is to split things up into multiple source files, and
know how to deal effectively with the issues of separate compilation.

I'm also getting errors like DIR is an undeclared identifier. I've
included , so why can't it recognize DIR?

Windows and Linux are different.

Windows does not know about all of the POSIX stuff (in general, it is not
POSIX conformant), and so things like DIR/readdir/... (or, pthreads, or BSD
sockets, ...) will not work on Windows...

they are not part of C, they are part of POSIX, or worse yet, there may be
things in use which are specific to Linux, or even a particular version of a
particular distribution. one is only gueranteed what things are gueranteed
in the relevant standards, and anything more is inherently non-portable (not
that it is not non-usable, only that to safely use it, one has to have a
fairly good idea what it is they are doing).


it is much the same as if you try to write a Linux app and expect DirectX
and GDI+ to work...

"#include <windows.h>"
and try to build on Linux:
"oh, tears..., what does it mean that 'windows.h' could not be found?... I
'just' wanted to compile my program, life is just so unfair, EMO...".

things don't "just work", as matters are not so simple...

 

[Seebs]

I'm not familiar with how exactly compilers and linkers etc work,

You should become familiar with them.

but
is there a difference between how VS and gcc compile/link #include
files?

No clue.

#include files are not compiled, or linked. They are included. Then the
file they're included in is compiled. Linking is totally unaware of #include
files.

My habit of programming in Linux has been to have one main.c
file, and #include all other .h or .c files that I need.

That is a very bad habit. Don't do it. Compile all the .c files separately
and link them.

But in VS, it seems as if the #include
files are not "seen" by the program, because I'm getting errors that
tell me certain structures or variables were not declared, even though
they are in my user-defined header files.

That's interesting. It could be caused by nearly anything from how little

I'm also getting errors like DIR is an undeclared identifier. I've
included , so why can't it recognize DIR?

I have no idea what you've included, but "DIR" sounds like one of the things
specific to a UNIX environment, which probably won't be available on Windows.

You might want to have a look at grabbing cygwin so you can use pseudo-POSIX
stuff and gcc.

-s

 

[Dann Corbit]

You should become familiar with them.


No clue.

#include files are not compiled, or linked. They are included. Then the
file they're included in is compiled. Linking is totally unaware of #include
files.


That is a very bad habit. Don't do it. Compile all the .c files separately
and link them.


That's interesting. It could be caused by nearly anything from how little


I have no idea what you've included, but "DIR" sounds like one of the things
specific to a UNIX environment, which probably won't be available on Windows.

You might want to have a look at grabbing cygwin so you can use pseudo-POSIX
stuff and gcc.

Some other things that may help his porting effort:
Mingw (there is a 64 bit version now) will create POSIX type binaries on
Windows. There are a few limitations, such as no fork(), and you need
to use winsock instead of netdb for communications.

There used to be a library called SFL that was useful for C ports from
POSIX to Windows (which would solve, for example, his DIR problem).
Apparently it has been replaced by this stuff:
http://download.imatix.com/pub/
I have not tried the current incarnation, but SFL was pretty neat.

 

[Nobody]

Mingw (there is a 64 bit version now) will create POSIX type binaries on
Windows. There are a few limitations, such as no fork(), and you need
to use winsock instead of netdb for communications.

MinGW is just gcc+binutils for Windows. Its "libc" is MSVCRT (Microsoft
Visual C++ Runtime), which provides the ANSI C functions (although not
all of them conform to the standard) as well as some of the basic POSIX
functions (open, read, write, close, etc).

MinGW's only real concession to Unix compatibility is that it also
includes a library which implements opendir/readdir/closedir. Other than
that, anything you can compile with MinGW you can also compile with MSVC.

 

[BGB / cr88192]

MinGW is just gcc+binutils for Windows. Its "libc" is MSVCRT (Microsoft
Visual C++ Runtime), which provides the ANSI C functions (although not
all of them conform to the standard) as well as some of the basic POSIX
functions (open, read, write, close, etc).

MinGW's only real concession to Unix compatibility is that it also
includes a library which implements opendir/readdir/closedir. Other than
that, anything you can compile with MinGW you can also compile with MSVC.

not exactly...

MinGW has a bunch of subtle C99 stuff which MSVC lacks, and MSVC expects a
lot more "decoration" of the source in a few cases (such as when building
DLLs, as GCC defaults to implicit imports and exporting everything when
building DLLs, but MSVC expects such things to be explicit).

so, code which will compile in MinGW need not compile correctly in MSVC, as
something so trivial as using '_Complex' or 'stdint.h' will demonstrate...

otherwise, granted, as far as the library goes, they are pretty much about
the same.

 

[Robert Latest]

Some other things that may help his porting effort:
Mingw (there is a 64 bit version now) will create POSIX type binaries on
Windows. There are a few limitations, such as no fork(), and you need
to use winsock instead of netdb for communications.

There is also DJGPP which produces native, statically-linked Win32
executables and tries to be POSIX-compliant.

robert