Więcej niż 4GB RAMu w Windows 7 x86 - program (download)

Jeżeli macie zamiar się sprzeczać kto ma rację, podawajcie jakieś dowody dotyczące waszego stanowiska.
Najlepiej takie, które można sprawdzić (głównie linki).
Posty na zasadzie "ja wiem to" i odpowiedzi "a ja wiem tamto" będę usuwał. Jeżeli będą bez jakiś dowodów.

W pliku C:\Windows\System32\spp\tokens\ppdlic\Kernel-ppdlic.xrm-ms są wpisane odpowiednie ograniczenia

@Inixi
W Windows Server jest 64GB w max allowed

A jak nie wiesz co to są za pliki w tym katalogu to nie mamy już więcej o czym gadać...

Reszty dowiesz się tutaj: http://www.remkoweijnen.nl/blog/2009/06/...of-memory/

War_3_ napisał(a):Jeżeli to podmienia oryginalne jądro(tak to zrozumiałem), to czy nie jest to łamanie praw autorskich ?

Ależ oczywiście, że jest! Lecz nie o to rozchodzi się, bo gdyby faktycznie to działało, to nie miałbym nic przeciwko.


http://infojama.pl/174,artykul.aspx

Cytat:Windows Server 2003 Enterprise Edition - posiada rozszerzoną funkcjonalność niż wersja Standard Edition o obsługę klastrów serwerowych, usług wielokatalogowych oraz serwera plików dla komputerów Macintosh. Wspiera niejednolity dostęp do pamięci, obsługę procesorów 64 bitowych Intel Itanium, może wykorzystywać do 32GB pamięci RAM przy zastosowaniu procesorów x86 lub 64GB RAM przy wykorzystaniu procesorów Itanium. Obsługuje maksymalnie 8 procesorów.

Czyli po prostu usługa katalogowa - active directory, obsługa macierzy dyskowych i ROLE, które są dostępne obsługują to poprzez wywołanie z svchost.

Programy desktopowe tych funkcji nie posiadają, dlatego w życiu nie będą wykorzystywały na systemie 32bit więcej niż 4GB RAM, zresztą na stronie, do której podałeś mi linka jest to wytłuszczonym drukiem napisane.

A żebyś nie trudził się z szukaniem tego, to specjalnie wkleję to tutaj:

http://www.geoffchappell.com/viewer.htm?...memory.htm

wyciąg ze strony, na której autor napisał(a):In 32-bit Windows, a process’s user-mode code is allowed between 2GB and 3GB of linear address space (depending on the increaseuserva boot option), and the remainder of the 4GB is reserved for use by kernel-mode code. Both 32-bit and 64-bit Windows can use all of physical memory, including above 4GB, but a 32-bit Windows application has at most 3GB of linear address space through which to access any physical memory.

Dobra koniec gadki, mi wszystkie procesy 3DSMax zajmują nawet 5GB RAM więc twoje argumenty są o kant D rozbić. A poza tym WS 2003 a WS2008 to ogromna różnica. Daj se już * i idź się przejść na świeże powietrze może ci przejdzie...

O nie nie, przez rozszerzanie głupoty w okresie wielu lat, do ludzkich łbów trafiała częściej niż czysta logika:

2 ^ 32 !> 4294967296

Czysta matematyka szanowny Panie.
Zamiast robić akcje marketingowe jakimś programom, które to niby ułatwiają życie, a tak na prawdę zaśmiecają dysk, ludziom powinno się wykładać HOW TO krok po kroku jak dojść do rozwiązania sytuacji i takie rzeczy zostawiać dla potomnych.

(25.01.2010 15:58)Inixi napisał(a):  O nie nie, przez rozszerzanie głupoty w okresie wielu lat, do ludzkich łbów trafiała częściej niż czysta logika:

2 ^ 32 !> 4294967296

Czysta matematyka szanowny Panie.
Zamiast robić akcje marketingowe jakimś programom, które to niby ułatwiają życie, a tak na prawdę zaśmiecają dysk, ludziom powinno się wykładać HOW TO krok po kroku jak dojść do rozwiązania sytuacji i takie rzeczy zostawiać dla potomnych.

