Aby temu zaradzić można użyć Windows NT Image Configuration Utility (Plask!). Narzędzie stworzone przez microsoft, a dostarczone wraz z 'Windows 2000 Server Resource Kit Supplement One'. Pozwala m.in. TRWALE ustalić koligację procesorów (lub rdzeni) dla określonej aplikacji. Trwałość tego przypisania polega na modyfikacji nagłówka wybranego pliku wykonywalnego i zapisaniu w nim informacji odnośnie przydziału zasobów procesora. Należy zatem przed edycją opornej aplikacji sporządzić jej kopię zapasową, gdyż proces nie jest odwracalny (tzn. nie da się wymazać przypisania poprzez program). Jest to o tyle istotne, że po takiej modyfikacji aplikacja może nie zostać rozpoznana przez różne oficjalne patche (rozmiar i zawartość pliku często muszą się zgadzać co do bajtu), które przez to mogą odmówić dalszych czynności patchujących .
Plik 'imagecfg.exe' dla wygody należałoby zapisać w folderze 'C:\windows\system32' umożliwiając korzystanie z niego w każdym folderze, nadając mu rangę polecenia systemowego. Składnia polecenia jest następująca:
Kod: Zaznacz cały
imagecfg -a 0x1 c:\program.exe
Jeszcze garść informacji odnośnie działania programu. Imagecfg.exe został zaprojektowany dla starszych aplikacji, sprzed epoki wielordzeniowości. Muszą być to jednak aplikacje typu win32. Dosowe lub zaprojektowane dla windows 3.11. nie są obsługiwane przez program. Przy próbie użycia go na takowych otrzymacie komunikat:
Dla plików dosowych, systemy operacyjne rodziny Windows NT (czyli od Windows 2000 wzwyż) zostały zaopatrzone w aplikację ntvdm.exe (NT Virtual Dos Machine, zlokalizowaną w c:\windows\system32), służącą do emulacji systemu MS-DOS na potrzeby starszych aplikacji. Ntdvm.exe uruchamiane jest zawsze, gdy pojawia się wywołanie dosowej aplikacji i wówczas również może się pojawiać problem obsługi wielu rdzeni/procesorów. Tutaj sprawa jest jeszcze prostsza - jako,że nie da się użyć imagecfg na dosowym programie, należy ustawić koligację dla ntvdm.exe (kopia zapasowa, żeby nie było płaczu). Wtedy każda uruchamiana przez ntvdm.exe aplikacja będzie od razu korzystać z jednego tylko rdzenia/procesora. Czyli:IMAGECFG: unable to modify DOS or Windows image file - program.exe
Kod: Zaznacz cały
imagecfg -a 0x1 C:\WINDOWS\system32\ntvdm.exe
Przy pierwszym użyciu na danej aplikacji, program imagecfg.exe zwróci komunikat (no chyba, że nie uruchamiacie go z wiersza poleceń - wtedy nie zdążycie zobaczyć co zwróci, bo mignie i zniknie):
Oznacza to, że aplikacja wcześniej nie była modyfikowana pod tym kątem (nie zawiera danych konfiguracyjnych) oraz, że zauktualizowano dane konfiguracyjne i od tej pory koligacja została ustawiona na pierwszy rdzeń/procesor. Jest też informacja, że podsystem jest w wersji 4.0, cokolwiek to znaczy...program.exe contains no configuration information
program.exe contains a Subsystem Version of 4.0
program.exe updated with the following configuration information:
Process Affinity Mask: 00000001
Po użyciu na tym samym pliku polecenia:
Kod: Zaznacz cały
imagecfg -a 0x2 c:\program.exe
To z kolei, oznacza, że dla aplikacji ustalono wcześniej koligację na pierwszy rdzeń oraz, że po aktualizacji zmieniono ją na drugi. Tu znów pojawia się tajemnicza informacja o wersji podsystemu, która wprowadza nieco intrygi w całą sprawę.program.exe contains the following configuration information:
Process Affinity Mask: 00000001
program.exe contains a Subsystem Version of 4.0
program.exe updated with the following configuration information:
Process Affinity Mask: 00000002
Należałoby jeszcze dodać, że oprócz rozwiązywania problemu wielordzeniowości/wieloprocesorowości w starszych aplikacjach, program Imagecfg jest remedium także na intelowską technologię Hyper-Threading (źródło). Jak widać, to małe cacko jest bardzo wszechstronne. Na dowód podam znów przykład Black Dahlii, dla uruchomienia której użycie imagecfg.exe jest kluczowe..., ale odpaleniu tej gry należałoby poświęcić osobny temat.