The way you're supposed to do this is to launch the developer command prompt.  In VS2013, this is in all programs->Visual Studio 2013->Visual Studio Tools.  Then cd to the directory your stuff is in and run the batch file.  They move this for every Visual Studio version.  I have no idea where it is for 12.  If headers are still missing, then it is possible you're missing dependencies.  If this is the case, good luck: setting up dependencies on windows can be a bit tricky at the best of times.  If windows.h is missing, then VS is not set up properly.  If anything else is missing, then you should say what it is so we can determine if VS is not set up properly.
You're not supposed to manually set any environment variables.  If you did this via control panel and not via writing a batch file, they are permanent.  In that case, you must undo them now.  If you don't, it will just screw everything up.
And the prompt you want is the regular one.  Ignore all the options for cross compilation, and you probably aren't going to want anything 64-bit, either.
if problems persist and it is not missing dependencies, then something may be wrong with the batch files.  Did you write these yourself?
And what are you trying to build and what are you trying to call it from?  This might be one of the notoriously hard ones as it is.

Okay. No.  Go look at all the new 32-bit tablets.  And the fact that everything under the sun runs 32-bit code.  32-bit is not going anywhere, and it is not a magical ram fix.  It's not a magical anything fix.  Your players will literally not notice.  It's also not something you can do if the thing with which you wish to use the DLL is 32-bit because you're not allowed to mix them in the same process.
most machines in this community don't go above 4 gb.  If you have a machine that goes above 4 gb and your game somehow manages to be super ram hungry, it might matter.  It is also worth remembering that the size of a pointer when using 64-bit code is doubled, which is why we have seen a bit of a comeback for tablets: when you have only 1 or 2 GB for everything, doubling the size of literally every pointer on the system is not a happy thing.  I should also point out that the VS defaults when using the IDE are still 32-bit.  64-bit matters for mathematical code and technically it gives the compiler more registers, but the actual performance and ram gains in this case are not important.  You're not going to see a real speed-up unless you're using C/C++ directly and for everything, and if your Audiogame needs 4 GB then we need to talk about algorithm efficiency because few here have 4 GB free on their system to throw at your program.
64-bit is a nice thing, potentially.  As in, in another 5 years when literally every non-tablet computer has enough ram for it to actually matter.  But even then you're still going to have the tablets and the servers, and neither of those likes or needs 64-bit code.  People have been saying that 64-bit is going to replace everything since it first came out, but I'll let you know when that actually starts happening.  For most programs, doubling the native sizes of a pointer and an int is not worth being able to access >4 gb of ram because they don't need that much, and now they've just doubled their ram footprint.

yes. You must launch the compilation from the developer prompt.  You cannot ever do c++ programming things by pressing enter in explorer, at least not without some fun and very hacky setups.

Running it from the developer prompt did what I wanted.
Compiling and debugging in the console is a little troublesome though, anyway thank you for the information.

I'm gonna agree with defender and camlorn here. Camlorn has actually helpt out with quite a lot with dmnb, and if it wern't for his handy link for getting a restart script for the server, we wouldn't be having the server up as offen as we do now. By the way camlorn thanks a lot for that. On this argument of 64 bit. I myself have a 32 bit computer, and do not have the current funds to replace it.

Oh, and one last thing: Camlorn does not know everything. He is not a god. He is not god. If he really did know everything, I might trust him much more. But just because you might know everything there is to know about a language does not give you to right to go and brag about how its so cool and such, or intentionally make everyone else feal like their put down because you think you know everything.

