Documenting an API carries with it an amount of immutability. The choice of interfaces often fundamentally impacts the nature of possible implementations of systems on both sides of the interface, and making all APIs immutable hampers improvement of the APIs and the implementations of those APIs.
Example:
Suppose an undocumented internal subsystem written by some developer at Microsoft exposes void *Foo() to other internal components.
Now require that this function and its behavior are publicly documented.
Then a third party developer reads the documentation and decides to build a business around making calls to Foo().
Suppose some developers at Microsoft decide that implementations using void *Foo() are inefficient and could be improved by making some more code common, by changing the semantics of Foo and moving some code between internal components.
Now, there are three likely things that could happen next:
The Microsoft developers decide to make an improvement to Windows by changing Foo. The third party developer's software will no longer work with the new version of Foo. Fortunately the new semantics were documented; unfortunately it is going to cost the third party a lot to rework their code to use the new implementation. Maybe they'll sue Microsoft.
The Microsoft developers decide to leave Foo alone because it's documented and they can't change it now. (Nothing can be changed now, because it's all documented.)
The Microsoft developers decide to keep an old version of Foo around and a new version, bloating and complicating the code.
The lesson: if you want to keep the cost of making changes low, don't document the API publicly. That way you can keep the compatibility problems internal.
You could document every single API, but then most of them would need to have a little note along with them: "by the way, don't ever call this API if you want your application to work with future versions of Windows."
Forcing documentation of every API takes away Microsoft's ability to define what Windows is, and what it means for software to be "Windows compatible".
That's a great excerpt that the previous poster pulled.
In the taped deposition, Steve seems a bit doomsday about things, and it's all too easy to dismiss his claims as such. But don't be too quick to judge -- he's pointed out some serious problems if you get down to the technical details.
It sounds like the suing states are envisioning a plan where Microsoft would "own" its source code, but anyone would have access to it and be allowed to replace parts of it. Basically, Windows would turn into a "grab bag" that anyone could grab parts from (paying Microsoft according to what they use) to assemble a platform. At first I considered using "toolkit" to describe what the plaintiffs want Windows to be, but that didn't seem very appropriate given that with a toolkit you generally rely on all of the tools to be present. One of the plaintiffs' goals appears to be to ensure that parts of the "toolkit" can be left out, making it more like a "grab bag" for whoever sets up the system.
Such an outcome seems like it would be a lot of fun for programmers. The value to consumers is debatable. (And we know where Microsoft stands.)
In any case, there are some very important questions that would need to be resolved first! Such as...
What's an interface?
Once we decide what an interface is, which ones need to be public?
Must these interfaces be immutable?
How big is a component allowed to be before it must be broken into subcomponents?
Is it fair to Java programmers to define all of the interfaces in C?;-)
You can really only have an arbitrary answer to the question of what an interface is. Today, for the purpose of Windows programming in C or C++, every programmer pretty much agrees that the interface is set forth in a set of header files for various SDKs, describing (among other things) the signatures for various entry points into DLLs that are part of Windows. Apparently this has been deemed not good enough to reach a settlement.
Do all the interfaces between internal components need to be made public as C and C++ header files? (By "internal components" I mean those components which currently are not documented in the public SDK headers today.) To accurately describe the semantics of these internal interfaces, would certain amounts of the implementation need to be exposed too?
Once these "interfaces" are documented, can Microsoft change them? Steve Ballmer makes a very good point that it is unreasonable to take away Microsoft's latitude to rearchitect its component architecture. Anyone who has sat down to start work on a new programming project can appreciate how difficult it can sometimes be to choose an interface and then leave it the same throughout the entire lifetime of the project -- now imagine that you had to do that with all of your internal interfaces. Sometimes you need to change interfaces, add interfaces, or remove interfaces entirely. Maintaining backwards compatibility with every old interface really turns program into a bunch of hacks and dead code after a few cycles!
It should be fairly evident that exposing every interface between all the components in a hierarchy is not conducive to innovative progress of the software if the interfaces are immutable. This implementation hiding philosophy that a lot of software engineers use today helped to inspire some of the core features in Java and C++.
Basically, in order to innovate at all, Microsoft would have to have the latitude to break compatibility with some (most) interfaces. That's how it works today. The documented interfaces are fixed, and all the other (internal) ones are free to change from release to release.
And as to how the value of Windows would be affected if it were turned into a programmer's grab bag, the only insight I can offer here is that it would be very difficult to provide users with adequate support without dictating which components they'd need to use, but then we'd be right back where we are today. The system requirements listed on software packages would also have to be a lot more fine grained. Individual software packages would be compatible with a smaller number of systems (given that some systems won't have all the components from the "grab bag"). The practice of software verification could be improved theoretically given that interfaces would be better documented, and test stubs could more easily be put in place, but from a practical standpoint, real, live, practical software verification could only be complicated by a proliferation of implementations of the component dependencies.
On the balance, I fail to see how this would make Windows more valuable to your average consumer.
D
(Didn't this all start getting out of hand when someone couldn't delete that "The Internet" icon off their desktop? I seem to recall the government's argument hinging on that at some point. Seems to me that Microsoft could just remove the icon and that'd be the end of it.)
Since you see so much room for improvement in Microsoft's software, maybe you ought to go over there and fix it. I know that isn't politically correct in this community, but it sure is practical. Provided you've got good skillz, it'd be a sure-fire way to get better software to reach a wide audience as quickly as possible.
Basically, you ought to consider looking for work based on where it looks like there's work to be done. Think about it -- if there was a software company with perfect products, they wouldn't need programmers because there'd be no need for any more programming.
When I was at Penn State I noticed that a lot of the CS and Math faculty (at least the ones who talked about MS) seemed to be more or less set against Microsoft. Whether their dislike of Microsoft is well founded or not, it rubs off on students. (Most of the tirades my profs went on about Microsoft software seemed to be more emotionally- than factually-based.)
I don't know how it is at other universities, but it's just a thought. Monkey see monkey do.
Students also ought to check with their university about the availability of some Microsoft development tools. I went to Penn State and we had a site license so any student could obtain a full copy of Visual Studio for free.
It seems that many failures in the computer industry are only about 3degrees from Microsoft.
Is there anything in the computer industry more than 3 degrees from Microsoft?
D
JVM is not language neutral.
on
What is .NET?
·
· Score: 1
If this poster had read the original article more closely, he would have noticed a link to this page, which is the work of someone who actually took the time to closely analyze everything on the list at the site that the poster provided a link to.
A closer inspection of this list at tu-berlin.de reveals that the vast majority of the items listed are not actually claiming to be compilers that produce Java byte-code. They are merely tools or compilers or interpreters written in Java. Of the few which claim to produce Java byte-code, even fewer are actually available for use (some were abandoned before completion) or have any additional information available about them.
A handful of items in the list translate source code from language subsets into Java source code first, which you can then run JAVAC on to build actual byte-code. (For example, Canterbury claims to have such a thing for Pascal, Oberon-2, and Modula-2. There is also one for translating C code to Java code, and Fortran code to Java code. Perhaps the most promising and truly byte-code producing tools on the entire page are the assemblers at the bottom.
It is worth pointing out that this still doesn't make the JVM a language-neutral platform. (Again, see the discussion at http://www.objectwatch.com/issue_33.htm.) While there are ways of producing Java byte-code from other languages, you've still got to write all of your code in whatever single language you choose. For example, there's no good way on the JVM to implement a class in Modula-2 code and derive from it in Pascal code, or throw an exception in C code and catch it in Fortran code. i.e. You've still got to have language affinity on the JVM. Not so on the CLR.
You're not going to find a single language that's got all those features. I won't bother questioning *why* it's so important that you find a langauge that does, but you might consider leveraging technologies such as COM or.NET to create a solution that combines components written in several different languages.
For example, VB and C++ can make a very powerful combo. VB excels at rapid GUI development, and C++ is great for writing multithreaded code and using a wide range of APIs. Your VB and C++ code can work together through a set of COM interfaces. Of course, you might decide that this particular language combo doesn't meet your needs, but this is just an example. (C++ doesn't have automatic garbage collection, for instance, but VB accomplishes something similar to it through its automatic use of AddRef and Release on COM interfaces behind the scenes.)
Hope this helps!
D
Bill Joy should have done some research.
on
Bill Joy's Takes on C#
·
· Score: 2, Insightful
He should have checked out the MSDN docs. He should also have read some security studies or even done his own. Perhaps then he would have realized that the security of the CLR has nothing to do with an arbitrary bit set to mark a block of code as "safe", but rather to do with a type-safety verifier that is completely independent of the compiler and language used to generate the code in question.
C# is not tied to the CLR like Java is tied to the JVM. The CLR (Common Language Runtime) is designed to run IL code, and there are compilers for many different languages besides just C# that can generate IL. That said, it should be clear that the security of a C# program is not derived from the C# compiler. It comes from the CLR, so the security policy is enforced at the IL level, not prior to compilation. (It would be laughable if the security of the CLR was enforced only by the C# compiler rejecting "unsafe" code. I'd just write my own C# compiler that allowed it, or I'd whip out my IL assembler.)
The "unsafe" marking of code occurs only at the source code level. Whether or not code is considered type-safe by the CLR is not determined by an arbitrary flag set by the developer; it's a function of the IL code itself. It needs to be that way, otherwise programs compiled with my evil compiler for my own non-type-safe language would slip through the cracks. Note that even if my IL code is actually type-safe, if the CLR's type-safety verifier can't prove it, it won't be considered type-safe.
That being said, "unsafe" is just a compiler feature. Perhaps Bill Joy would have had nothing to say if Microsoft had decided to use a keyword other than "unsafe", like maybe "dont_generate_an_error_at_compile_time_if_the_cod e_inside_this_block_fails_the_type_safety_check_ev en_though_it_is_going_to_fail_when_the_CLR_tries_t o_run_it_in_a_context_that_requires_type_safety". (Actually you can achieve this if you don't mind adding a #define to your C# source and then running it through a C preprocessor first.)
But why take my word for it? Check out an interesting study into C# and the CLR's security done by some students at Rice University at http://www.owlnet.rice.edu/~jsinger/comp527/propos al.html. They have a lot of detail there about tests they ran, as well as a good paper summing up their results.
As everyone knows, Microsoft sells X-Boxes in the US at less than cost, losing $80 on every sale. The actual cost of each unit is around $380 = 437. It would appear that Microsoft is just not planning on selling the units for less than cost in Europe. As for the remaining 480 - 437 = 43, this would have to be a combination of taxes, shipping, and a fundraiser to cover legal fees for various other company ventures.
Did you ask Microsoft for a source code lisense? They do grant them, you know. Lots of customers have access to the latest source code from MS and actively review it, diffing the versions before and after various fixes to keep MS in line.
I should also state the glaringly obvious, which is that everyone has access to the machine code.
What does a C/C++ compiler really do? It basically just solves bunch of complex allocation and alignment problems required to implement a specification. When you're looking at the machine code, you're seeing the solution to those problems. To reiterate: when you're looking at the machine code, the problem is already solved; you're seeing the raw specification, open for all who have the binaries to see.
Tools like SoftIce, RegMon, and FileMon, or any good debugger for that matter, can all be used to gain a very clear understanding of exactly what the code does.
The biggest benefit you get from having the original source code is that it makes it easier to change the specification, since all you have to do is recompile.
And this brings me back to my original point, which is that the difference between open and closed is fundamentally not a difference in the availability of information.
Open source haven't proven more secure than closed, as the theory about "given enough eyes all bugs are shallow" says.
I agree. One of the reasons this is the case is that the notion that closed source gains security through obscurity is really a myth. "Closed" does not mean that people can't look at the source code. For example, many of Microsoft's large corporate customers, as well as government agencies, and universities, all have access to view Microsoft's source code -- including sources to current versions of Windows, like XP. Some customers have reported bugs to Microsoft after reviewing the code, and then they'll even go and diff the sources between versions to verify that a fix actually solves the problem.
Really the only thing I can see that the "open" model allows for differently is that more people are free to change the code and redistribute it.
My conclusion is that open source does not have any added benefit for locating bugs, since closed source is really not obscure in the first place. If anything, the "open" in open source more appropriately refers to its openness to fragmentation.
I disgree with your interpretation of the data there. Scores do not add up; each service pack of NT is a different product, as is each build of RedHat. Summing up all the vulnerabilities found in the various RedHat builds over the past 5 years does not take into account that the current version may not have all of those vulnerabilities, given that some of the previously known problems have been fixed or otherwise removed. The only remotely meaningful interpretation of the data is to consider known vulnerabilities between current versions of the individual products, which is what the NTBugTraq site attempted to do, after qualifying it.
Also, I hope you realize that Outlook and sendmail are totally different types of software; Outlook is not an SMTP server, and has no real use running on a server.
Try remote desktop just once and you will notice how much more performant it is over netmeeting and VNC. It is actually quite usable even when you're on a 56K modem. Netmeeting and VNC use up so much bandwidth it's almost impossible to use them over a low bandwidth connection. I'm sure you've noticed how annoying it can be trying to move your mouse cursor in a controlled manner with VNC, even when you've got a fast ethernet connection to the remote host -- not so with RDC! RDC is still faster even if you've got it set up to pull down full color depth and audio from the remote host too.
Sure, a lot of the new XP features you mentioned are not of significant corporate benefit. However, there are at least two XP-only features that may end up being very important to corporations:
Remote desktop from XP pro -- allows your users to connect to their computer remotely and continue using their applications where they left off before. Great for VPNing in from home. I personally use this feature a lot. Unfortunately for the employee, this makes it very easy to work on weekends from home, but employers probably won't mind.
Remote assistance. Invaluable feature for IT help desks, especially in large corporations. Saves you hours of painful voice-only walkthroughs that end in a trip to the user's desk anyway. "...ok, right click on Properties, choose the Advanced tab...".
There's no way a foreign government will be able to impose its laws and succeed in prosecuting citizens of a separate sovereign nation under them. A foreign government that wants to pursue such an approach ought to start by suing the people who operate the network infrastructure at the first point of contact into their jurisdiction.
MS's active directory schema does support inetOrgPerson. Just do a schema add.
If you don't feel like adding it yourself, installing Exchange 6.5 will do the schema update for you to add inetOrgPerson, once it is released.
D
Perhaps this is not what it seems...
on
Sklyarov Indicted
·
· Score: 1
This indictment is quite a preposterous scenario -- a foreign company, a foreign citizen, an untested law with the masses crying "unconstitutional" for its stomping on Fair Use and squeltching free speech and stymying legitimate research. The "injured" party is even calling for the indicted's release.
Perhaps the best way to get this law overturned is for the Federal Gov't to press for criminal charges in such a ridiculously overboard and publicized manner as is going on here. This way they generate a high profile case to lure enough public hatred for the DMCA that it makes it that much easier for a court to overturn it. I don't see anyone standing up for the DMCA now but the federal prosecution.
This could be just what we need. Maybe the Feds are on our side now, and just have to play evil for a little longer.
Watch closely for a wink at the camera from a DOJ attorney.
In short, civilization is as hooked on Microsoft as any heroin addict is on their drug.
It is not because the standard is a "Microsoft standard" that we are hooked on it. We are hooked on it because it is just that, a standard.
Microsoft can tell the market exactly what to do, and the market will respond.
Now you are saying that we are not tied down, because someone has the power to move the market at will. I disagree, and your prior argument that we are tied down to the "Microsoft standard" argues that. Microsoft is tied down to it just as much as anyone else. If Microsoft were to make any attempt to change its own standard, it would have to be prepared to replace everything all at the same time, in a scenario much akin to what you described above. The greatest competitors to Microsoft's future products are their past products.
This is merely an exercise in the obvious, isn't it?
it uses the SAME trick as IIS to gain speed - it runs in KERNEL space
IIS does not run in a privileged (a.k.a. "kernel-mode") process. It cannot directly read/write addresses in kernel memory. As an IIS developer at Microsoft for the SMTPSVC who actively debugs IIS every day, I know very well that INETINFO.EXE is a user-mode process.
The source of your confusion may be that IIS threads have SYSTEM tokens, granted from the NT SCM which launches INETINFO.EXE. This, however, does not offer any performance boost, nor does it allow access to kernel memory space. As with any user-mode process, any attempt by an IIS thread to read/write kernel memory results in an access violation, regardless of the thread's access token.
The good performance of IIS's W3SVC is due to its asynchronous architecture that allows its threads to avoid blocking on I/O operations. Thus many I/O operations can be pending concurrently without a bloat in the number of threads, avoiding excessive context switching and VM swapping for extra stack space.
So according to the Sherman Act all this talk of divestiture and behavioral remedies is really just a waste of time, seeing as a maximum penalty for MSFT is a $10 Mil fine. Any ideas on how all these other punishments got cooked up if there is no basis for them in the law?
Slashdot Mirror
This a pretty shortsighted.
Documenting an API carries with it an amount of immutability. The choice of interfaces often fundamentally impacts the nature of possible implementations of systems on both sides of the interface, and making all APIs immutable hampers improvement of the APIs and the implementations of those APIs.
Example:
Now, there are three likely things that could happen next:
The lesson: if you want to keep the cost of making changes low, don't document the API publicly. That way you can keep the compatibility problems internal.
You could document every single API, but then most of them would need to have a little note along with them: "by the way, don't ever call this API if you want your application to work with future versions of Windows."
Forcing documentation of every API takes away Microsoft's ability to define what Windows is, and what it means for software to be "Windows compatible".
D
That's a great excerpt that the previous poster pulled.
In the taped deposition, Steve seems a bit doomsday about things, and it's all too easy to dismiss his claims as such. But don't be too quick to judge -- he's pointed out some serious problems if you get down to the technical details.
It sounds like the suing states are envisioning a plan where Microsoft would "own" its source code, but anyone would have access to it and be allowed to replace parts of it. Basically, Windows would turn into a "grab bag" that anyone could grab parts from (paying Microsoft according to what they use) to assemble a platform. At first I considered using "toolkit" to describe what the plaintiffs want Windows to be, but that didn't seem very appropriate given that with a toolkit you generally rely on all of the tools to be present. One of the plaintiffs' goals appears to be to ensure that parts of the "toolkit" can be left out, making it more like a "grab bag" for whoever sets up the system.
Such an outcome seems like it would be a lot of fun for programmers. The value to consumers is debatable. (And we know where Microsoft stands.)
In any case, there are some very important questions that would need to be resolved first! Such as...
You can really only have an arbitrary answer to the question of what an interface is. Today, for the purpose of Windows programming in C or C++, every programmer pretty much agrees that the interface is set forth in a set of header files for various SDKs, describing (among other things) the signatures for various entry points into DLLs that are part of Windows. Apparently this has been deemed not good enough to reach a settlement.
Do all the interfaces between internal components need to be made public as C and C++ header files? (By "internal components" I mean those components which currently are not documented in the public SDK headers today.) To accurately describe the semantics of these internal interfaces, would certain amounts of the implementation need to be exposed too?
Once these "interfaces" are documented, can Microsoft change them? Steve Ballmer makes a very good point that it is unreasonable to take away Microsoft's latitude to rearchitect its component architecture. Anyone who has sat down to start work on a new programming project can appreciate how difficult it can sometimes be to choose an interface and then leave it the same throughout the entire lifetime of the project -- now imagine that you had to do that with all of your internal interfaces. Sometimes you need to change interfaces, add interfaces, or remove interfaces entirely. Maintaining backwards compatibility with every old interface really turns program into a bunch of hacks and dead code after a few cycles!
It should be fairly evident that exposing every interface between all the components in a hierarchy is not conducive to innovative progress of the software if the interfaces are immutable. This implementation hiding philosophy that a lot of software engineers use today helped to inspire some of the core features in Java and C++.
Basically, in order to innovate at all, Microsoft would have to have the latitude to break compatibility with some (most) interfaces. That's how it works today. The documented interfaces are fixed, and all the other (internal) ones are free to change from release to release.
And as to how the value of Windows would be affected if it were turned into a programmer's grab bag, the only insight I can offer here is that it would be very difficult to provide users with adequate support without dictating which components they'd need to use, but then we'd be right back where we are today. The system requirements listed on software packages would also have to be a lot more fine grained. Individual software packages would be compatible with a smaller number of systems (given that some systems won't have all the components from the "grab bag"). The practice of software verification could be improved theoretically given that interfaces would be better documented, and test stubs could more easily be put in place, but from a practical standpoint, real, live, practical software verification could only be complicated by a proliferation of implementations of the component dependencies.
On the balance, I fail to see how this would make Windows more valuable to your average consumer.
D
(Didn't this all start getting out of hand when someone couldn't delete that "The Internet" icon off their desktop? I seem to recall the government's argument hinging on that at some point. Seems to me that Microsoft could just remove the icon and that'd be the end of it.)
Since you see so much room for improvement in Microsoft's software, maybe you ought to go over there and fix it. I know that isn't politically correct in this community, but it sure is practical. Provided you've got good skillz, it'd be a sure-fire way to get better software to reach a wide audience as quickly as possible.
Basically, you ought to consider looking for work based on where it looks like there's work to be done. Think about it -- if there was a software company with perfect products, they wouldn't need programmers because there'd be no need for any more programming.
D
When I was at Penn State I noticed that a lot of the CS and Math faculty (at least the ones who talked about MS) seemed to be more or less set against Microsoft. Whether their dislike of Microsoft is well founded or not, it rubs off on students. (Most of the tirades my profs went on about Microsoft software seemed to be more emotionally- than factually-based.)
I don't know how it is at other universities, but it's just a thought. Monkey see monkey do.
D
And don't forget about the Platform SDK.
Students also ought to check with their university about the availability of some Microsoft development tools. I went to Penn State and we had a site license so any student could obtain a full copy of Visual Studio for free.
D
This is untrue. I have a DECstation 3000 Model 300LX here under my desk that's based on the AXP architecture and has an Alpha 21064-AA.
I've attempted to install Linux on my DECstation before, but so far I've been blocked by two things:
If anyone else has gotten Linux working under similar circumstances and can offer any help, I'd be happy to hear it.
D
Is there anything in the computer industry more than 3 degrees from Microsoft?
D
If this poster had read the original article more closely, he would have noticed a link to this page, which is the work of someone who actually took the time to closely analyze everything on the list at the site that the poster provided a link to.
A closer inspection of this list at tu-berlin.de reveals that the vast majority of the items listed are not actually claiming to be compilers that produce Java byte-code. They are merely tools or compilers or interpreters written in Java. Of the few which claim to produce Java byte-code, even fewer are actually available for use (some were abandoned before completion) or have any additional information available about them.
A handful of items in the list translate source code from language subsets into Java source code first, which you can then run JAVAC on to build actual byte-code. (For example, Canterbury claims to have such a thing for Pascal, Oberon-2, and Modula-2. There is also one for translating C code to Java code, and Fortran code to Java code. Perhaps the most promising and truly byte-code producing tools on the entire page are the assemblers at the bottom.
It is worth pointing out that this still doesn't make the JVM a language-neutral platform. (Again, see the discussion at http://www.objectwatch.com/issue_33.htm.) While there are ways of producing Java byte-code from other languages, you've still got to write all of your code in whatever single language you choose. For example, there's no good way on the JVM to implement a class in Modula-2 code and derive from it in Pascal code, or throw an exception in C code and catch it in Fortran code. i.e. You've still got to have language affinity on the JVM. Not so on the CLR.
D
You're not going to find a single language that's got all those features. I won't bother questioning *why* it's so important that you find a langauge that does, but you might consider leveraging technologies such as COM or .NET to create a solution that combines components written in several different languages.
For example, VB and C++ can make a very powerful combo. VB excels at rapid GUI development, and C++ is great for writing multithreaded code and using a wide range of APIs. Your VB and C++ code can work together through a set of COM interfaces. Of course, you might decide that this particular language combo doesn't meet your needs, but this is just an example. (C++ doesn't have automatic garbage collection, for instance, but VB accomplishes something similar to it through its automatic use of AddRef and Release on COM interfaces behind the scenes.)
Hope this helps!
D
He should have checked out the MSDN docs. He should also have read some security studies or even done his own. Perhaps then he would have realized that the security of the CLR has nothing to do with an arbitrary bit set to mark a block of code as "safe", but rather to do with a type-safety verifier that is completely independent of the compiler and language used to generate the code in question.
C# is not tied to the CLR like Java is tied to the JVM. The CLR (Common Language Runtime) is designed to run IL code, and there are compilers for many different languages besides just C# that can generate IL. That said, it should be clear that the security of a C# program is not derived from the C# compiler. It comes from the CLR, so the security policy is enforced at the IL level, not prior to compilation. (It would be laughable if the security of the CLR was enforced only by the C# compiler rejecting "unsafe" code. I'd just write my own C# compiler that allowed it, or I'd whip out my IL assembler.)
The "unsafe" marking of code occurs only at the source code level. Whether or not code is considered type-safe by the CLR is not determined by an arbitrary flag set by the developer; it's a function of the IL code itself. It needs to be that way, otherwise programs compiled with my evil compiler for my own non-type-safe language would slip through the cracks. Note that even if my IL code is actually type-safe, if the CLR's type-safety verifier can't prove it, it won't be considered type-safe.
That being said, "unsafe" is just a compiler feature. Perhaps Bill Joy would have had nothing to say if Microsoft had decided to use a keyword other than "unsafe", like maybe "dont_generate_an_error_at_compile_time_if_the_cod e_inside_this_block_fails_the_type_safety_check_ev en_though_it_is_going_to_fail_when_the_CLR_tries_t o_run_it_in_a_context_that_requires_type_safety". (Actually you can achieve this if you don't mind adding a #define to your C# source and then running it through a C preprocessor first.)
But why take my word for it? Check out an interesting study into C# and the CLR's security done by some students at Rice University at http://www.owlnet.rice.edu/~jsinger/comp527/propos al.html. They have a lot of detail there about tests they ran, as well as a good paper summing up their results.
D
As everyone knows, Microsoft sells X-Boxes in the US at less than cost, losing $80 on every sale. The actual cost of each unit is around $380 = 437. It would appear that Microsoft is just not planning on selling the units for less than cost in Europe. As for the remaining 480 - 437 = 43, this would have to be a combination of taxes, shipping, and a fundraiser to cover legal fees for various other company ventures.
D
Did you ask Microsoft for a source code lisense? They do grant them, you know. Lots of customers have access to the latest source code from MS and actively review it, diffing the versions before and after various fixes to keep MS in line.
D
I should also state the glaringly obvious, which is that everyone has access to the machine code.
What does a C/C++ compiler really do? It basically just solves bunch of complex allocation and alignment problems required to implement a specification. When you're looking at the machine code, you're seeing the solution to those problems. To reiterate: when you're looking at the machine code, the problem is already solved; you're seeing the raw specification, open for all who have the binaries to see.
Tools like SoftIce, RegMon, and FileMon, or any good debugger for that matter, can all be used to gain a very clear understanding of exactly what the code does.
Example: Windows Product Activation accurately reverse engineered by some German guys who didn't have the source code.
The biggest benefit you get from having the original source code is that it makes it easier to change the specification, since all you have to do is recompile.
And this brings me back to my original point, which is that the difference between open and closed is fundamentally not a difference in the availability of information.
D
I agree. One of the reasons this is the case is that the notion that closed source gains security through obscurity is really a myth. "Closed" does not mean that people can't look at the source code. For example, many of Microsoft's large corporate customers, as well as government agencies, and universities, all have access to view Microsoft's source code -- including sources to current versions of Windows, like XP. Some customers have reported bugs to Microsoft after reviewing the code, and then they'll even go and diff the sources between versions to verify that a fix actually solves the problem.
Really the only thing I can see that the "open" model allows for differently is that more people are free to change the code and redistribute it.
My conclusion is that open source does not have any added benefit for locating bugs, since closed source is really not obscure in the first place. If anything, the "open" in open source more appropriately refers to its openness to fragmentation.
D
I disgree with your interpretation of the data there. Scores do not add up; each service pack of NT is a different product, as is each build of RedHat. Summing up all the vulnerabilities found in the various RedHat builds over the past 5 years does not take into account that the current version may not have all of those vulnerabilities, given that some of the previously known problems have been fixed or otherwise removed. The only remotely meaningful interpretation of the data is to consider known vulnerabilities between current versions of the individual products, which is what the NTBugTraq site attempted to do, after qualifying it.
Also, I hope you realize that Outlook and sendmail are totally different types of software; Outlook is not an SMTP server, and has no real use running on a server.
D
Try remote desktop just once and you will notice how much more performant it is over netmeeting and VNC. It is actually quite usable even when you're on a 56K modem. Netmeeting and VNC use up so much bandwidth it's almost impossible to use them over a low bandwidth connection. I'm sure you've noticed how annoying it can be trying to move your mouse cursor in a controlled manner with VNC, even when you've got a fast ethernet connection to the remote host -- not so with RDC! RDC is still faster even if you've got it set up to pull down full color depth and audio from the remote host too.
D
...and the first thing they'll probably do is hardcode advertisements into the kernel so I can't turn them off.
Sure, a lot of the new XP features you mentioned are not of significant corporate benefit. However, there are at least two XP-only features that may end up being very important to corporations:
- Remote desktop from XP pro -- allows your users to connect to their computer remotely and continue using their applications where they left off before. Great for VPNing in from home. I personally use this feature a lot. Unfortunately for the employee, this makes it very easy to work on weekends from home, but employers probably won't mind.
- Remote assistance. Invaluable feature for IT help desks, especially in large corporations. Saves you hours of painful voice-only walkthroughs that end in a trip to the user's desk anyway. "...ok, right click on Properties, choose the Advanced tab...".
DThere's no way a foreign government will be able to impose its laws and succeed in prosecuting citizens of a separate sovereign nation under them. A foreign government that wants to pursue such an approach ought to start by suing the people who operate the network infrastructure at the first point of contact into their jurisdiction.
D
Even better, the Whistler AD already includes inetOrgPerson for you. :-)
MS's active directory schema does support inetOrgPerson. Just do a schema add.
If you don't feel like adding it yourself, installing Exchange 6.5 will do the schema update for you to add inetOrgPerson, once it is released.
D
This indictment is quite a preposterous scenario -- a foreign company, a foreign citizen, an untested law with the masses crying "unconstitutional" for its stomping on Fair Use and squeltching free speech and stymying legitimate research. The "injured" party is even calling for the indicted's release.
Perhaps the best way to get this law overturned is for the Federal Gov't to press for criminal charges in such a ridiculously overboard and publicized manner as is going on here. This way they generate a high profile case to lure enough public hatred for the DMCA that it makes it that much easier for a court to overturn it. I don't see anyone standing up for the DMCA now but the federal prosecution.
This could be just what we need. Maybe the Feds are on our side now, and just have to play evil for a little longer.
Watch closely for a wink at the camera from a DOJ attorney.
It is not because the standard is a "Microsoft standard" that we are hooked on it. We are hooked on it because it is just that, a standard.
Now you are saying that we are not tied down, because someone has the power to move the market at will. I disagree, and your prior argument that we are tied down to the "Microsoft standard" argues that. Microsoft is tied down to it just as much as anyone else. If Microsoft were to make any attempt to change its own standard, it would have to be prepared to replace everything all at the same time, in a scenario much akin to what you described above. The greatest competitors to Microsoft's future products are their past products.
This is merely an exercise in the obvious, isn't it?
Are you suggesting something like the following?
Is this a recipe for progress?
IIS does not run in a privileged (a.k.a. "kernel-mode") process. It cannot directly read/write addresses in kernel memory. As an IIS developer at Microsoft for the SMTPSVC who actively debugs IIS every day, I know very well that INETINFO.EXE is a user-mode process.
The source of your confusion may be that IIS threads have SYSTEM tokens, granted from the NT SCM which launches INETINFO.EXE. This, however, does not offer any performance boost, nor does it allow access to kernel memory space. As with any user-mode process, any attempt by an IIS thread to read/write kernel memory results in an access violation, regardless of the thread's access token.
The good performance of IIS's W3SVC is due to its asynchronous architecture that allows its threads to avoid blocking on I/O operations. Thus many I/O operations can be pending concurrently without a bloat in the number of threads, avoiding excessive context switching and VM swapping for extra stack space.
D
So according to the Sherman Act all this talk of divestiture and behavioral remedies is really just a waste of time, seeing as a maximum penalty for MSFT is a $10 Mil fine. Any ideas on how all these other punishments got cooked up if there is no basis for them in the law?