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...

Some notes:

Calling dvm regardless of arguments always prints out this string at
the bottom after any info before it:
"The system cannot find the file specified."

Calling with -h or --help doesn't print out anything.
Calling dvm install or dvm fetch or dvm use without arguments throws
an out of bounds exception.

It might be useful to document where dvm installs DMD to (in appdata). Also, I'm thinking about any problems vista/win7 users might have with UAC, e.g. if UAC will attempt to block writing to the appdata folder. I'm just second-guessing though, I'm not too familiar with how it works.

If I run:
> dvm --default use 2.052
and close and start a new command shell, 2.053 will still be used. What exactly is the use case for "dvm --default use"?

I didn't really know how to use dvm install without looking at the linux dvm page. I attempted to just run 'dvm install' after installing dvm, but it threw an out of bounds exception. Maybe the app should instead print out: "install needs an argument like 'dvm install 2.053'". The same goes for other commands.

Other than that, it seems to work my system. Nice work!

P.S. Turns out I'm a little silly for not realizing that I can use 'dvm install 2.053', since it was mentioned in your post.

On 2011-06-04 12:44, 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.

This is great news, I'll merge your changes as soon as you are ready for a pull request. I'm interested in knowing how the "use" command works. I've quickly skimmed through your code and noticed some references to the registry that I suspect has something to do with it. This was the biggest obstacle for me to implement a Windows version.

-- 
/Jacob Carlborg

On 2011-06-04 17:38, Andrej Mitrovic wrote:
> Some notes:
>
> Calling dvm regardless of arguments always prints out this string at
> the bottom after any info before it:
> "The system cannot find the file specified."
>
> Calling with -h or --help doesn't print out anything.
> Calling dvm install or dvm fetch or dvm use without arguments throws
> an out of bounds exception.
>
> It might be useful to document where dvm installs DMD to (in appdata).
> Also, I'm thinking about any problems vista/win7 users might have with
> UAC, e.g. if UAC will attempt to block writing to the appdata folder.
> I'm just second-guessing though, I'm not too familiar with how it
> works.

Maybe it should be installed in the users home directory instead. The user should always be able to write to that directory. This is also where it's installed on Posix platforms.

> If I run:
>> dvm --default use 2.052
> and close and start a new command shell, 2.053 will still be used.
> What exactly is the use case for "dvm --default use"?
>
> I didn't really know how to use dvm install without looking at the
> linux dvm page. I attempted to just run 'dvm install' after installing
> dvm, but it threw an out of bounds exception. Maybe the app should
> instead print out: "install needs an argument like 'dvm install
> 2.053'". The same goes for other commands.
>
> Other than that, it seems to work my system. Nice work!


-- 
/Jacob Carlborg

I'm ok with appdata as long as it works for everyone. I guess it should, maybe I'm just being paranoid that it won't. (I'll test it out soon on win7 and report). Otherwise polluting home on Windows is kind of ugly, I'm sure Nick will agree. :)

I get the same "The system cannot find the file specified." on Win7 at the end of invoking dvm.

UAC seems to be ok with installing in appdata.

Btw, is there a shortcut for getting the latest DMD release? E.g.
something like:
dvm install 2.x, for the latest 2.x release?

Also I still can't get --default to work, neither XP or Win7.

"Jacob Carlborg" <doob@me.com> wrote in message news:isdk9m$t7p$2@digitalmars.com...
> On 2011-06-04 17:38, Andrej Mitrovic wrote:
>> Some notes:
>>
>> Calling dvm regardless of arguments always prints out this string at
>> the bottom after any info before it:
>> "The system cannot find the file specified."
>>
>> Calling with -h or --help doesn't print out anything.
>> Calling dvm install or dvm fetch or dvm use without arguments throws
>> an out of bounds exception.
>>
>> It might be useful to document where dvm installs DMD to (in appdata). Also, I'm thinking about any problems vista/win7 users might have with UAC, e.g. if UAC will attempt to block writing to the appdata folder. I'm just second-guessing though, I'm not too familiar with how it works.
>
> Maybe it should be installed in the users home directory instead. The user should always be able to write to that directory. This is also where it's installed on Posix platforms.
>

%APPDATA% *is* inside the user's home directory. It's typically something like:

C:\Users\{User Name}\Application Data

(Of course, with "Documents and Settings" instead of "Users" on XP. And possibly a different drive on different computers, etc...)

The Unix concept of "home directory" has a few different equivalents on Windows, depending on the nature of the data:

C:\Users\{User Name}  aka %USERPROFILE%:
The "root" home directory, so to speak. This is only supposed to be for
Windows to store it's own user-specific stuff (user-specific system
settings, the desktop, start menu entries, etc), as well as all the other
"home directories" for the user. Ie, it's for stuff that's actually part of
Windows.