I did not say that everything under the sun is 32-bit, just that 32-bit code is not obsolete yet, nor will it be soon.  If your computer is going to have more than 4 GB of RAM, then it will need a 64-bit processor and a 64-bit OS to take advantage of it.  Even 32-bit programs get benefit from this as the operating system can give them more memory.  Back on the older 32-bit only systems, you'd have to keep back half the ram for windows.  I cannot go into specifics on how this works because honestly I've never cared enough to learn X86 assembly far enough to write my own virtual memory management, but there are many books on Windows if you're interested in specifically how Windows manages memory.  The last time I had to go there, I used Windows Internals.  That's not a bad book and it's on Bookshare with decent quality as I recall.  The key point here is that letting your OS access more than 4 GB of ram is a super good thing even if your app can't.
If I'm down in C++ land and I'm doing mathematical code, 64-bit code may help.  but as soon as we're talking about something like BGT or Python, the only benefit is the Ram.  Since you can't reasonably write apps that use more than 4 GB of ram (I'd say that even more than 2 is pushing it), you don't get anything.  I only have 8, and my system is a bit above average.  If we count the OS and the things I have running in the background, we're down to about 5.  If I open your game that uses more than 4 GB and then open Firefox, we're probably looking at near continuous swapping of pages from the hard drive to RAM.  This is way beyond bad for system performance.
A quick bit of math.  On a 32-bit platform, a linked list of ints is 12 bytes per item: the previous pointer, the next pointer, and the value itself.  On a 64-bit platform, pointers double in size.  This raises us to 20 bytes per item.  If you push the 4 GB limit and are using any pointer-heavy data structures, something which is quite common, switching to 64-bit code will give you more ram.  But it'll also push up your ram requirement, possibly quite respectably.  I did have a factual error in my post: C/C++ ints do not change size.  Longs can, but this appears to only be true on OS X.  But pointers are still pretty damning.  I also can't speak for other languages, i.e. Purebasic which is free to do whatever it pleases; pointers pretty much have to be 8  bytes, and that's the only constant across all 64-bit supporting languages.
As for speed, it won't help for most apps.  Our processors have grown in performance exponentially, but ram hasn't.  Nowadays, your app is going to spend a lot of time waiting on ram.  Once you're in a language without the JIT, you lose most gains from having a processor with more registers.  I have done tuning in Libaudioverse along these lines, and it's difficult and counterintuitive.  If you're at a level above where you can do this tuning, then it's not worth worrying about it at all.  It may be possible to do it in something like java, but your solution is going to be fragile and depend on how kind the JIT is feeling today.  I'm not sure if there are any instruction set extensions that only work on a 64-bit processor, but I don't think so.  And even if there are, they're not usually a super big deal unless you're going out of your way to use intrinsics or write assembly for the simple reason that your compiler can't prove necessary conditions to automatically use them to itself.
But the biggest problem is the practical one.  If you have a DLL compiled as a 64 bit assembly, you can only use it in 64 bit processes.  If even one of your dlls is 32 bit only, you have to switch all of them.  Moving a body of C/C++ code from 32 bit to 64 bit can be very difficult depending on what specifically it does.  And then not everyone can run it: 32 bit systems are certainly cheaper, and we have the aforementioned comeback on the windows tablets that only have 1 or 2 GB of ram.  So now you have to compile your app and everything in it twice and put out two versions.  Since you're not likely to actually see any real benefit in most things and it's going to significantly up your ram footprint anyway, you might as well compile as 32 bit and be done with it.  People who truly need 64 bit like to have math and science in their job descriptions, and this isn't us.  Maybe there's something in audiogame programming that can only be done in or would benefit greatly from 64-bit processors.  But I have never, ever, ever seen even a hint of such.
But really I made the original comment because the OP is almost certainly using the DLL with something that is 32-bit, there's like 4 or 5 options for developer command prompt, and using the wrong one is going to give you a DLL for the wrong architecture.  This leads to fun error messages down the road.
And for the record, I don't assume I know everything.  I don't comment on threads for which I don't know the answer.  I say I think when I am unsure.  I'm not sure what you want me to do, Ethin,  pretend I don't have answers?  I've been working with C++ for almost 10 years. I've been working with C++ at the level of a career C++ programmer for the last year and a half.  I have gone through an entire computer science curriculum which I will be finishing in May including 4 classes that talk about this low level stuff.  One of them involved writing programs for a Texas Instruments microcontroller.  Another involved a 12-page research paper and presentation on how Windows works.  If you told me right now that I needed to start teaching a C++ class on Monday or I'd die, that wouldn't really be a problem.  In fact, I'd be thrilled; my ideal job is teaching.  I think that if anyone is qualified to talk about it, up to and including saying that it's probably the wrong tool for the job, it's me.  I submit as evidence Libaudioverse, which you can feel free to download from Github and which I would show to any employer as an example of high-quality, well organized C++.  I'd even expect them to hire me.

read this sentence carefully:
And the fact that everything under the sun runs 32-bit code. 

And I reasert:
And the fact that everything under the sun runs 32-bit code. 

You did say that, Camlorn. You also stated that 32 bit was not obsolete, but don't say you didn't say something you infact did.
Ethin:
Because 64-bit is, as has been clearly stated, doubled. And it's newer than 32 bit, so that's probably why. I don't really know what this whole 32 64 bit junk is all about (I'm just becoming a game programmer, barely that), so can't join the debate. But so far as what's been said here I don't see why, if Ukio is creating this for computers, he shouldn't use 64 bit

Nice speech, Camlorn. I don't code for iwndows phone, so your observations hold no weight. Speaking of weight, where did you learn that pointers are doubled? Did you take apart a processor and look at its internals? (Windows internals only applies to windows. What about Mac or Linux? That book does not apply in that situation.)
Oh, and stop lying to us. Severestormsteve1 said it himself: In post 4 (re-read it if you have to), you explicitly said, "And the fact that everything under the sun runs 32-bit code." Start remembering, Camlorn. Don't lie to us, because your a horrible lyre. Not everything under the sun runs 32-bit code.

God damn!  Ethin, you need to fix that infiriority complex of yours, it's really showing...

I don't even know what to say, it's just so damned obvious that Camlern knows what he's talking about and that your arguing just for the sake of it even though you don't know shit that their isn't any point in explaining it.

Stop wasting everyone's time trying to one up someone who has more years of experience than the time you've been alive, especially considering the relatively short time that you've been dicking around with code in.

Ethin, you started it and you have just been keeping it going. So camlorn was right and you were wrong that's no reason to start a war. I can guarantee you, you will be wrong a lot in your life it happens you have to learn to deal with it. Look at your posts you've completely lost control. Your the same way on dmnb sometimes.
For some reason camlorn seems to always be right lol. He has been helping me learn python and you should see all the stupid questions I have asked him. He doesn't act like a know it all but if you know things like computer science it's pretty easy to correct somebody when there wrong like you were.

No comment