Wątek zablokowany 2012-09-16 12:11 przez somekind.
Program czyta dane o pececie z klucza, który w XP był tu:
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System
tam jest data biosu, szybkość procesora w MHz, i inne parametry sprzętu.
a w nowszych windowsach, albo może tylko w wersji 64-bit, program jakoś nie widzi tych kluczy (program jest 32-bitowy).
Co znowu wymyślili te jełopy z Microsoftu - jakaś zgodność powinna być chyba tu zachowana... gdzie poprzenosili te dane?
Może jakiś kod pokaż?
Widzi ale klucz HKEY_LOCAL_MACHINE bez praw admina można otworzyć tylko w trybie tylko do odczytu.
Azarien napisał(a):
Może jakiś kod pokaż?
Chodzi o strukturę rejestru.
Kod jest nieistotny - otwieramy normalnie odpowiednie klucze, itd.
Poza tym gdy wpisuję klucz aplikacji - w HKLM\Software i tu standardowo: nazwa firmy, itd,
Tego nie widać potem w regedit w tym miejscu,
no ale program odczytuje wcześniej zapisane tam dane, więc to nie przeszkadza.
Mam pod ręką tylko Win XP i 32-bit, więc nie mogę sprawdzić gdzie to siedzi w nowszych Win 7, albo raczej w wersji 64-bitowej, bo tu chyba o to chodzi.
kAzek napisał(a):
Widzi ale klucz HKEY_LOCAL_MACHINE bez praw admina można otworzyć tylko w trybie tylko do odczytu.
Jest otwierane do odczytu.
HKEY hChildKey = NULL, hKey = HKEY_LOCAL_MACHINE;
if( ERROR_SUCCESS == RegOpenKeyEx(hKey, string_key), 0, KEY_READ, &hChildKey) )
{
// tu lecimy w pętli po hChildKey za pomocą RegEnumValue...
RegCloseKey(hChildKey);
}
wil napisał(a):
Poza tym gdy wpisuję klucz aplikacji - w HKLM\Software i tu standardowo: nazwa firmy, itd,
Tego nie widać potem w regedit w tym miejscu,
no ale program odczytuje wcześniej zapisane tam dane, więc to nie przeszkadza.
Chodzi o to, że nie masz praw do grzebania w kluczach system-wide, Windows wirtualizuje takie operacje żeby jednocześnie zapewnić bezpieczeństwo i umożliwić pracę średniowiecznie napisanym aplikacjom (jak Twoja). Wprowadzasz zmiany w kluczu, którego nie możesz zapisać jako zwykły użytkownik (użytkownik ma takie prawa do HKEY_CURRENT_USER, do HKLM jedynie odczyt), system przekierowuje operację i wszystko kończy się powodzeniem, Twoja aplikacja widzi dane tam, gdzie próbowała zapisać, mimo wszystko globalna konfiguracja nie uległa zmianom. W ten sposób Microsoft radzi sobie z problemem idiotów siedzących kiedyś na adminie i pseudoprogramistów, którzy nie znają zasad tworzenia oprogramowania dla Windows.
Nie chodzi o to - to mnie akurat nie interesuje.
No, ale widzę że dla dzisiejszy studencików te komputerki biurowe to tajne laboratoria na stole.
Uruchom program z uprawnieniami administratora. Jak będzie działać w porządku to znaczy, że gdzieś są skopane uprawnienia. Twój program nie powinien pisać do HKLM. Tym się zajmują instalatory. Jeśli twój program nie może się bez tego obyć (np. narzędzie do czyszczenia rejestru) to dodaj odpowiedni manifest, program zażąda uprawnień administratora podczas odpalania. W innym wypadku nie powinieneś pisać do HKLM, jeśli instalator nie załatwia sprawy to użyj innych gałęzi np. HKEY_USERS (gałąź wspólna dla wszystkich użytkowników) czy HKEY_CURRENT_USER. Nowsze Windowsy zwyczajnie podnoszą poziom bezpieczeństwa wymuszając odpowiednią architekturę i nie pozwalają sobie grzebać gdzie popadnie pierwszemu lepszemu programowi.
No to sprawdź sobie jaki błąd dostajesz skoro debuggera nie używasz bo funkcja musi coś zwracać:
HKEY hKey = HKEY_LOCAL_MACHINE;
HKEY hChildKey = NULL;
LONG hResult;
LPTSTR errorText = NULL;
LPTSTR string_key = "Software";
hResult = RegOpenKeyEx(hKey, string_key, 0, KEY_READ, &hChildKey);
if (hResult == ERROR_SUCCESS) {
RegCloseKey(hChildKey);
}
else {
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_IGNORE_INSERTS, NULL, hResult, MAKELANGID(LANG_NEUTRAL,
SUBLANG_DEFAULT), (LPTSTR)&errorText, 0, NULL);
//cout << errorText << endl; //lub dla konsoli
MessageBox(0, errorText, TEXT("Test"), MB_ICONERROR);
if (NULL != errorText) {
LocalFree(errorText);
errorText = NULL;
}
}
Tego typu informacje należy pobierać poprzez WMI lub używając odpowiednich funkcji WINAPI. Te klucze nie należą do publicznego interface'u programowania.
Chodzi mi tylko o informacje o sprzęcie, które w XP 32-bit są pod HKLM, a nie userów.
HARDWARE\DESCRIPTION\System
System\CurrentControlSet\Control\BiosInfo
czy to jest w tym samym miejscu w win 7, itp. ?
w 98 było to tu:
ENUM\Root*PNP0C01\0000
A te uwagi o ochronie systemu (przed jego właścicielem),
czyli blokadach wpisu pod hklm\software są śmieszne i możecie sobie to darować.
To nie jest w ogóle mój problem:
jeśli ktoś chce używać jakiegoś softa, no to go sobie na pewno zainstaluje
na swoim własnym sprzęcie, nie na cudzym, do którego nie ma dostępu.
wil napisał(a):
To nie jest w ogóle mój problem
Twoim problemem jest to, że nie korzystasz z rozwiązań oficjalnie oferowanych i zatwierdzonych przez Microsoft. Wina leży wyłącznie po Twojej stronie.
wil napisał(a):
No, ale widzę że dla dzisiejszy studencików te komputerki biurowe to tajne laboratoria na stole.
Mistrzostwo autoironii.
Próbujesz podłączyć kuchnię gazową do sieci wodociągowej, dziwisz się, że nie działa i zrzucasz winę na producenta rur.
Wybacz, ale programowanie to zajęcie dla ludzi, którzy potrafią czytać dokumentację.
wil napisał(a):
Nie chodzi o to - to mnie akurat nie interesuje.
No, ale widzę że dla dzisiejszy studencików te komputerki biurowe to tajne laboratoria na stole.
Jaja sobie robisz chłopczyku? Przyszedłeś zadać pytanie, czy sprowokować całe forum i wyżalić się całemu światu że nie potrafisz czytać dokumentacji, a do badania podstawowych rzeczy użyłeś nieoficjalnych hacków? Jeśli to drugie to najlepiej od razu wyjdź i nie wracaj.
wil napisał(a):
To nie jest w ogóle mój problem:
jeśli ktoś chce używać jakiegoś softa, no to go sobie na pewno zainstaluje
na swoim własnym sprzęcie, nie na cudzym, do którego nie ma dostępu.
Wiesz, że właśnie zakwestionowałeś sens istnienia jakichkolwiek zabezpieczeń i stopniowania przywilejów użytkowników? Jeśli faktycznie nie widzisz sensu istnienia tych mechanizmów to znając życie jesteś typowym luserem, który cały czas siedzi na koncie admina i zrzędzi jakie to te Windowsy awaryjne i zawirusowane.
Widzę że macie tu poważne problemy ze zrozumieniem języka naturalnego.
Mnie naprawdę nie interesują te wasze problemy i metody ochrony systemu przed jego użytkownikami.
Po prostu macie tu klub dla zasrańców - mitomanów, a nie forum... jakiekolwiek.
wil napisał(a):
Mnie naprawdę nie interesują te wasze problemy i metody ochrony systemu przed jego użytkownikami.
System stopniowania przywilejów użytkowników ma chronić nie tyle system, co samych jego użytkowników. Przeanalizuj sobie na serio korzyści jakie daje na przykład odpalenie przeglądarki z konta normalnego użytkownika, a nie administratora. Przykład dość życiowy, obecnie exploitów na przeglądarki jest co nie miara. Różnica? Jedna zasadnicza i dość prosta: w przypadku wdarcia się exploita do systemu przez przeglądarkę wirus może jedynie zaingerować w specyficzną konfigurację obecnego użytkownika, w przypadku administratora można bez problemu podłożyć rootkita, podmienić po cichu bootloader i zaszywać się w dowolnym miejscu w systemie.
System naturalnie nie pozwala zwykłym użytkownikom na zmienianie czegoś co może mieć wpływ nie tylko na nich. Skorzystaj z metod polecanych przez Microsoft, zamiast nieoficjalnych, nieudokumentowanych hacków. Wszystko co potrzebne zostało wspomniane wcześniej w wątku.
Rozumowanie "cały świat to banda jełopów" zwykle z reguły jest błędne, najpierw postaraj się zrozumieć sens istnienia podstawowych mechanizmów, które nie bez powodów istnieją nie tylko na Windowsie, a potem weź za implementację ;]
Po prostu macie tu klub dla zasrańców - mitomanów, a nie forum... jakiekolwiek.
Mitomanów? Póki co to Twój kod korzystający z hacków nie działa. Wykaż trochę więcej pokory, inaczej nie masz żadnych szans. Uwierz, było wielu przed Tobą, którzy myśleli podobnie ;)
Przypominam:
deus napisał(a):
Tego typu informacje należy pobierać poprzez WMI lub używając odpowiednich funkcji WINAPI. Te klucze nie należą do publicznego interface'u programowania.
wil napisał(a):
Widzę że macie tu poważne problemy ze zrozumieniem języka naturalnego.
Mnie naprawdę nie interesują te wasze problemy i metody ochrony systemu przed jego użytkownikami.
Powtórzę raz jeszcze: stosowane przez Ciebie rozwiązanie jest niewłaściwe, te klucze mogą całkowicie zniknąć w kolejnej aktualizacji systemu (w NT 6.x zaszły zmiany m. in. w prawach dostępu, ale nie tylko). Nie są one oficjalną drogą uzyskiwania tego typu informacji, to trick specyficzny dla konkretnych wersji Windows NT. Użyj udokumentowanej metody, jaką są klasy WMI Win32_Processor oraz Win32_BIOS.
wil napisał(a):
Po prostu macie tu klub dla zasrańców - mitomanów, a nie forum... jakiekolwiek.
Mamy tutaj forum dyskusyjne, które służy... dyskusji. Tego typu hacki można naprawić jedynie tymczasowo, kultywowanie i wspieranie złych praktyk prowadzi do obniżenia jakości i niezawodności oprogramowania, jako wieloletni programista Win32 będę podawał wyłącznie WŁAŚCIWE rozwiązania. Co do mitów: wskazałem oficjalne źródła danych, udowodniłem swoje racje. Jeżeli naprawdę chcesz skorzystać z przedstawionej przez Ciebie metody to podaj link do dokumentacji, gdzie znajdują się informacje o tych kluczach, wtedy możesz liczyć na pomoc wykraczającą poza nakierowanie na WMI.
Uważaj na słowa, to moje jedyne ostrzeżenie.
Niestety, ale informacje o zarejestrowaniu produktu - legalności kopii, dotyczą komputera, zatem nie może to być zapisywane pod usera, lecz pod maszynę.
Sam system Windows wyprawia cuda żeby uniknąć nielegalnego kopiowania - instaluje do tego celu specjalne haki i zapisuje tony danych gdzie popadnie, monitoruje zmiany sprzętu.
Informacje o sprzęcie nie są tajne, więc żaden system nie powinien blokować takich informacji, ani próbować utrudniać dostęp do nich.
Cała ta maszyneria wmi jest niepoważna, a tym bardziej że nawala powszechnie, czyli jest wysoce niepewna.
Jest pełno zapytań w sieci jak naprawić to dziadostwo. Sami autorzy tych pomysłów pogubili się w tym - naprodukowali pełno łatek, specjalnych narzędzi do diagnostyki, naprawy, itd.
https://www.google.pl/search?q=wmi+problems
Nowsze wersje windows mogą zmieniać sobie te klucze, tak samo jak i mogą przeprogramować lub wycofać zupełnie to wmi,
a tysiąc razy łatwiej dodać string do listy, niż grzebać się co raz rok, czy dwa, w takich robaczywych cudactwa.
Programiki - zabawki z MS, w stylu sysinfo, mogą sobie używać takich duperelek, a najlepiej powinni to zupełnie utajnić - niech system używa sobie tego wewnętrznie, np. do sprawdzania czy jest legalnie zainstalowany.
@Will: z takim podejściem możesz także nie korzystać z WinAPI, aby komunikować się z rejestrem, bo przecież to może zostać zmienione :|
Najlepiej ręcznie parsuj plik rejestru ( :P ), ale - czekaj!
No przecież potrzebujesz WinAPI, aby móc obsługiwać pliki, a przecież nazwy i parametry funkcji API mogą zostać zmienione!
A może w ogóle za rok wycofają pliki *.exe na rzecz nowego formatu z Pioneer.OS'a i Twoja aplikacja będzie bezużyteczna?
wil napisał(a):
Niestety, ale informacje o zarejestrowaniu produktu - legalności kopii, dotyczą komputera, zatem nie może to być zapisywane pod usera, lecz pod maszynę.
To dorzuć odpowiedni manifest i wymagaj praw administratora podczas instalacji, samo odczytanie klucza stworzonego w HKLM bez nałożonych dodatkowych regułek bezpieczeństwa jest możliwe z normalnego użytkownika.
wil napisał(a):
Cała ta maszyneria wmi jest niepoważna, a tym bardziej że nawala powszechnie, czyli jest wysoce niepewna.
Jest pełno zapytań w sieci jak naprawić to dziadostwo. Sami autorzy tych pomysłów pogubili się w tym - naprodukowali pełno łatek, specjalnych narzędzi do diagnostyki, naprawy, itd.
Przeczytałeś chociaż czego dotyczą te wyniki wyszukiwania?
Pewne zmiany blokady zabezpieczeń wprowadzone w systemie Microsoft Windows XP z dodatkiem Service Pack 2 (SP2) mogą być przyczyną problemów z usługą Instrumentacja zarządzania Windows (WMI), szczególnie w scenariuszach zdalnych.
Patch wprowadzony po to, żeby nieco ograniczyć grzebanie w WMI maszyny spoza tej maszyny. Nie widzę niczego niepoważnego, a że powstają oficjalne artykuły o troubleshootingu to chyba dobrze? Jeśli aplikacja na nowym systemie wysypie się z powodu jakiejś zmiany potencjalnie łamiącej kompatybilność to masz o tym informację bezpośrednio od Microsoftu wraz ze wskazaniami jak robić, żeby było dobrze. Takich wskazań nie dostaniesz jeśli korzystasz z nieudokumentowanych internalsów systemu - one mogą się zmieniać jak się komu żywnie podoba.
Nowsze wersje windows mogą zmieniać sobie te klucze, tak samo jak i mogą przeprogramować lub wycofać zupełnie to wmi,
a tysiąc razy łatwiej dodać string do listy, niż grzebać się co raz rok, czy dwa, w takich robaczywych cudactwa.
Gdzie ta robaczywość? Nie mogą usunąć WMI ze względu na to, że od dawna utrzymują dużą kompatybilność wsteczną. Co innego można powiedzieć o zmienianiu bajerów z których korzystałeś, a których producent nie podawał do publicznej wiadomości.
wil napisał(a):
Cała ta maszyneria wmi jest niepoważna, a tym bardziej że nawala powszechnie, czyli jest wysoce niepewna.
Jest pełno zapytań w sieci jak naprawić to dziadostwo. Sami autorzy tych pomysłów pogubili się w tym - naprodukowali pełno łatek, specjalnych narzędzi do diagnostyki, naprawy, itd.
http://www.google.pl/search?q=wil+problems zwraca 45 razy więcej wyników.
wil napisał(a):
Niestety, ale informacje o zarejestrowaniu produktu - legalności kopii, dotyczą komputera, zatem nie może to być zapisywane pod usera, lecz pod maszynę.
Niestety, ale są legalne sposoby współdzielenia informacji pomiędzy użytkownikami, naprawdę czas douczyć się podstaw programowania dla Windows NT, co najmniej od 2000 nic się w tym względzie nie zmieniło. Jeśli coś dotyczy maszyny (jako całości) to winien móc to zmienić jedynie administrator. Musisz po prostu dobrać odpowiednią lokalizację w zależności od tego, jakiej formy współdzielenia potrzebujesz.
wil napisał(a):
Sam system Windows wyprawia cuda żeby uniknąć nielegalnego kopiowania - instaluje do tego celu specjalne haki i zapisuje tony danych gdzie popadnie, monitoruje zmiany sprzętu.
Wszystko siedzi w kluczach powiązanych z konkretnymi elementami systemu, poza tym nawet powiązane z tym muteksy mają ładne nazwy.
wil napisał(a):
Informacje o sprzęcie nie są tajne, więc żaden system nie powinien blokować takich informacji, ani próbować utrudniać dostęp do nich.
Oczywiście przecież, że nie są tajne, system ich nie blokuje, nie utrudnia do nich dostępu, po prostu te konkretne klucze nie były nigdy przewidziane do użytku przez zewnętrzne aplikacje, nie zostały nigdy oficjalnie udostępnione programistom.
wil napisał(a):
Cała ta maszyneria wmi jest niepoważna, a tym bardziej że nawala powszechnie, czyli jest wysoce niepewna.
Jest pełno zapytań w sieci jak naprawić to dziadostwo. Sami autorzy tych pomysłów pogubili się w tym - naprodukowali pełno łatek, specjalnych narzędzi do diagnostyki, naprawy, itd.
WMI jest standardem przemysłowym, problemy bywają ze wszystkim, przede wszystkim z niepoważnymi programistami, którzy są za głupi na korzystanie z WMI, piszę to z doświadczenia. Dla niektórych rejestr to szczyt pojmowalnej abstrakcji. Dodatkowo "problems" polegają na tym, że pod keywordem "wmi" kryje się cały toolchain i dosłownie setki tysięcy skryptów pisanych przez administratorów podczas codziennej pracy.
wil napisał(a):
Nowsze wersje windows mogą zmieniać sobie te klucze, tak samo jak i mogą przeprogramować lub wycofać zupełnie to wmi,
a tysiąc razy łatwiej dodać string do listy, niż grzebać się co raz rok, czy dwa, w takich robaczywych cudactwa.
WMI jest częścią interface'ów programowania i administracji Windows NT, te klucze nigdy nie były, są przeznaczone do wewnętrznych celów systemu. Czy masz jakieś doświadczenie z programowaniem obiektowym? Technicznie rzecz biorąc można uzyskać dostęp do każdej składowej obiektu, ale czy wykorzystanie czegokolwiek poza publiczny interface nie jest proszeniem się o kłopoty? WMI to jeden z najważniejszych komponentów Windows i główne źródło informacji o sprzęcie, ponad 90% danych nie znajdziesz nigdzie indziej w systemie. "Robaczywym cudactwem" jest Twoje oprogramowanie, WMI jest uznawane za jedno z najlepszych rozwiązań w swojej klasie.
wil napisał(a):
Programiki - zabawki z MS, w stylu sysinfo, mogą sobie używać takich duperelek, a najlepiej powinni to zupełnie utajnić - niech system używa sobie tego wewnętrznie, np. do sprawdzania czy jest legalnie zainstalowany.
Korzystasz z kluczy cudzej aplikacji, które mają prawo ulec zmianie, nie zostały oficjalnie udostępnione programistom, od pozyskiwania tych informacji masz publiczny interface programowania. "Utajnianie" mija się z celem, zawsze znajdzie się jakiś "alchemik", który znajdzie dane w najczarniejszej dziurze i zacznie z nich korzystać.
Patryk27 napisał(a):
@Will: z takim podejściem możesz także nie korzystać z WinAPI, aby komunikować się z rejestrem, bo przecież to może zostać zmienione :|
Oczywiście i z pocałowaniem w rączkę, gdyby windows nie blokował dostępu do sprzętu.
Kiedyś czytałem sobie kawałek ROMu i cześć - operacja zupełnie bezpieczna, no ale od wersji NT są z tym problemy... może da się jakoś to odczytać, ale pomimo wielu prób nie udało się, więc musiałem z tego zrezygnować.
Patryk27 napisał(a):
No przecież potrzebujesz WinAPI, aby móc obsługiwać pliki, a przecież nazwy i parametry funkcji API mogą zostać zmienione!
Obawiam się że chłopcy z MS są za słabi na taką rewolucję.
Te podstawowe funkcje robiono z 20 lat temu - jeszcze w epoce zawodowców, którzy potrafili programować z sensem.
Patryk27 napisał(a):
A może w ogóle za rok wycofają pliki *.exe na rzecz nowego formatu z Pioneer.OS'a i Twoja aplikacja będzie bezużyteczna?
Takie myślenie ma sens, prawda?
Jasne, z tym waszym rewelacyjnym podejściem MS może nawet wymagać programowania w Paint - w formacie bmp.
wil napisał(a):
Jasne, z tym waszym rewelacyjnym podejściem MS może nawet wymagać programowania w Paint - w formacie bmp.
Nie widzę żadnego problemu. Archiwalny mały research deusa: http://deus.4programmers.net/hello_world.bmp
Po zmianie rozszerzenia na .exe wyświetla "Hello World!" ;)
wil napisał(a):
Obawiam się że chłopcy z MS są za słabi na taką rewolucję.
Te podstawowe funkcje robiono z 20 lat temu - jeszcze w epoce zawodowców, którzy potrafili programować z sensem.
No jasne, bo przecież takie rzeczy jak zrywanie elementarnej kompatybilności wstecznej robią tylko programiści z jajem. Jak to dobrze, że do pracy nad Windowsem jednak biorą ludzi wyposażonych w mózg.
Skoro się uważasz za mądrzejszego od programistów MS to może złóż tam aplikację i daj im popalić, tudzież wystąp na jakiejś znanej konferencji? Twoje rewolucyjne przemyślenia niedouczonego eksperymentatora z pewnością zostaną uznane przez któregoś z organizatorów za ciekawy temat na prelekcję.
wil napisał(a):
Oczywiście i z pocałowaniem w rączkę, gdyby windows nie blokował dostępu do sprzętu.
Kiedyś czytałem sobie kawałek ROMu i cześć - operacja zupełnie bezpieczna, no ale od wersji NT są z tym problemy... może da się jakoś to odczytać, ale pomimo wielu prób nie udało się, więc musiałem z tego zrezygnować.
To było 20 (DWADZIEŚCIA!) lat temu, przynajmniej jeżeli chodzi o systemy profesjonalne. Dostęp do pamięci fizycznej wymaga praw admina... Tak w ogóle to np. SMBIOS można odczytać z pomocą WMI właśnie.
wil napisał(a):
Obawiam się że chłopcy z MS są za słabi na taką rewolucję.
Te podstawowe funkcje robiono z 20 lat temu - jeszcze w epoce zawodowców, którzy potrafili programować z sensem.
WINAPI nie ulega zmianom, jedynie rozszerzeniu, to się nazywa "kompatybilność wsteczna". Tak do Twojej informacji: ci sami zawodowcy tworzyli WMI, które od kilkunastu lat jest integralną częścią systemu, również trzyma kompatybilność wsteczną.
To było 20 (DWADZIEŚCIA!) lat temu, przynajmniej jeżeli chodzi o systemy profesjonalne.
20 lat temu był Win 3.1 - 16 bit.
Zresztą teraz też to można zrobić - dosowe programy czytają bez problemu ROM.
WINAPI nie ulega zmianom, jedynie rozszerzeniu, to się nazywa "kompatybilność wsteczna". Tak do Twojej informacji: ci sami zawodowcy tworzyli WMI, które od kilkunastu lat jest integralną częścią systemu, również trzyma kompatybilność wsteczną.
Mnie to nie interesuje, podobnie jak DirectX i inne przereklamowane skecze marketingowe.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa389276%28v=vs.85%29.aspx
nie ma sensu analizować od zera tego szmelcu, żeby odczytać kilka batów o biosie, czy procesorze.
wil napisał(a):
20 lat temu był Win 3.1 - 16 bit.
Ponad 19 lat temu został wydany Windows NT - 32bit.
wil napisał(a):
Zresztą teraz też to można zrobić - dosowe programy czytają bez problemu ROM.
"Teraz" DOSowe programy nie działają w systemach x64. "Teraz" czyli od ponad siedmiu lat.
wil napisał(a):
Mnie to interesuje, podobnie jak DirectX i inne przereklamowane skecze marketingowe.
Powinno interesować, te klucze, które próbujesz czytać to właśnie mirror informacji SMBIOS, naturalnie udostępnianych przez WMI...
wil napisał(a):
http://msdn.microsoft.com/en-us/library/windows/desktop/aa389276%28v=vs.85%29.aspx
nie ma sensu analizować od zera tego szmelcu, żeby odczytać kilka batów o biosie, czy procesorze.
Co tu jest do analizowania? Masz link Creating a WMI Application Using C++, który poprawadzi Cię za rączkę, na końcu masz Example: Creating a WMI Application.
ty jesteś naprawdę tak ograniczony umysłowo czy tylko udajesz? Napisałeś kiedykolwiek coś bardziej skomplikowanego od "Hello Word", gdzie dodanie nowej funkcjonalności to nie było przepisywanie połowy systemu, co działało na różnych systemach i na różnym sprzęcie? Czy kiedykolwiek wyszedłeś poza swoje bardzo wąskie ramy pojmowania świata? A w kuchni rozumiem nadal masz piec węglowy bo przecież gaz/prąd to takie "przereklamowane skecze marketingowe". Tak samo rozumiem, że nie używasz lodówki/zamrażarki tylko trzymasz jedzenie w zimę na parapecie a w lato w ziemiance bo przecież lodówka to takie "przereklamowane skecze marketingowe".
Jeśli chodzi o programowanie to po pierwsze jesteś neandertalczykiem trzymającym się ponad 20-letnich sztuczek, kiedy programista musiał wiedzieć co w jakiej komórce pamięci siedzi a po drugie masz głęboko w dupie wytyczne TWÓRCÓW systemu na który próbujesz coś napisać i wielce się dziwisz, że nie działa. Do samochodu z diesel`em też będziesz lał benzynę i lamentował, że to złom bo nie chce jeździć???
BTW stwierdzenie Mnie to nie interesuje, podobnie jak DirectX i inne przereklamowane skecze marketingowe. bardzo dobrze obrazuje to jaki jesteś zacofany i jak głęboką posiadasz niewiedzę o tym o czym piszesz.
deus napisał(a):
Ponad 19 lat temu został wydany Windows NT - 32bit.
No i co z tego, skoro prawie nikt tego nie używał.
wil napisał(a):
"Teraz" DOSowe programy nie działają w systemach x64. "Teraz" czyli od ponad siedmiu lat.
7 lat temu pojawiły się procesory 64 bitowe, na których do dziś zwykle stoi win 32 - na większości komputerów.
No i to właśnie nawala tylko na 64 bitowych, czyli to nie jest problem ochrony, dostępu, itp. co tu sugerujecie.
wil napisał(a):
7 lat temu pojawiły się procesory 64 bitowe, na których do dziś zwykle stoi win 32 - na większości komputerów.
Dwa lata temu było mniej więcej tyle samo kompów z 32 i 64 bitową wersją Windows 7. Teraz 64 jest w większości.