Ble BLe Ble

http://en.wikipedia.org/wiki/Physical_Address_Extension

PAE - Rozszerzeń Fizycznego Adresu - jak sama nazwa wskazuje

Jak już coś to:
2 ^ 36 !> 68719476736

Poza tym:

"For the ordinary kernel, the license value for the maximum physical address is the same as for the total amount of memory, but the PAE kernel has a separate license value, named Kernel-MaxPhysicalPage. Again, the data for this value is a number of MB. Again, all 32-bit editions of Windows Vista are installed with this value set to 0x1000, representing 4GB.

The run-time limit arises from needing to be sure that an array of MMPFN structures can be set up to represent all the pages of physical memory, one structure per 4KB page, from zero up to the maximum physical address. The kernel’s capacity for such an array depends on how much of the linear address space is already in use. This gives the run-time limit on the maximum physical address. It is the size of the largest block of free linear address space, divided by the size of an MMPFN structure (0x18 or 0x1C bytes for the ordinary and PAE kernels, respectively), and then multiplied by the page size.

The preceding calculation also produces an architectural limit on the use of physical memory by 32-bit Windows with a PAE kernel. The largest block of linear address space that is available even this early cannot be as large as 1GB and could be much smaller. Even if it is very nearly 1GB, that’s only enough to fit an MMPFN array for a maximum physical address of 128GB (given that the maximum should be a power of two). This limit is hard-coded in the PAE kernel, as is 4GB for the non-PAE kernel.

For the question of whether the kernel in 32-bit Windows Vista will use all the physical memory it learns about from the loader, the hard-coded limit of 4GB is dominant as the maximum address for the ordinary kernel, which truly cannot form addresses for physical memory above 4GB, but the license limit is dominant for the PAE kernel. If you have physical memory above 4GB and wonder how it can be that the PAE kernel does not use that memory, the answer is licensing. The 32-bit code for using memory beyond 4GB is present in Windows Vista as Microsoft supplies it, but Microsoft prepares license values in the registry so that this code never gets to work with any physical addresses above 4GB. "

Jeśli masz więcej niż 4 GB i zastanawiasz się, jak to możliwe, że po włączeniu kernel PAE nie używa tej pamięci, odpowiedzą jest: licencjonowanie!. Wykorzystywanie pamięci powyżej 4GB jest możliwe przez 32 bitowy soft w Windows Vista, jednak Microsoft za pomocą odpowiednich wpisów licencjonowania w rejestrze uniemożliwia wykorzystanie tej pamięci powyżej 4GB.

A ja Ci tłumacze że Sunrise dostarcza drugie alternatywne jądro do Windows 7 i umożliwia rozruch z nim. Plik się nazywa ntsunkrnl.exe. Modyfikuje też odpowiednie wpisy i dodaje opcję botowania za pomocą tego kernela. Nie podmienia oryginalnego!



Ale tyś odporny na wszelkie argumenty

Czy mam rozumieć przez to, że namawiasz na korzystanie z nielegalnego kernela przy włączeniu tej opcji w Sunrise? Skoro to jest podmieniony kernel niepochodzący od M$ i nie jest OpenSource to zdaje mi się, że jest nielegalny...

---

Ps. Dlaczego 2 ^ 36 ? O ile pamiętam to posługujemy się potęgami dwójki (2,4,8,16,32,64,128 etc).

@Inixi
Masz rację, że pojedynczy proces ma ograniczenie od 2 do 3GB.

Ale nie zmienia to faktu, że suma pamięci udostępnionych przez jądro dla procesu może przekraczać 4GB. I zmiana sterowników i API nie jest konieczna, bo dla każdego procesu działają one w zakresie 4GB. Rozszerzenie adresowania jest niewidoczne dla procesów. Nie jest im potrzebna wiedza gdzie znajduje się fizycznie pamięć odwzorowana na jej prywatną przestrzeń adresową.

