Difference between Windows and Linux GCC compiler

[Rayne]

Hi all,

I'm interested to know what is the difference in programming using MS
Visual C++ on Windows and using the GCC compiler on Linux, i.e. what
are some of the things I can do on Visual C++ that won't compile/run
on Linux, and vice versa.

For example, I know that Windows uses the LLP64 model, while Linux
uses the LP64 model, so I can't use the long long data type when
programming on Linux. Also, the windows.h file is only available in
Windows, and can't be used on Linux. I've also read that there is also
some differences in network programming, since winsock, and especially
the underlying ip headers are much different in Windows than Unix/
Linux gcc. Is this true?

Thank you.

 

[Ian Collins]

Hi all,

I'm interested to know what is the difference in programming using MS
Visual C++ on Windows and using the GCC compiler on Linux, i.e. what
are some of the things I can do on Visual C++ that won't compile/run
on Linux, and vice versa.

For example, I know that Windows uses the LLP64 model, while Linux
uses the LP64 model, so I can't use the long long data type when
programming on Linux.

Where did you get that idea from?

All the models do is specify the size longs and pointers. long long is
part of the C standard.

Also, the windows.h file is only available in
Windows, and can't be used on Linux.

What use would it be on anything other than windows?

I've also read that there is also
some differences in network programming, since winsock, and especially
the underlying ip headers are much different in Windows than Unix/
Linux gcc. Is this true?

Not really. Once you get past initialisation, there's not a lot of
difference and socket level code is pretty portable between platforms.

This isn't really the place to ask, you have more luck asking windows
questions on a windows group and Unix ones on comp.unix.programmer.

 

[James Kanze]

Rayne wrote:

[...]

Not really. Once you get past initialisation, there's not a
lot of difference and socket level code is pretty portable
between platforms.

This isn't really the place to ask, you have more luck asking
windows questions on a windows group and Unix ones on
comp.unix.programmer.

