Why does the CreateWindow() function want the WindowClass's name member and not a pointer to the class itself?

Question

I'm reading Luna's Introduction to 3D Game Programming with DirectX 11. Having always programmed for the Linux command line, I decided to start by reading Appendix A, a win32 programming primer, and I don't understand a certain behavior of the CreateWindow() function. Its first parameter is the name of the window class you want to create - so you first have to declare a window class, then "register" it (which I assume means adding the class to some class stack somewhere in the mysterious win32 API), and then you pass the window class's lpszClassName member to the function, like this:

WNDCLASS wc;
//set all the various members of wc
wc.lpszClassName = L"BasicWndClass";
RegisterClass(&wc);
ghMainWindow = CreateWindow(L"BasicWndClass", L"LOL", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 0, 0, instanceHandle, 0);

I don't understand why the last line isn't something along the lines of

ghMainWindow = CreateWindow(&wc, L"LOL", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 0, 0, instanceHandle, 0);

Is there some historical or practical reason I'm not aware of?

EDIT: Also, is it bad practice to do something like this?

ghMainWindow = CreateWindow(wc.lpszClassName, L"LOL", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 0, 0, instanceHandle, 0);

Answer 1

Because the CreateWindow and the RegisterClass calls are generally not in the same module. CreateWindow is an application-level call, RegisterClass is a library-level call. The canonical examples are the "Edit" and "Listbox" classes, buried inside the OS. Using a string or an atom is a very simple way to avoid having to rely on a implementation dependent structure.

Compare WNDCLASS vs WNDCLASSEX to see why that's a good idea.