izaw, mogę mieć fizycznie 4GB RAM w systemie, a ustawić, żeby system widział nawet i 128GB poprzez wpisy w rejestrze, albo WMIC, lecz aplikacje i tak wyrzucą komunikat "out of memory" jak przekroczą granicę 4GB, ale tamten Pan upiera się, że to kwestia tylko licencji. Tak jakby ta metoda działała na zasadzie "i co z tego, że nie działa, skoro widać".

(25.01.2010 20:27)Inixi napisał(a):  izaw, mogę mieć fizycznie 4GB RAM w systemie, a ustawić, żeby system widział nawet i 128GB poprzez wpisy w rejestrze, albo WMIC, lecz aplikacje i tak wyrzucą komunikat "out of memory" jak przekroczą granicę 4GB, ale tamten Pan upiera się, że to kwestia tylko licencji. Tak jakby ta metoda działała na zasadzie "i co z tego, że nie działa, skoro widać".

Program "tamtego pana" umożliwił mi dostęp do całej pamięci w moim komputerze (Lenovo Y530 3GB ram, 1GB GF9600GS). Wcześniej miałem dostęp do 2,5GB ram - teraz mam już pełne 3GB. Tak więc u mnie spatchowanie jądra jak najbardziej pomogło.

(25.01.2010 18:30)War_3_ napisał(a):  Czy mam rozumieć przez to, że namawiasz na korzystanie z nielegalnego kernela przy włączeniu tej opcji w Sunrise? Skoro to jest podmieniony kernel niepochodzący od M$ i nie jest OpenSource to zdaje mi się, że jest nielegalny...

---

Ps. Dlaczego 2 ^ 36 ? O ile pamiętam to posługujemy się potęgami dwójki (2,4,8,16,32,64,128 etc).

Czyli jak coś nie pochodzi od MS albo nie jest OpenSource to jest nielegalne?

A gdybyś wszedł chociażby tutaj: http://en.wikipedia.org/wiki/Physical_Address_Extension
To byś wiedział że włączenie PAE powoduje rozszerzenie adresu fizycznego z 32 do 36 bitów

"x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits"

(26.01.2010 18:28)sCooBy^ napisał(a):  Czyli jak coś nie pochodzi od MS albo nie jest OpenSource to jest nielegalne?

Jeżeli nie masz na to licencji to moim zdaniem tak.

A niestety wątpię, że osoby rozpowszechniające i te które zmieniły kernel (patrz: ruski patch do kernela, o którym była mowa) miały na to licencję, prawda?

To nie wątek dotyczący rozstrzygania o prawach autorskich itd...
Takie rzeczy są szeroko opisywane w necie. Zresztą Nie ma różnicy w cenie Win7 x86 i Win7 x64 i z tego co wiem osoby które zakupiły x86 mają prawo do instalacji x64 na tym samym kluczu. Więc taka modyfikacja nikomu (zwłaszcza MS) nie przeszkadza. Może jedynie pomóc ludziom którzy z jakichś powodów nie chcą instalować wersji x64 a mają więcej niż 4GB RAM

http://www.geoffchappell.com/viewer.htm

A jak odniesiesz się do tych 36 bitów ?

Cóż, nie wiedziałem o tym, ale się dokształciłem i wychodzi na to, że x86 z PAE to jest 2^36, czyli bodaj maksymalnie 64gb pamięci mogłoby obsłużyć.

O ile wiem M$ nie wygłosił oficjalnego stanowiska odnośnie tego zmienionego kernela, więc nie wiemy czy im przeszkadza czy nie.

