Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects



01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004


Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ "10 is the new 6" my #*&

I'm trying to give the Visual Studio team the benefit of the doubt with their "10 is the new 6" push, but I just tested something in the VS2010 CTP and nearly blew my top. Therefore, it's rant time.

A long time ago, I filed a bug on Visual Studio 2005, or really, VS2003:

This bug's really simple: if you have a stack of overlapping controls in the Visual Studio dialog editor and click on them, the editor selects the one on the bottom. It's a pain in the butt, because when you've got a bunch of overlapping controls that you're trying to fix -- such as from a copy-and-paste -- you try clicking on one to drag it and you end up messing up the positioning of some other control, so you've got to undo that and then try to find some way to select the one you actually wanted. You can't marquee the errant, control, because the marquee is inclusive and invariably also picks the group box that surrounds it. Shift-clicking out the unwanted controls is dangerous, because it sometimes registers as a double-click and then you get a random event handler added to your code or something.

I checked VS2010. It still picks the control on the bottom. It's still broken. It's been broken since Visual Studio .NET 2002, I've been waiting more than eight years for them to fix this bug, and it is STILL BROKEN. Does anyone actually use this anymore??

I really do want to give the Visual Studio team the benefit of the doubt. I do like a lot of the improvements in the compiler. Yet, I'm afraid that if I ever met a member of the IDE team that I would wrap my hands around his neck and strangle him, for the sheer amount of pain his team has inflicted upon me. I mean, c'mon. What visual editor with draggable components selects the one on the bottom?? There are so many other pet peeves of mine that still aren't fixed. All I have to do is look at the nearly unchanged project settings dialog to get the sinking feeling that the team still doesn't really get what they need to do to achieve "10 is the new 6." Then I look at the new MSBuild-based C++ project system in progress, which takes more than 30 seconds to load the converted VirtualDub.sln and prints out a 400+ column command line by default for every file group that it builds, and I get really depressed. And I look over the fence at other stuff like the XAML editor, and things don't really look that rosier over there, either.

Please, make VS2010 better. I tried Eclipse once and I hated it. I'd have to wear a bag over my head if I had to resort to EMACS. I don't want to succumb to the temptation of writing my own IDE. I don't need new features. I just need what's there now to work well.


Comments posted:

Did you realise the bug was closed WONTFIX two years ago for the last version? ;-)

nine - 05 12 08 - 03:31

Yeah, I get the emails. I'm in the running for the most consecutive bugs closed as "won't fix" or "as designed."

As far as I know, Microsoft doesn't generally reopen bugs in the public bug database even if they're planning on fixing them in a later version, so we can't tell from that whether they have it open for VS2010 (although I highly doubt it, at this point). That's probably for the best, because if they actually reflected all of the times that they closed and reopened bugs internally, we'd probably be very confused.

Phaeron - 05 12 08 - 03:42

The reason behind it is probably - the control is at the bottom because it's first on the controls list - so it's drawn first, and selected first, too.

And well... I can totally see the 'shutdown when finished' option in VirtualDub's Job Control window which is actually *hidden* under Options menu (where it is the only control) and is pretty much capable to ruin your work if you forget to check its state before starting the job (the setting is saved!) and leave computer for a minute at the wrong time... I guess it's the same kind of 'bug', including the long time since it was reported, which you can see from the other side ;-)

Kasuha - 05 12 08 - 04:01

Why EMACS? Only vim can help you! (And after igniting the flame war, I go away).


Mitch 74 (link) - 05 12 08 - 04:03


Okay, fair enough. I'd like to point out a few things, though.

First, yeah, I'm sure iterating from bottom to top in Z-order is the reason behind the current behavior. I hope you're not suggesting that's a good reason for it to stay that way...?

Second, there were only two states of existence for VirtualDub's shutdown option: it didn't exist, and then I added it in with auto-save. I don't think you can point at an earlier version where you can say it worked better than the current state, unless either you (a) don't want it at all, or (b) don't want that option to save. I'd be interested in hearing your reasoning if you believe in either case being better than the current implementation, because I don't think I've had any requests to the contrary, and I generally get far more complaints about options that don't save than ones that do. (Perhaps I'm wrong in this case. My bug database is a .txt file.) The bugs I'm complaining about, though, were regressions from an earlier version of Visual Studio where they did work as expected. I've filed other bugs on Visual Studio that are causing issues that I'd like fixed, but those features didn't exist at all in VC6 and I'm still better off having the mostly working feature.

