Needs for Windows SDK Tools?

Anna Jayne Metcalfe

If you'd asked that 5 years ago I'd have had a wish list as long as your arm. These days I've ditched most of the SDK tools in favour of more highly evolved free equivalents (put Windiff head to head against WinMerge and you'll see what I mean). However, the one thing you could do is radically improve the interface and stability of Spy++. Not only is its UI cripplingly unpleasant to use (try spying for messages while trying to faultfind a subtle bug involving messages sent between multiple windows), but its all to easy to freeze the system while using it. If I think of anything else I'll be sure to let you know. :) Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.

Tom Archer

Don't forget that I'm also talking about utilities such as ai, sn, gacutil and so on. So anything that would make that part of your life easier would be great. Tom Archer (blog) Program Manager MSDN Online (Windows Vista and Visual C++) MICROSOFT

Shog9 0

I'm only going to make one suggestion, because nothing else i could add would be anywhere near as important to me: Get whoever wrote DEPENDS.EXE (Steve Miller?) to help out with the UI for the other tools that have a UI. 'Cause by comparison, they don't. Best. SDK Tool. Ever. ----

Bots don't know when people die. --Paul Watson, RIP

Marc Clifton

Wrap 'em all into a nice UI so that you can select all the friggin command line options from a UI, and they should have some nice help text/links for what they do, and run them from a UI. Be able to workflow them, so I can run several of them together. A little macro capability would be nice if you workflow them, so I can have them operate on a file set, etc. Why we're stuck with DOS (oh, forgive me, the command line prompt) to run these things is beyond me. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures

Blake Miller

I would like to see something that graphically presents the relationship between all the LIB, DLL, and EXE in a given directory tree. We have about 217 projects, and nowhere is it documented what their relationship is to each other. It would be nice to have some query or hilighting capabilities in the graphics, so the tree could easily be followed. A complementary tool would be something that checks for inconsistencies in threading models, optimizations, exception handling settings, etc. among the various projects. A utility such as this would help us migrate all our projects to Visual Studio 2005 much more quickly. I would imagine this could be done by parsing the DSP files - and applying a decent UI to the utility. People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks

Anna Jayne Metcalfe

Virtually all of our development is native at the moment (.NET just can't do what we need it to), so we're more interested in what you can do to enhance the native tools right now. Oh and a graphical version of dumpbin would be good. Preferably with decent search and highlighting facilities. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.

Marc Clifton

Anna-Jayne Metcalfe wrote:

(.NET just can't do what we need it to),

Care to elaborate? I'm always on the lookup for what pits I'm digging for myself, embracing C# as much as I am. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures

Mircea Grelus

Ok. Probably this has got nothing to do with the SDK, but maybe yoy know the right person to ask about his stuff. I can't seem to enable script debugging in Internet Explorer. I can't do this nor on my work computer neither on my home machine. See an earlier unanswered post of mine[^]. On other computers I have tried it worked. Now I guess it has to do with some Microsoft products installed. On the machine in my office mostly all products are Microsoft. I've been trying to find an answer on this for quite a while and I've had no luck. I'm in real need of solving this. Any help would be greatly appreciated. Again, I know this is completely off topic. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.

Anna Jayne Metcalfe

The main reason we don't use it is that for support reasons we produce a single binary, targetting all versions of Visual Studio from 2002 to 2005 (with Visual Studio from 6.0 - and likely eVC 4.0 - being added soon). Although I like the C# language (but where's const?) I've encountered several issues: 1. Inproc framework versioning. If we wanted to target VS2002 using a .NET add-in, we'd be stuck developing in VS2002. That's a showstopper....we should be able to use later tools to target earlier versions, and be able to mix framework versions within the same process if necessary. 2. VS 6.0 and eVC 4.0 support. On these platforms we simply can't assume any version of the framwork is installed, and given our complete installation is only 3 MB a 20 MB+ runtime isn't acceptable. Potential customers without it are simply likely to walk away. This issue isn't likely to go away unless MS can offer us a statically linked version which discards all the bits we don't use. 3. Speed. Visual Lint is heavily threaded (we use two thread pools, both adaptive and with variable priority), and does a lot of background processing and string mangling. For this, a GC solution is likely to be more memory hungry and less efficient than native code. Managing pointers in this sort of application is no big deal really. 4. User interface. What I've seen of Winforms (and I have used it in a production environment) has convinced me that it has a long, long way to go before I'd consider it for a UI intensive application. The flexibility of native UI frameworks simply isn't there, and the whole paradigm of laying out a "form" in code quite simply stinks. The Visual C++ 1.5 dialog editor was a joy to use in comparison with any of the Winforms editors I've used. Based on what I've seen, I suspect that when we do change the way we do UI we're more likely to use XAML than Winforms. Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.

Warren Stevens

Since Microsoft has little interest in making any meaningful changes or improvements to MFC, how about releasing the MFC project like WTL was? Then Microsoft doesn't have to hear about not supporting it anymore, and the people that still use it will be happy doing their own thing:-D Warren

Nish Nishant

Warren D Stevens wrote:

Since Microsoft has little interest in making any meaningful changes or improvements to MFC, how about releasing the MFC project like WTL was?

MFC always came with source, so anyone should be able to change it as they want to (though I don't know about licensing issues). Regards, Nish

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!

Gary R Wheeler

One tiny little problem: the standard version of MFC is installed with the OS. Everybody will be overwriting that with some botched-up custom version.

Software Zen: delete this;

Fold With Us![^]

Warren Stevens

Gary R. Wheeler wrote:

the standard version of MFC is installed with the OS

Are you sure about that? I've always had to install it, and as far as I know it's not installed automatically.

Gary R. Wheeler wrote:

Everybody will be overwriting that with some botched-up custom version.

You can do that already, making a custom build of MFC 2) You shouldn't install it in the system folders anyway - just beside your app. 3) My original idea was to have some "community" develop, and then there would be some large "stable" releases of a new MFC (just like the WTL project - look at it), not just a lot of individual efforts Warren

Warren Stevens

Nishant Sivakumar wrote:

MFC always came with source, so anyone should be able to change it as they want to

Yes, but that just leads to tons of individuals doing their own thing, that go nowhere in the end. You need a community development, so you can build on the work of others (like all of the projects out there). MFC has some great qualities (or there wouldn't be so many people still using it), I was thinking it could take some ideas from QT, WTL, modern C++ features (e.g. templates) and go from there. Imagine MFC with: Internationalization support like QT resource ID system without all of the resource.h pitfalls. dialog layout like C# WinForms or like QT etc... You might even have a company donate a basic version of a grid control (which would become part of the MFC standard). And then the company could offer the "derived, extended, and super-functional" verion for a fee. Warren

Joe Woodbury

An icon editor. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke

LimeyRedneck

I was waiting for a clue as to your next article .... :laugh: Nothing is impossible, we just don't know the way of it yet.