C:\Users\{User Name}\Application Data aka %APPDATA%:
This is equivalent to "~/.*" on Unix. It's where misc applications are
supposed to store their user-specific data. Unfortunately, there are a *lot*
of programs that misbehave and instead of using this directory when they
should, they misuse either the previous directory or the following one:

C:\Users\{User Name}\My Documents:
This is (supposed to be) exclusively for data the user actually creates (or
downloads, etc). Such as *DOCUMENTS*, for example. Etc.

And then just for fun, there's also:
C:\Users\{User Name}\Local Settings\Application Data:
I'm not certain, but I *think* this is for when a single user account is
usable on multiple computers, then this is like %APPDATA% but for things
that are specific to just the local machine.

As long as I'm talking about all this, I may as well also point out FWIW that Windows stores *both* the system environment variables and the user's environment variables in the registry. I don't remember what key the system environment vars are in, but the user's environment vars are in: "KHEY_CURRENT_USER\Environment"

>> If I run:
>>> dvm --default use 2.052
>> and close and start a new command shell, 2.053 will still be used. What exactly is the use case for "dvm --default use"?
>>

Hmm, I'll have to look into it. That's the last thing I added, and it was really late and I really should have been asleep ;) Maybe I managed to screw it up...

Can you try one thing for me though? In the new shell, when it's not using the default it's supposed to be using, what do you get when you do "echo %DVM%"?

It *should* have two things (separated by semicolon): %APPDATA%\dvm\compilers\dmd-{default dmd version}\bin %APPDATA%\dvm\bin

(%APPDATA% will actually be expanded, I only wrote it there for brevity.)

>> I didn't really know how to use dvm install without looking at the linux dvm page. I attempted to just run 'dvm install' after installing dvm, but it threw an out of bounds exception. Maybe the app should instead print out: "install needs an argument like 'dvm install 2.053'". The same goes for other commands.
>>

At the moment, the upstream DVM doesn't do much cmdline param validation either. See this ticket: https://bitbucket.org/doob/dvm/issue/7/no-error-on-invalid-command

You're right that needs to be done, but my top priority with this right now is to bring it in sync with the Linux DVM. Then I'll be better able to help out with cross-platform enhancements like this.

Regarding the message "The system cannot find the file specified.", I'll check, but I'm pretty sure that's just the part where the batch wrapper tries to delete DVM's "tmp" directory after running the dvm binary (which doesn't always create/use the tmp dir). I don't know why I wasn't getting that message too, but regardless, it's an easy fix (assuming it's what I think it is).

>> Other than that, it seems to work my system. Nice work!
>

Thanks! :)

"Jacob Carlborg" <doob@me.com> wrote in message news:isdk4u$t7p$1@digitalmars.com...
> On 2011-06-04 12:44, 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.
>
> This is great news, I'll merge your changes as soon as you are ready for a pull request. I'm interested in knowing how the "use" command works. I've quickly skimmed through your code and noticed some references to the registry that I suspect has something to do with it. This was the biggest obstacle for me to implement a Windows version.
>

Yea, I intended to explain all of that on the wiki down in the "Technical Differences From Linux Version" section, but I couldn't think anymore and needed to go to bed ;) I'll fill that in today.

"Nick Sabalausky" <a@a.a> wrote in message news:ise6ef$1pbt$1@digitalmars.com...
> "Jacob Carlborg" <doob@me.com> wrote in message news:isdk9m$t7p$2@digitalmars.com...
>>> If I run:
>>>> dvm --default use 2.052
>>> and close and start a new command shell, 2.053 will still be used. What exactly is the use case for "dvm --default use"?
>>>
>
> Hmm, I'll have to look into it. That's the last thing I added, and it was really late and I really should have been asleep ;) Maybe I managed to screw it up...
>
> Can you try one thing for me though? In the new shell, when it's not using the default it's supposed to be using, what do you get when you do "echo %DVM%"?
>
> It *should* have two things (separated by semicolon): %APPDATA%\dvm\compilers\dmd-{default dmd version}\bin %APPDATA%\dvm\bin
>
> (%APPDATA% will actually be expanded, I only wrote it there for brevity.)
>

Something I just thought of: When you start a new command prompt, Windows puts the system PATH ahead of the user's PATH. DVM currently only installs things for the local user (that's the way it currently does it on Linux, too). So if you already have 2.053 in your *system* path, then Windows will find and use that before it ever gets to the path DVM installs.

Could you see if that's maybe what's happening for you?

I'll have to think about how to handle that situation. Not sure if I should just tell the user about it, or try to find/remove dmd from the system path (maybe with prompting?), etc...