Third, the Visual Studio team is explicitly mounting a campaign to targeted at users that prefer the old VC6 behavior -- they've explicitly asked why we like VC6 better, what's not working well or is broken, and what we'd like fixed. This is one of the things that isn't fixed and makes VS2010 CTP not "the new 6." It'd be like me releasing a new version of VirtualDub that has no MMX/SSE acceleration and runs at 1/10th the speed, and you guys hate it and want the old version back. Then I release another version that's 10% faster than the previous, but still 90% slower than the old version because it still has no MMX/SSE support, but it also now supports TIFF files, and I claim it's the "new old version." That's not really hitting the target.

Phaeron - 05 12 08 - 04:52

** Project Settings **

I started a short discussion about the Project Settings dialog here:

Sadly it sounds like it's going to stay awful in VS2010. It makes me wonder if anyone writing VS2010 actually uses that part of it as surely they share our pain.

** Dialog Editor **

I gave up on the dialog editor long ago. These days I do the layout in code, building up a small library that knows how to resize components to fit their labels & font metrics, and which knows how to space components according to the Windows UI style guide.

As well as the annoyance with the VS dialog editor that you mention, I hate the way it provides no tools for doing proper layout and spacing between different types of elements. In fact, Microsoft lack of support for good, easy GUI layout and resizing is probably my biggest complaint about the Windows platform as a whole. 15 years ago the Amiga had a better UI library (though that wasn't built-in to the OS, to be fair)...

** F1 Help **

Another thing which drives me crazy in Visual Studio is the way that F1 help is completely broken, at least for Win32 C++ authors. It worked back in VC6, or at least allowed you to remove unwanted parts of MSDN from the search space so that you only got Win32 API docs when you hit F1. After that it has become continually worse until what we have in VS2008:

Pushing F1 will take you to a page that probably has the text under the cursor but is in a random part of MSDN, probably about a .Net or MFC or Windows CE function with a similar name. I don't understand this. The IDE damn well knows you are editing a C++ file in a Win32 C++ project; why can't it tell the help viewer?

And there is no longer any way to exclude parts of MSDN from the F1 search as apparently that feature was removed when they added the web integration. WTF wants or uses that anyway? I want F1 help to open a quick, local copy of the relevant, official documentation. If that doesn't give me enough information and I need to search the web then I will do that from a web browser.

Unfortunately, if you look through the Connect site, the broken F1 help problem has been reported many, maaaaany times by many people but every time it's been met with responses saying the problem cannot be reproduced -- I find that difficult to believe! -- and everything works fine and the issue is closed. You'd think, with so many people reporting the problem for so many *years*, that it would get the attention it needs.

** Still... **

I do still think VS is great. No other IDE is close to as good as it (though that's as much to do with those IDEs being rubbish as it is to do with VS being good). I admit to being negative here when there are a lot of things to be positive about. I know I'm somewhat taking VS for granted. I just wish MS would put their resources into the right place as it's frustrating to see huge, obvious and painful flaws in the product persist year after year.

** Random other gripes while I am ranting: **

* Whenever I hear "10 is the new 6" I dream of being able to push F7, have the Output Window appear and then, like I could in VC6, hit Esc in a code editor to hide that bottom panel and re-claim the space for the editor.

From VS.Net onwards the new UI has meant lots of mouse clicking to do this. Or having the output window auto-hide, which is deeply annoying in ways I could write another five paragraphs about. Making things worse is that you have to keep closing and re-opening all the other windows that use that area (e.g. Find Results). Ergonomic it is not, yet in VC6 it was perfect. It appeared when it needed to and could be dismissed via a single keypress without changing focus from the main code editor.

* The new GUI controls that MS are providing (e.g. the ribbon) are all MFC-based. MFC had been so neglected over the years, and is such a badly-designed obfuscation layer for all but the most simple projects, that I was hoping it would be left to die.

On one hand I am sick of Microsoft's continual process of "here's a great new way to make GUIs!" every couple of years, with each new way turning out to be either terrible or unsupported and then, either way, soon replaced by yet another new way... (I lost count of how many times that happened in C++ and it's already happened in .Net... Yet we still don't have a decent system for GUI design, layout and re-sizing. Pathetic.)

On the other hand, MFC was the one GUI framework which I really felt deserved to die and stay dead! I know I'm not alone in that. (It's got to be bad when using C-style Win32 is preferable to C++ objects and methods because of all the badness that comes with the MFC design and how little it actually improves...)

Now it seems that MFC -- the thing that should not be -- is the one C/C++ GUI framework which Microsoft want to support. Brilliant. :-(

If the new controls were Win32 (or whatever) then I wouldn't mind MS supporting MFC by providing wrapper classes. (I'd think that was a good thing. Despite hating it I do still use MFC occasionally for *very simple* projects.) It's rubbish, though, that using MFC is the *only* way to get those new controls. I know they bought them from a 3rd party but that doesn't change the fact that they're MFC-only. Nor that MS had to buy a 3rd party's remake of controls written by their own Office team.

(I really wish the people in the Office team creating non-standard GUI stuff would be moved into the OS team: If you want those GUI features then get them built into the platform for everyone to use, and so that the OS has a standard look & feel. Sadly it seems that Office is more important than the OS itself sometimes.)

** Still... (again!) ***

Still, the TR1 stuff is good and the C++ compiler, and template support in particular, has much improved over the years.

Perhaps the problem is that VS doesn't have any real competition so there's no threat that any of us will switch to something else.

...Cripes, that turned out to be quite a rant. :) Feels good to get that off my chest.

