Visualize A Stable IDE



  • Fairly recently, my job has had me doing more and more Windows-oriented work (C/C++).  I'm no big fan of Windows, but whatever, it's the platform this project is on.  Furthermore, I'm not much of an IDE guy, I prefer doing most of my work with Textpad and a command prompt.  Regardless, I've used Visual Studio before, and it has in my experience been the only IDE that was not terrible*.  And by not terrible, I mean it lets me write, compile, and debug my programs while being stable, fast, and not taking up 500 megs of runtime memory (*cough*Eclipse*cough*).

    Oh, how things have changed between VS6 and VS2005.  Visual Studio 2005 (nee 8.0) has a habit of crashing.  Often.  For any reason.  For no reason.  Because you looked at it funny.  It crashes so often that it has a built in feature to restart VS when it crashes, which to me seems to be the developers just admitting defeat.  Now, it's embarrassing enough (not to mention absurd) to have crashes in a development and debugging tool (because, you see, if you're developing a development tool, one would hope... well, you get the picture).

    But that's not why I'm writing.  I'm also not writing about how terribly buggy the syntax highlighting is, especially when it comes to active versus inactive preprocessor blocks.  Or how useless the search feature is.  Or how it sometimes misses changes in header files and you have to clean and rebuild all to actually have them included.  Or the fact that it crashes if you close the tabs too fast.  I'm writing because of one special feature.  That is, and you know you all love this one: when you double-click on an error message in the output window, it takes you to the line that contains the error.  Very handy, I'm sure you would all agree.  This feature has a slight bug, however.  If you double-click on a linking error (which has no associated line), the behavior is yet another crash.  This is repeatable, 100% of the time.  VS2005 has been out for about 2 years now.  I have the latest service packs installed.  This bug is trivially reproducible, and, unless the code is such a WTF that it is beyond my imagination, a very easy fix.  And yet it still occurs.  How can they not have fixed this?  Please, someone explain it to me.

     

    * You haven't seen a truly terrible IDE until you've tried Texas Instruments' Code Composer Studio.  Now there's a WTF of staggering proportions.

    **  Or Forte, which, being written in Java, ran your test programs as a thread.  This had the nice effect that if your own threads had some issues (deadlocks, infinite loops, wild thread spawning, et cetera), you had to kill the IDE.



  • I think I speak for everyone (or at least for myself) when I say that you have the best avatar picture on the entire internet.



  • @joe_bruin said:

    * You haven't seen a truly terrible IDE until you've tried Texas Instruments' Code Composer Studio.  Now there's a WTF of staggering proportions.

    Been there, done that, fixed a bug in the TMS320F2407 C library startup code without even learning the assembly language.  And I'm the hardware guy...



  • Funny, VS2005 has always worked for me. The only glitch I notice is when I open the help viewer, and it has to load up the catalog for the entire MSDN library. (I think I can forgive it, just this once.)

    Other than that, the only crashes I've ever noticed while using VS2005 were while debugging... and in my applications. Then again, I mostly write C# code. Maybe it behaves differently with C++...?



  • I'm with you on Visual Studio.  I also found VS6 to be a pretty solid development platform, at least once I upgraded to Windows 2000.  Though I have not sunk good money after bad buying VS.Net 2005, I did acquire .Net 2002 Pro [Academic Edition] and my experiences with that glitzy POS disincline me to further enmesh myself in M$ development tools.  The porting tools left well-worked out programs in a limbo of incompatibility.  The tutorials provided in the MSDN Help system simply did not work without major tweaking.  [I refer here to step-by-step tutorials]  The bundled MS Desktop Engine did not mesh with the IUSR_%MACHNE_NAME% object.  [I had to load the SQL 7 that came with VS6 Enterprise to get DB connectivity]  All in all, the .Net tools proved to be a bundle of WTFs.

    I did not, though encounter the specific bug you refer to, but that is probably just because I abandoned .Net for more productive pursuits:  PHP/MySQL, and Programmers File Editor as my code editor.  The latter may be missing some of the fancy integration features of a full-scaled IDE, but it was free of the entanglements.

     

     

     



  • I have been considering to switch from Vb.Net to C#, but one of the main reasons to stay in VB is that the syntax higlighting actually works quite well in VB. I am very happy to see typing and programming errors realtime. In C# it sucks, you have to rebuild to see if something is wrong in your code. Well, that's how things have usually been in the past, but I like the way how Visual Studio does syntax check realtime in the background, it just makes things more fluent. I wonder why it works well only in VB?



  • @sirhegel said:

    I have been considering to switch from Vb.Net to C#, but one of the main reasons to stay in VB is that the syntax higlighting actually works quite well in VB. I am very happy to see typing and programming errors realtime. In C# it sucks, you have to rebuild to see if something is wrong in your code. Well, that's how things have usually been in the past, but I like the way how Visual Studio does syntax check realtime in the background, it just makes things more fluent. I wonder why it works well only in VB?

     

    Probably because VB has been doing it forever, or at least since 1998. 



  • Never had problems with it, it has a lot of nice features such as XML documentation and stuff. And the class designer, although it is a bit lame they stole it from BlueJ. But they sat around the table and shook hands afterwards.

    When it did crash, it is usually attributable to me as an intern getting the most crappy old workstations all the time. Or not at all, Editing C# in notepad FTW!!

    I guess there are other good IDE's (Eclipse, IntelliJ). However, Java interfaces tend to be very slow!! Argh!! Zend anyone? Only solution seems to be switching the Theme of XP to Classic. But Zend is crap compared to VS2005.

    I am not sure however how the DataSet Designer works with other Databases than MS SQL.

    Otherwise it is one of the better IDE's I have worked with. And when it crashes, or your system, Project Recovery is a breeze! A real relief to start up again afterwards and read "Your computer crashed, however we have fixed the project up for ya, no problemo."



  • I also like this feature, until the compiler crashes... When it does, every time the code changes the compiler is run... and crashes... Note that the compiler crashes, not VB. The only solution is to restart VB (I'm using the Express Edition) and when you do so, it closes each file, and each file causes the compiler to be run (WhyTF?) and to crash. Well, that scenario happened to me when I tried to put a custom control (not a UserControl, a ContainerControl - I think) on a form inside the same project. Fortunately, there was a patch and it worked.

    Now we have stability.



  • @rjnewton said:

    Probably because VB has been doing it forever, or at least since 1998.
    Make that 1988 (or even earlier - I know that QB 4.0 already had this feature).



  • @sirhegel said:

    I wonder why it works well only in VB?
    C# has had equally good intellisense as VB for a very long time. I don't recall ever having to rebuild the application to find errors in my code with C#, though the earliest IDE used for that would have been VS 2003 Professional (and I used VS 2002 for VB). 2005 is ace. :-)



  • All I have to say is: a failure occurred while attempting to start the compilation



  • Too bad that microsoft closes 99% of the reported bugs as "not reproducible", and considers that to be the end of it.

     VS2005 has caught up with and surpassed Eclipse for memory hoggage, crashing, instability, F-ed up behaviors, inconsistency and slowness. The only way MS will fix anything is if you, the dev, take time out of your schedule to do their work for them, tracking down exact 100% reproducible scenarios that they can then verify. They do next to nothing to validate submitted bugs.

    ON top of that, we were practically stalked by our contact person there. All we ever got from her was "here's a hotfix to try, apply it immediately and let me know how it works. We're on a tight schedule here". Excuse me lady, WE'RE on a tight schedule HERE, and your POS IDE is making it TIGHTER. 

     I too have the latest patches and service packs for VS2005. They've fixed trivial issues, but some major problems are still there, and they've introduced more.

    But .NET 3.0 and ORCAS is almost out! Why not write a new version before you fix the old one. Good Idea. 

     Favorite current IDE issue:

    Compile freezes in the middle.Can't STOP it, no response from IDE.Can't CLOSE the IDE because you have a compile in process. Wheeeee!

     

     



     



  • @tster said:

    I think I speak for everyone (or at least for myself) when I say that you have the best avatar picture on the entire internet.

     That logo is only the start... take a look at The "Works on My Machine" Certification program
     



  • Ah, Visual Studio 6, how I loved you.  It's a shame what an aberration you became with the next release.  They took away InterDev!  Plus, it crashed all the time when compiling with lots of resources.  In one of my software engineering courses in college, I had to work on an application designed by previous classes (which could inspire a week's worth of WTFs) that had a massive image file included in the resources -- something like 20MB.  I couldn't convince the rest of the team to remove it from the executable because the file had to be there to work.  Anyway, any time you messed with any of the resources, VC++ would crash.  You'd have to recompile four or five times before it would finish successfully.  God I hated that thing.

    And don't even get me started on Eclipse!  Try having Eclipse, Firefox 2, and a 60 MB PDF in Acrobat all open at once.  My machine had 2GB of memory and still came to a grinding hault if I didn't kill them all off and restart them every day when I came in and after lunch.  Maybe two years ago I tried the Eclipse GUI designer when I was working in Java.  That thing was so slow I actually preferred to write the Swing code by hand.  And I had thought nothing was worse than Swing code.

     The only reason to use an IDE is for intellisense and integrated debugging.  Intellisense is just a sign that your language is too frigging big and unpredictable (I'm looking at you, Java).  Integrated debugging is nice, but it's not worth the overhead.  Give me a text editor with syntax highlighting and customizable indentation rules, and I'm set.



  • No crashes in VS2005 for me. I write in C#, C++ and VB.Net (when I absolutely have to).

     

    Have you considered that you may have faulty hardware? 



  • make sure you have sp1 installed for vs2005, it may help:

    http://msdn2.microsoft.com/en-us/vstudio/bb265237.aspx 

    I used it every day and I don't think I've had it crash on me yet.  C#, VB.NET, ASP.NET, even smart device applications.  I think it's a very good IDE. 



  • @joe_bruin said:

    I have the latest service packs installed.

     

    @Jeff S said:

    make sure you have sp1 installed for vs2005

    Congratulations, you can't read. 



  • VS2005 is unstable when the language is VB.  I've seen the compiler crashes as one of the other posters have noticed and it is annoying.  It rarely crashes when I'm using C#.

    The only non-VB crash I've ever seen is with databinding, specifically when you've bound a control to a custom class and then renamed the class later.  After that, when you tried to databind another control you'd either get the Object not set to an instance error or a hard crash.  The fix is to delete the renamed datasource object from under the project items.  I think SP1 fixed the crash bug as I only see the error message now.

    Other than that, I'm pleased with VS2005.  It could be better with memory, but I've got plenty to spare.

     



  • @sirhegel said:

    I have been considering to switch from Vb.Net to C#, but one of the main reasons to stay in VB is that the syntax higlighting actually works quite well in VB. I am very happy to see typing and programming errors realtime. In C# it sucks, you have to rebuild to see if something is wrong in your code. Well, that's how things have usually been in the past, but I like the way how Visual Studio does syntax check realtime in the background, it just makes things more fluent. I wonder why it works well only in VB?


    That's one of the worst reasons to pick a language I've ever heard.  There are good reasons to pick VB (namely, knocking out a simple windows UI-heavy app in no time), but "It has good syntax highlighting"?  If your editor doesn't have good syntax highlighting for a language, you pick a new editor, not a new language.

     



  • Visual Studio 2002 was a WTF in and of itself.

    On the C++ side, one of my friend told me that whatever version (2003, 2005) is terrible regarding syntax highlighting and code completion. I don't know about C#, but on the VB side of things it is, as far as I can tell, quite good (meaning it works, and when something is not highlighted correctly, it's a pretty strong indication of an error in your code).

    I can imagine parsing C++ is quite a bit more complicated than parsing VB or C# though (pre-processor, templates...), although I'm sure there are IDEs out there that actually manage to do that much better.

    On the minus side, it sometimes crawls with a big solution (updates to the highlighting can take forever) and is a real hog on resources when debugging. Sometimes the compiler will just give up and crash, and syntax highlighting will be dead. That does not happen to me near enough to be a nuisance, though.




  • @asuffield said:

    @joe_bruin said:

    I have the latest service packs installed.

     

    @Jeff S said:

    make sure you have sp1 installed for vs2005

    Congratulations, you can't read. 

    Well, all things considered, I'd rather be someone who is guilty of quickly skimming a forum post and missing a point while trying to be helpful, rather than someone who is apparently is incapable of drawing accurate or logical conclusions (I can't read?) from situations.  But that's just me.



  • I would have to disagree. I use VS.Net 2005 daily and have yet to have a problem with it crashing. In fact I don't recall ever having it crash on me. Maybe, like stated before, it behaves differently with C++/C/VC++, but with VB.Net and C# I honestly have yet to have the IDE crash on me. JMHO



  • @ender said:

    @rjnewton said:
    Probably because VB has been doing it forever, or at least since 1998. 
    Make that 1988 (or even earlier - I know that QB 4.0 already had this feature).

    I remember BASIC language syntax errors being pointed out as you entered them on a Sinclair ZX81 at the beginning of the 1980's. Admittedly, the message was always "SYNTAX ERROR - REDO FROM START" and the line being entered was then discarded, but either way ...



  • @Martin said:

    I remember BASIC language syntax errors being pointed out as you entered them on a Sinclair ZX81 at the beginning of the 1980's. Admittedly, the message was always "SYNTAX ERROR - REDO FROM START" and the line being entered was then discarded, but either way ...
    The editor in QB 4.0 behaved identically to the editor in VB 6.0 (haven't used VB.net) - by default it'd immediately hilight the line and point out the error (and it would force all keywords to upper-case, and variable/sub/function names to the case they were declared with).
    Oh, and wasn't the basic on ZX81 from Microsoft?



  • I had to go back to Visual Studio for the first time since 6, recently. I found it ran without crashing, but is very slow and unpredictable. I found I could do the same thing several different times and get different results. It's getting really frustrating.



  • I actually thought about doing a VS2005 bug blog. I could post daily without even having to try to come up with material. I use it just for C++, no proprietary garbage languages. I have a VM in which it runs and nothing is installed but Windows, VS2005, the Windows Mobile SDKs, ActiveSync, and a few tools like Beyond Compare. So, not much chance for extra software to be causing trouble. All the same bullshit happens outside a VM on co-worker's machine so its not just my weird isolated development environment (some people have said the VM is the fault, but nothing else gets this screwed up by it).

     
    With SP1, it always has linker warnings because some of the .lib files are are messed up.

    If you open configuration manager, you can change whats selected for the active config, but if you change the active solution configuration or platform, it'll go change what's selected for some other permutation of configuration and platform. You must go out, change the active configuration, then go back in to adjust the next.

    Intillisense barely works. I can click on a function that's used 2 lines away from the definition, tell it to take me to the definition, and it says its not defined. Same thing can happen on the definition and declaration itself. It works about 10% of the time. Better yet, if I open a a project with 10K of source, it'll crank away for minutes to produce an 11MB .ncb file. Just what the hell is in that file!? It certainly doesn't seem to contain the locations of my functions. Even better, the .ncb is always written 2 bytes at a time. Even better, touching ANYTHING starts it into 'Updating Intellisense...', which could be the death. Opening a project, changing the active configuration, etc starts this. None are code changes, so that data should not need updating,. but updating it does. This seems to run on the same thread as the UI, because there's a brief window I can interrupt it by launching a build, but outside that window the whole UI it completely unresponsive to the point it becomes a blank white window if I drag something else over it. Sometimes this is a few seconds, other times it takes 10 minutes. So, I deleted the damn dll that runs Intellisense. Its not like I even edit in there, as I have a useful editor outside the VM and I just use VS2005 to kick off the compiler. It still craps out little .ncb files but at least it doesn't get stuck all the time.

    Project/solution files randomly corrupt themselves. It was fine the day before, now VS crashes when opening. No error saving, diff shows nothing obvious, XML all reads sanely, etc. Delete the sln, open the vcproj on another computer (just try several until one opens it, always someone else's will but whose varies), hit save all and bring the files back and bam I can open them. Freakin' mystery.

    Changing a single property in a project configuration has about a 20% chance of shuffling the file. Literally, the order of whole sections in the vcproj file change. No good reason, editing by hand and changing one line results inb a file of equal functional content. So, editing by hand is easier than using the UI as far as keeping it sane and human readable as far as history in the source control. Also, find and replace with a text editor is much faster than changing one setting a dozen times for all the permutations of configuration and platform.

    When editing the properties, if you select multiple configurations and/or platforms, you can edit them together IF they are already the same. If the value differs, you can easily make them all be the same by just setting the new value. However, if they differ, the value shows blank. Is it empty, or are they different? Which one is different? Is that difference important or not? Who knows! Have to go through every permutation of configuration and platform one by one and look at the value. Someone that doesn't know this can easily blow away all the preprocessor definitions or library includes by just going to add one to all configuration at once.

    Number of simultaneous compilation threads MUST BE set to 1. Setting more will cause build errors sooner or later. Either a header file can't be found, which was used in the prior source file just fine, or a library can't be found that was just generated by the prior build task. Run the build again and it works works. So, building becomes rebuild to get out the flack, since it can't figure out what's chanegd, then hit build until it completes without dumb errors, which could be several times. Really, no code changes, but files that existed and didn't come back. I think there's some serious issues with file locking and concurrent access, as in last buld step hasn't quite closed the file when the next build step tries to open it and fails with a sharing violation, which it declare as FILE_NOT_FOUND rather than retrying after a brief pause.

    A similar problem with missing files can be  created by the aforementioned shuffling of the vcproj file. I have one project where ANY change made in the properties editor on the project WILL move the first source file in the list (stdafx.cpp) to the bottom. If that file is not the first, it will claim stdafx.h does not exist for the first file compiled. stdafx.cpp MUST be first, yet changing anything makes it not the first, so I have to close the solution, repair vcproj by hand, reload solution, and compile again. Easier just to edit the vcproj outside VS2005 in the first place.

    Creating a new platform from an existing one causes it to substitute in values for some macros in the new platform configuration. Thus, the macros don't exist anymore and its impossible to use that as the source of yet another platform without first fixing all the macros. All it has to do is copy them as-is, which it does for some, but not for others, such as $(PlatformName) in some instances (not all). So, more hand editing.

    The resource editor has no indication of how anything you are laying out relates to the physical screen. No way to tell it to start out your window at the size of the screen on the device. All ifdefs in the .rc file will be removed when making a single change in the resource editor. Huge sections of the .rc file will be translated from bitwise ORs of defined values into computed dword values, making future hand editing harder. The size of certain things, like just about any text element, differs on the actual device vs what is show in the dialog editor. Its easier to lay out everything using a calculator and a text editor to directly fill in the .rc file than to fiddle around things in the resource editor, constant tweaking, rebuilding, and testing to see what else is off by a few pixels here or there. Never mind why I'm laying stuff out at all, except the GUI library on the platform is absolute trash that was barely useful in the 80s much less now.

    In the end, VS2005 ends up being a very inefficient way of kicking off a compiler that uses really big and ugly makefiles that are composed in XML for no apparent reason. For bonus points, the XML schema is atrocious and requires duplicating huge amount of settings. Template files can be made and included to help reduce the duplication, except all the settings from those don't show up at all in VS2005 itself so others have no idea they are there and start running over the inherited values without realizing it as they add stuff. Also, you must reload the whole solution to when editing the templates because VS doesn't detect the change as it does when editing the vcproj files directly.

    For extra fun, there's all the errors in the compiler that lies under VS2005. I have instances where it simply generates wrong code. Now and then its a matter or rebuilding to get something that resembles the source's intent. Other times, the source has to be changed to work around some bug. A few times now I've found a situation where I have to add a logging statement (generalized, a function call that takes a string literal as a parameter, so maybe fiddling the stack?) as the first in the else block (which I might have to add)  of an if statement, other the whole function ends right where the if statement starts, the return value is garbage, and no exception is thrown. In all cases, it takes a day or more to trace down because everything is correct in the code, and somewhere along the way debugging the problem just goes away, but then all the logging or MessageBox()es or whatever else was added needs to be stripped away one by one until I find the one that must stayt. In all cases the code worked before but some other unrelated change elsewhere in the file, or just the exact way the file is handled during compilation due to a change in project settings like the addition of another platform, wrecks havoc on the previously tested and correct code.

    To top it off, a bunch of the little tools to go with the compiler, including bcsmake.exe, cabwiz.exe, makecab.exe and signtool.exe, have severe problems when operating on files on networks drives. Some of the issues are resolved by removing all spaces from the path. Others by ensuring files are all on a network driver OR all on a local disk, but not mixed. Some can't handle relative paths and don't supports macros (cabwiz, I'm looking at you) which makes it more difficult to work around. The build process is littered with batch files that copy files around between various steps just so these things will work. All the extras in the compiler like incremental linking must be turned off. To use precopmiled headers, it must be set to create the precompiled header every tie, otherwise at random points it'll insist the precompiled header does not match the vs80.idb file or whatever, even if I just had it on create and did a rebuild and now switched to use precompiled headers and hit build.

    I thought using Windows was bad. Turns out developing for it is even worse. I spend more time working around bug in the development tools or figuring out what the error in the documentation is than actually developing functional code. There are whole weeks that go by in which no new code is written. Whenever I come across a new one of these gems I just want to go stab someone at Microsoft in the face. Repeatedly. And their family too. Friends also.


     



  • @merreborn said:

    That's one of the worst reasons to pick a language I've ever heard.  There are good reasons to pick VB (namely, knocking out a simple windows UI-heavy app in no time), but "It has good syntax highlighting"?  If your editor doesn't have good syntax highlighting for a language, you pick a new editor, not a new language.

    Silly response IMHO; I did not choose VB because "it has good syntax highlighting". Instead I did not switch to C# because I found the IntelliSense to be buggier in C#. The reason I code mostly in VB.Net is simply because I have been programming in VB6. If you look at .NET framework more closely, there is quite few practical differences beetween programming in C# of VB.Net. Of course the syntax is different and a good reason for many nearly religional opinions, but the framework and OO stuff is the same. Try using eg. .NET reflector, you can decompile the IL code to either C# or VB.Net and compile it back to fully functional application, so there is (almost) no practical difference beetween them. Just opinions, I.M.H.O.



  • Reflector does a good job decompiling, but I have NEVER had it spit out a project intact.  (ie:  will compile without heavy modifications)



  • @merreborn said:

    @sirhegel said:

    I have been considering to switch from Vb.Net to C#, but one of the main reasons to stay in VB is that the syntax higlighting actually works quite well in VB. I am very happy to see typing and programming errors realtime. In C# it sucks, you have to rebuild to see if something is wrong in your code. Well, that's how things have usually been in the past, but I like the way how Visual Studio does syntax check realtime in the background, it just makes things more fluent. I wonder why it works well only in VB?


    That's one of the worst reasons to pick a language I've ever heard.  There are good reasons to pick VB (namely, knocking out a simple windows UI-heavy app in no time), but "It has good syntax highlighting"?  If your editor doesn't have good syntax highlighting for a language, you pick a new editor, not a new language.

     

    He's actually not the only one who sees VB in that light. sirhegel should have said "background compilation" instead of "syntax highlighting" though, but I think we all get the point.

    http://www.codinghorror.com/blog/archives/000860.html



  • @djork said:

    He's actually not the only one who sees VB in that light. sirhegel should have said "background compilation" instead of "syntax highlighting" though, but I think we all get the point.

    http://www.codinghorror.com/blog/archives/000860.html

    Great article, that was just exactly what I ment; sorry for mixing these (indeed obviously different) terms.
     



  • @IHateEverybody said:

    {huge VS rant} 

    For extra fun, there's all the errors in the compiler that lies under VS2005. I have instances where it simply generates wrong code. Now and then its a matter or rebuilding to get something that resembles the source's intent. Other times, the source has to be changed to work around some bug. A few times now I've found a situation where I have to add a logging statement (generalized, a function call that takes a string literal as a parameter, so maybe fiddling the stack?) as the first in the else block (which I might have to add)  of an if statement, other the whole function ends right where the if statement starts, the return value is garbage, and no exception is thrown. In all cases, it takes a day or more to trace down because everything is correct in the code, and somewhere along the way debugging the problem just goes away, but then all the logging or MessageBox()es or whatever else was added needs to be stripped away one by one until I find the one that must stayt. In all cases the code worked before but some other unrelated change elsewhere in the file, or just the exact way the file is handled during compilation due to a change in project settings like the addition of another platform, wrecks havoc on the previously tested and correct code.

    I agree with just about everything you've said except this point.  This sounds like a classic memory corruption bug, manifested by a Load-Bearing Print Statement (whether you're causing the corruption or something else is, I don't know).  I think the one thing we both have in common (I'm the original poster) that most of the other responders don't is that we use the Windows Mobile SDK and ActiveSync and are targeting CE and alternate architectures, which may explain why we see so many more bugs than "normal" Windows developers.


Log in to reply