Installing Visual C++ the hard way

In order to install Visual Studio C++ 2008 on an offline PC, in order to avoid all the trouble with VSC++ 2010 (including that it can't convert old VS6.0 dsw files), I was again bitten by not having a DVD writer on my desktop PC. VS 2008 can be had as an iso file (for DVD only), as can the SDK. So, I found a couple of links on how to rip open the install configuration files and manually pull down the pieces that would be installed by the web install. Too bad this approach is so scattershot that it basically has no chance of working. I of course tried it anyhow. Here is the first article that gives the general idea:

http://vicker313.wordpress.com/2008/11/26/how-to-offline-install-visual-studio-express-without-download-the-whole-image-file/

This told me to download WinRAR to open up the setup files.

http://www.win-rar.com/download.html

From a comment in the first article, I got links to much more complete articles on how to download the pieces. It turns out that I needed a bunch more pieces. The VCPP installed easily and runs great, but I don't have any of the DLLs or .h files for compiling windows apps. It looks like I need to download the massive, DVD-iso-only SDK. I tried it piecemeal but the headers and dlls were not installed.

http://blogs.msdn.com/b/astebner/archive/2008/03/14/8214926.aspx
http://blogs.msdn.com/b/astebner/archive/2008/03/24/8334544.aspx

That said, the above articles are pure genius.

Here is an article by somebody who has the same experience, but whose outraged post is much more poetic than I could ever be. The nice thing is that some M$ folks on the forum explain how to download the SDK. Or maybe they're robots, since it's the same answer over and over ten times in the comments.

http://social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/2bfed529-fb6d-48a3-ad48-fc6301486646/

A different post on another forum which had the same answer pointed to the download page for the SDK, which warned of a problem that occurs when the SDK is installed after VC++2008:

The download page:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en

The problem:
http://support.microsoft.com/kb/974479

Lastly, here is some advice from the comments area of social forum thread above which describes how to download a 2003 SDK and reconcile it with VC++2005, which supposedly you don't have to do with 2008 but it seems like since I've been doing everything bass-ackwards so far I'm going to have to do some of these steps:

http://www.codeproject.com/KB/applications/FreeVS2005Win32.aspx

Here's a link from another hacker who wants to take just the necessary parts of a multi-gig SDK package. He's talking about a really old version of VCPP, but these are still good hints:

http://bfilter.sourceforge.net/doc/vctk.php

M$ "Sleep" function for C/C++

There is no "sleep" function in C, but (apparently similarly to one provided in unix) there is one that's part of the Windows libraries. If the correct .h file is included, it does sleeps in milliseconds. It's apparently not very precise, and must be capitalized, i.e. "Sleep(i)" where i is in milliseconds. Apparently, this is all very well known, but also still one of the most asked questions on forums. See the followoing links, all filled with entertaining flail:

http://cboard.cprogramming.com/c-programming/111229-how-use-sleep-function.html

http://forums.devshed.com/c-programming-42/using-visual-studio-2005-and-the-sleep-function-418938.html

http://stackoverflow.com/questions/3379139/sleep-function-in-windows-using-c

Issues related to compiling a control program from the Opal Kelly API

For some reason, there are painful issues with compiling a stand-alone executable from C code to make an OK API-based control program. When I started a new project, added the OK API .h and .cc files and made my executable, and then took it over to the PC where it was going to be run, it complained about the lack of a "MSVCP100D.DLL" file. That's when I noticed that I'd made a debug build accidentally and went back and compiled a "Release" build. After that it complained about a missing "MSVCP100.DLL" file. This problem does not occur when building the flashloader.exe.

I began comparing the compile options between my project and the flashloader project. There is a preprocessor options entry that's full of flags corresponding to ifdef's in the OK code for the flashloader project, so I added the same flags to my own project, but it didn't mitigate the DLL issue.

I found out that the DLL is the C++ standard library, as shown here:

http://msdn.microsoft.com/en-us/library/8kche8ah.aspx

Obviously, there's something in the way that the flashloader executable is linked that includes the library in the executable, but my freshly-started project is linking in such a way that it requires dynamic access to the DLL. Downloading DLLs from sites returned by Google is a pretty bad idea, so I went about figuring out how to find it on my system or get it from M$.

The following site hints that this DLL should have been installed on my system at a particular location (C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages). However, it wasn't. I think that this was because I am using VS Express, not the full version.

http://cboard.cprogramming.com/windows-programming/128217-msvcp100-dll.html

Navigating a series of links from the above and other hits from Google (here is some entertaining flail: http://code.google.com/p/nulldc/issues/detail?id=109), I learned that what DLLs can be "redistributed" by developers is a big hairy deal, and there's a confusing list of what can and can't, but no direct link to how to get any of them. Here is the M$ list:

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

That would seem to hint that distribution of this DLL is frowned on, but in spite of that, M$ will give you a download that installs this DLL and several others on any target system. It's called vcredist_x86.exe, and can be had from here:

http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84

So, once I had vcredist_x86.exe, I put it on the system in the lab and was able to run my executables (rather than find what I was doing wrong with the linker).


Edit: The answer might be in a post that I missed in the cboard thread above. One of the lower posts says:

"Also you can statically link the runtime libraries by changing your project settings:

Configuration Properties -> C/C++ -> Code Generation -> Runtime Library

If you want to statically link the runtime, don't choose one of the DLL options."

How to compile Opal Kelly's flashloader.exe

The XEM-3005 has a serial configuration EEPROM (I guess its actually Flash RAM? The XEM-3005 UM refers to it as an SPI PROM) from which the Spartan 3E 1200 can be self-configured at power-up. Self-configuration setup is easy, you just set the tiny switch from the "USB Config" position to the "PROM Config" position, and remember to include a line in the VHDL to set the MUXSEL pin to '0' after configuration is complete to allow the USB port to still work for all other regular communication. However that EEPROM is not on the JTAG chain, so you can't just push a bitfile into it like you normally would with a Xilinx serial PROM. Apparently, the only way to program the bit file into the EEPROM is through the FPGA itself. The XEM-3005 says "This PROM may be programmed using the Opal Kelly FrontPanel Application or through API calls from your own software. NOTE: This feature is not yet available in FrontPanel." Later, the UM says "Opal Kelly’s FrontPanel application software and API both provide methods to program the SPI Configuration PROM." (Meaning that the API can be used to program the PROM, since this feature is not yet available in FrontPanel.)

The Opal Kelly Front Panel UM talks about the EEPROM used to store parameters for the PLL (which I'm not utilizing) but does not mention what methods are used to write to the boot PROM. However, in the Samples directory installed with the FrontPanel software, there is a folder called "flashloader". The README.TXT file in this directory explains the SPI PROM loading process in a roundabout way. The process is that you set up flashloader.exe in a directory with a bitfile supplied by OK, and the DLL that has all the OK API stuff in it, and the bitfile to be loaded to the PROM. You then run flashloader.exe from a DOS command line, and it will configure the OK FPGA with the bitfile supplied by OK, and then communicate with the configured FPGA to load your bitfile to the PROM.

However, OK does not supply flashloader.exe. Instead they helpfully supply just the source code. So you have to compile it yourself for whatever platform you're running on. Now, you can always compile in Cygwin, which requires you drag around their runtime DLL on a ball and chain with your executable. However, I found that M$ also supplies a C compiler, naturally wrapped up in the "Express" version of their huge, bloated do-everything development platform called "Visual Studio". Visual Studio Express can be downloaded from here: http://www.microsoft.com/express/ . When you click through to Download, it seems that you are offered four separate pieces, including VB, C#, C++, and "Web Developer". I picked just the C++ piece.

What I discovered is that it turns out that you'd better use Visual Studio, because that's how Opal Kelly did it. Their "source code" also comes with a VS project file that has all of the preprocessing directives and other compile options all set up perfectly. Once you've installed VS, you can compile flashloader.exe in two ways. First, you can use a DOS command window that's launched from a shortcut in the VS start menu folder, and follow the instructions in this M$ tutorial: http://msdn.microsoft.com/en-us/library/bb384838.aspx. Or, you can just open VS, go get a snack while it opens, and then from File->Open->Project/Solution select the .vcproj file in the "Cxx" subdirectory of the source code folder and (after converting to a .vcxproj file because nothing is allowed to be backwards compatible after 2010) just right-click on the flashloader project top level to get "Build". It will first build a "Debug" version because that's VS's default setting. Then you can set the build type to "Release" and build it again. The debug executable is placed in a "Debug" subfolder, and the release executable is placed in a "Release" subfolder. Both seem to run fine, and it is now possible to follow the procedure given in the README.TXT file.