Needs for Windows SDK Tools?

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.