www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Unofficial DVM Windows Beta

reply "Nick Sabalausky" <a a.a> writes:
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...
Jun 04 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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

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!
Jun 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
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

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
Jun 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"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

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! :)
Jun 04 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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

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...
Jun 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-04 22:57, Nick Sabalausky wrote:
 "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...)

Ah, Ok. -- /Jacob Carlborg
Jun 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jun 04 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jun 04 2011
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jun 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:ise6jf$1pfj$1 digitalmars.com...
 "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.

All the technical details you should need to know are up on the Wiki now: https://bitbucket.org/Abscissa256/dvm/wiki/Home Let me know if anything's missing or you're unclear on something (or have any other questions).
Jun 04 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:isekt3$2e96$1 digitalmars.com...
 "Nick Sabalausky" <a a.a> wrote in message 
 news:ise6jf$1pfj$1 digitalmars.com...
 "Jacob Carlborg" <doob me.com> wrote in message 
 news:isdk4u$t7p$1 digitalmars.com...
 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.


All the technical details you should need to know are up on the Wiki now: https://bitbucket.org/Abscissa256/dvm/wiki/Home Let me know if anything's missing or you're unclear on something (or have any other questions).

Just as a quick summary of the "use" command: Setting the default compiler with "--default" works by setting the user's environment vars in the registry. That's just simply how they're stored on Windows. (Then it broadcasts the change so you don't have to logout and back in again.) Setting the current compiler (ie not the default one) works pretty much like the Linux version: A shell wrapper actually runs the DVM binary, which writes a "result" script. The shell wrapper then runs the result script, which invokes one of the "dvm/env/..." scripts, which sets the current cmd line session's path via "SET var=...blah...". Some of the details are slightly different, though. For instance, instead of being a shell function, the DVM shell wrapper is just an ordinary batch file.
Jun 04 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-06-05 03:03, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:ise6jf$1pfj$1 digitalmars.com...
 "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.

All the technical details you should need to know are up on the Wiki now: https://bitbucket.org/Abscissa256/dvm/wiki/Home Let me know if anything's missing or you're unclear on something (or have any other questions).

Thanks, I'll have a look. -- /Jacob Carlborg
Jun 05 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-05 03:03, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:ise6jf$1pfj$1 digitalmars.com...
 "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.

All the technical details you should need to know are up on the Wiki now: https://bitbucket.org/Abscissa256/dvm/wiki/Home Let me know if anything's missing or you're unclear on something (or have any other questions).

I'm still having trouble understanding how the "use" command works, this may just be because I don't know the differences between Posix and Windows in this case. On Posix it behaves like this: When I run, on the command line, an application or a shell script and it sets environment variables, i.e. PATH, they won't be available to the shell that run the app/script. This is the whole reason for the shell function and "sourcing" a result file on Posix. Is this not the case when running an application or a batch script on Windows? Another thing, about the dvm-default-dc and dvm-current-dc scripts. They're actually not really necessary on Posix for DVM to work but they can be used by other applications, like GUI applications. For example, if you set the current D compiler using "dvm use 2.053" and want to run DMD from your editor. If you just run "dmd" it won't use 2.053, it will use the default D compiler or it won't find DMD. Instead you can refer to the full path of "dvm-current-dc" which will always point to the current D compiler. Similar "dvm-default-dc" will always point the default D compiler. I don't know if Windows has this problem. -- /Jacob Carlborg
Jun 05 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:isfqme$17bl$1 digitalmars.com...
 On 2011-06-05 03:03, Nick Sabalausky wrote:
 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have
 any other questions).

I'm still having trouble understanding how the "use" command works, this may just be because I don't know the differences between Posix and Windows in this case. On Posix it behaves like this: When I run, on the command line, an application or a shell script and it sets environment variables, i.e. PATH, they won't be available to the shell that run the app/script. This is the whole reason for the shell function and "sourcing" a result file on Posix. Is this not the case when running an application or a batch script on Windows?

