0

I've seen in other threads from 7 years ago that this is how you get the logged in user's name:

#include <iostream>
#include <string>
#include <windows.h>
#include <Lmcons.h>
using namespace std;

int
main()
{
  char username[UNLEN + 1];
  DWORD username_len = UNLEN + 1;
  GetUserName(username, &username_len);
  std::cout << username << "\n" << &username_len;
}

But when i debug it, i get the errors: *argument of type "char " is incompatible with parameter of type "LPWSTR" and 'BOOL GetUserNameW(LPWSTR,LPDWORD)': cannot convert argument 1 from 'char [257]' to 'LPWSTR'

Aykhan Hagverdili
  • 28,141
  • 6
  • 41
  • 93
  • you need a good intro into windows.h programming. You need `TCHAR` instead of `char` iirc – bolov Mar 15 '20 at 21:05
  • Change `char` to ` wchar_t` or use `GetUserNameA` – Alan Birtles Mar 15 '20 at 21:06
  • @bolov i think using `TCHAR` is not recommended on new programs – Alan Birtles Mar 15 '20 at 21:06
  • This answer on an older post along with what @bolov said about `TCHAR` could at least point you in the right direction https://stackoverflow.com/a/17972581/8678978 – chrisbyte Mar 15 '20 at 21:08
  • @AlanBirtles I am not up to date with windows.h programming. And I hope I never have to be. (unless they bring a new modern C++ API) – bolov Mar 15 '20 at 21:08
  • @AlanBirtles if you change to `wchar_t` shouldn't you also change to `GetUsernameW`? – bolov Mar 15 '20 at 21:18
  • `GetUserNameA` worked thanks – Kyuuyaku_ibunroku Mar 15 '20 at 21:18
  • 1
    I mean, afair your options are `TCHAR` with `GetUsername`, `char` with `GetUsernameA` and `wchar_t` with `GetUsernameW`. Well, well depending whether `_UNICODE ` is defined or not some other pairing would work, but if you want to work with any `_UNICODE` definition you need one of the above 3. From what I can recall anyway. – bolov Mar 15 '20 at 21:22
  • @AlanBirtles *"I think using `TCHAR` is not recommended on new programs"* Why not? Could you provide some reference? – Aykhan Hagverdili Mar 15 '20 at 21:26
  • @ayx: `TCHAR` maps to either `char` or `wchar_t` depending on the build environment. `char` cannot represent all Unicode code units. If you are querying for data outside your control (like a user's name), you don't want to use a character type, that cannot represent all possible names. Use `wchar_t` everywhere. It's your only safe option. (`TCHAR` was meaningful only in the short period where Microsoft maintained both Win9x and Windows NT at the same time, to ease porting from the former to the latter. Today, `TCHAR`'s only justification is to make consultants rich.) – IInspectable Mar 15 '20 at 21:33
  • @IInspectable OP seems to be writing a console application, which possibly doesn't have `_UNICODE` defined. – Aykhan Hagverdili Mar 15 '20 at 21:38
  • @ayx: What does the subsystem have to do with proprocessor symbols? And `_UNICODE` doesn't control the Windows API anyway. It's `UNICODE`. – IInspectable Mar 15 '20 at 21:39

1 Answers1

1

Microsoft suggests that you use the Unicode versions of the functions. To do that, use wchar_t and GetUserNameW:

#include <Lmcons.h>
#include <iostream>
#include <windows.h>

int
main()
{
        wchar_t username[UNLEN + 1];
        DWORD username_len = UNLEN + 1;
        GetUserNameW(username, &username_len);
        std::wcout << username << '\n';
}
Aykhan Hagverdili
  • 28,141
  • 6
  • 41
  • 93
  • @Downvoter care to explain? – Aykhan Hagverdili Mar 15 '20 at 21:34
  • The tooltip on the downward pointing arrow reads: *"This answer is not useful"*. So, at a guess, this answer simply isn't useful. – IInspectable Mar 15 '20 at 21:35
  • @IInspectable it may not be useful for you, but it solves OP's problem, which is the only reason any answer exists at all. – Aykhan Hagverdili Mar 15 '20 at 21:36
  • It solves the OP's problem, until the OP runs the code under a user account named "". – IInspectable Mar 15 '20 at 21:38
  • @IInspectable I would love to see some references to reputable sources backing up your objection against `TCHAR`. Until then it seems to be *an opinion* about how things should be. – Aykhan Hagverdili Mar 15 '20 at 21:40
  • I just gave you easy to follow proof. Why don't you go ahead, create a user account "", run your ANSI code under that user account, and observe what the API returns. When done, you can delete the comment that seems to indicate, that a proof based on logical reason were some sort of *"opinion"*. Or maybe, this new-fangled Unicode stuff just caught you by total surprise, and you just need a few decades longer to get used to this. – IInspectable Mar 15 '20 at 21:42
  • @IInspectable If you care about ""s, you should compile your code with Unicode support. Assuming OP wants unicode support is just that, *an assumption*. In fact, OP's [comment](https://stackoverflow.com/questions/60697609/how-do-you-get-the-username-of-the-currently-logged-in-user-win32-api#comment107390135_60697609) indicate that they ended up calling the ANSI version of the function. Some of us like *describing* how things are instead of *prescribing* how things should be in our *opinion*. – Aykhan Hagverdili Mar 15 '20 at 21:47
  • You are failing to acknowledge the important detail here: The code is running against data the OP does not control. Like the user that chose to use Unicode characters in their user name. And just for giggles, here's some *"reputable source"*. From [Working with Strings](https://learn.microsoft.com/en-us/windows/win32/learnwin32/working-with-strings): *"New applications should always call the Unicode versions."* And then, further down: *"The `TEXT` and `TCHAR` macros are less useful today, because all applications should use Unicode."* – IInspectable Mar 15 '20 at 21:52
  • @IInspectable Thank you for the reference. You may do it just for giggles, but I only now can take your point seriously :-) – Aykhan Hagverdili Mar 15 '20 at 21:58
  • My name is `"Bălan"` so yeah, unicode does very much matter. – bolov Mar 15 '20 at 23:54