[VC++] Registry uitlezen

[sariel]

Hallo iedereen,

ik ben een programmaatje in elkaar aan het zetten dat probeert om de proxygegevens uit het register te halen (zodat er later via de eventuele proxy verbonden kan worden met een webserver).

Ik heb de volgende code om het registry te bekijken:

C++:

void getRegistryValueStr(string keyLocation, string keyValueName, string* pKeyValue)
{
    DWORD dwType = NULL;
    HKEY m_key;
    char data[100] = "";
    DWORD dwCount = sizeof(data);

    if(RegOpenKeyEx(HKEY_CURRENT_USER, (LPCSTR)keyLocation.c_str(), 0, KEY_QUERY_VALUE, &m_key)==ERROR_SUCCESS)
    {
        cout << "a\n";
        cout << RegQueryValueEx(m_key, (LPCSTR)keyValueName.c_str(), NULL, &dwType,(LPBYTE)&data, &dwCount);
    }
    RegCloseKey(m_key); //Always close anything that was opened
    *pKeyValue = (string)data;
}

Dit kan als volgt aangeroepen worden:

C++:

getRegistryValueStr("\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings", "ProxyServer", &strValue);

Op zich, zou dit, theoretisch, prima moeten werken.....maar ja, het blijft Windows, dus niet.
het probleem zit er nu in, dat er geen strings, char* of watooit wordt geaccepteerd voor RegQueryValueEx en RegOpenKeyEx, maar LPCWSTR objecten (2 bytes/char ipv 1 byte/char)....
Fijn allemaal, maar die dingen zijn gewoon niet te converteren van wat naar wat dan ook...(heb net ongeveer 3 uur op het net gezocht, maar niets werkends gevonden....)

Hoe kan ik nou die strings omzetten naar iets wat RegQueryKeyEx zal accepteren?

[The End]

Als jij UNICODE in je project hebt gedefinieerd, dan zal de functie LPCWSTRs moeten verwerken. Als je geen UNICODE hebt gedefinieerd, dan zal de functie LPCSTRs verwerken (gewone chars).

Het staat ook redelijk duidelijk in de documentatie

Overgens kan je met de functies wcstombs en mbstowcs converteren tussen UNICODE en non-UNICODE characters...

[ Voor 19% gewijzigd door The End op 09-06-2006 15:58 ]

[sariel]

Geweldig Bedankt voor de hulp, nu lukt het eindelijk

irritante unicode die standaard aan staat

[The End]

sariel schreef op vrijdag 09 juni 2006 @ 16:21:
Geweldig Bedankt voor de hulp, nu lukt het eindelijk

irritante unicode die standaard aan staat

Je kan, als je alleen voor Windows NT4,2000,2003,XP programmeert, beter overal unicode gebruiken...

Het enige wat je eigenlijk hoeft te doen, is UNICODE aan te zetten (te definieren) en overal char te veranderen in TCHAR.

Op die manier heb je gratis ondersteuning voor andere talen

[sariel]

Andere talen maakt eigenlijk niet uit, want er zal eigenlijk alleen ascii gebruikt worden (nederlandse en engelse taal, speciale characters maakt niet uit)

[Verwijderd]

Dan nog is unicode gebruiken een goed idee.

[MSalters]

Geen goed idee. Ik bedoel via de geristry gaan, dat Unicode gebeuren is allemaal vrij vanzelfsprekend. Er is namelijk een officiele API om de goede proxyserver te vinden. Ik zou maandag even kunnen kijken, want ik heb het recent zelf gebruikt. MSDN helpt ook.

[MSalters]

The End schreef op vrijdag 09 juni 2006 @ 16:31:
[...]
Je kan, als je alleen voor Windows NT4,2000,2003,XP programmeert, beter overal unicode gebruiken...

Het enige wat je eigenlijk hoeft te doen, is UNICODE aan te zetten (te definieren) en overal char te veranderen in TCHAR.

wchar_t zul je bedoelen. TCHAR is een stuk ellende wat je alleen gebruikt als je èn Windows95 èn NT wil supporten èn je geen zin hebt in Unicows maar dat je twee aparte builds maakt (en test etctera)

bovendien werkt strlen weer niet met TCHARs. Als je C++ schrijft maakt dat niet veel uit, het blijft dan .size( ). Voor andere functies geldt meestal hetzelfde; C++ ondersteunt wchar_t via overloading maar C heeft een hele set wcXXX functies naast strXXX

[Verwijderd]

Mag ik nog een offtopic suggestie doen? Waarom geef je zaken die je toch niet gaat veranderen niet gewoon als reference door? Waarom alles 'by value' doorgeven?
Dus:

C++:

void getRegistryValueStr(const string& keyLocation, const string& keyValueName, string* pKeyValue)
{
...
}

Oh, en je zou eens moeten kijken naar static_cast, const_cast, reinterpret_cast. Dan hoef je geen c-style casts te schrijven zoals in die laatste regel. Als ik code zoals

C++:

*pKeyValue = (string)data;

zie staan komt m'n haar al recht. Je wil niet weten hoeveel van die dingen ik al heb aangepast in m'n leven omdat ze de oorzaak waren van bugs...

Alle beetjes helpen

