Name 2 Microsoft programs (not dev tools) that use MFC. Did you say Paint and Wordpad?
Great, name another....I'm waiting...nope...Scribble doesn't count!
Name a shipping Microsoft application built on the .Net framework....that isn't a 'sample' application.
In all seriousness, I have heard a friend or two mention that Microsoft uses completely different libraries (and sometimes private/secret API's) for app development and the rest of us get the stuff that ships with Visual Studio.
The anecdotal evidence seems to support this at least to some degree as I just don't see a lot of production MS apps based on MFC or .Net. Is this just a misconception? Does Microsoft have a 'secret' set of libraries they use internally for all the cool docking
toolbars and fancy windows we see in MS products? Am I asking too many questions?
Does a Microsoft developer sit down and use VS.NET all day like I do? Using the shipping .Net framework classes, or the shipping MFC? Or do they have 'special' development environments not suitable for the public?
I dunno. I suspect much of the problem for "office" style toolbars and menus is the accumulated "cruft" of a non-designed solution. i.e. It needs a lot of refactoring to make it generically useful
Once upon a time I assume there was a plan to do some serious work on MFC as certain editions of the class map in MSDN had a "CDockWnd" in the diagram (Note name is almost certainly wrong)
To do those kinds of things last time I used BCGsoft, next time it'll be Ghengis (Thanks chris & co)
Whidbey does seem to have a few more of these things built in, but in general I suspect MS use them just with different libraries.
MS say that in surveys most UI designers admit to just ripping off the current version of Office, so Offices UI will always be the next generation.
What should be interesting is the side effects of the "Microsoft Business Framework" which has gotten spun out the Great Plains/Navision mergers and where that ends up going. The powerpoints from the PDC seem to imply there's a report engine and a new forms
editor which may mean that this whole area gets properly "componentised" as the resellers will need to modify the code for end users.
>>Name 2 Microsoft programs (not dev tools) that use MFC. Uh... FrontPage... Oh jeeze. Good question! >>Name a shipping Microsoft application built on the .Net framework.... Commerce Server 2004, SQL Server Reporting Services, Project Server.... There
is a pretty cool sounding stack called Genghis that Chris Sells is somehow involved with. That's not exactly a secret weapon, though.
"Does a Microsoft developer sit down and use VS.NET all day like I do? Using the shipping .Net framework classes, or the shipping MFC? Or do they have 'special' development environments not suitable for the public?"
I am a Microsoft software engineer and a Channel 9 guy (one of the two developers on the Channel 9 team. Channel9 was written completely in C# and bad HTML, which we will fix... Visusal Studio and Visual Source Safe are the only tools used, plus a windows form
app that I wrote to get the moblog pictures up to the site).
Visual Studio 2003 is running from the time I start up in the morning to the time I shut down in the evening (or the next morning, depending on the situation...). The VS.NET IDE is the best IDE I have ever used. As for secret tools or secret APIs, no. You get
the best we have to offer, just as I do.
Yah I think the best gauge for the quality/trustlevel of a tool is when the developer is "dog foodin it"
I think like any other company, including MS, it's going to take time to start seeing complete .NET applications rolling out. I think they will be much more aggresive then your average company out there in migrating to .NET because they have to be able to say
"look we use/trust it" but to be honest I'd rather and I think most customers would rather see the next version of a product with more features then the same product rewritten in .NET w/o any new features. This would be cool for developers but would not make
much sense from a business perspective when it's new features that drive a customer to upgrade/purchase not that it was developed using the latest and greatest technology.
We're doing new development in my company with .NET and some updates to existing applications in .NET to take advantage of what .net offers and the improved development toolset(language and IDE) but if our existing stuff ain't broke I can't really justify porting
it just to port it and I'm thinking that MS probably has a similar philosophy.
I'm sure MS has some custom tools just like any other company out there but it is good to see that they are using there own tools
Yes, Microsoft uses custom tools like all dev companies: All development teams and many developers at Microsoft write custom tools to make their lives easier. But a custom tool is not a product. It's just a tool that has a very specific purpose that may
or may not evolve into a product. To achieve product status at Microsoft, your tool needs to be incredible...
In terms of Microsoft porting unmanaged applications to managed, sure, some applications can't be ported yet, but make no mistake, it is a clear goal of every single product team at Microsoft to incorporate .NET in any new product or product update. In some
cases this is really hard to achieve, but for most of our products, new managed apis will become core to the product. You can bet on this. We did.
The fact that you sit in front of VS.NET all day like I do actually makes me very happy! It creates some sense of kinship...even if it's just in my head .
And even if folks are complaining about your adherence to HTML, this site has been rock solid since you put it up (at least from my perspective).
There's a lot to be said for that.
Another important point...
When creating a new version of .NET, you don't have tools like Visual Studio ready until late in the cycle. Other supporting test tools, profilers and the like have to be written to support development before the Visual Studio team can complete their work.
I for one think that what most customers really want is for us to build the best software we possibly can regardless of the tools that we use to build it. With the size and scale of development that we have going on here, there are requirements that very few
other companies need. This is why many of the internal tools that we use are simply not suitable to ship as product.
We are actually not allowed to use "secret" APIs. Everything we use has to be public interfaces that anyone else can use.
Comment removed at user's request.
this is an interesting question...i imagine you will get all kinds of answers...
I'm a dev in the directory services group of windows, and i pretty much use visual studio 100% of the time in my day to day work when writing code. For longhorn stuff it's whidbey builds, for win2k3 its everett.
One of our products ( uddi ) is essentially a .net 1.1 application on top of sql, so the web-service integration / debugging features in .net are really useful. For the harder multithreading / interop debugging issues, i find nothing beats windbg / ntsd + sos at
the end of the day though, so use those now and again...
Of course this is microsoft, so there are those hardcore types who debug without symbols, and use notepad as their editor of choice ( they do exist, believe me ), but i've never really aspired to such giddy heights...
Offical builds are all command driven through scripting magic of course, but day to day studio is it in my case...
Do we use VS.Net to write VS.Net?
Why of course we do
I usually have 2 installs of VS on each of my dev machines: the one I'm working on and the one that I use to debug and edit with. I have VS projects for the DLL's that I work on and all my UI work is done in the Winforms designer. I work on our resources files
with our new resources editor as well. The only thing that I don't do in VS is build. Our build system dates back to the NT days and is pretty standard across MS.
I *love* Visual Studio. I *love* Whidbey. Every week I stumble on one or two features that really knock my socks off and I can't wait to get it in the hands of developers around the world.
Speaking of which, I have some bugs to get back to...
Comment removed at user's request.
Maybe this could be an idea for an upcoming video. What is the typical PC a developer gets work with at Microsoft? What tools do you typically use? What is the work environment like? Are you crammed into cubicles Dilbert style or just chained to the oars?
Most of the devs at MS have offices. Offices with doors. A lot of them have offices with windows as well as doors. When I think of my dev days at Digital and the cubes we worked in I can't get over the difference. I mean nice offices, free soft drinks
- does it get any better than that?
Here's my view from the trenches in windows...
one thing we do get is good kit. as you'll know developers love kit more than anything else - food, personality, hygene etc - so this is a good thing.
I've a dual 2.8 xeon with lots of ram etc as my primary dev box, an itanium-2, and a quad AMD64 in my office + 3 quad lab boxes for test etc hosted remotely.
Tools i typically use are vs, windbg, ntsd, cordbg etc + the usual debugging friends ( heapmon, regmon, filemon etc )
work environment in my experience is very flexible. I probably work from home 30% of the time ( it's been all 4 days this week so far ) , otherwise it's the office. I've been here long enough to have a window, which is cool...but hardly ever look out...
all the tools we use for official checkin / build etc are command line driven, and seeped in history and lore ....they are very cool but it's heavy perl etc and i never did learn to effectively read that...
i can build windows on my machine by typing a single command though, which is pretty cool...
time wise it's typical dev stuff...sometimes it's quiet, and sometimes its completely crazy 7day weeks, you know how it is...
I'll definitely try to cover that in videos in the future.
Most developers get their own office, by the way. There is not a single cubicle that I know of on campus and I've been in most of the buildings.
Some developers are doubled up in offices. Space is getting tight in many buildings (we're almost finished with building 36, which'll house hundreds of people).
Machines? They range all over. The really hot people have a 200 DPI IBM monitor that costs $8500 (Bill Hill has one of those on his desk). Driven by 3GHz Dell machines.
Some devs have multiple machines/multiple monitors in their offices.
We use the same compilers but we the reason we don't build from VS is because that has the latest and greatest bits but also the most unstable. We build using a last known good compiler that gets updated much less regularly than everyday. That's the fun of
writing the compiler, the platform, and the tools all at the same time (and writing the tools in the new languages for the new platform!).
As far as the build system goes, it's ancient ways are best left to those who know it's secret incantations . Well, its not that bad but there are whole teams dedicated to getting our daily builds done and I have nothing but respect for the feats they pull
off each day. I wish I could tell you more but I haven't plumbed the depths of our build system too far...yet...
Comment removed at user's request.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.