How does the Left() function work with the GetWindowsDirectory API when passed a fixed-length string? - excel

Question

I could not make my title both descriptive & concise. I am reading through a book called Power Programming with VBA, and one of the examples uses a Windows API called GetWindowsDirectoryA, which takes the string lpBuffer & long nSize parameters. Once it is declared, the author uses it in a subroutine to retrieve the Windows directory.
What confuses me is the way in which this happens. Here is the code:
#If VBA7 And Win64 Then
Declare PtrSafe Function GetWindowsDirectoryA Lib "kernel32" _
(ByVal lpBuffer As String, ByVal nSize As Long) As Long
#Else
Declare Function GetWindowsDirectoryA Lib "kernel32" _
(ByVal lpBuffer As String, ByVal nSize As Long) As Long
#End If
Sub ShowWindowsDir()
Dim WinPath As String * 255 'Why does this work even if I make it a regular variant string?
Dim WinDir As String
WinPath = Space(255) 'Also works fine if I change this number or comment it out, though if I comment it out, the symbols remain
WinDir = Left(WinPath, GetWindowsDirectoryA(WinPath, Len(WinPath)))
MsgBox WinDir, vbInformation, "Windows Directory"
End Sub
Nothing is wrong with how it works. When I watch it execute step-by-step in the editor, it seems to somehow perform an extra step that isn't obvious to me.
When WinPath is declared it is an empty string with a capacity of 255 characters. I am not sure why this is necessary, since removing the fixed-length nature of the string still works fine.
WinPath is filled with 255 spaces for unknown reasons. It works just as well without this.
Here is my paradox. We are passing WinPath as an argument to Left, but WinPath has only 255 spaces in it, & the second part of Left normally tells it to truncate the 1st parameter to X number of spaces. How does providing GetWindowsDirectoryA(WinPath, Len(WinPath)) circumvent this normal logic, and suddenly produce the result: "C:\Windows"?
I feel like if I understand how this works, it will help me understand how the other APIs do business as well. Btw, the comments in the code are mine, not the author's.

Answer 1

Before a function may be called, all its parameters need to be evaluated. Until that happens, the function is not called yet.
Left has two parameters, and we provide an expression for the second parameter. That expression, GetWindowsDirectoryA(WinPath, Len(WinPath)), has to be evaluated in full before Left is called.
The expression has a side effect of modifying the contents of WinPath, so after GetWindowsDirectoryA() returns, WinPath contains new value.
Only then execution enters Left, and it gets a chance to read the arguments that have been passed to it.
Note that it would not even matter in this case if WinPath was actually pushed on the stack before GetWindowsDirectoryA was executed. If that was the case, it's the variable that is pushed, not its contents. So when Left would have been called, it would have read the WinPath variable from the stack and it would have anyway pointed to the modified data.
As for your concerns about the initial contents of WinPath, the buffer has to be allocated before you call GetWindowsDirectoryA, so you do need to fill it with some throwaway characters such as spaces or vbNullChars. You can do that by having the * 255 modifier or by calling = Space(255), doing both is redundant. Note however that the buffer should be MAX_PATH characters long, which is 260.

Answer 2

When the function is executed, the parameter list needs to be in positive order when it pops up from the stack, so it needs to be in reverse order(from back to front) when loading, GetWindowsDirectoryA executes first, then WinPath gets a value, and then returns the value to the parameter list.
Here's a simple Win32 program.
#include <windows.h>
#include <iostream>
void f(int a, int b)
{
printf("a = %d\nb = %d\n", a, b);
}
int main()
{
int i = 1;
f(i, ++i);
getchar();
return 0;
}
result:
a = 2
b = 2
But not
a = 1
b = 2