[bug] r4951 - missing inet_?to? on XP

[VS]

When starting an executable compiled & linked with MSVC on Windows XP, functions inet_ntop and inet_pton are not found in WS2_32.dll (sockets), because they are not there.

According to the information I could find, after the OS was released, the standard defining socket interface for IPv6 changed and added these, or something along these lines. The resulting executable uses delayed loading for the particular DLL, so the failure appears only after running it.

It might be possible to substitute these in some way, but is that something generally desired?

[prissi]

They should be there after service pak 2 on XP and are missing before.

Easy fix: Define "USE_IP4_ONLY". Of course then you cannot connect to IPv6 server.

[VS]

Oh... thanks As to service packs, this is weird, because my windows came with SP2 pre-installed, and later got SP3. Obviously it can't be said that 3 > 2 in this case

[prissi]

Maybe some program (virus) downgraded them?

[Junna]

Oh... thanks As to service packs, this is weird, because my windows came with SP2 pre-installed, and later got SP3.

Same with mine.

[jamespetts]

Hmm - has any solution to this been found? Is there any possibility of digging up an old WS2_32.dll and putting it in the simutrans directory?

[prissi]

Those function were not REALLY needed. Thus I removed them, which should help also various other architectures like Haiku. Only the first time an default IPv6 is opened on a none IPv6 client, there will be a short delay.

[jamespetts]

Ahh, I see. Thank you for letting me know!

[Ashley]

Not needed? What were they replaced with? AFAIK inet_ntop/inet_pton are the standard way of doing network to presentation mapping of addresses for code which deals with IPv6.

[jamespetts]

Timothy,

do your servers run ipv6?

[Ashley]

Yes.

[prissi]

getaddrinfo works with IPv6 too; you are actually using it for exactly that purpose. Only on a non-IPv6 capable computer there will be a short delay the first time it is called with an IPv6 address; at least on windows XP. On WIndows 7 (with IPv6 tunneling) I had seen no difference.

[jamespetts]

Yes.

Ahh - does this mean that I'll have to apply this fix from Standard and release a new version before you'll be able to run an Experimental server to which people running Windows XP SP3 will be able to connect?

[Ashley]

IMO people running Windows XP still can just use a version compiled without IPv6 support, and connect from their legacy operating system using the legacy version of the Internet Protocol...

[jamespetts]

Ahh - so your servers work both with IPv6 and IPv4? Apologies for being dim - I didn't realise that they were cross-compatible.

[prissi]

Well, the currently submitted version can use IPv6 even on XP and Win2k ...

[Ashley]

Do you think there would be any benefit in doing with the networking what is currently done with the platform-specific graphics code, e.g. splitting the platform-specific bits into their own files? Might be a neater way to handle the platform-specific code issues. All of the legacy/IPv4-only code could then be split off from the dual-stack stuff...

[prissi]

inet_ntop and inet_pton does also not work on Haiku, while the current code does for IPv6 on Haiku and XP. Thus I would rather use the smallest common denomenator.

One could of course move network.cc to a simsys_net.cc or so instead leaving it in the dataobj folder. However, the code is nearly completely independent from the other backend stuff, so I would not put it into simsys_d.cc or similar.