Leo Davidson (link) - 05 12 08 - 05:01

The reply "we are no longer fixing bugs that don't cause more serious problems" is really making me laugh, why wouldn't they fix a bug if they know exactly how to fix it?

Stefan - 05 12 08 - 06:15

Maybe you should stop writing software for Windows and you know, stop supporting an operating system and company that treats its users like shit?

Steve - 05 12 08 - 09:24

> VS doesn't have any real competition

I agree. VS2008 is a good command-line C++ compiler, faster than g++. And... well, that's all folks, nothing else to see. So I'm not surprised the new version is still a good command-line C++ compiler and nothing else.

Fabien - 05 12 08 - 10:43

I kind of feel like this would be similar to Apple not fixing a problem in MacOS X that plagued MacOS 9 apps, or that Maya hasn't implemented a feature that used to be really great in Wavefront's Advanced Visualizer (assuming any features of TAV were ever great). Both examples are just meant to illustrate that .NET is Microsoft's future, that's where they're putting all of their development resources.

I can't disagree with your assessment that "10 is the new 6" is bunk, though worrying about native VC++ dialog designers seems pretty passe to me. If I was doing UIs in VC++ and never had any plans to use WPF or .NET Forms, I'd use QT. A lot of people do. VC++ users are probably just going to have to take this into their own hands at some point, either by adopting QT or making something new.

But I you know you're itching to reimplment VirtualDub in C# and WPF. roflcopter.

Trimbo (link) - 05 12 08 - 12:23

"This behavior is by design", ticketese for "screw off".

I can't bring myself to try a beta release of a Microsoft program (test their software for free, when there's no chance they'll even fix the problems I'll find?), but--have they fixed the insanely slow find dialog redraw? That alone doubles the stress level of using the IDE.

> stop supporting an operating system

You don't write software for an operating system. You write software for users who use an operating system. It wouldn't affect Microsoft at all; it'd just screw over the users. You can't (meaningfully) "boycott" Windows.

Glenn - 05 12 08 - 16:15


If nothing is seriously worse (big if), seriously, I'll be happy if Intellisense won't randomly HARD LOCK THE IDE.


Glenn - 05 12 08 - 21:43

Hahaha, just today I had to kill it several times because intellisense locked up. If I feel the mouse bit sluggish then I carefully save my files before right clicking on anything.

Gabest - 06 12 08 - 06:38

> The reply "we are no longer fixing bugs that don't cause more serious problems" is really making me laugh, why wouldn't they fix a bug if they know exactly how to fix it?

That's actually a fairly good reason, and one that I'm willing to give a lot of leeway for. Fixing a bug in a project as big as Visual Studio is an expensive affair -- it takes time to implement and time to test. The testing part is actually the killer, because the amount of integration that VS has results in a large testing matrix and a lot of opportunity for bugs. Does this break with C++? Does it break with C#? Does it break with VB? Does it break on Professional edition, Enterprise, or Express? Does it break on XP or Vista? You get the point. All of these are opportunities for breakage. For good measure, you can also throw in customers depending on bugs (which happens frighteningly often), as well as just plain unforeseen circumstances.

Basically, this is par for any commercial development -- as you get closer to ship, the bar for bug fixes gets higher and higher, and at some point you have to stop. For most projects, the question is not when you've fixed all the bugs, but when the point at which the seriousness of the remaining bugs doesn't justify fixing them because doing so might risk the ship date. This isn't great, of course, but it's basically required until we find an overall much better development process.

