I saved and compiled the code given as getenv.d on the page http://www.digitalmars.com/d/archives/digitalmars/D/learn/623.html but I'm not entirely sure why it works.

The reasons that I don't understand it are:
1. GetEnvironmentStringsA() and the other functions aren't mentioned in std/c/windows/windows.d . and I can compile it with a simple "dmd getenv.d" without passing any other object files or libraries. If it's not in windows.d, why is windows.d even imported?

2. MSDN says that GetEnvironmentStringsA() returns LPTCH but getenv.d's version returns LPVOID.

Mike L. Wrote:

> I saved and compiled the code given as getenv.d on the page http://www.digitalmars.com/d/archives/digitalmars/D/learn/623.html but I'm not entirely sure why it works.
> 
> The reasons that I don't understand it are:
> 1. GetEnvironmentStringsA() and the other functions aren't mentioned in std/c/windows/windows.d .

It is not defined int std.c.windows.windows, that's why it is defined in the code itself:

# // function retrieves the environment variables for the current process.
# extern( Windows ) LPVOID GetEnvironmentStringsA();
#

> and I can compile it with a simple "dmd getenv.d" without passing any other object files or libraries. If it's not in windows.d, why is windows.d even imported?
> 

std.c.windows.windows is imported so that compiler knows about LPSTR, LPVOID, BOOL etc.

> 2. MSDN says that GetEnvironmentStringsA() returns LPTCH but getenv.d's version returns LPVOID.

That's true, you should update function's return type and remove unneccessary casts:

extern( Windows ) LPTSTR GetEnvironmentStringsA();
...
for (lpszVariable = lpvEnv; *lpszVariable; lpszVariable++)

Denis Koroskin Wrote:

> Mike L. Wrote:
> 
> > I saved and compiled the code given as getenv.d on the page http://www.digitalmars.com/d/archives/digitalmars/D/learn/623.html but I'm not entirely sure why it works.
> > 
> > The reasons that I don't understand it are:
> > 1. GetEnvironmentStringsA() and the other functions aren't mentioned in std/c/windows/windows.d .
> 
> It is not defined int std.c.windows.windows, that's why it is defined in the code itself:
> 
> # // function retrieves the environment variables for the current process.
> # extern( Windows ) LPVOID GetEnvironmentStringsA();
> #
> 
> > and I can compile it with a simple "dmd getenv.d" without passing any other object files or libraries. If it's not in windows.d, why is windows.d even imported?
> > 
> 
> std.c.windows.windows is imported so that compiler knows about LPSTR, LPVOID, BOOL etc.
> 
> > 2. MSDN says that GetEnvironmentStringsA() returns LPTCH but getenv.d's version returns LPVOID.
> 
> That's true, you should update function's return type and remove unneccessary casts:
> 
> extern( Windows ) LPTSTR GetEnvironmentStringsA();
> ...
> for (lpszVariable = lpvEnv; *lpszVariable; lpszVariable++)

Thanks for your response. Could you tell me what the compiler is linking to that contains GetEnvironmentStringsA() (and others) and how the compiler knows to do this?

On Sat, Jan 24, 2009 at 8:38 PM, Mike L. <mike.linford@gmail.com> wrote:
>
> Thanks for your response. Could you tell me what the compiler is linking to that contains GetEnvironmentStringsA() (and others) and how the compiler knows to do this?
>

It's in either user32 or kernel32, and I think DMD always links against them (since virtually every program on Windows needs to).