I was not basing my comparison of the GUI speed on server side benchmarks. The Windows API is not object oriented or even good.
Where the hell did I mention the Windows API? If you're talking about Windows Forms, it is a part of the.NET framework. See? To clarify, it IS object oriented and, however subjective this statement may be, it IS good.
Even if I was talking about the Windows API, I'm still not entirely sure of what you're on about. Passing IDs? You mean handles? Yeah it's not object oriented - it doesn't have to be, it's written in C: a procedural language. I suppose the Linux Kernel developers must really suck in your eyes, 'cause they're not OOP monkeys.
And if you want to talk about wasting programmer time, compare the time it takes to implement a simple tree control in Swing compared to the time it takes to implement something similar in Windows Forms. That's FORMS, not API.
This is a compounded advantage compared to Swing with the current state of JITC. When JITC is as good as C compilers, Swing will be faster than native widgets because of the ability to inline function calls of the API.
Yeah, Java code will get faster as the Java JITC gets better, but so will.NET code as the.NET just-in-time compilation improves. I've heard (but can't substantiate at this moment in time) that when you install the.NET framework, the code is actually compiled from MSIL to native code (as in, native code not bytecodes that are then JITC at runtime) to a certain degree. How can Java possibly compete with this? Of course, this may very well be a 'windows-only' thing.
But faster than native widgets? I very, very much doubt it - but we'll see.
On the general speed of Java verses CLI, I only admit my findings as some evidence since there is no real good evidence. Sure my evidence is flawed, but I stated it out right so as to not decieve anyone. I didn't make an unsupported claim like you did.
You're right, my bad. My claim was unsupported. However I do know that on my system, it takes an eternity for simple things like a Swing JFileDialog to appear.
I didn't intend to mislead or deceive anyone. It was a mistake, I admitted it in a previous post, I'm admitting it now.
I don't care about ISO/ANSI/ECMA standards because by and large they mean less than I've seen from Java. There are few, if any, C++ compilers that are up to spec. Even if they were, the standard class library is too little to be usefull. There are standard text based IO streams, but you have to use some third party library for anything else you need or write your own. The end cost for developing C/C++ programs is much greater than Java because of this. These third party libraries can't really be taught in school because there are usually 3-8 different competing libraries that are all considered on equal footing in the marketplace.
There's a lot that isn't taught in schools.
Comparing Java to C/C++ is a waste of time. Yes, Java is easier to program with. No, it can't do everything. Live with it. As for cost, it really depends on the sort of application.
Boost adds a lot of functionality to the standard C++ library - not nearly as much functionality as the Java runtime, but then it's not quite so high level either. As I said, you're barking up the wrong tree.
What language do you think is used for low level native Java methods?
Java changes quicker than C/C++ because it's not an ECMA standard.
I don't know about you, but Java changing a lot says to me that it has a lot of problems.
Ah the futilities of arguments between us techie types:)
Your top point is language independence. This sounds great; what are the actual benefits of this?
Well, as I mentioned in a previous post - imagine being able to use C#/J#/C++ for the majority of your project, then dropping into Perl.NET for processing complex documents. Not everything is going to use XML, however cool it is:)
Porting the bytecodes to another platform should be easier since there is only one set of instructions to implement, but I suspect that Microsoft will do something to make sure the bytecodes don't run on non-Windows platforms. Otherwise how are they going to make money? Time will tell on this one.
Microsoft are standardizing large parts (the whole lot?? somebody??) of.NET - ISO/ECMA standardization from what I've read here which, to me at least, seems to indicate they have some intention of keeping things 'down the line' so to speak.
Another advantage would be the ability to open code written in one language and use another language to make edits. I have my doubts about this as well, since most people choose to use a language based on what other languages cannot do. Wouldn't code written in one language violate rules of other languages? Maybe someone who has worked with.Net can enlighten me.
Not totally sure what you mean with the 'rule violation' statement, but I think I see where you're coming from. Sort of like using Delphi for bit twiddling: possible, but not as nice to read as C bit twiddling:P (This is subjective, don't whine Delphi-lovers) Well, that's where I imagine the ability to use different language for the same program would be of great use. Sure, some languages can't do certain things. So use another language to do it. With.NET, you can do it in the same program and avoid hack-arounds.
Your second assertion regarding platform independence is puzzling. Java is already quite a bit more platform independent then.Net, and right now it has the support of companies like IBM that actually care about platform independence, rather than companies like Microsoft that thinks "platform" and "Windows" are synonymous.
I said "Potentially" platform independant..NET is young compared to Java (by about six or seven years). Give it time.
Your third assertion is difficult to support since the only benchmark I know of that compared the two was commissioned by Microsoft.
I concede I probably jumped the gun a bit here. On my system, at least, smaller.NET apps tend to run faster than similar sized Java projects. The simple act of opening a file dialog with Java's Swing toolkit takes a relative eternity. Don't get me wrong, I'm not basing my entire opinion of Java on a file dialog - I have been developing with Java for six years - but.NET just seems so much smoother - from both a development and a runtime perspective.
There is a Java compiler and IDE plugin (for Visual Studio) for.NET. What's your point?.NET's architecture itself is language independant. If I wanted to write a LISP interpreter in.NET (god forbid), I can do so in any.NET-supported language without first having to write that language in Java.
No it's not. Not as much as Java. Looking at the way MS treated Java (changing the core java.* libraries) I doubt it ever will be.
Look. As I said, not yet, but at least it's being standardized.
You'll have to excuse me for looking at MS's track record to gauge their future conduct instead of fairy-tale hype told to managers to try to persuade them to buy.
I've heard no such hype myself, although I am aware of it, and I'm not a manager. Nor do I avidly wave little flags saying "Yay Microsoft". Fact is I've used.NET and I like it. Sure, it's not Java yet, but Java is eight years old.
No it doesn't.
Okay, so let me get this straight. You're saying, "No it doesn't..."
As far as I can tell, MS really doesn't want to benchmark this at all. There have been no C# vs anything benchmarks. Not even the falsified for the public kind.
"... but there's no proof, so I can't back that up..."
There have been benchmarks of 2.5 Tier.Net web applications against broken, obfiscated J2EE implementations though.
"... but what proof there is is old..."
They tend to suggest that you can use 10x the LOC and still only be 2x slower. Sounds to me like Java cat run 5x more code per clock.
"... but I'll guess at how fast Java is anyway..."
I don't doubt the UI will be faster for.Net when you write a GUI. No faster than SWT, but faster than Swing by some ammount.
"... hell, I'll even comment about how fast Windows Forms is compared to AWT based on the old, server-side application comparison."
Quite a mouthful.
.Net programs will start faster because it will be loaded at boot time like explorer(22M).
Great. So.NET starts fast, but is obviously much too bloated...
Java will have this capability, and shared VM capability soon though, and most of my Java programs, with the VM, only use 11-14M of RAM.
... but when Java does the same thing you won't complain?
Yeah on the surface it looks similar, but then there's little additions here and there... most notably, properties:// SomeDude.cs
public class SomeDude
{
public string Name
{
get { return Name; }
set { Name = value; }
}
public SomeDude( string Name )
{// calls this.Name.set( Name )
this.Name = Name;
}
}// end
and enumerations (something I felt Java sorely missed - having to write "public static final int" for every field in an enumeration is pretty ridiculous):// SomeDude.cs
public class SomeDude
{
public enum Gender
{
GUY_DUDE,// == 0
GAL_DUDE// == 1
}
private Gender gender;
public SomeDude( Gender gender )
{
this.gender = gender;
}
public static void Main( string[] args )
{
new SomeDude( SomeDude.Gender.GUY_DUDE );
}
}// end
Hope this helps clarify.
Tom L
You make an excellent point, one that I was trying to get at in an earlier post:.NET suffers an identity crisis (read "marketing bungle") that leaves management, amongst others, scratching their heads and wondering what exactly this whole.NET thing is.
I think this problem may also have to do with the fact that.NET is used collectively to describe several technologies produced by Microsoft that all integrate at a certain level. Thus, several technologies + one name for them all leads to an understandable confusion. At the same time, it's hard to seperate all the components of.NET (the framework, the CLR, the languages) because they're all so tightly integrated.
Is it a framework?
Yes. Well, there's the ".NET Framework" - but the framework itself isn't.NET.
A language?
No, but it provides a common runtime for programs that is language independant: the CLR ('common language runtime' funnily enough)
A methodology?
Um...
An idealogy?
I can think of two responses to this:
1) MS wishes.
OR
2) The "Develop Web Applications, You Fool!" ideology
Can you buy.NET in a box?
Portions of it. Or you can download the runtime, or the developer setup which even provides a C# compiler for you. I have Visual C++.NET Standard, Visual C#.NET Standard and Visual Studio.NET academic sitting here beside me. So I guess it kinda comes in boxes:)
Can you eat with spam? I do not like it, Sam I Am!
LOL - awesome:)
It's a shame so many people are taking this "oh god don't lock us in" stance. To me, and people will disagree with this,.NET is the Sun/Java 'write once, run anywhere' concept done right because it's:
- Language Independant (although I would agree that C# seems best suited to it for me) - Potentially Platform Independant (not yet, maybe not soon, but possible - well done to the Mono team) - Generally runs faster than Java on Windows ('big surprise' you say - but see how Mono goes)
This isn't even mentioning the fact that developers can gather together to work on a software project using.NET, and can contribute regardless of their language of choice.
Naturally there's barriers to such a thing actually happenning. For example, imagine reading the source code to a large project developed in such a manner: where My.Namespace.Person is written in C#, My.Namespace.BusDriver is written in J#, My.Namespace.BusinessManager is written in VB.NET and My.Namespace.HospitalityManager is written in Managed C++. In such a scenario, Person would be the base class of BusDriver and BusinessManager, and HospitalityManager would be derived from BusinessManager.
Thus to understand that relatively small section of a project (four classes!) you need to know four separate languages. Obviously, a good design will save a person from having to do such a thing. Unfortunately, good designs are hard to come by. Harder still is following a good design to the letter. Although you can argue otherwise, the fact of the matter is that we haven't yet perfected the art/science of software engineering at its current level of complexity - why make it more complex?
That said, there's nothing to stop you from developing with, for example, C# as your main language then using Python or Perl for handling complex text files.
As previously stated, so far as I'm aware there's no more 'lock-in' to.NET than there is to other Microsoft (and indeed some non-Microsoft) software. I've spoken to various companies here in Australia and few of them are even thinking about installing the.NET CLR on their Windows systems - let alone their servers.
I think the biggest problem with.NET for managers is a lack of understanding..NET has a bit of an identity crisis in that it seems hard to define what it is in layman terms, and the technical terms tend to evolve from simple two-line explanations into long, drawn-out descriptions of the CLR and assemblies.
It's a simple concept that I feel is hard to convey. How do others feel regarding this?
I don't think it's so much the popularity of the program (IIS/MS-SQL/etc) itself, but with the infamy of the vendor amongst the hacker/cracker community.
Taking on the shroud of a hacker/cracker mindset, which would be the more exhilarating experience to you?
* Humiliating a big company who has poured truckloads of money into a piece of software
or
* Humiliating the guys around the corner who work on top notch software for free in their spare time?
If I had pointy horns and an Anti-MS cracker pitchfork, I know which one I'd prefer to target.
If there's software I want within an affordable range for me (as a student), I'll buy it (Visual C++.NET & Visual C#.NET to name two). If there's student editions, I'll buy them too.
Otherwise, I'll download it off the Internet.
Am I a criminal because I pay for what I can afford, but download ('pirate' some might say) what I can't afford and thus wouldn't buy anyway?
In the eyes of federal/state laws: of course I am.
It's my responsibility to understand my country's laws. Even if they don't make any sense.
And it seems to me, your stack got hacked By a buffer overflow. You're never fixed by patches, 'Cause you still free() twice. And I would try not to install you, If I had another choice. cvs diff you now, And hope they don't get r00t.
As opposed to the police force, which rummages through garbage in hopes of scoring evidence according to a recent/. article I can't seem to find right now:P
# #... [more configuration crap] # # end httpd.conf
I imagine you could do something similar to deny access to.bak files generated by Access. Not that you would be using Apache in Windows, when there's that IIS thing:D
Slashdot Mirror
Thankfully I live in Seattle so maybe I can collect an easy $500 before Microsoft guts the current law.
But think of all the free penis enlargers you'll be missing out on!
That was awesome, when's the next episode????? :D
what the hell?
... and as a result I'm short two fingers and a big toe
I was not basing my comparison of the GUI speed on server side benchmarks. The Windows API is not object oriented or even good.
Where the hell did I mention the Windows API? If you're talking about Windows Forms, it is a part of the .NET framework. See? To clarify, it IS object oriented and, however subjective this statement may be, it IS good.
Even if I was talking about the Windows API, I'm still not entirely sure of what you're on about. Passing IDs? You mean handles? Yeah it's not object oriented - it doesn't have to be, it's written in C: a procedural language. I suppose the Linux Kernel developers must really suck in your eyes, 'cause they're not OOP monkeys.
And if you want to talk about wasting programmer time, compare the time it takes to implement a simple tree control in Swing compared to the time it takes to implement something similar in Windows Forms. That's FORMS, not API.
This is a compounded advantage compared to Swing with the current state of JITC. When JITC is as good as C compilers, Swing will be faster than native widgets because of the ability to inline function calls of the API.
Yeah, Java code will get faster as the Java JITC gets better, but so will .NET code as the .NET just-in-time compilation improves. I've heard (but can't substantiate at this moment in time) that when you install the .NET framework, the code is actually compiled from MSIL to native code (as in, native code not bytecodes that are then JITC at runtime) to a certain degree. How can Java possibly compete with this? Of course, this may very well be a 'windows-only' thing.
But faster than native widgets? I very, very much doubt it - but we'll see.
On the general speed of Java verses CLI, I only admit my findings as some evidence since there is no real good evidence. Sure my evidence is flawed, but I stated it out right so as to not decieve anyone. I didn't make an unsupported claim like you did.
You're right, my bad. My claim was unsupported. However I do know that on my system, it takes an eternity for simple things like a Swing JFileDialog to appear.
I didn't intend to mislead or deceive anyone. It was a mistake, I admitted it in a previous post, I'm admitting it now.
I don't care about ISO/ANSI/ECMA standards because by and large they mean less than I've seen from Java. There are few, if any, C++ compilers that are up to spec. Even if they were, the standard class library is too little to be usefull. There are standard text based IO streams, but you have to use some third party library for anything else you need or write your own. The end cost for developing C/C++ programs is much greater than Java because of this. These third party libraries can't really be taught in school because there are usually 3-8 different competing libraries that are all considered on equal footing in the marketplace.
There's a lot that isn't taught in schools.
Comparing Java to C/C++ is a waste of time. Yes, Java is easier to program with. No, it can't do everything. Live with it. As for cost, it really depends on the sort of application.
Boost adds a lot of functionality to the standard C++ library - not nearly as much functionality as the Java runtime, but then it's not quite so high level either. As I said, you're barking up the wrong tree.
What language do you think is used for low level native Java methods?
Java changes quicker than C/C++ because it's not an ECMA standard.
I don't know about you, but Java changing a lot says to me that it has a lot of problems.
Ah the futilities of arguments between us techie types :)
Hi GF,
Your top point is language independence. This sounds great; what are the actual benefits of this?
Well, as I mentioned in a previous post - imagine being able to use C#/J#/C++ for the majority of your project, then dropping into Perl.NET for processing complex documents. Not everything is going to use XML, however cool it is :)
Porting the bytecodes to another platform should be easier since there is only one set of instructions to implement, but I suspect that Microsoft will do something to make sure the bytecodes don't run on non-Windows platforms. Otherwise how are they going to make money? Time will tell on this one.
Microsoft are standardizing large parts (the whole lot?? somebody??) of .NET - ISO/ECMA standardization from what I've read here which, to me at least, seems to indicate they have some intention of keeping things 'down the line' so to speak.
Another advantage would be the ability to open code written in one language and use another language to make edits. I have my doubts about this as well, since most people choose to use a language based on what other languages cannot do. Wouldn't code written in one language violate rules of other languages? Maybe someone who has worked with .Net can enlighten me.
Not totally sure what you mean with the 'rule violation' statement, but I think I see where you're coming from. Sort of like using Delphi for bit twiddling: possible, but not as nice to read as C bit twiddling :P (This is subjective, don't whine Delphi-lovers) Well, that's where I imagine the ability to use different language for the same program would be of great use. Sure, some languages can't do certain things. So use another language to do it. With .NET, you can do it in the same program and avoid hack-arounds.
Your second assertion regarding platform independence is puzzling. Java is already quite a bit more platform independent then .Net, and right now it has the support of companies like IBM that actually care about platform independence, rather than companies like Microsoft that thinks "platform" and "Windows" are synonymous.
I said "Potentially" platform independant. .NET is young compared to Java (by about six or seven years). Give it time.
Your third assertion is difficult to support since the only benchmark I know of that compared the two was commissioned by Microsoft.
I concede I probably jumped the gun a bit here. On my system, at least, smaller .NET apps tend to run faster than similar sized Java projects. The simple act of opening a file dialog with Java's Swing toolkit takes a relative eternity. Don't get me wrong, I'm not basing my entire opinion of Java on a file dialog - I have been developing with Java for six years - but .NET just seems so much smoother - from both a development and a runtime perspective.
Oh really?
Yeah, really.
There are even LISP compilers for Java....
There is a Java compiler and IDE plugin (for Visual Studio) for .NET. What's your point? .NET's architecture itself is language independant. If I wanted to write a LISP interpreter in .NET (god forbid), I can do so in any .NET-supported language without first having to write that language in Java.
No it's not. Not as much as Java. Looking at the way MS treated Java (changing the core java.* libraries) I doubt it ever will be.
Look. As I said, not yet, but at least it's being standardized.
You'll have to excuse me for looking at MS's track record to gauge their future conduct instead of fairy-tale hype told to managers to try to persuade them to buy.
I've heard no such hype myself, although I am aware of it, and I'm not a manager. Nor do I avidly wave little flags saying "Yay Microsoft". Fact is I've used .NET and I like it. Sure, it's not Java yet, but Java is eight years old.
No it doesn't.
Okay, so let me get this straight. You're saying, "No it doesn't ..."
As far as I can tell, MS really doesn't want to benchmark this at all. There have been no C# vs anything benchmarks. Not even the falsified for the public kind.
"... but there's no proof, so I can't back that up ..."
There have been benchmarks of 2.5 Tier .Net web applications against broken, obfiscated J2EE implementations though.
"... but what proof there is is old ..."
They tend to suggest that you can use 10x the LOC and still only be 2x slower. Sounds to me like Java cat run 5x more code per clock.
"... but I'll guess at how fast Java is anyway ..."
I don't doubt the UI will be faster for .Net when you write a GUI. No faster than SWT, but faster than Swing by some ammount.
"... hell, I'll even comment about how fast Windows Forms is compared to AWT based on the old, server-side application comparison."
Quite a mouthful.
Great. So .NET starts fast, but is obviously much too bloated ...
Java will have this capability, and shared VM capability soon though, and most of my Java programs, with the VM, only use 11-14M of RAM.
... but when Java does the same thing you won't complain?
Yeah on the surface it looks similar, but then there's little additions here and there ... most notably, properties: // SomeDude.cs
public class SomeDude
{
public string Name
{
get { return Name; }
set { Name = value; }
}
public SomeDude( string Name )
{ // calls this.Name.set( Name )
this.Name = Name;
}
} // end
and enumerations (something I felt Java sorely missed - having to write "public static final int" for every field in an enumeration is pretty ridiculous): // SomeDude.cs
public class SomeDude
{
public enum Gender
{
GUY_DUDE, // == 0
GAL_DUDE // == 1
}
private Gender gender;
public SomeDude( Gender gender )
{
this.gender = gender;
}
public static void Main( string[] args )
{
new SomeDude( SomeDude.Gender.GUY_DUDE );
}
} // end
Hope this helps clarify.
Tom L
You make an excellent point, one that I was trying to get at in an earlier post: .NET suffers an identity crisis (read "marketing bungle") that leaves management, amongst others, scratching their heads and wondering what exactly this whole .NET thing is.
I think this problem may also have to do with the fact that .NET is used collectively to describe several technologies produced by Microsoft that all integrate at a certain level. Thus, several technologies + one name for them all leads to an understandable confusion. At the same time, it's hard to seperate all the components of .NET (the framework, the CLR, the languages) because they're all so tightly integrated.
Is it a framework?
Yes. Well, there's the ".NET Framework" - but the framework itself isn't .NET.
A language?
No, but it provides a common runtime for programs that is language independant: the CLR ('common language runtime' funnily enough)
A methodology?
Um ...
An idealogy?
I can think of two responses to this:
1) MS wishes.
OR
2) The "Develop Web Applications, You Fool!" ideology
Can you buy .NET in a box?
Portions of it. Or you can download the runtime, or the developer setup which even provides a C# compiler for you. I have Visual C++ .NET Standard, Visual C# .NET Standard and Visual Studio .NET academic sitting here beside me. So I guess it kinda comes in boxes :)
Can you eat with spam? I do not like it, Sam I Am!
LOL - awesome :)
It's a shame so many people are taking this "oh god don't lock us in" stance. To me, and people will disagree with this, .NET is the Sun/Java 'write once, run anywhere' concept done right because it's:
.NET, and can contribute regardless of their language of choice.
.NET than there is to other Microsoft (and indeed some non-Microsoft) software. I've spoken to various companies here in Australia and few of them are even thinking about installing the .NET CLR on their Windows systems - let alone their servers.
.NET for managers is a lack of understanding. .NET has a bit of an identity crisis in that it seems hard to define what it is in layman terms, and the technical terms tend to evolve from simple two-line explanations into long, drawn-out descriptions of the CLR and assemblies.
:)
- Language Independant (although I would agree that C# seems best suited to it for me)
- Potentially Platform Independant (not yet, maybe not soon, but possible - well done to the Mono team)
- Generally runs faster than Java on Windows ('big surprise' you say - but see how Mono goes)
This isn't even mentioning the fact that developers can gather together to work on a software project using
Naturally there's barriers to such a thing actually happenning. For example, imagine reading the source code to a large project developed in such a manner: where My.Namespace.Person is written in C#, My.Namespace.BusDriver is written in J#, My.Namespace.BusinessManager is written in VB.NET and My.Namespace.HospitalityManager is written in Managed C++. In such a scenario, Person would be the base class of BusDriver and BusinessManager, and HospitalityManager would be derived from BusinessManager.
Thus to understand that relatively small section of a project (four classes!) you need to know four separate languages. Obviously, a good design will save a person from having to do such a thing. Unfortunately, good designs are hard to come by. Harder still is following a good design to the letter. Although you can argue otherwise, the fact of the matter is that we haven't yet perfected the art/science of software engineering at its current level of complexity - why make it more complex?
That said, there's nothing to stop you from developing with, for example, C# as your main language then using Python or Perl for handling complex text files.
As previously stated, so far as I'm aware there's no more 'lock-in' to
I think the biggest problem with
It's a simple concept that I feel is hard to convey. How do others feel regarding this?
Anyway I'm rambling now. Outies
Tom L
I don't think it's so much the popularity of the program (IIS/MS-SQL/etc) itself, but with the infamy of the vendor amongst the hacker/cracker community.
Taking on the shroud of a hacker/cracker mindset, which would be the more exhilarating experience to you?
* Humiliating a big company who has poured truckloads of money into a piece of software
or
* Humiliating the guys around the corner who work on top notch software for free in their spare time?
If I had pointy horns and an Anti-MS cracker pitchfork, I know which one I'd prefer to target.
True to a degree.
.NET & Visual C# .NET to name two). If there's student editions, I'll buy them too.
If there's software I want within an affordable range for me (as a student), I'll buy it (Visual C++
Otherwise, I'll download it off the Internet.
Am I a criminal because I pay for what I can afford, but download ('pirate' some might say) what I can't afford and thus wouldn't buy anyway?
In the eyes of federal/state laws: of course I am.
It's my responsibility to understand my country's laws. Even if they don't make any sense.
ana.mil
... my brain would print in technicolour and be abnormally spotted.
And it seems to me, your stack got hacked
By a buffer overflow.
You're never fixed by patches,
'Cause you still free() twice.
And I would try not to install you,
If I had another choice.
cvs diff you now,
And hope they don't get r00t.
Just found the news article, still no luck with the story on slashdot
As opposed to the police force, which rummages through garbage in hopes of scoring evidence according to a recent /. article I can't seem to find right now :P
... I'd say, "What's Linux?"
- Tom L
If you REALLY must use .inc, for whatever reason, then (for Apache 1.3/2):
... [other configuration crap]
.php .inc
... [more configuration crap]
.bak files generated by Access. Not that you would be using Apache in Windows, when there's that IIS thing :D
# begin httpd.conf
#
#
#
# treat *.inc the same as *.php and life will
# be fuzzy and warm
AddType application/x-httpd-php
AddType application/x-httpd-php
#
#
#
# end httpd.conf
I imagine you could do something similar to deny access to
I Can't Believe It's Not Buffer!