Ok, just to be clear: My understanding of Posix is that there are two ways of running a shell script: Normally: ./foo.sh Sourcing it: . ./foo.sh The difference between the two is that if the script sets environment vars, the "normal" way will keep the env changes private to within the script itself, and the "sourcing" way makes them affect the shell that ran the script. Right? On Windows, running a batch file is *always* equivalent to "sourcing" it. Batch files do not run in a new instance of the shell. (There is an "official" way to write the batch file to make env changes private to within the batch itself, but it's really screwy and not really worth bothering unless absolutely necessary). Although, if you just simply launch the batch file from the GUI, then it'll run in a temporary cmd prompt which closes as soon as the batch file finishes, and so naturally, any env changes won't outlive that temporary cmd prompt. Now, running an *executable binary* from the Windows command prompt, I'm fairly sure any changes that makes to the environment are *not* visible from the command prompt that ran it. (Although I admit I haven't tested that.) Therefore, when DVM wants to set the current compiler, it has to use the same trick as Posix: launch the DVM binary from a batch file, and then if the DVM binary creates a "tmp/result.bat", the batch file will run it and the current environment variables will get set for the user's command prompt. The only difference from Posix when setting the current compiler is that Windows doesn't support two things: 1. Shell functions. Where you have a "dvm" shell funtion on posix, I just simply have a plain old "dvm.bat" (placed inside "[dvm_install_dir]\bin\" so that the PATH can find it. And the DVM binary is named _dvm.exe to guarantee the batch file gets run instead). 2. Shell startup script. Because of this, Windows can't and doesn't have an equivalent of "[dvm_install_dir]/scripts/dvm.sh". Fortunately it's not needed, because all of the default paths (ie, the paths to DVM itself and to the default compiler) are set in the registry. (Technically, Windows does support a shell startup script, but it's really hackish and just not a good way to go.) Does that help?
 Another thing, about the dvm-default-dc and dvm-current-dc scripts. 
 They're actually not really necessary on Posix for DVM to work but they 
 can be used by other applications, like GUI applications.

Ahh, I see.
 For example, if you set the current D compiler using "dvm use 2.053" and 
 want to run DMD from your editor. If you just run "dmd" it won't use 
 2.053, it will use the default D compiler or it won't find DMD. Instead 
 you can refer to the full path of "dvm-current-dc" which will always point 
 to the current D compiler. Similar "dvm-default-dc" will always point the 
 default D compiler. I don't know if Windows has this problem.

Sounds like "dvm-current-dc" would be useful on Windows, too, then. I'll add it in. Of course, it would always point to the most recent "dvm use xxx" from *any* command prompt, but I assume that's the same on Posix, too. I can't imagine there'd be any realistic way around that on either OS. 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.
Jun 05 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-06-05 22:48, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob me.com>  wrote in message
 news:isfqme$17bl$1 digitalmars.com...
 On 2011-06-05 03:03, Nick Sabalausky wrote:
 All the technical details you should need to know are up on the Wiki now:
 https://bitbucket.org/Abscissa256/dvm/wiki/Home

 Let me know if anything's missing or you're unclear on something (or have
 any other questions).

I'm still having trouble understanding how the "use" command works, this may just be because I don't know the differences between Posix and Windows in this case. On Posix it behaves like this: When I run, on the command line, an application or a shell script and it sets environment variables, i.e. PATH, they won't be available to the shell that run the app/script. This is the whole reason for the shell function and "sourcing" a result file on Posix. Is this not the case when running an application or a batch script on Windows?

Ok, just to be clear: My understanding of Posix is that there are two ways of running a shell script: Normally: ./foo.sh Sourcing it: . ./foo.sh The difference between the two is that if the script sets environment vars, the "normal" way will keep the env changes private to within the script itself, and the "sourcing" way makes them affect the shell that ran the script. Right?

Yes.
 On Windows, running a batch file is *always* equivalent to "sourcing" it.
 Batch files do not run in a new instance of the shell. (There is an
 "official" way to write the batch file to make env changes private to within
 the batch itself, but it's really screwy and not really worth bothering
 unless absolutely necessary). Although, if you just simply launch the batch
 file from the GUI, then it'll run in a temporary cmd prompt which closes as
 soon as the batch file finishes, and so naturally, any env changes won't
 outlive that temporary cmd prompt.

 Now, running an *executable binary* from the Windows command prompt, I'm
 fairly sure any changes that makes to the environment are *not* visible from
 the command prompt that ran it. (Although I admit I haven't tested that.)
 Therefore, when DVM wants to set the current compiler, it has to use the
 same trick as Posix: launch the DVM binary from a batch file, and then if
 the DVM binary creates a "tmp/result.bat", the batch file will run it and
 the current environment variables will get set for the user's command
 prompt.

Ok, now I understand.
 The only difference from Posix when setting the current compiler is that
 Windows doesn't support two things:

 1. Shell functions. Where you have a "dvm" shell funtion on posix, I just
 simply have a plain old "dvm.bat" (placed inside "[dvm_install_dir]\bin\" so
 that the PATH can find it. And the DVM binary is named _dvm.exe to guarantee
 the batch file gets run instead).

 2. Shell startup script. Because of this, Windows can't and doesn't have an
 equivalent of "[dvm_install_dir]/scripts/dvm.sh". Fortunately it's not
 needed, because all of the default paths (ie, the paths to DVM itself and to
 the default compiler) are set in the registry. (Technically, Windows does
 support a shell startup script, but it's really hackish and just not a good
 way to go.)

 Does that help?

That helps, thanks.
 Another thing, about the dvm-default-dc and dvm-current-dc scripts.
 They're actually not really necessary on Posix for DVM to work but they
 can be used by other applications, like GUI applications.

Ahh, I see.
 For example, if you set the current D compiler using "dvm use 2.053" and
 want to run DMD from your editor. If you just run "dmd" it won't use
 2.053, it will use the default D compiler or it won't find DMD. Instead
 you can refer to the full path of "dvm-current-dc" which will always point
 to the current D compiler. Similar "dvm-default-dc" will always point the
 default D compiler. I don't know if Windows has this problem.

Sounds like "dvm-current-dc" would be useful on Windows, too, then. I'll add it in. Of course, it would always point to the most recent "dvm use xxx" from *any* command prompt, but I assume that's the same on Posix, too. I can't imagine there'd be any realistic way around that on either OS.

Yes, that's how it works on Posix, always points to the most recent "dvm use xxx".
 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. -- /Jacob Carlborg
Jun 06 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Jun 06 2011
parent Jacob Carlborg <doob me.com> writes:
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
Jun 07 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I think this might be a cool place to link DVM from:
http://prowiki.org/wiki4d/wiki.cgi?action=browse&;id=D__Tutorial/StartingWithD/Compiler/DMD&amp;oldid=D__Tutorial/InstallingDCompiler
Jun 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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. :)
Jun 04 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Jun 04 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.628.1307208393.14074.digitalmars-d-announce puremagic.com...
 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?

There currently isn't, but that's a very good idea. One of the great things about DVM is that it's fantastic for first-time D users, but we shouldn't expect such newbies to know what version they want or what the latest version is. Just brainstorming here: I think the best way to handle this would involve somehow finding out the latest version from digitalmars.com. It definitely wouldn't be good if a DVM developer needed to manually update something every time Walter issues a release. But we also wouldn't want to try to force another TODO onto Walter's plate whenever he pushes a DMD update. DVM could try different download URLs and see which is the highest version number that doesn't 404, but that's obviously an ugly resource-intensive kludge. The best thing I can think of right now would be to download the changelog page on digitalmars.com and scrape that to find the latest version. Maybe we could have some web server automatically do it at regular intervals (twice daily?) and provide a simple "latest-dmd2" and "latest-dmd1" URL which would just return the right version number. Jacob: Your thoughts?
Jun 05 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-06-05 09:39, Nick Sabalausky wrote:
 "Andrej Mitrovic"<andrej.mitrovich gmail.com>  wrote in message
 news:mailman.628.1307208393.14074.digitalmars-d-announce puremagic.com...
 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?

There currently isn't, but that's a very good idea. One of the great things about DVM is that it's fantastic for first-time D users, but we shouldn't expect such newbies to know what version they want or what the latest version is. Just brainstorming here: I think the best way to handle this would involve somehow finding out the latest version from digitalmars.com. It definitely wouldn't be good if a DVM developer needed to manually update something every time Walter issues a release. But we also wouldn't want to try to force another TODO onto Walter's plate whenever he pushes a DMD update. DVM could try different download URLs and see which is the highest version number that doesn't 404, but that's obviously an ugly resource-intensive kludge. The best thing I can think of right now would be to download the changelog page on digitalmars.com and scrape that to find the latest version. Maybe we could have some web server automatically do it at regular intervals (twice daily?) and provide a simple "latest-dmd2" and "latest-dmd1" URL which would just return the right version number. Jacob: Your thoughts?

I have previously asked about a symlink on the digitalmars ftp to point to the latest release. That didn't happen, but I got a reply with a shell script finding the latest release. Here's the thread: http://www.digitalmars.com/d/archives/digitalmars/D/Symlink_to_Latest_dmd_on_the_Digital_Mars_FTP_126791.html I guess this can be ported to D and incorporated with DVM. -- /Jacob Carlborg
Jun 05 2011
prev sibling parent reply David Nadlinger <see klickverbot.at> writes:
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...

Jun 07 2011
parent "Nick Sabalausky" <a a.a> writes:
"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.
Jun 07 2011