Fog Creek Software
Discussion Board




Built into the operating system...

I just read this at blogs.msdn.com (which was a exerpt of http://blogs.msdn.com/tims/archive/2004/07/19/186946.aspx)

"MSBuild is actually built into the operating system, rather than the development environment. This means you can build Visual Studio projects without VS installed; all you need is Windows (and .NET Framework 2.0 until Longhorn)."

Here's a message to you, Microsoft - quit building this shit "into the operating system".  This mindset is the #1 reason why I wish Microsoft was broken up by the DOJ - "Hey, let's just stuff it into the operating system!". Outlook Express - this turdulent piece of crap is a "part of the operating system!". MSN Messenger. It's a "part of the operating system!".

.
Monday, July 19, 2004


It means that a compromise in one can quickly become a compromise for all.

Arg.

KC
Monday, July 19, 2004

Hey if they want to build insecure software, let 'em.

.net, the equivalent of MS Bob.
Monday, July 19, 2004

So I guess you don't think MSI should be included either?

It seems to me a universal build system could be extremely useful.  The Windows equivalent of the Unix config(?)/make.  It's pretty clear that's the inspiration.

I'm with you on the MS Messenger/Outlook Express business, however.

Doug
Monday, July 19, 2004

Very humorous.

The more people try to avoid 'make', the more they reinvent it.

Is 'make' part of the OS?  No, but its common to find make on almost all Unix distributions.  MSBuild can't *really* be considered part of the OS, can it?  Its just bundled in there.

What would constitute a peice of the OS?  A service or something else hooked into the OS which other parts of the OS depend on.

Is IE part of the OS? Sort of, in the same way that COM is.  Published interfaces that people come to depend on and are turned on by default - I suppose.

But, just for a minute while I clear this brain-fart:
<whoopie cushion noise>
Now suppose that Microsoft decides that builds could be distributed. Break your XML build file up into pieces and distribute them via HTML, letting your build farm go crazy. Now, turn on the remote build service by default and throw it out there with the Windows SP. WOOHOO! You could compile the next Win32 widget in milliseconds. Now, you've got an OS component.  I say ship it.
</whoopie noise>

What would be the correct syntax in MSBuild for "spambot/keyboard logger"?

hoser
Monday, July 19, 2004

They do it because people want it.

Remember how everybody uses 5% of the features, but everyone has a different 5%?

Don't count something as irrelevant because you don't use it.  That's the sign of a narrow mind.

Conspiracy Anti-Theorist
Monday, July 19, 2004

"Turdulent" is a great word. I need to remember that one.

Bored Bystander
Monday, July 19, 2004

"They do it because people want it.

Remember how everybody uses 5% of the features, but everyone has a different 5%?"

A good portion of windows exploits have been caused by the esoteric features that they just had to install on every machine (usually going so far to make it impossible to remove it. It's not because people want it, it's because they want to make you want it goddamnit). A server machine has absolutely no reason to have a build environment on it, yet some day a few years from now a massive exploit will be released that utilizes msbuilt to pown the machine.

In any case, there is this thing called the interweeb where we can download and install all the SDK or extensions that we want. I see absolutely no viable reason for yet another steaming creation to be shoehorned onto every PC.

.
Monday, July 19, 2004

nah...  this time they did it because they (their developers) wanted it.

You know the frustration I have when I log into a field deployed server, and don't have access to a gcc compiler, make, find and grep?

Its aggravating as heck.  And, its also best practice: not putting unnescessary tools on a deployment server. So, curse the token word, and build the debug widget off-site, put it on-site, debug the item, and pull it off when you're done.

That's life in secure-land. That's because there is truth in the words "nothing is completely secure", so you minimize your global vulnerability set and bound your risk. No matter how invulnerable you may think "this one little thing" may be, I wouldn't want to be the person who turned it on in a deployed environment only to have it cracked.

hoser
Monday, July 19, 2004

Distributing across a build farm is one of the key objectives here. I had a nice chat with Alex Kipman (The PM for MSBuild) at TechEd over this and there will be more stuff in just that area over the next few months (or at least thats the impression I got)
However as always whats planned vs whats shipped may be very different.

Peter Ibbotson
Monday, July 19, 2004

"A server machine has absolutely no reason to have a build environment on it"

nor a chat client
nor media player
nor a whole lotta other junk

.net, the equivalent of MS Bob.
Monday, July 19, 2004

So in your world Linux servers don't have make in the path?

Chris Nahr
Tuesday, July 20, 2004

I agree with the original poster. Windows base should be just the kernel and abstraction layers, for example: networking (winsocks), 2D/3D graphics (GDI/DirectX) and other base services.

Stuff like .NET, build system, IE, Windows Explorer should be add on applications and installed in <HD device>:\Program Files\<directory>

dude
Tuesday, July 20, 2004

No.  Not a server in the field.

hoser
Tuesday, July 20, 2004

*  Recent Topics

*  Fog Creek Home