And no - you cannot simply cast a plain old ascii string to a LPCWSTR the way you are trying to do (well the cast will go through) but the result will not make sense - as you have found out.
A bit more about windows string pointers.
I have counted 11 different type of string pointers in windows as follows;
1 2 3 4 5 6 7 8 9 10 11
PWSTR //always wide string
PCWSTR //always wide string
LPWSTR //Always wide string
LPCWSTR //always wide string
PSTR //always 8 bit
PCSTR //Always 8 bit
LPSTR //Always 8 bit
LPCSTR //always 8 bit
PTSTR //LPWSTR if UNICODE defined, LPSTR if UNICODE not defined
PCTSTR //LPCWSTR if UNICODE defined, LPCTSTR if UNICODE not defined
LPTSTR //LPWSTR if UNICODE defined, LPSTR if UNICODE not defined
If you are using string literals you simply use the _T macro and that will take care of the Ascii (A) or Wide (W) functions versions.
For Example MessageBox(NULL, _T("Hello"), _T("Andy"), MB_OK);
if for some reason the pointer to your text has been already been declared as PSTR or LPWSTR then you use MessageBoxA or MessageBoxW:
1 2 3 4
PSTR pstr="Andy";//just ordinary text for MessageBoxA
LPWSTR lpwstr = L"Michael";//L means make wide string - needed for MessageBoxW
MessageBoxA(NULL, pstr, "GuestGulkan", MB_OK);//just ordinary text for MessageBoxA
MessageBoxW(NULL, lpwstr, L"GuestGulkan", MB_OK); //L means make wide string - needed for MessageBoxW
If you are using char* or wchar_t (like the address of buffers, or arrays) then use MessageBoxA or MessageBoxW as appropriate:
As for printing out an address. Here is an example
1 2 3 4 5 6 7
char buffer[256]={0};
int *p;
int A = 3;
p = &A;
sprintf_s(buffer , 255, "Address of variable A is: Hex :%x (Decimal: %d)",p,&A);//p and &A are the same thing
MessageBoxA(NULL, buffer, "GuestGulkan", MB_OK);
There are a number of c runtime functions that take a user supplied pointer to buffer and do copy to/copy from opertions on that buffer.
These are functions like printf, scanf, sprintf......and so on.
These functions never did any checks on the supplied buffer and in this day and age it is considered a high security risk.
In the Microsoft products, MS has introduced new versions of these functions - they have the same name nut with _s at the end. This means (enhanced) security.
The old functions are still there, but when you use them, the compiler will warn you about them and suggest that you use the secure versions instead.