Windows 8

I don't run either DevCPP or Windows 8. However, I did some checking around and found the following answers. The related links to them are provided beneath this answer.

1) Run DevCPP in Windows XP Compatibility Mode: right-click the icon and select "Run in earlier versions of Windows"

2) Update DevCPP (see the SourceForge related link below)

The problem seems to be that you're running an outdated version of MinGW GCC.

If neither of the above answers help, try a Web search for devcpp "windows 8" or devc++ "windows 8".

Also, keep in mind that Windows 8 is still in beta development, so expect errors and problems to crop up. I'd recommend sticking with earlier Windows versions until at LEAST a service pack gets released if you continue to encounter technical difficulties and are unable to find answers on the Web.

Winsl 8 sngl olp nl acdmc legalization getgenuine

This OS full version for new systems or only upgrade version for existing old pc.

"Commit charge" is the total size of all memory which could be stored in the page file(s). It can be thought of as the amount of memory needed by running programs and their data. (In this context, "memory" can be more than just "RAM".)

Modern computers and operating systems don't simply put programs and data into RAM "as is". They use more sophisticated techniques to manage memory. Memory is divided into "pages". Each task gets its own "virtual address space" (also called "virtual memory"). Pages in the virtual address space are mapped to physical RAM and other hardware. That mapping is done by the memory management unit, which is part of the microprocessor.

Some pages may be shared among multiple tasks. These may be the same for all processes. Some shared pages may be "copy on write", where a page starts out as a virtual copy of another page. As long as that virtual copy is only read -- and never written to -- only the original page is needed. An actual copy in RAM isn't made until the virtual copy is written to -- the copy is made "on write", not "on copy".

Some pages in the virtual address space are not used for program storage at all. Disk, video, and network interface controllers generally have memory or buffers of their own, and these get mapped in to virtual memory as well. These pages are used for hardware input/output operations, not storage.

Files from file-systems on disk volumes can also be mapped into virtual memory, making reading and writing to those files work just like reading or writing memory.

As a program runs, it requests memory from the operating system. The system allocates that memory as pages, but doesn't necessarily map them to RAM right away. The system may wait until the program actually accesses the pages before mapping them. This lets a program request a big chunk of memory all at once, even if it doesn't need it right away.

As RAM gets used up, the system can move the contents of less-recently-used pages out to disk (in the page file), freeing up RAM for more active use. If a program then tries to read or write from such pages, the system reads the contents back into RAM before allowing the program to continue.

Because of all this, pages allocated in virtual memory doesn't necessarily use RAM or the page file. Not all pages are allocated for storage, and even those that are allocated for storage may be copies or unused. The system hasn't necessarily allocated actual storage for those yet. However, once a page is allocated for storage, the system is committed to being able to provide storage for it if needed. That is the "commit charge" -- the storage the system has to be able to provide if asked.

Imagine a program which allocates a huge chunk of memory but doesn't use any of it right away. The commit charge will be large, even though actual storage used (RAM, page file) will be small. If that program then writes to every one of those pages, the storage used will catch up to the commit charge.

The limit on the commit charge is the size of usable RAM, plus the size limits of all page files.