Porting code from Linux to Windows
lance...@yahoo.com
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
Richard Heathfield
lance...@yahoo.com wrote:
> 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,
I hope you created a "blank project", because otherwise VS tends to
set up some rather brain-damaged "helpful" source for you.
> 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.
Sounds good so far.
> 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?
The specifics of the implementation will obviously vary, but standard
headers always work. Both GNU C and VS have ways to let you specify
paths for your own headers, but the easiest way for basic projects is
simply to put your headers in the project directory, upon which a
simple #include "myhdr.h" should work just fine.
> 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.
Oooooh bad idea. Right for .h, but wrong for .c - what you ought to do
(on both gcc and VS) is compile the C files separately, and link them
at the end. This may cause you some teething troubles (which are
easily resolved by consultation!), but it's the Right Way and will
save you trouble in the long run.
> 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.
Without the specifics, it's hard to comment sensibly. Are you getting
messages along the lines of "can't find header"? If not, then that
isn't your problem - you have a C problem (quite possibly related to
the fact that you're #including the world and his dog) which we can
help with if we can see the code.
> I'm also getting errors like DIR is an undeclared identifier. I've
> included , so why can't it recognize DIR?
That's a POSIX thing, not a C thing, and Visual Studio is under no
obligation to support it. (Last I checked, it doesn't, but it's
conceivable it has been added. Look it up on MSDN.) Of course VS has
a way of reading directories, but the details are rather different
from what you're used to. Although it's off-topic here (and thus any
answers you get along those lines should be viewed with suspicion),
it's bang on topic in comp.os.ms-windows.programmer.win32 where some
serious Windows experts hang out. But the following link may give you
some clue as to what's involved in reading directories in Win32
(remember, treat this link with suspicion!):
http://www.cpax.org.uk/prg/windows/dirparse.c
But your first step should be to understand how a basic multi-file
project works in Visual Studio.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Michael Tsang
Hash: SHA1
lance...@yahoo.com wrote:
> 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
<lance...@yahoo.com> wrote in message
news:55ab051f-1735-4f2c...@o9g2000prg.googlegroups.com...
> 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
you've told us. Are you using "foo.c" or <foo.c> for your #include
statements? The latter may not work for user-provided stuff.
> 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
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Dann Corbit
nos...@seebs.net says...
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
"Nobody" <nob...@nowhere.com> wrote in message
news:pan.2009.11.20....@nowhere.com...
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