Which raises an interesting question: where do I ask about
portable socket code? Either about what portable libraries
might exist (I'd say that could be asked here), or since you
mention that much is pretty portable, about that portable part?
(I don't think that belongs here, but I don't know where else to
send someone.)

 

[Ian Collins]

Rayne wrote:
[...]

I've also read that there is also some differences in
network programming, since winsock, and especially the
underlying ip headers are much different in Windows than
Unix/ Linux gcc. Is this true?

Not really. Once you get past initialisation, there's not a
lot of difference and socket level code is pretty portable
between platforms.

This isn't really the place to ask, you have more luck asking
windows questions on a windows group and Unix ones on
comp.unix.programmer.

Which raises an interesting question: where do I ask about
portable socket code? Either about what portable libraries
might exist (I'd say that could be asked here), or since you
mention that much is pretty portable, about that portable part?
(I don't think that belongs here, but I don't know where else to
send someone.)

c.u.p is fairly tolerant, there used to be a lot more interesting
networking questions there than we see today.

I've written a number of portable networking applications and the
differences between WinSock and "normal" BSD sockets is minimal.

I don't know of a specific network programming group.

 

[Pascal J. Bourguignon]

Rayne wrote:
[...]

I've also read that there is also some differences in
network programming, since winsock, and especially the
underlying ip headers are much different in Windows than
Unix/ Linux gcc. Is this true?

Not really. Once you get past initialisation, there's not a
lot of difference and socket level code is pretty portable
between platforms.

This isn't really the place to ask, you have more luck asking
windows questions on a windows group and Unix ones on
comp.unix.programmer.

Which raises an interesting question: where do I ask about
portable socket code?

To google of course!

Either about what portable libraries
might exist (I'd say that could be asked here), or since you
mention that much is pretty portable, about that portable part?
(I don't think that belongs here, but I don't know where else to
send someone.)

comp.programming

be.comp.networking ch.network clari.tw.computers.networking
cmh.network cruzio.network cu.courses.csci-networks cuug.networking
dsm.network fido7.ru.networks kw.networks memphis.networking
okinawa.networks osu.network relcom.fido.ru.networks slac.networks
tw.bbs.comp.network um.network uw.network uwo.ssc.network
vmsnet.networks.misc

 

[Ron AF Greve]

Hi,

You can write completely portable code for sockets. The difference is that
windows in addition to the 'regular' calls for sockets also has some special
stuff that integrates with windows itself. For instance normally you would
create a bunch of sockets and start listening on them. In a single threaded
app that means it wouldn't respond to windows messages . So windows added
its own sockets to remedy that problem. However you just use the portable
sockets all you have to do is start it in a separate thread and let the main
thread handle the message queue while the separate thread will do a
(blocking or blocking with certain timeout) 'select()' on the portable
sockets. My network code works on various unix/linux as well as on windows
without problems.

Well having that said, I had a quick look in my code and there are some very
minor differences (not sure if they are actually necessary).

To get the error code

#ifdef WIN32
ErrorCode << Error << " " << WSAGetLastError();
#else
ErrorCode << Error << " " << strerror( errno );
#endif

And also if you use windows sockets you have to call some function one time
in your program on startup and on exit (something like
WSAInitialize()/WSACleanup() or something) (I am too lazy to look it up
right now )..

Regards, Ron AF Greve

http://informationsuperhighway.eu

 

[Ron AF Greve]

Sorry., forgot this one

#ifdef WIN32

if( ioctlsocket( Socket, FIONBIO, &True ) ) //; // Hope this works
(undocumented)?
{

int Error = WSAGetLastError();
}
#else
fcntl( Socket, F_SETFD, O_NONBLOCK | fcntl( Socket, F_GETFD ) );
#endif




Regards, Ron AF Greve

http://informationsuperhighway.eu

 

[SaticCaster]

See "1. The first step. 64-bit mode can be different. Let’s sort it
out" in article
Seven Steps of Migrating a Program to a 64-bit System
http://www.viva64.com/art-1-2-850243650.html

 

[Balog Pal]

Well having that said, I had a quick look in my code and there are some

very minor differences (not sure if they are actually necessary).

There is a good faq on the net listing the differences of winsock and bsd
sockets, must-read for anyone writing such code.

 

[REH]

Sorry., forgot this one

 #ifdef WIN32

    if( ioctlsocket( Socket, FIONBIO, &True ) ) //; // Hope this works
(undocumented)?
  {

   int Error = WSAGetLastError();
  }
 #else
   fcntl( Socket, F_SETFD, O_NONBLOCK | fcntl( Socket, F_GETFD ) );
 #endif

What I've done for systems I have to build on multiple targets is
define a common interface, and have the build system pull in the
appropriate library. It's much cleaner and easiler to maintain
(especially when it comes the adding a new target).

REH

 

[Ron AF Greve]

Hi,

Yes, I don't much like the #if's in my code either. Especially if there are
exceptions for multiple systems it makes the code hard to read, although it
makes it easy to use the same code between g++ and VC++ since I don't have
to do something special. But indeed for parts where you get multiple #if's
for various systems it would be nicer to put the difference in the make
files instead of the code.



Regards, Ron AF Greve

http://informationsuperhighway.eu

Sorry., forgot this one

#ifdef WIN32

if( ioctlsocket( Socket, FIONBIO, &True ) ) //; // Hope this works
(undocumented)?
{

int Error = WSAGetLastError();
}
#else
fcntl( Socket, F_SETFD, O_NONBLOCK | fcntl( Socket, F_GETFD ) );
#endif

What I've done for systems I have to build on multiple targets is
define a common interface, and have the build system pull in the
appropriate library. It's much cleaner and easiler to maintain
(especially when it comes the adding a new target).

REH

 

[REH]

Hi,

Yes, I don't much like the #if's in my code either. Especially if there are
exceptions for multiple systems it makes the code hard to read, although it
makes it easy to use the same code between g++ and VC++ since I don't have
to do something special. But indeed for parts where you get multiple #if's
for various systems it would be nicer to put the difference in the make
files instead of the code.

I've got code that I build with different compilers, including g++ and
vc++, for various platforms, without a single #if. I've setup my make
system so I can do things like:

make gcc
make gcc release
make gcc clean
mkae vc05
make vc08

etc. Although, lately I've switched from make to jam (actually boost
jam) which makes creating targets like the above much, much easier.

REH