Earlier this year I spent much of my time looking for a software development internship for the summer. I submitted my Resume to Monster, and Hot Jobs, set up this site and applied for as many internships as I could find. For the most part I focused on trying to get an internship with a game developer, but those are very rare. I scored a phone interview with Insomniac Games (the guys who made Spyro the Dragon for the Playstation), but the position was given to another candidate. It was getting later in the year and I was seriously doubting I would find another game development internship before I finished my junior year of college, so I set my goals a little lower and started applying to any internship positions that sounded remotely interesting. I tried to stay away from web development internships, since that’s what I had been doing for the past few years, and I wanted some different experiences this summer. As the summer drew nearer and nearer, I became more and more consumed with trying to find an internship. In a final act of desperation I sent an email to someone at AOL who was looking for a Linux software developer to work on some unknown project. Even though I had very little experience developing software for Linux, I thought I’d send off an email, since I didn’t think it could be too complicated and I was confident in my ability to learn everything I’d need to complete my project on the job.
Two weeks later when I was still busy looking for housing in Washington DC, I got an email back from AOL Wireless asking me to get back to them so I could take place in a phone interview. Being the geek that I am, I thought for sure I’d loose my geek card if I was caught dead doing anything for AOL. Due to that, I almost sent back an email saying I wasn’t interested in an AOL internship, but I stopped myself and decided I would listen to what they had to say first before I made such a rash decision. Once I found out more, I discovered that I would be working for Tegic, one of the companies AOL purchased in 2000, much like the folks at Nulsoft who develop WinAmp. But instead of developing music software, Tegic develops text input software for mobile devices. If you’ve text messaged on your cell phone, you may have used their T9 text input software that guesses what word you want based upon what numbers you press on your phone’s keypad.
The interview with Tegic proceeded very well. I was able to answer all the questions I was asked very easily. The very last part of the interview consisted of a test where I was asked to document a piece of code I had never seen before, and to implement a Queue. I was given an hour to complete the test and I finished it with ten minutes to spare. About a week later I was offered the internship position and I accepted it immediately. Relocating to Seattle for the summer would be MUCH easier than relocating to DC.
As soon as I got off the phone I began familiarizing myself with the Seattle area so I would know where I would want to find an apartment. After completing my research I determined it would be best if I could find housing with people close to my own age, so I began looking for housing in the area in and around the University of Washington, which happens to be located within Seattle. After a few weeks of browsing through Craig’s List I managed to find someone who had a similar schedule to myself and I was able to sublet my room from them, while they were away at their internship in California. The house was fairly large contianing four bedrooms and three bathrooms and spanning three stories. My bedroom was on the top floor so it got a little hot at the beginning of the summer. The rooms were fairly big, although I think my dorm room at OIT is a little larger.
The location was excellent, I was only five miles from my Internship and it was a very easy bike there. Only took me around 20-25 minutes to get there if I was going at a good pace. The Seattle area is packed, there’s something on every corner and hills everywhere. The office where I worked was much smaller than I expected. After seeing aerial pictures of the Google complex I was expecting AOL’s Seattle offices to be a little larger than two floors of an office building. It was still a very nice office, much larger than the one at Boise Cascade.
As part of this internship, I was able to travel to Finland to attend the Human Computer Interface conference in Finland where my project was shown. I flew the whole way to Finland Business Class, and that’s a good thing, because I don’t think I could have survived such a long flight, flying coach. Amazingly Finland looked a lot like the forested areas of Oregon and Washington, but its winters are much, much colder. Unlike Oregon and Washington, the terrain was super flat and lacking of any mountains. While at Finland I attended a few meetings and got to travel in just about every form of transportation known to man, planes, trains, automobiles and a boat. For dinner each night, I could hardly go anywhere without having raw fish as part of my meal. They also served wine with each meal, probably because you’d have to be a little drunk to enjoy them. I did find some good food though. The first night I was there my hotel made a mean club sandwich, and one night I had an acceptable Mexican meal.
All in all I had a very enjoyable summer, and my trip to Finland really topped things off. Hopefully my next summer will be as memorable as this one.
September 24th, 2006
Will
Over the past year I’ve had more than my share of fun dealing with problems somehow related to my project’s Runtime Library option. I’ve never really went over this compiler option in class and I could never find a quick reference guide to explain to me when one option should be used over another. I finally found the time a few days ago and ended up spending around six hours playing around with settings to resolve some linking issues I’ve been having with certain application dependencies. Here is what I discovered about this compiler option.
The Runtime library compiler option hiding under C/C++ -> Code Generation in Visual C++ 2005 tells the compiler how it should link to the external runtime libraries which seems to have things like the STL and other features associated with it. For a normal application the default setting of this option is Multi-threaded (or Multi-threaded debug depending on weather you are in release or debug mode). What multi-threaded does for you is statically links to the C++ runtime libraries. The other option available is Multi-threaded DLL, which dynamically links to the C++ runtime libraries. In most cases when developing an executable project you will want this option set to statically link to the runtime libraries so that you won’t need to include the C++ runtime dll’s when you redistribute your application. When developing a DLL application it is generally desirable to dynamically link to the runtime libraries to keep dll sizes smaller.
Dynamically linking to dll’s using different runtime library settings works perfectly, but the problem arises when you try to statically link to a library that is using a different runtime library setting than the project your statically linking from. I believe this is due to the fact that there is in essence two competing ways of communicating with the runtime libraries in the same binary. If you try to statically link to a library with a different runtime library setting than the project your linking from, you will get a plethora of linking errors that give messages somehow relating to the STL string class. This is easily solved however by rebuilding your static library to use the same runtime library setting as the project you want to link to it from.
So to summarize, when statically linking to other libraries make sure that your runtime library settings are the same in all the projects your statically linking from and to. Also be careful when sending STL classes created on the heap between libraries that use different runtime library settings. In my experience if everything has the same runtime library linkage this is no problem, but if there are difference between dlls that are passing information STL information from one dll’s heap to another heap allocation errors will run amok. So in this instance passing const references to STL classes may be more desirable than creating copies on the heap.
February 24th, 2006
Will
Microsoft has made it even more difficult to deploy native C++ projects with Visual Studio 2005, due to the fact that depending on how your project’s code generation is set, it looks like you need some form of the .NET Framework installed on the system. You can get around the problem by setting the code generation to Multi threaded instead of Multi threaded DLL (statically linking to the msvcp dll’s instead of dynamically linking). But for all the application’s I’m writing I’m forced to set my code generation to Multi threaded DLL due to the fact that the external libraries I’m using are compiled that way. I’ve had problem’s with deploying my applications in the past but didn’t really know what the cause was until I came across this Code Project Article detailing all the different workarounds available for deploying native C++ applications in Visual Studio 2005. In Visual Studio 2003 all I had to deploy my Multi threaded DLL projects was include the msvcm mscvp and msvcr dll’s in my project directory and I was set. But in Visual Studio 2005, I’m forced to also include this Microsoft.VC80.CRT.Manifest file along with those dll’s.
I haven’t had the opportunity to test on a computer that doesn’t have the .NET Framework installed yet, but I fear that by requiring that manifest file to be with my native C++ app, I’m going to require some form of the .NET framework to be installed in order to run it. I know this won’t be a huge problem once Windows Vista comes out and everyone upgrades, and a computer having the .NET framework is expected, but as a matter of principle, native C++ applications should have absolutely nothing to do with the .NET Framework, and I don’t see why Microsoft has imposed this limitation on native app’s using its new IDE.
February 19th, 2006
Will
Not long ago I was really anticipating the release of Visual Studio 2005, because it was supposed to bring the XML documentation experience that I loved in C# to C++. After the release however, I soon learned that what XML documentation functionality Microsoft did add to their C++ part of the IDE was limited to writing managed libraries. After fooling around with C# 2005, they’ve really improved the user experience by adding intellisense everything when you begin typing, but for C++ not much has changed.
I’m very disappointed with Microsoft with this release of Visual Studio because they don’t seem to take the people developing with C++ and not utilizing the .NET framework very seriously. Just by comparing the programming experiences between C# and C++ you really get the feeling that it isn’t in Microsoft’s interests to make the C++ development experience pleasant for developers. Why can’t C++ have intellisense pop up as I’m typing in variable names? Why can’t C++ offer to replace the names of function arguments within my function body when I change the name in the function definition. Why can’t an XML comment template appear when I type in /// like it does in C#?
I know the .NET framework is an awesome alternative to writing applications using Windows API, but (and Microsoft will probably disagree) its not the best solution all applications. I enjoy developing C++ applications and I feel quite comfortable with that language, and I don’t understand why Microsoft can’t get their C# team together to help the Visual C++ team to create an interactive C++ IDE that is just as good as C#’s.
I do hope Microsoft will change its attitude toward C++ developers, because no matter how great C# is, C++ isn’t going away anytime soon.
December 1st, 2005
Will