The Visual Studio 2010 Release Candidate was released last week, and I dutifully pulled it down and installed it since I've been tracking the VS2010 betas. Since I use Visual Studio very heavily, I have a lot of interest in coming down the pipe. Of course, anything could change between RC and RTM -- including of course the ship date -- and so all of this has to be taken with a grain of salt, but given that this is the Release Candidate and we're about two months from the current ship date, what we've got now is fairly representative of what we can expect from RTM.
So, what's the RC like?
First, general impression: I don't hate it. I should explain a bit. When I first pulled down the Visual Studio .NET beta, I hated just about everything in it, including the slowness, the awful UI, etc... but I thought, hey, it's a beta, it'll get better before ship. Then we got the final version, which was pretty much exactly like the beta, and the only thing I could think of was: I'm screwed. Ever since then, my approach to evaluating VS has been to pull down the beta, try using a bit, and then imagine how much my life would suck if I had to use that version in production work. I'm pleased to say that after using the RC for a bit, I don't hate it -- I can actually concentrate on what I'm doing without being distracted by huge gaffes in Visual Studio. That's a promising start, at least. It took me about an hour to get Altirra and VirtualDub compiling, which is not too bad. Of course, there are still glitches in various areas, like:
The UI: It's blue. No really, it's got a dark blue window background. It doesn't bother me much, although it is a bit startling at first. Judging by bug reports, though, it's really distracting to some people. A VS team member has written an extension to change the color palette. It would be much better if this was integrated into Visual Studio itself, but at least there's a way to change the colors. There were some bizarre rendering errors in the UI, especially in combo boxes, but it seems that these have been fixed since beta 2. The unhinted menu text has also been fixed. The UI unfortunately has a tendency to redraw a lot, which manifests itself as massive lag and flickering whenever you resize the window.
Editor: The editor has been totally rewritten in WPF, so unfortunately, there are some random regressions here and there, like the caret ending up in unexpected positions. The significant change here is that due to the change to WPF the editor can no longer render non-antialiased fonts. ClearType font quality has been improved noticeably since beta 2, although there is still a little bit more color fringing compared to GDI. Given that going back to GDI rendering for this is release is likely impossible, if you are one of those people who cannot tolerate antialiased font rendering you are absolutely going to hate this release just for this reason alone. It's always possible that nonantialiased text rendering will be added for RTM but I highly doubt it. Editor speed doesn't seem too bad; on Windows 7 it seems decent, and I suspect on Vista or with a WDDM 1.0 driver it might actually beat VS2005 with a high resolution due to bypassing software GDI rendering.
C/C++ Compiler: Fairly solid; expect few problems here for existing code. I haven't had a chance to use the C++0x derived features much, so I'm not sure how solid they are. I did try to break lambdas a bit, but surprisingly they work fine with vector intrinsics types. Come to think of it, I don't think I've logged a single bug on the VS2010 compiler. That's got to be worth something.... or maybe I'm slipping. I haven't seen any big overall improvements in code generation, but there are a few tasty improvements in intrinsics code generation.
Libraries: I don't use ATL or MFC, so my experience here is in the base CRT and STL libraries. Everything looks pretty good here too; the weird min/max overloads are gone and my stuff compiles and runs without breaking now. The manifest system has been ditched and they're back to the old MSVCR**.DLL filename based versioning for the CRT. One change that I ran into that did cause problems, though, was that RC has a version of the Platform SDK that at least is definitely newer than VS2005; I don't know if it's newer than VS2008, but it did break a bunch of previously valid code that I had, and it's also incompatible with older versions of the DirectX SDK due to a header conflict.
Debugger: Beta 2 had some pretty big performance problems here, mainly related to overzealous refreshing in the panes and slow text view updates. RC seems better in this regard and it's much closer to VS2005 in stepping speed, including disassembly view. There are some interesting changes in some of the views, such as thread and breakpoint grouping, but nothing earth shattering for native code development.
Intellisense: It still spends a lot of time parsing, sorry. You do have good visibility into what it's doing, and in beta 2 the accuracy and popup speed are decent. I haven't had a chance to use it with a really big project, so I can't tell if it still has the update delay problems that VS2008 had. One minor nice touch, though: it now autocompletes #include statements. No support for C++/CLI... so if you do interop work with that, well, it's going to be a bit rough.
Resource Editor: Looks about the same as before, unfortunately. Don't expect a lot here unless you really like using a mockup image to layout your dialog. And yes, it still picks the frigging bottommost control in a stack. (I'm going to keep bitching about that until I die or until it gets fixed. Don't try to stop me. Get off my lawn.)
Project System: A lot of the kinks have been worked out in the RC, and once you get everything up and running, odds are that you won't have too much trouble with the new MSBuild-based project system. The output has been cleaned up since beta 1, and in the RC it's actually too quiet: you'll have to raise the MSBuild logging level to Minimal if you want to see the names of files being compiled. Where you are likely to experience major pain, however, is in initial project conversion. Neither Altirra nor VirtualDub convert cleanly: there are still bugs in the Makefile project conversion that affect Altirra, and VirtualDub breaks in several ways. The main problems are: additions of backslashes to various properties and macros, causing command lines with quoted paths like "$(IntDir)" to fail; user macros not declared in forward evaluation order silently break, which in VirtualDub's case causes it to build into the root directory until fixed; and there are numerous problems where quotes are either handled improperly or simply cause conversion to fail. There has been major progress in this regard since beta 2, but if you have a non-trivial project chances are low that it will convert successfully in RTM without the need for manual fixups. The underlying project format is also tremendously more complex and radically different from earlier versions, so if you're expecting to be able to change the version field in the project file from 10.0 to 9.0 or 8.0: forget it.
Help: Oh boy. Sorry, but I'll just say it: the new Help system sucks bigtime. It didn't even install properly for me in beta 2, and in the RC it's a shock: the help viewer has been replaced with your web browser connecting to a custom local web server. (Sadly, this means that Help startup time is still likely to be dominated by disk thrashing if you're using Firefox as your web browser.) I hate local web server based help systems with a passion, but the real kick in the pants is that the index is gone. That's right, you get search and TOC, and that's it. There also doesn't appear to be any way to filter. The Connect bug on this is now up to 71-0 in voting and is #5 on the Most Up-Voted Active Bugs list, so I hope the Help team got flak vests. The good news is that apparently the underlying help API does support an index and people have been working on replacements in the old help viewer style, such as H3Viewer.
Source code control: Haven't really exercised this, but Perforce's P4SCC plugin does work with RC.
.NET Framework: I don't do much .NET and haven't tested this much, but there is one specific improvement I want to call out. As a programmer who primarily writes native code, one of the things that absolutely drove me nuts was that if a .NET program crashed in a call into native code, the runtime captured the native exception and translated it to a .NET exception object, which was then caught or displayed. Unfortunately, AccessViolationException is totally worthless for debugging the problem on the native side, as it contains no native context whatsoever and the unwind process blows it away, preventing a JIT debugger from working. This has now been fixed and the default behavior is for such critical exceptions to tunnel through .NET exception handlers and activate the native handler. This has two benefits: first, you can now get the native call stack and context to debug the problem, and second, it makes it harder for applications to accidentally catch and eat such exceptions and continue in an unstable state. You can still use attributes to tag cases where you still want to catch and handle such exceptions.
Editions: I missed the announcements on this around beta 2, but the major change here is that Standard Edition is gone. This is a bit of a shock to me as previously in VS2008 MS had been going the other way and pushing functionality down from Professional into Standard. Express is still around and has gained some features since VS2005 (most notably MASM), but if you need Win32 resource editing, MFC/ATL/OpenMP, add-in support, source code control integration, or project level support for x64 this will put you in a bind as you will have to go to Professional. So, unfortunately, this is likely to be a fairly big price hike for individuals. :( There is also a lot of change up in the Team System range as well, but that won't matter if you stick with the common practice of using Professional Edition with third party packages for source code control, unit testing, etc.
Again, we'll have to wait for the RTM for the final verdict, but my current thoughts: if shipped as-is, I think I could work with this version. For C/C++ development it's a bigger change than VS2008 from VS2005, both in terms of added features and in regressions/breakage, but I'd say it's a net plus. Whether it's worth the cost and the upgrade churn... I don't know. It certainly doesn't meet the "must have" bar for me, but at least I'd feel I was getting more value than VS2008, which I felt added so little for what I do that I skipped it.
The Visual Studio team has made additional fixes to WPF text rendering for the RTM version which will improve text clarity: they've identified and fixed a problem that was still causing antialiased text to be blurrier than GDI, and they've clarified that ClearType is only forced on with the Consolas font, with every other font rendering non-antialised if the system is set for that.(Read more....)
I actually released this last month, but for those of you still into Atari 8-bit systems, Altirra 1.5 is out. Once again, this contains a number of fixes to low-level emulation to closer match the actual hardware, and also contains some feature improvements such as more disk support and better input and UI options. The main page contains the full changelist for those interested.
An item that's somewhat hidden in the changelist is emulation of Video Board XE, which is an add-on board produced recently by some folks in Poland. It's FPGA-based and adds display abilities that are something like Amiga's bitmap capabilities combined with NES-style tile maps, while still being driven by an Atari 800XL or equivalent. While it is somewhat whimsical to extend '80s technology with 2010 video circuitry, I found the design interesting enough to hack in emulation for it so I could check out a few of the existing demos and also program it a bit. Long story short, I managed to get everything working well enough that I was able to write a program to do rotation via three shears on the blitter and it worked the first time on real hardware even though I'd only been able to test it on the emulator myself. It's a bit weird trying to write software to nothing but a spec, and rather gratifying when it actually works.
One of the problems I've run into when reverse engineering the Atari is that my hardware skills and equipment aren't always up to snuff. I'm primarily a software guy, and that limits my ability when it comes to reading schematics and determining what the hardware is doing, particularly when it comes to non-program visible results like color output. In the case of V1.5, one of the things I had to look at was emulating a particular bug in the chip that drives frame timing (ANTIC) which affected vertical blank. Unfortunately, the Atari's video output is borderline with regard to NTSC compliance; only one of the two capture cards I use can capture it at all, and the other one isn't configurable enough. Since I don't have an oscilloscope or logic analyzer what I ended up doing was hooking up the video to my sound card and digitizing at the highest frequency I could, 96KHz, which provided a barely adequate 6.5 samples per scan line. This was clumsy, but just enough to see what was going on with the vertical sync region and to emulate the bug. In doing so I learned tha modern LCD-based TVs frequently don't actually handle non-interlaced video correctly; they just pretend that the video is interlaced anyway. I suppose TV manufacturers aren't overly concerned with what the output from a computer in the early 80s looks like on a 46" HD display.(Read more....)