Jump to content
  • Advertisement

SBD

Member
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

161 Neutral

About SBD

  • Rank
    Member

Personal Information

  • Interests
    Business
    Programming
  1. I've also managed to test this on Windows Server 2012 R2, and it behaved correctly. One could reasonably extrapolate that this applies to Windows 8.1 as well. I've provided the repro info/code to Microsoft, we'll what happens (read; I wouldn't hold my breath). Will update this thread with the resolution if and when such a thing occurs.
  2. Hey SyncViews, There are no external libraries aside from those required by win32 functionality (Iphlpapi.lib, Psapi.lib,Shlwapi.lib, Winmm.lib, Ws2_32.lib). The most perplexing bit is that it is complaining about something being redefined in the same library, meaning not the usual MSVCRT.lib vs MSVCRTd.lib, etc. (the usual thing caused by CRT mismatches). I've opened the issue with Microsoft, and was able to get them the info they should need to repro. I wasn't aware of this, but there is functionality in Visual Studio for generating repro information for linker issues. You can add "/linkrepro:C:\ReproDir" to your linker command-line and it will dump all the necessary files and info to reproduce the linker phase into the specified directory. This includes .obj files as well as all .LIBs it is attempting to link. In looking through this, it confirms that there is only a single CRT lib being included (MSVCRT.lib). So, we'll see what Microsoft has to say (and I'll update here with results).
  3. Hey frob, thanks for the response. I had the same thoughts regarding the other settings you mentioned. Unfortunately, the Target Platform, Windows SDK Version, Platform Toolset, and all of the VC++ directories settings are identical across all of the projects in the solution (and none of which reference anything from VS2010). In reality, when I somewhat ambiguously said I checked all settings, I meant it quite literally; all General, VC++ Directory, and C/C++ options match across all projects (aside from things which necessarily differ, like PDB output file). For those who might not know it, a handy feature in VStudio is that you can multi-select projects and open the properties dialog, and just like when you have "All Configurations" or "All Platforms" selected, it will show which properties differ between the projects for the selected configuration(s)/platform(s). Per your suggestion, I visually inspected the solution and project files, but it didn't reveal anything odd. I had also inspected the generated command-line for the compiler/linker, and nothing seemed amiss there either. My gut is telling me that something has gone wrong regarding the weak referencing the linker does for overridden global new/delete, which seems to be borne out by the problem disappearing when I remove my overridden global delete operators (the variants the link error refers to). Definitely a strange one...I've also opened up a thread with Microsoft, but unless I can extract a repro for them I don't think it'll be much help.
  4. Normally something I would follow up on in a Microsoft forum, but thought I'd drop in here first... I had migrated my project from Visual Studio 2010 to Visual Studio 2017 late last year, and everything went smoothly. Just recently, however, I was reviving a testing harness I was using for network code and have been encountering a linker error that is slightly befuddling. Specifically, only in my release builds, I get these: MSVCRT.lib(delete_array.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPEAX@Z) already defined in MSVCRT.lib(delete_array.obj) MSVCRT.lib(delete_scalar.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPEAX@Z) already defined in MSVCRT.lib(delete_scalar.obj) Now, normally the first stop in MSVCRT linker errors is to check and make sure all the CRT code generation settings are matching across all libs (Multithreaded DLL, etc.). I have meticulously checked ALL settings 6 times over to ensure they match. But then, things are actually a little strange when you consider that in this particular case it's complaining that something in MSVCRT.lib is already defined in...MSVCRT.lib. That's interesting. I do have my own overrides for global new and delete, and commenting out the specific ones noted in the link errors does get things linking error-free. It is worth noting that my overrides are NOT inlined (I guess these days, it's actually not allowed). Further, why it is *only* those two variants (not the std::nothrow_t variants), and only delete (no issues with the overridden new(s)) is a bit perplexing. Even more, I am using said overrides/library in many other projects without this issue (and as noted, this was not an issue in this particular project back in Visual Studio 2010). This smells to me like a Visual Studio 2017 linker issue, but I thought I'd pop in here and see if anyone had seen something similar?
  5. I managed to get this tested on a Windows 10 machine, and it behaves correctly (returns "::1" as the link-local address). Another Windows 7 machine exhibits the problem. So with that small sample size, it appears it's something that's since been fixed after Windows 7.
  6. Oh yes, I am well aware of Windows 7's support status/EOL. I have nothing against Win10 (although I prefer Win7 overall). But for the purposes of development (and at present a one machine dev/testing local environment), I find it advantageous to develop on my min supported spec. Once Microsoft (and more consequentially, publishers) drop Windows 7 support then onwards and upwards to the latest I will go. I sure as heck am not going to run an OS that isn't getting security updates any longer. But I am generally of the mindset that I want to support as many users as possible (read; older hardware/OS) when it's within reason to do so. I also derive some sort of sadistic satisfaction in finding workarounds to these weird OS-specfiic quirks...at least, when it's not a critical blocking issue.
  7. Yes, I suppose on reflection perhaps this is the code path/combination less traveled. As you stated, routers not supporting hairpin was the impetus for having the local discovery. That's what I get for trying to support older hardware...no good deed goes unpunished, as they say. I've put together a repro which I'm planning to send off to Microsoft. Should anyone have the time to drop it in and see the results on their system, that would be more data I could provide. I'm particularly interested in the results on Windows 8+ systems. I expect unless one could contort this into a "security issue", the chances of this getting fixed on Windows 7 are slim to none. DualStackGetsocknameRepro.cpp
  8. Well, my IPv6 internet discoverability seems to have fixed itself (test-ipv6.com reports full 10/10 now...yay AT&T). So I think we're pretty firmly in the land of "OS network stack issue". I did implement my aforementioned disgusting hack, which gets me around the issue. But I also find it sort of hard to believe that no one else has encountered this. Are folks generally not doing dual-stack sockets, and/or is my method of link-local address discovery not common?
  9. I'm running on Windows 7 Ultimate 64-bit, SP1. My ISP is AT&T. For what it's worth, my network setup is I have my own router chained behind their garbage Pace 5268AC gateway (not DMZ'd, and this thing has no real passthrough mode). I am configured for native IPv6, am assigned the proper addresses, etc., and I was fully IPv6 accessible the last time I checked explicitly. However, as mentioned in my original post, something got broken recently and my IPv6 internet discoverability is hosed. That said, I have also tried the link-local discovery just using the loop-back addresses as the destination (127.0.0.1, and ::1, respectively), and I get the same behavior (everything comes back properly except the dual-stack IPv6, which in this case gives me ::ffff:0.0.0.0,53123). So I am less inclined to think it's some ISP-related issue, and more likely a quirk of my local network stack, as you say. That's an interesting thought. While I prefer to keep the client server(s) address discovery homogeneous across remote/local networks (everything goes through the remote lookup, which provides all the remote/local address info), the server broadcast to discover own local address is not a bad take. The other distasteful thing to do in my GetBoundLocalAddressForDestination() method on my socket class is when we see that we're dual-stack and the destination address is IPv6, simply create a new temporary IPv6 socket with the same port and use that for discovery. I suppose it's conceivable that it might get bound to a different network interface (and thus this may not be the most reliable way), but it's certainly a quick-and-dirty fix. Thoughts?
  10. I have a multiplayer-enabled PC (Windows 7+, UDP) game project, which I've had IPv4 and IPv6 successfully running on for quite some time (via a config option to select one or the other). I've finally just now got around to adding dual-stack socket support so that I can accommodate IPv4 and IPv6 players at the same time on the same server. This was pretty straightforward, and overall things seem to be working as expected...all permutations of socket types (single or dual-stack) can connect to all permutations on the other end, transmit/receive data, etc. However, I am seeing one strange thing that I have yet to figure out. Part of the data I provide when advertising a server connection is the *local* IP address, so that clients on the same network as the server can connect directly (try local IP, then remote). To generate this link-local IP address, I use the standard connect, getsockname, disc-connect method. This has been working perfectly for eons for both IPv4 and IPv6, and with the dual-stack socket it gives me what I expect in all cases except one. When I provide an IPv6 destination address to a dual-stack socket for determining the link-local address, getsockname is giving me back a mapped IPv4 address. Further, that (mapped) address is not even an IPv4 link-local address, it doesn't make much sense (ffff:38.0.23.0, port 51013). The port is completely sensible (it is one past the last one allocated). I check all return values on all socket calls, everything is returning success. As implied above, I do get the proper mapped IPv4 local address when I provide an IPv4 mapped destination address. But for the life of me I can't figure why I'm getting this result for a straight IPv6 destination address. It's worth noting that my internet IPv6 connection seems to be a bit flaky at present. I am able to do IPv6 DNS lookups, but I am seeing that websites are reporting they can't get my IPv6 address (google IPv6 test site, for instance). Now, I might reasonably expect that my connect call would fail in such a scenario, but that's not the case. But I can also reason that the IPv6 address doesn't necessarily need to be reachable to determine what the bound local address/port will be...? Especially since this all works just fine on a straight IPv6-only socket. Has anyone seen this before? Am happy to provide more details that might help.
  11. In addition to everything mentioned, one further thing to consider is that you are effectively surrendering control of when global static variables are created/instantiated. This may not be an issue in many cases, but for managers/containers that may need to interface with a custom memory manager, or otherwise have order-of-creation dependencies (sometimes dealing with platform requirements), it proves problematic. For that reason (and the others previously mentioned), and to otherwise simply be able to reason about and control what objects are being created/initialized when, static objects are are forbidden in most projects I have been involved with. While it may be fine and suit your current purposes, I would suggest you avoid them going forward. Static methods are more of an interface/stylistic choice. While it's a bit of an ugly pattern, I have seen a workaround to the above concerns with global static variables by making the global static variable a pointer to an object, and then putting an initialization check + creation into any static method which accesses it. IMO, at that point you may as well have static Initialize()/Terminate() methods and be very explicit about when you are creating/destroying your object(s), rather than doing it "on demand".
  12. What it sort of boils down to is that if you want to support Windows 7, then depending on what bits of the DirectX SDK you're using you might need to install the Legacy Standalone (June 2010) DirectX SDK to have access to those older versions. I believe XInput 1.3 is one of those things (and the older XAudio version may be as well, IIRC). You shouldn't need to supply redistributables for XInput (although there is a legacy DirectX redist), but you need to build against the earliest version that supports the Windows version you need. https://blogs.msdn.microsoft.com/chuckw/2012/04/25/xinput-and-windows-8/ https://blogs.msdn.microsoft.com/chuckw/2010/09/08/not-so-direct-setup/ This also may mean you need to do include path shenanigans in your projects to make sure you're including the legacy SDK headers and not a more recent Windows SDK version. Once you move past needing Windows 7 support (which no one really can afford to do yet), I think there is no more need for the Legacy standalone DirectX SDK and things are much simpler.
  13. I believe Windows 7 only supports XInput 1.3 (or 9.1.0)...I don't think you can redistribute 1.4 for Windows 7. Which is to say, XInput 1.4 is only available with Win8+ SDK. https://msdn.microsoft.com/en-us/library/windows/desktop/hh405051(v=vs.85).aspx
  14. Just a quick correction to this statement: stdint.h was first supported/supplied in Visual Studio 2010, so while Microsoft was behind the ball on this, it's been in there for some time now.
  15.     Yes, I was not quite clear enough on the intent.  I didn't mean to imply you would need to do this "live" all the time.  Rather, you can use it to validate that your assumption about the endianness of the system is valid.  To Hodgman's point, an assertion or static assertion at the right place to indicate if there's a mismatch.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!