The problem is when you keep putting off bug fixes from version to version, which basically means you're accumulating bugs as you go. It's pretty clear at this point that the Visual Studio team's current processes are not working, if they've got user-facing bugs that are persisting for more than four releases and they have trouble putting out SP1 for one product before they ship the next one. It doesn't help that they're trying to evolve Visual Studio in 15 different ways, for .NET, for C++, for the web, for databases, for an integrated source code control and bug database, etc.

> I agree. VS2008 is a good command-line C++ compiler, faster than g++. And... well, that's all folks, nothing else to see. So I'm not surprised the new version is still a good command-line C++ compiler and nothing else.

What about the debugger?

> "This behavior is by design", ticketese for "screw off".

Yeah, some of the by-design closes are pretty bogus. The compiler team largely uses Won't Fix instead, which I think is more appropriate.

> I can't bring myself to try a beta release of a Microsoft program (test their software for free, when there's no chance they'll even fix the problems I'll find?), but--have they fixed the insanely slow find dialog redraw? That alone doubles the stress level of using the IDE.

Well, it's kind of a catch-22. If you don't try the betas, you're going to be suffering with the bugs anyway. I don't know if you remember what it was like before the public bug database was started, but it was nearly impossible to submit bugs without calling PSS, which required an incident ($$). There was one web form you could use for VC++, and on a good day, with the winds blowing north at 2.7 knots, it could work without throwing errors. I think I got maybe one bug fixed through that path; I've had a lot more fixed through Connect, everything aside. There are also some benefits, too -- the VS2010 CTP does let you play with lambdas.

> You don't write software for an operating system. You write software for users who use an operating system. It wouldn't affect Microsoft at all; it'd just screw over the users. You can't (meaningfully) "boycott" Windows.

No, but you can boycott versions. I'm basically staying on XP and seeing how Windows 7 turns out, and I refused to go to Visual Studio 2008. Fortunately, as a hardcore C++/Win32 programmer I have that option... it's a little less of an option if you're trying to stay on top of the .NET world, since VS and .NET Framework versions are so tightly coupled.

> If nothing is seriously worse (big if), seriously, I'll be happy if Intellisense won't randomly HARD LOCK THE IDE.

ren feacp.dll problem_solved

Phaeron - 06 12 08 - 23:14

...and people complain that gcc, Eclipse/EMACS/vi, Qt/gtk+ and automake/other-automatic-project-configurator are separate projects that use separate release schedules.

All right, I'll --->[]

Mitch 74 (link) - 08 12 08 - 04:37

I gave up on VC a long time ago. For me, it was crap like this that put the nail in the coffin...

VCMAME: compiles with VC2003, fails with VC2005

Krick - 08 12 08 - 11:21

> I gave up on VC a long time ago. For me, it was crap like this that put the nail in the coffin...

> VCMAME: compiles with VC2003, fails with VC2005

Can't argue with that. If the compiler ICEs on your critical code, you can't really switch. I have to say though, it's almost worse when you don't have an excuse like this, because you COULD switch... and deal with the bugs and hassles. And sometimes, you're forced to for various reasons (never take an external dependency in .lib form if you value your sanity).

Phaeron - 09 12 08 - 00:33

