A free Windows-compatible Operating System - mirrored from GitHub

cdriversgplhacktoberfestkerneloperating-systemososdevreactoswin32win32apiwindowsx86

ReactOS Portable Systems Group 7ca0ac88f8 We were looping the memory descriptors in order to find the number of pages that are available to the system, that is to say, your RAM, minus pages that the BIOS said belong to it. This part is good. Next up, we were creating the page array for these pages, up to the highest entry, which we called, the number of pages on the system. This is the problem. Suppose we had 1000 pages somewhere in low memory that were used by the BIOS, we'd now call the total pages RAM - 1000 (correct). However, we'd also set the highest page array entry to RAM - 1000, which is wrong, because esssentially this eats up 10MB of memory, since the top 10MB (which are FREE, usable memory) are never entered into the database. So really, what we want to do is differentiate the TOTAL amount of usable RAM, versus the HIGHEST page that is usable (which is actually what should be the highest entry in the page array). This will reclaim the lost RAM ReactOS has been eating up all these days. But it gets better: eventually, someone noticed ReactOS was eating memory, and added 1MB more to the "total", making the highest entry "1mb higher". This ...kind of... fixes the problem above by giving you one more MB, but what if ReactOS was only eating up 150KB, as was more the case? Then ReactOS would believe that the other 850KB of memory are "Free physical memory", when actually, they're pages that don't even exist. Wow! ... Fixed these bugs. svn path=/trunk/; revision=32359		2008-02-14 18:33:38 +00:00
irc
reactos	We were looping the memory descriptors in order to find the number of pages that are available to the system, that is to say, your RAM, minus pages that the BIOS said belong to it. This part is good. Next up, we were creating the page array for these pages, up to the highest entry, which we called, the number of pages on the system. This is the problem. Suppose we had 1000 pages somewhere in low memory that were used by the BIOS, we'd now call the total pages RAM - 1000 (correct). However, we'd also set the highest page array entry to RAM - 1000, which is wrong, because esssentially this eats up 10MB of memory, since the top 10MB (which are FREE, usable memory) are never entered into the database. So really, what we want to do is differentiate the TOTAL amount of usable RAM, versus the HIGHEST page that is usable (which is actually what should be the highest entry in the page array). This will reclaim the lost RAM ReactOS has been eating up all these days. But it gets better: eventually, someone noticed ReactOS was eating memory, and added 1MB more to the "total", making the highest entry "1mb higher". This ...kind of... fixes the problem above by giving you one more MB, but what if ReactOS was only eating up 150KB, as was more the case? Then ReactOS would believe that the other 850KB of memory are "Free physical memory", when actually, they're pages that don't even exist. Wow!	2008-02-14 18:33:38 +00:00
rosapps	Deleted ext2 driver	2008-02-11 11:29:54 +00:00
rostests	Winesync to Wine-0.9.55.	2008-02-10 13:22:36 +00:00
wallpaper