On Thu, 20 Apr 2006 00:48:55 +0200, Tydr Schnubbis <fake@address.dude> wrote:
>>  without the addEnv calls above I get the behaviour you're describing. With  them it works.
>>
> Works for me too, thanks!

NP.

>> Without them, and using printf I can see that ping responds with:
>>  "Pinging °ÿ with 32 bytes of data:"
>>  note the weird characters there. At first I thought maybe the command line  I was passing to CreateProcessA was temporary and being collected by the  GC, so I changed process.d to use:
>>  cmd = strdup(std.string.toStringz(command));
>>  where cmd is a member of Process - so will persist as long as it does.  That made no difference. I have no idea why it's doing that, perhaps it  reads it's args in a strange way?? I might write a debug program and run  that passing different args etc to see if I can replicate the odd  behaviour and figure out where it comes from.
>
> Not sure if this helps:
> http://www.digitalmars.com/techtips/windows_utf.html

Nope :(

It's my understanding that if you're using ASCII, as we are, you can call the A functions without any conversion, you simply need to ensure there is a null terminater on the string (which is what toStringz does).

In any case I tried both toMBSz with CreateProcessA and toUTF16 with CreateProcessW, it made no difference. Those results plus the same ones I got dup'ing the command value suggest to me that the command we're passing isn't the problem. Further, the complete output from ping later shows the parameter correctly, see:

"Pinging °ÿ with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=5ms TTL=255"

(which also means ping can operate without enviroment vars provided it does not need to do a DNS lookup on the name you give it, in this case an ip)

I think there may be a bug in ping .. as much as I hate to suggest it (because in most cases you later find out you're wrong). I suspect it somehow uses an enviroment variable without error checking when printing that first line, resulting in garbage being printed.

Regan