[ Voor 3% gewijzigd door Verwijderd op 09-06-2006 21:00 ]

[Verwijderd]

MSalters schreef op vrijdag 09 juni 2006 @ 20:45:
[...]
bovendien werkt strlen weer niet met TCHARs. Als je C++ schrijft maakt dat niet veel uit, het blijft dan .size( ). Voor andere functies geldt meestal hetzelfde; C++ ondersteunt wchar_t via overloading maar C heeft een hele set wcXXX functies naast strXXX

Dus werkt strlen wel met tchars, maar dan moet je iets als tcslen gebruiken, wat op z'n beurt weer een macro is die afhankelijk van de unicode definitie strlen of wcslen aanroept.

Maargoed, dan is alsnog gewoon in unicode werken en overal wide chars gebruiken een handigere oplossing.

[H!GHGuY]

Verwijderd schreef op vrijdag 09 juni 2006 @ 20:59:
Mag ik nog een offtopic suggestie doen? Waarom geef je zaken die je toch niet gaat veranderen niet gewoon als reference door? Waarom alles 'by value' doorgeven?
Dus:

C++:

void getRegistryValueStr(const string& keyLocation, const string& keyValueName, string* pKeyValue)
{
...
}

Oh, en je zou eens moeten kijken naar static_cast, const_cast, reinterpret_cast. Dan hoef je geen c-style casts te schrijven zoals in die laatste regel. Als ik code zoals

C++:

*pKeyValue = (string)data;

zie staan komt m'n haar al recht. Je wil niet weten hoeveel van die dingen ik al heb aangepast in m'n leven omdat ze de oorzaak waren van bugs...

Alle beetjes helpen

met die const kan ik je zeker volgen. Maar ik dacht dat string wel een efficiente copy-constructor had waardoor je by-value kan meegeven zonder enig performance verlies.

[MSalters]

Nee, hoe zou dat moeten? Als je een string van een miljoen karakters doorgeeft, en je verandert het eerste karakter, dan moet dat alleen in de kopie veranderen.

[H!GHGuY]

tjah, dat is enkel wat mij gezegd is.

misschien mis ik wel met een const copy-constructor of zo... Ik ga alleszins het standpunt niet verdedigen dat het al dan niet zo is aangezien ik het zelf niet zeker ben.

[Verwijderd]

MSalters schreef op zaterdag 10 juni 2006 @ 12:14:
Nee, hoe zou dat moeten? Als je een string van een miljoen karakters doorgeeft, en je verandert het eerste karakter, dan moet dat alleen in de kopie veranderen.

Je kan hem natuurlijk pas kopieren op het moment dat een actie een mogelijk veranderbare string terug geeft of als je zelf expliciet een veranderende operator of method aanroept. Als ik me niet al te erg vergis werkt MFC's CSting tot op zekere hoogte op die manier...

[MSalters]

MFC's CString doet dat (Copy-on-Write) inderdaad, maar dat is omdat 't een stuk antiek is. Als je namelijk maar een beetje verkeerd naar een string kijkt moet die kopie alsnog gemaakt worden. Je krijgt dan het effecht dat operator[] al een kopie kan triggeren. Dat betekent dus ook dat elke call naar operator[] een check moet doen om te kijken of er een kopie nodig is. Dat is in de praktijk nog inefficienter dan gewoon altijd een kopie maken. Het verschil is echt dramatisch in multi-threaded omgvingen, aangezien COW dan thread-synchronisatie vereist.

[.oisyn]

HIGHGuY schreef op zaterdag 10 juni 2006 @ 10:18:

met die const kan ik je zeker volgen. Maar ik dacht dat string wel een efficiente copy-constructor had waardoor je by-value kan meegeven zonder enig performance verlies.

Maar dat is het punt nou juist. Jij denkt dat het wel efficient is. Je weet het echter nooit zeker, en het kan ook per implementatie verschillen. Een const reference is daarentegen -altijd- efficient.

[H!GHGuY]

Ik heb gisteren ook even zitten rondzoeken en ben een online boek tegen het lijf gelopen (thinking in c++) waarin stond dat de "standaard" niet voorschreef wat er moet gebeuren. sommige string-implementaties gebruiken dus misschien wel reference counting en copy-on-write maar je kan er niet vanop aan.

conclusie: braaf zijn dus en const reference'n en je compiler doet de rest wel


edit: ik zat net even door de string.h en string bestanden te bladeren van mijn VS install en blijkbaar is de hele basic_string extern ? Ik wist wel dat veel string functies in ntdll.dll zitten maar die van basic_string toch niet ?
Ik blader nu ook even door m'n borland include's en daar staat ie wel... dan gaan we daar maar es in neuzen

De borland implementatie heeft toch echt wel copy-on-write en reference-counting... (hoewel je die met een simpele define kunt uitschakelen)

[ Voor 44% gewijzigd door H!GHGuY op 12-06-2006 08:55 ]

[.oisyn]

VC6 had ook een cow string implementatie, maar in multithreaded omgevingen is het dramatisch zoals MSalters al zei, omdat meerdere threads tegelijkertijd de buffer aan kunnen passen (terwijl dit via verschillende string instances gaat en dus heb je daar als programmeur geen idee van)