I don't understand, you are basing your argument that 10 isn't 6 on the control order when clicked? At least for VB, 6 had the exact same behaviour and it ennoyed the hell out of me (I didn't use other languages back then, was still in highschool).

So to me you are arguing that 10 is 6.

keije - 10 12 08 - 10:28

Heh, I just noticed something. On Google's Chrome page, where they give advice on how to set up the Visual Studio Visualizer for chromium, 2 of the 3 reference links are to your posts :)

keije - 11 12 08 - 19:48

No, I'm not basing my argument that 10 isn't 6 just based on this one bug. I'm using it as an example of a bug that contributes to this not being the case. I could spend a lot of time naming other problems, such as how much harder it is to edit multi-project properties, how the project system builds projects even though you explicitly say "no" to the build dialog, etc. It's a good thing I'm not an MFC programmer or I'd be extremely bitter about Class Wizard.

Also, keep in mind that I'm talking about C++ here. VB6 is a whole another ball of wax... but Microsoft screwed the VB folks even worse by taking away native code generation and making VB a poor stepchild of C#. If I were a VB programmer rather than a C++ programmer, I think realistically I'd have been forced to make the transition to C# a long time ago. I don't know why Microsoft still supports VB at all... it seems like they've already neutered most of VB's unique advantages.

Phaeron - 12 12 08 - 01:14

I think the reason they still support C++ and VB in .net is so that it is "easier" for those who used to such languages to make initial translation into .net framework, then they find out the problems, re-evaluate what they've already got, and decide that it's easier to just go full blown C#.

I am watching this happen in slow-mo at my workplace.

keije - 12 12 08 - 18:20

Try Netbeans, it supports Java, C++, PHP, Groovy, Ruby. Truthfully, I have never used it for C++, but it is free. So, you have nothing to lose.

Mp - 13 12 08 - 14:36

yea give netbeans a shot...i use it regularly and have minimal problems with it..
moreover the guys are really active listeners (and they act too) to all the bug listings.. and they keep releasing a new version every now and then
i hav actually grown quite fond of netbeans! :D probably u will too..

Sanjay - 18 12 08 - 01:57

Re: [Phaeron - 05 12 08 - 04:52]
I'm not saying it's correct in VC10 and I'm actually also not calling for fix in VirtualDub, I was just trying to point out the different points of view developers and users have. What looks like a serious bug making the software unusable or highly annoying to one might seem like a little glitch with easy workaround to the other one. Also developers often prioritise their tasks and solve them in the priority order, then leave some tasks at the end of the line unfixed if they are not crucial and if there is not time/budget/willpower to fix them. To me it is normal, that's how things work, like it or not.

Kasuha - 19 12 08 - 09:01

Why not stick with vc6?
I use it in combination with the intel c++ compiler.
Works very well.

Hugo - 21 12 08 - 08:07

Why not use Code::Blocks?

Code::Blocks can import Visual Studio solutions and projects and you can adapt them to work with Code::Blocks quicker. Once in Code::Blocks, you can configure the Code::Blocks workspace and projects to use the MSVC compiler instead of MinGW.

More importantly, it is a hell lot lighter than Visual Studio. And if in the future, you want to transition to MinGW (you could still use MASM with MinGW), then you can easily switch to MinGW in the project settings.

Pharaoh Atem (link) - 21 12 08 - 11:35

Woah, you use YASM now? I just saw that :D

Pharaoh Atem (link) - 21 12 08 - 11:38

The VC6 debugger is pretty raw at this point -- it can't use the symbol server, it can't read newer system symbols, it leaks astounding amounts of memory if it reads older ones, and it has no visualizer support. VC6's Intellisense is also pretty raw (no enums!). There's also no 64-bit platform support in the project system. VC6 did a lot of things better than current VS, but I'd still rather stick with VS2005.

The general disadvantage to switching to other IDEs is the debugger -- most other IDEs are built on top of GDB, which means they either don't or poorly support debugging VC++/Win32 built modules. I generally need to do a lot of debugging close to the Win32 API or external .libs, so this is a problem for me. It looks like Code::Blocks may redirect through CDB, which is interesting... probably not the fastest or most reliable way to debug, but then again the CDB/WinDbg engine is also an order of magnitude faster than the VC++ debug engine.

Phaeron - 21 12 08 - 16:55

I use Code::Blocks when doing my Linux projects. It is working fine, their "intellisense" seems to just work. The main issue imho is the code editor: The smart indent feature is _very_ basic, far away from VS or vim. It is not context related and just reacts on entering { or } brackets.

powARman - 22 12 08 - 10:35

I know this is kinda late, but isn't the CDB/WinDbg engine considered more powerful than the VC++ debug engine?

Also, what do you mean by poor to no support debugging Win32 built modules? I never heard of such a thing before. Unless you are talking about the fact that until recently, GDB did not have native support for WIn32 debugging. With GDB 6.8, native debugging for the win32 platform was introduced. But, meh.

The VC++ thing stumped me until I thought about the reimping required for DirectX SDK to work with MinGW. If you wanted to use the entirety of the Microsoft Platform SDK with MinGW, you would have to 'reimp' the .lib files to .a files for them to work to build into a program using MinGW. Unfortunately, currently reimping is required for using DirectX with MinGW. I don't know if that would ever change really, but meh.

I say meh too much :D

Pharaoh Atem (link) - 11 01 09 - 23:08

The CDB/WinDbg engine is indeed more powerful than the Visual Studio debugger, and I use it a lot. Unfortunately, the UI is also a lot weaker. It also doesn't support data structure visualizers, which I've come to love.

GDB 6.8 may have support for debugging natively under Win32, but what's important is having support for the PDB format. Microsoft doesn't document PDB, so supporting the newest incarnations can be a problem. For instance, when I was looking at the Wine DirectDraw issue, I tried Winedbg and discovered that while it can handle CodeView symbols in PDB, it has problems with VS2005 PDBs. The system PDBs from the Microsoft symbol server are very, very useful but you need a relatively recent debugger to handle them.

Phaeron - 14 01 09 - 00:35

Comment form