Unofficial DVM Windows Beta

[Nick Sabalausky]

"Jacob Carlborg" <doob at me.com> wrote in message 
news:isdk9m$t7p$2 at 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! :)