Nie wiem też na ile jest to skuteczne rozwiązanie (to rozszerzanie pamięci) - na Twoim screenie z TM masz ponad 1gb pamięci buforowanej (co by dawało 4gb w użyciu fizycznym i 1gb buforowane = 5gb zajęte jak widać.
Nie testowałem, więc nie wiem jak to wygląda w praktyce.

(26.01.2010 18:57)War_3_ napisał(a):  Cóż, nie wiedziałem o tym, ale się dokształciłem i wychodzi na to, że x86 z PAE to jest 2^36, czyli bodaj maksymalnie 64gb pamięci mogłoby obsłużyć.

O ile wiem M$ nie wygłosił oficjalnego stanowiska odnośnie tego zmienionego kernela, więc nie wiemy czy im przeszkadza czy nie.

Nie wiem też na ile jest to skuteczne rozwiązanie (to rozszerzanie pamięci) - na Twoim screenie z TM masz ponad 1gb pamięci buforowanej (co by dawało 4gb w użyciu fizycznym i 1gb buforowane = 5gb zajęte jak widać.
Nie testowałem, więc nie wiem jak to wygląda w praktyce.

Ja widzę, że coś jest nie tak
Zadeklarowane powinno być 5800 z hakiem na 9141 MB.
Dostępna powinna być Razem - (Buforowana + Wolna)

Albo coś gosciu kręcisz, albo sobie biedy narobiłeś tym paczowaniem.

Ok, pokazujesz większe zużycie niż wcześniej i pamięć buforowana nawet spadła.
Czyli wychodzi, że korzystasz z większej ilości pamięci (a może nie, to może być system x64 który pokazujesz ) niż obsługiwane 4GB.

Tylko zastanawia mnie co M$ na takiego kernela i gdzie jest ha ha haczyk (ukryty lub nie, gdzieś musi być) ?
Oczywiście można też nie korzystać z tej opcji jeżeli ktoś nie chce jak np. ja, zgadza się?

(26.01.2010 20:35)Inixi napisał(a):  Ja widzę, że coś jest nie tak
Zadeklarowane powinno być 5800 z hakiem na 9141 MB.
Dostępna powinna być Razem - (Buforowana + Wolna)

Albo coś gosciu kręcisz, albo sobie biedy narobiłeś tym paczowaniem.

Kto ci tak powiedział?

Tutaj masz np. screen z http://tnij.org/fnoe

@Inixi nie zrozumiałeś mnie.

Tutaj są dwie sprawy.

Jedna to ilość pamięci dostępna dla pojedynczego procesu. I tutaj nic się nie zmienia. Aplikacja ma dostępną 32 bitową przestrzeń adresową. Choć nie jest to tak dobrze, bo część z niej zajmuje jądro.

Druga sprawa to pamięć dostępna dla systemu. I tutaj jest różnica. System może widzieć więcej. A co to daje? Masz na pokładzie 16GB RAMu i odpalasz aplikację korzystającą z 2GB. Potem drugą. One sobie pracują w tle, a ty w tym czasie robisz coś innego. Na standardowym systemie największą pracę wykonuje dysk, a konkretnie plik wymiany. W nowym jądrze system może każdej udostępnić RAM i każda aplikacja ma szansę pracować sensownie. Oczywiście jeżeli procesor się wyrobi.

Podsumowując. Każda aplikacja działa identycznie, tylko ma szansę na pamięć fizyczną, a nie z pliku dyskowego. Ale system ma już możliwość tak przeadresować, że każdej aplikacji może udostępnić RAM.

No więc tak sCooBy przetestowałam tą opcję na 32 bitowym Windows 7 i mam kilka spostrzeżeń, po pierwsze i najważniejsze podobnie jak w przypadku zastosowania rosyjskiego patcha, po instalacji sterownika Mobile Intel® 4 Series Express Chipset Family do kart Intelowskich, podobnie jak po w/w patchu występuje blue screen.
Owszem tak samo jak patch działa, ale tylko do momentu zainstalowania w/w sterownika, później przy ładowaniu systemu następuje błąd. Wnioskuję zatem, że ta modyfikacja owszem działa ale nie u każdego. Są w takim wypadku dwa wyjścia pierwsze to nie korzystać, a drugie nie instalować sterownika. Mi osobiście to drugie nie bardzo pasuje, nie wiem czy takich przypadków jak u mnie będzie więcej (ponieważ dużo zależy od konfiguracji komputera), ale może faktycznie była by możliwość jakoś ten problem rozwiązać, myślę, że wtedy więcej osób mogłoby z tego skorzystać. Pozdrawiam

Oczywiście screeny zrobione już na bocie bez modyfikacji, jedynym rozwiązaniem w tym przypadku jest tryb awaryjny i odinstalowanie sterownika, wtedy modyfikacja działa poprawnie.

A to widok z Monitora wydajności po usunięciu w/w sterownika: