"Jacob Carlborg" <doob@me.com> wrote in message news:isib2k$8h4$1@digitalmars.com...
> On 2011-06-05 22:48, Nick Sabalausky wrote:
>> The "dvm-default-dc", however, shouldn't be needed on Windows. Since
>> Windows
>> stores the user's PATH and other env vars in the registry instead of a
>> shell-specific script like ~/.bashrc, I'm pretty sure that the default
>> compiler will work fine even from a GUI app just by running "dmd".
>> (Although, come to think of it, I'm going to have to test that...) It
>> should
>> pick up the correct path from the user's PATH environment variable just
>> like
>> the command prompt would. Although, if the user changes the default
>> compiler
>> while the GUI app is running, then to pick up the new changes, the GUI
>> app
>> would have to handle the WM_SETTINGCHANGED/"Environment" message: And I
>> don't know how common that is (maybe it's automatically handled by the
>> Win
>> API?) If that can't be relied on, then maybe "dvm-default-dc" would still
>> be
>> useful on Windows too. I'll look into it.
>
> That would be great, thanks.
>

I did a quick little GUI test in VS.NET/C#, trying a couple different methods. It did *not* automatically pick up the changes to the env vars while it was running (and at at one point it even stopped picking up the changes at all, even after restarting the little test app. Which was weird.) So they need to be specifically coded to pick up env changes. I didn't test it from D, but something as major as .NET doesn't do it by default, then "dvm-default-dc" is definitely useful on Windows.

So I've added both "dvm-default-dc" and "dvm-current-dc" to my windows fork.

I'm not sure if this message got through a few days ago, so I'm reposting it:

———

Wouldn't the DMD installations currently be part of your synced profile in Active Directory setups? It might be a good idea to move them to AppData/Local instead. But as it has been long since I last actively worked with an AD, you'd better double-check that…

David


On 6/4/11 12:44 PM, Nick Sabalausky wrote:
> I've been working on a fork of Jacob Carlborg's excellent DVM tool (D
> Version Manager) to add Windows support. It should now be fully-usable on
> Windows, with the exception of installing Tango and any post-v0.2.0 features
> (I haven't yet merged in any changes from upstream since I originally forked
> v0.2.0.) I figure I'll submit a pull request after I've gotten those
> features merged in and working.
>
> Main page: https://bitbucket.org/Abscissa256/dvm/wiki/Home
>
> A precompiled Windows binary is on the downloads page:
>
> https://bitbucket.org/Abscissa256/dvm/downloads
>
> As with the Linux version, download the precompiled binary, and then install
> it by running:
>
> dvm-0.2.0-win-beta1 install dvm
>
> Then you should be able to use dvm just like on Linux:
>
> dvm --help
> dvm install 2.053
> dvm --default use 2.053
>
> Etc...
>
>

"David Nadlinger" <see@klickverbot.at> wrote in message news:isl5rm$2q5i$1@digitalmars.com...
> I'm not sure if this message got through a few days ago, so I'm reposting it:
>
> ---
>
> Wouldn't the DMD installations currently be part of your synced profile in Active Directory setups? It might be a good idea to move them to AppData/Local instead. But as it has been long since I last actively worked with an AD, you'd better double-check that.
>

*Shrug* I don't know anything about Active Directory.

And I assume you mean Local/AppData. I have that on my system, but don't have one the other way around.

If I'm correct in my assumption that %APPDATA% is accessable to the same user account on multiple computers, and "Local Settings/Appliation Data" is user-specific *and* machine-specific, and assuming that's even what you're talking about (again, I don't know anything about Active Directory) then I would think %APPDATA% would be the better place for it.

On 2011-06-07 01:55, Nick Sabalausky wrote:
> "Jacob Carlborg"<doob@me.com>  wrote in message
> news:isib2k$8h4$1@digitalmars.com...
>> On 2011-06-05 22:48, Nick Sabalausky wrote:
>>> The "dvm-default-dc", however, shouldn't be needed on Windows. Since
>>> Windows
>>> stores the user's PATH and other env vars in the registry instead of a
>>> shell-specific script like ~/.bashrc, I'm pretty sure that the default
>>> compiler will work fine even from a GUI app just by running "dmd".
>>> (Although, come to think of it, I'm going to have to test that...) It
>>> should
>>> pick up the correct path from the user's PATH environment variable just
>>> like
>>> the command prompt would. Although, if the user changes the default
>>> compiler
>>> while the GUI app is running, then to pick up the new changes, the GUI
>>> app
>>> would have to handle the WM_SETTINGCHANGED/"Environment" message: And I
>>> don't know how common that is (maybe it's automatically handled by the
>>> Win
>>> API?) If that can't be relied on, then maybe "dvm-default-dc" would still
>>> be
>>> useful on Windows too. I'll look into it.
>>
>> That would be great, thanks.
>>
>
> I did a quick little GUI test in VS.NET/C#, trying a couple different
> methods. It did *not* automatically pick up the changes to the env vars
> while it was running (and at at one point it even stopped picking up the
> changes at all, even after restarting the little test app. Which was weird.)
> So they need to be specifically coded to pick up env changes. I didn't test
> it from D, but something as major as .NET doesn't do it by default, then
> "dvm-default-dc" is definitely useful on Windows.
>
> So I've added both "dvm-default-dc" and "dvm-current-dc" to my windows fork.

Thanks.

-- 
/Jacob Carlborg