Leaderboard

Get some collection of information to help user open a ticket at a 'service desk' - User ID: Login Name of User - Model: Model of PC - Service Tag: Service tag or serial number of the PC (Tested on Dell) - Computer Name: Identification of the PC - IP Address: All Network adaptors with IP address If the adaptor if not currently in use, mentions '(Disabled)' after the IP address WLan connection : xxx.xxx.xxx.xxx LAN Connection : xxx.xxx.xxx.xxx (Disabled) Putclip when done ComputerInfo.au3 GreenCan

While its most convenient to think of local variables as stored on the stack, there's no guarantees that a variable will be stored there, or even created. Compiler optimizations can completely optimize out a variable, or place it in a processor register. Usually, the only way to be sure that it's going to land on the stack is to somewhere take the address of that variable. But even then, optimizations could get rid of it. Also, anything declared 'static' inside a function, or any variables outside of a function won't be stored on the stack. They'll be stored in the data segment, which is loaded up along with the executable. Heaps are resources that are allocated by the runtime library, or some overloaded functions. Heaps don't have to exist in memory, nor do they have to be allocated using specific structures. As others have pointed out, typically the amount of memory available to the O/S doesn't limit the amount of memory you can allocate for each process. But thats all irrelevant if your focus is on what is keeping track of those resources. Any pointer to a resource must be known by the running code, so if something is allocated, there's a guarantee that something 'concrete' locally will contain a pointer to it (whether its the stack, a register, or a place in the data segment). P.S. Since you're compiling using VC++2010, I suggest learning Modern C++ style. shared_ptr's, weak_ptr's, and unique_ptrs are your friend.