WindowsStuffWorthKnowing

• Downloading Microsoft Compilers and Command Line Tools
  • We're using Microsoft Visual Studio Community 2013.
    • That's free but it takes a very long time to download. We probably don't need all of it.
  • For development, Will uses the VS2013 x86 Native Tools Command Prompt.
  • The bullets that follow this one are old and may be obsolete.
  • The .NET Framework SDK comes with a command line compiler, cl.exe that handles C and C++ and is the same compiler that comes with Visual C++.
    • Searching via Google: http://www.google.com/search?q=microsoft+.net+developer+download
  • The .NET Framework SDK has a C/C++ compiler, but it does not have the standard set of headers that you need to do Win32 development. To be able to compile code that has directives like #include "windows.h", you need to get the Platform SDK.
    • Searching via Google: http://www.google.com/search?q=microsoft+sdk+download
  • (the content above is based on original links from from http://www.winprog.org/tutorial/msvc.html, which unfortunately still points to Microsoft-broken pages...; Felix is attempting to avoid doing the same by sending you through a Google search instead of hard-coding a link that Microsoft will later break.)
  • After installing both of the SDK's above, you will have two different new folders in the Applications portion of your Start Menu, and somewhere in those folders are commands to run batch scripts that set up the environment variables appropriately.
  • After installing the Framework SDK, you can sanity check by attempting to run nmake and cl (both of which are needed during a IA32 build of native Larceny on Windows).
  • After installing the Platform SDK, you can sanity check by attempting to compile (with cl) a small file that uses the Platform SDK, like:

#include "windows.h"
int main() { return 0; }

• Emacs
• http://math.claremontmckenna.edu/ALee/emacs/emacs.html
• Cygwin
• http://x.cygwin.com/
• Cygwin isn't needed, but is very useful.
  • In particular, cygwin is one way to obtain git, emacs, and other familiar tools.
• When downloading cygwin, selecting the parts you want is extremely tedious, time-consuming, and error-prone. There's got to be a better way than going through the list of available downloads and checking every tool you think you want.

---

When working on CommonLarceny, you need:

• to have various executables from the Microsoft SDK available in your PATH
  • such as ilasm.exe, cl.exe (maybe; Felix thinks we use this for preprocessing [source:trunk/larceny_src/src/Rts/DotNet/SchemeObject.cs.cpp SchemeObject.cs.cpp]), csc.exe, etc.
  • You can find out what your PATH is currently set to by using echo %PROMPT% in a command prompt.
  • You can set an environment variable like PATH within a command session with the set command.
  • If you find a value for an environment variable that you like and want it to persist across command sessions, you can set environment variables globally on Windows by following this sequence of clicks:
    1. Start..
    2. Control Panel..
    3. System icon..
    4. Advanced tab..
    5. Environment Variables button..
• There are other environment variables that need to be set to various magic values to use tools in the Microsoft SDK tools.
  • The obvious way to get a command prompt with these variables set to the appropriate values is to search through Microsoft .NET releated subtrees in the Start menu and find one that sounds like SDK command prompt.
  • After you find one that works (since there are often multiple matches in the above search), you can right click it in the Start menu, choose Properties, and then examine the resulting Properties window to find out what batch script is associated with that command prompt.
  • Then you can read the source code to that batch script to find out what environment variables it is setting.
    • Or you can make a different batch script that explicitly invokes the one you found in the Properties window, which is the technique that Felix prefers to use.

---

One environment variable that you need to be a little bit careful about is LARCENY_ROOT.

• You're usually best off if that variable is set to nothing at all, because on Windows the application binaries have system functions to determine their own directory and therefore it can infer an appropriate LARCENY_ROOT from that context.

---

If you find that your prompt is getting long (perhaps because you've checked out the trunk into a directory like C:\Documents and Settings\pnkfelix\Desktop\larcenydev\trunk-dotnet\larceny_src), you can set it to something shorter by setting the PROMPT variable

• (there is also a prompt command you could run. Felix can't tell whether this is distinguishable from just setting the PROMPT environment variable via e.g. set PROMPT=$p$g)
• In particular, the $_ variable in a PROMPT string will introduce a newline. Thus $p$_$g introduces a newline after printing the path but before printing the greater than sign >.
  • As far Felix can tell, Microsoft's prompt language is much less expressive than e.g. bash's. For example, there's no way to tell it to only print the top-most directory in your path, a common way to summarize one's context. You can put backspaces into the PROMPT string, but that won't help you express printing the top-most directory...
• There is some useful information on what special variables one might use in setting one's prompt at this page: http://blogs.msdn.com/stephtu/archive/2007/03/27/the-joy-of-prompt.aspx