LOL. I admit it was a troll, but I feel I should point out I am not a limey.
My comment was not directed at you personally, but at citizen^H^H^H^H^H^Honsumers of the USA in general, who tend, on average, to be a bit less knowledgeable about other regions of the planet (geopolitical distribution of oil reserves excepted).
Interesting. I would have expected that "national security" is one of the few places where 'random' poking around, following up idle speculations etc. is absolutely worth doing, because you might uncover something important.
I can see this might be a problem in the USA though. In mosts countries, the secret services have nothing to do with law enforcement so a spook coming across a record that showed minor suspicous (in a criminal sense) behaviour, as long as it has no national security implications, would just ignore it. Unfortunately, in the USA, the agency likely to be doing the (illegal) snooping is the one and the only FBI, it means that (1) the national security has its hands tied by being constrained by procedures designed for ordinary criminals, and (2) procedures that ought to be use ONLY for serious national security (eg echelon?, unauthorized wiretaps etc) get misappropriated for urban law enforcement.
Maybe, just maybe, in a hospital database I would agree. But there are many fields where you would want people to notice and flag suspicous looking records.
Even in the hospital example, what would you do if the office worker noticed something was wrong? Say, there was an obvious typo or something like that, potentially serious if nobody notices. Do you want the worker to be afraid of reporting it?
While I can see the obvious abuse, poking around stuff that you wern't specifically told to poke is the stuff of legends, it would be a shame if society evolved into a "no permission means no look, no touch" attitude.
Sure, I can see that honeytokens can (and are - after all its just a version of the old 'put a marked note in the safe' trick that has been used in one form or another probably forever) be really useful - but it isn't a replacement for TRUST. I wouldn't want to see this applied universally, especially on public networks.
Forked from 386BSD, which predates Linux. History would have been different, but it was railroad time--someone would have built one.
Exactly. But think about how different it would be, especially with the arguments that go on today with binary modules, or misappropriating free software into proprietary software. I'm not sure whether it would be better or worse - worse probably since the BSD license is more open to abuse IMHO.
Jeez, when did I say that Linus and others were incapable of writing their own shell?
Of course they were, but the point is (1) a complete set of userspace tools is a huge amount of code, far more than a basic kernel (I'm talking about Linux 1.0 here, not what Linux has since turned into), and (2) such tools already existed, and were freely available.
Sure, Linus could have started out reinventing gcc, and then gone on to write a shell, file utilities, etc etc etc, to accompany his kernel. But there is a reason why he didn't do this. Isn't it rather obvious why?
No, it is probably true. Linus wrote a kernel because that is all he needed to write: the GNU user-space tools (bash, gcc etc) were already there. Without GNU, what use is a Kernel? (Okay, nowdays there is much more free/open software, and there is the BSD user-space, but that didn't exist or was not available when Linux was first written.)
Now, perhaps FreeBSD or some other system would have hit the big time instead, if Linux had never been created. But history would have been very different, especially if said OS used something other than the GPL.
I think you misinterpret slightly. He made many other comments disparaging of BillG, such as
"The reason why it was not used for personal computers was not a technical one, it was a political one."
Also
But the dream was shattered in 1989 when the United States threatened to designate TRON as an unfair trade barrier under its Super 301 trade law when it learned of plans by the Japanese government to use the software for computers in schools.
...
Sakamura said he was puzzled by the initial U.S. move and disappointed at the reaction of Japanese firms.
So, as an engineer he was disappointed and puzzled as to why his technically better, and free, OS was treated with so much hostility by the Americans. From MS, up to the US government risking a trade dispute in order to block it. And the Japanese firms went where the money was and followed MS.
Perhaps his comment on Gates is instead a gentle dig at the American religion of capitalism?
Hehe yeah the same thing happens in the Netherlands - especially Amsterdam. I think any self-respecting American tourist must get very embarrased seeing their countrymen making fools of themselves in foreign countries.
Not that I've ever met a self-respecting American of course:-)
It is many years since I did any programming on Windows. My question would be, how well does mingw integrate with the Windows? Can you compile MFC apps with it? COM? Exceptions?
By "they", you really mean "the rest of the industry":-)
Whatever the terminology, the ABI is the spec you need to get static linking interoperability, using some language. There are obviously lots of different levels to this. At the lowest level, the hardware vendor (not even the OS writers) needs to specify, eg the alignment restrictions and floating point formats. If you are an assembly programmer and you don't need any syscalls, then this is as much as you need. Then, if you are interested in making system calls from assembly language, you need some more of the ABI, where it is specified by the OS designers how to make a system call. If you want to call C library functions, you need a bit more. And if you are using C++, you need more still. The OS-defined part of the ABI is a very minimal document though[*]. Anything beyond making syscalls from assembly language is pure user-space, and is usually determined by the compiler/library authors, not the OS authors.
In the contexts where I have seen it used, the term "Object model" refers not so much to the low-level layout in memory, but rather to the language capabilities, eg whether it supports multiple inheritence (.NET managed environemt does not, IIRC), covariant return types, virtual base classes, etc etc. In other words, the ABI specifies the data structures that implement the object model. So, C++ has an object model, which is slightly different to that of Eiffel, which is again different to that of Smalltalk. This is important, because there are some things in the MS ABI (and the old g++ ABI, and the Sun ABI, etc etc) that mean that it is not actually possible to implement a fully ISO-conformant C++ object model. Additionally, the object model of COM is different to that of C++ (no implementation inheritance), but on the Windows platform they use the same ABI. This of course puts a lot of constraints on the C++ implementation.
The point is though, the Microsoft ABI (as THEY define it, not me) includes such things as an object layout compatible with COM, name mangling conventions, and other things that affect the object model. eg, another long-time problem with the MS compiler is the lack of covariant return types. IIRC, this is due to problems with the ABI which MS were very slow in fixing (if indeed they are fixed yet!). I remember using the borland compiler in around 1994 I think, and it had covariant return types; presumably this was at the expense of ABI compatability - I don't recall but there was probably an option to disable it.
The low-level parts of the ABI ("OS ABI", as you call it, although it must include some hardware-vendor supplied stuff too) is not the problem. There are, and always have been, heaps of x86 compilers that will run on a x86 windows machine (g++ and cygwin or mingwin, DOS compilers, etc). The issue is obtaining compatability with the full ABI. That is really what it means to say that a compiler targets the "Windows Platform". And my original argument still stands: I claim that it is harder to achieve this on Windows than it is for most other platforms, mostly due (directly or indirectly) to actions from Microsoft themselves.
[*] If is a bit different on Windows, because there are quite high level interfaces to the operating system (eg, COM). Indeed, this is one of the things that makes using the MS ABI so hard.
No, all of these things are part of the C++ ABI. Your comment is a bit silly, what would be the point of following an ABI if it didn't give you static linking compatability? (C++ features are not part of the C ABI of course, perhaps that is where the confusion is coming from?) The primary purpose of an ABI is to get static linking between different compilers. That must be at least partially language-dependent.
Some examples:
See here for some info on the common C++ ABI for g++. I think everything discussed on this thread (including vtable layout) is mentioned as part of this ABI.
The Macintosh ABI covers:
The PowerPC ABI,
Structure Alignment and Bit Field Layout,
Name Mangling,
Class Object and V-Table Layout,
RTTI,
Exception Handling,
Special C++ Calling Conventions
The C++ ABI includes the C ABI. In addition, it involves the following features:
layout of hierarchical class objects, i.e., base classes, virtual base classes
layout of pointer-to-member
passing of hidden function parameters (e.g. this)
how to call a virtual function
vtable contents and layout
location in objects of pointers to vtables
finding adjustment for the this pointer
finding base-class offsets
calling a function via pointer-to-member
managing template instances
external spelling of names ("name mangling")
construction and destruction of static objects
throwing and catching exceptions
some details of the standard library
implementation-defined details
typeinfo and run-time type information
inline function access to members
The name-mangling algorithm is part of the ABI, because it defines how a compiler must generate external references and definitions for program entities. If two compilers or compiler versions do not mangle equivalent declarations the same way, a program composed of parts compiled from the two compilers will not link correctly.
Enough said?
Of course, a vendor could choose to follow the C ABI but not the C++ ABI. That would give you the ability to at least call native C functions. But disregarding the platform ABI for any language is not something that a vendor would ever do lightly.
However, I think there is a lot more political diversity in the EU than the USA, because the diverse cultures are (for the most part) localized into their own country, with their own political system, and own head of state. I'll wager that the differences in politics between eg. the UK and France are bigger than between any two states of the USA. And that isn't even bringing the Italians, Greeks or Swedes into the equation!
I don't know enough about EU politics to have an opinion on the 'vocal minority' issue, but I don't think the EU parliament and the USA Federal government are really comparable structures anyway. In my experience, I don't think it applies to any of the national governments within the EU, except possibly UK, Italy (for different reasons!), maybe Germany. The smaller countries tend to have quite representative governments, or at least, if they have sold out to big business, it is not obvious (to me) that they have done so.
I don't think so. Templates, for example, especially function templates, and template-template parameters, change the name-mangling scheme quite considerably. In fact, the reason why there were so many changes in the G++ ABI was because it was not possible to implement the ISO standard with the old one.
Microsoft have other problems which affect standard compliance, for example (maybe fixed now?), in standard C++, 'class' and 'struct' are equivalent, they just have different default access specifiers. But in the MS scheme, they mangle to different names so you cannot interchange 'struct' and 'class' anymore. This is part of the ABI, its a bigger problem than just one compiler. (Sure, a vendor could fix it unilaterally, but a compatability flag would be required to get interoperability with MS headers.)
The ABI also includes such things as how to pass 'this' to member functions, and how to represent pointers to member functions, and all sorts of things that are not in C anyway. The EDG front-end must of course produce C code which is consistent with the C++ ABI, that is (one of) the reason why the intermediate C code produced by the EDG front-end is not portable.
And don't forget that a Windows compiler has to have the same object model that MS specifies, because that is part of the COM specification. Most other platforms don't have such constraints.
The geographical and cultural differences evident in the US span those in any 10 nations,...
Really? I think you had better be more careful with what you say.
Here is 10: Sweden, Estonia, Nepal, Saudi Arabia, Tonga. Heck, I don't need 10, 5 will do.
Are you really trying to say that the USA has more geographical and cultural differences than the span of those 5 countries?
Heck, I would be prepared to bet that there is more cultural diversity in Amsterdam than there is in the USA... Not too much money though, I have not travelled very widely in the USA. I have at least been to the 1 (!) state that has a second official language.;)
Yeah but no one is planning anything nearly that big for C++0x. In fact, any big proposal of the likes of those from 94 to 98 is guaranteed to be shot down in flames this time around.
The 'late' changes to the C++98 standard were almost all beneficial, and it is a significantly better language than that envisaged in 1994. But I think the committee also recognize that the time for rampant additional features without an implementation and without real-world (or even experimental) experience, is over.
I think everyone on the committee is dedicated to having the next standard out in good time. Well, I hope:-)
Porting a compiler to a given platform is not just a matter of re-targetting the assembly or object format. Usually there is a ABI, supplied by the vendor, which specifies such things as calling conventions, sizes of data types, and in the Windows case, it also specifies such things as layout of virtual tables (for COM compatability) and more.
The hard part is not in taking a compiler and getting it to construct Windows executables. The hard part is getting it to cooperate with the existing ABI well enough that you can integrate with the other compilers for the platform. This is much harder to do for Windows than it is for, say, *nix.
In other words, if Microsoft wanted to make it easy to make 3rd party compilers for the Windows platform, then they could have done so. I am claiming that they instead did the opposite, and made it difficult to construct and maintain a 3rd party compiler. I think even Borland would agree with me on this.
Is it Sun's fault that MS doesn't have a VB compiler for Solaris?
No, but in this hypothetical situation, if MS had investigated making a VB compiler for Solaris but gave up because of difficulties imposed by Sun, then some of the blame must go towards Sun.
Funny, I thought functional programming was rather different to OOP.
The joke is, that you can do functional programming in C++, after a fashion, but doesn't use many of the OOP concepts to do it!
For my work, C++ allows a programming style better than OOP: a procedural style based around generic algorithms. See, for example, Andrei Alexandrescu's book for an idea of the possibilities. This style is not available in Java because it requires templates, and last time I saw the proposals to add templates to Java, they were rather crippled anyway and wouldn't give the same functionality.
In this style of programming, virtual functions are only used as a kind of 'single dispatch', when you must to invoke polymorphism at runtime, rather than the more robust and safer compile-time polymorphism. And I find myself wanting multiple dispatch as often as I want single dispatch, for which virtual functions don't suffice anyway.
In other words, if all you see in C++ is a not very pure OOP language, then you have missed all of the exiting parts.
Slashdot Mirror
My comment was not directed at you personally, but at citizen^H^H^H^H^H^Honsumers of the USA in general, who tend, on average, to be a bit less knowledgeable about other regions of the planet (geopolitical distribution of oil reserves excepted).
No need, you are just an ignorant yank. In the English system, one billion is one million million, or 10^12.
I can see this might be a problem in the USA though. In mosts countries, the secret services have nothing to do with law enforcement so a spook coming across a record that showed minor suspicous (in a criminal sense) behaviour, as long as it has no national security implications, would just ignore it. Unfortunately, in the USA, the agency likely to be doing the (illegal) snooping is the one and the only FBI, it means that (1) the national security has its hands tied by being constrained by procedures designed for ordinary criminals, and (2) procedures that ought to be use ONLY for serious national security (eg echelon?, unauthorized wiretaps etc) get misappropriated for urban law enforcement.
Even in the hospital example, what would you do if the office worker noticed something was wrong? Say, there was an obvious typo or something like that, potentially serious if nobody notices. Do you want the worker to be afraid of reporting it?
While I can see the obvious abuse, poking around stuff that you wern't specifically told to poke is the stuff of legends, it would be a shame if society evolved into a "no permission means no look, no touch" attitude.
Sure, I can see that honeytokens can (and are - after all its just a version of the old 'put a marked note in the safe' trick that has been used in one form or another probably forever) be really useful - but it isn't a replacement for TRUST. I wouldn't want to see this applied universally, especially on public networks.
Yeah, but no single person actually had 64MB, did they? DID THEY??
LOL! So tarball hell has just morphed into RPM hell and it isn't really any different nowdays!
Sorry, I'm drunk, nostalgic and depressed at the moment. Ignore this post.
Exactly. But think about how different it would be, especially with the arguments that go on today with binary modules, or misappropriating free software into proprietary software. I'm not sure whether it would be better or worse - worse probably since the BSD license is more open to abuse IMHO.
Of course they were, but the point is (1) a complete set of userspace tools is a huge amount of code, far more than a basic kernel (I'm talking about Linux 1.0 here, not what Linux has since turned into), and (2) such tools already existed, and were freely available.
Sure, Linus could have started out reinventing gcc, and then gone on to write a shell, file utilities, etc etc etc, to accompany his kernel. But there is a reason why he didn't do this. Isn't it rather obvious why?
No, it is probably true. Linus wrote a kernel because that is all he needed to write: the GNU user-space tools (bash, gcc etc) were already there. Without GNU, what use is a Kernel? (Okay, nowdays there is much more free/open software, and there is the BSD user-space, but that didn't exist or was not available when Linux was first written.) Now, perhaps FreeBSD or some other system would have hit the big time instead, if Linux had never been created. But history would have been very different, especially if said OS used something other than the GPL.
"The reason why it was not used for personal computers was not a technical one, it was a political one."
Also
But the dream was shattered in 1989 when the United States threatened to designate TRON as an unfair trade barrier under its Super 301 trade law when it learned of plans by the Japanese government to use the software for computers in schools.
Sakamura said he was puzzled by the initial U.S. move and disappointed at the reaction of Japanese firms.
So, as an engineer he was disappointed and puzzled as to why his technically better, and free, OS was treated with so much hostility by the Americans. From MS, up to the US government risking a trade dispute in order to block it. And the Japanese firms went where the money was and followed MS.
Perhaps his comment on Gates is instead a gentle dig at the American religion of capitalism?
Not that I've ever met a self-respecting American of course :-)
isn't this article a complete ripoff of the first article on this posted to slashdot?
It won't count for anything though, another excuse will be found to avoid lifting the distance restriction.
If you think real life is lacking substance, then you clearly have never been to Amsterdam. ;)
It is many years since I did any programming on Windows. My question would be, how well does mingw integrate with the Windows? Can you compile MFC apps with it? COM? Exceptions?
Whatever the terminology, the ABI is the spec you need to get static linking interoperability, using some language. There are obviously lots of different levels to this. At the lowest level, the hardware vendor (not even the OS writers) needs to specify, eg the alignment restrictions and floating point formats. If you are an assembly programmer and you don't need any syscalls, then this is as much as you need. Then, if you are interested in making system calls from assembly language, you need some more of the ABI, where it is specified by the OS designers how to make a system call. If you want to call C library functions, you need a bit more. And if you are using C++, you need more still. The OS-defined part of the ABI is a very minimal document though[*]. Anything beyond making syscalls from assembly language is pure user-space, and is usually determined by the compiler/library authors, not the OS authors.
In the contexts where I have seen it used, the term "Object model" refers not so much to the low-level layout in memory, but rather to the language capabilities, eg whether it supports multiple inheritence (.NET managed environemt does not, IIRC), covariant return types, virtual base classes, etc etc. In other words, the ABI specifies the data structures that implement the object model. So, C++ has an object model, which is slightly different to that of Eiffel, which is again different to that of Smalltalk. This is important, because there are some things in the MS ABI (and the old g++ ABI, and the Sun ABI, etc etc) that mean that it is not actually possible to implement a fully ISO-conformant C++ object model. Additionally, the object model of COM is different to that of C++ (no implementation inheritance), but on the Windows platform they use the same ABI. This of course puts a lot of constraints on the C++ implementation.
The point is though, the Microsoft ABI (as THEY define it, not me) includes such things as an object layout compatible with COM, name mangling conventions, and other things that affect the object model. eg, another long-time problem with the MS compiler is the lack of covariant return types. IIRC, this is due to problems with the ABI which MS were very slow in fixing (if indeed they are fixed yet!). I remember using the borland compiler in around 1994 I think, and it had covariant return types; presumably this was at the expense of ABI compatability - I don't recall but there was probably an option to disable it.
The low-level parts of the ABI ("OS ABI", as you call it, although it must include some hardware-vendor supplied stuff too) is not the problem. There are, and always have been, heaps of x86 compilers that will run on a x86 windows machine (g++ and cygwin or mingwin, DOS compilers, etc). The issue is obtaining compatability with the full ABI. That is really what it means to say that a compiler targets the "Windows Platform". And my original argument still stands: I claim that it is harder to achieve this on Windows than it is for most other platforms, mostly due (directly or indirectly) to actions from Microsoft themselves.
[*] If is a bit different on Windows, because there are quite high level interfaces to the operating system (eg, COM). Indeed, this is one of the things that makes using the MS ABI so hard.
Some examples:
See here for some info on the common C++ ABI for g++. I think everything discussed on this thread (including vtable layout) is mentioned as part of this ABI.
The Macintosh ABI covers: The PowerPC ABI, Structure Alignment and Bit Field Layout, Name Mangling, Class Object and V-Table Layout, RTTI, Exception Handling, Special C++ Calling Conventions
The Sub C++ ABI covers:
The C++ ABI includes the C ABI. In addition, it involves the following features: layout of hierarchical class objects, i.e., base classes, virtual base classes layout of pointer-to-member passing of hidden function parameters (e.g. this) how to call a virtual function vtable contents and layout location in objects of pointers to vtables finding adjustment for the this pointer finding base-class offsets calling a function via pointer-to-member managing template instances external spelling of names ("name mangling") construction and destruction of static objects throwing and catching exceptions some details of the standard library implementation-defined details typeinfo and run-time type information inline function access to members
The name-mangling algorithm is part of the ABI, because it defines how a compiler must generate external references and definitions for program entities. If two compilers or compiler versions do not mangle equivalent declarations the same way, a program composed of parts compiled from the two compilers will not link correctly.
Enough said?
Of course, a vendor could choose to follow the C ABI but not the C++ ABI. That would give you the ability to at least call native C functions. But disregarding the platform ABI for any language is not something that a vendor would ever do lightly.
However, I think there is a lot more political diversity in the EU than the USA, because the diverse cultures are (for the most part) localized into their own country, with their own political system, and own head of state. I'll wager that the differences in politics between eg. the UK and France are bigger than between any two states of the USA. And that isn't even bringing the Italians, Greeks or Swedes into the equation!
I don't know enough about EU politics to have an opinion on the 'vocal minority' issue, but I don't think the EU parliament and the USA Federal government are really comparable structures anyway. In my experience, I don't think it applies to any of the national governments within the EU, except possibly UK, Italy (for different reasons!), maybe Germany. The smaller countries tend to have quite representative governments, or at least, if they have sold out to big business, it is not obvious (to me) that they have done so.
Microsoft have other problems which affect standard compliance, for example (maybe fixed now?), in standard C++, 'class' and 'struct' are equivalent, they just have different default access specifiers. But in the MS scheme, they mangle to different names so you cannot interchange 'struct' and 'class' anymore. This is part of the ABI, its a bigger problem than just one compiler. (Sure, a vendor could fix it unilaterally, but a compatability flag would be required to get interoperability with MS headers.)
The ABI also includes such things as how to pass 'this' to member functions, and how to represent pointers to member functions, and all sorts of things that are not in C anyway. The EDG front-end must of course produce C code which is consistent with the C++ ABI, that is (one of) the reason why the intermediate C code produced by the EDG front-end is not portable.
And don't forget that a Windows compiler has to have the same object model that MS specifies, because that is part of the COM specification. Most other platforms don't have such constraints.
Really? I think you had better be more careful with what you say.
Here is 10: Sweden, Estonia, Nepal, Saudi Arabia, Tonga. Heck, I don't need 10, 5 will do.
Are you really trying to say that the USA has more geographical and cultural differences than the span of those 5 countries?
Heck, I would be prepared to bet that there is more cultural diversity in Amsterdam than there is in the USA... Not too much money though, I have not travelled very widely in the USA. I have at least been to the 1 (!) state that has a second official language. ;)
The 'late' changes to the C++98 standard were almost all beneficial, and it is a significantly better language than that envisaged in 1994. But I think the committee also recognize that the time for rampant additional features without an implementation and without real-world (or even experimental) experience, is over.
I think everyone on the committee is dedicated to having the next standard out in good time. Well, I hope :-)
The hard part is not in taking a compiler and getting it to construct Windows executables. The hard part is getting it to cooperate with the existing ABI well enough that you can integrate with the other compilers for the platform. This is much harder to do for Windows than it is for, say, *nix.
In other words, if Microsoft wanted to make it easy to make 3rd party compilers for the Windows platform, then they could have done so. I am claiming that they instead did the opposite, and made it difficult to construct and maintain a 3rd party compiler. I think even Borland would agree with me on this.
Is it Sun's fault that MS doesn't have a VB compiler for Solaris?
No, but in this hypothetical situation, if MS had investigated making a VB compiler for Solaris but gave up because of difficulties imposed by Sun, then some of the blame must go towards Sun.
Since when was Java any good for systems programming?
The joke is, that you can do functional programming in C++, after a fashion, but doesn't use many of the OOP concepts to do it!
For my work, C++ allows a programming style better than OOP: a procedural style based around generic algorithms. See, for example, Andrei Alexandrescu's book for an idea of the possibilities. This style is not available in Java because it requires templates, and last time I saw the proposals to add templates to Java, they were rather crippled anyway and wouldn't give the same functionality.
In this style of programming, virtual functions are only used as a kind of 'single dispatch', when you must to invoke polymorphism at runtime, rather than the more robust and safer compile-time polymorphism. And I find myself wanting multiple dispatch as often as I want single dispatch, for which virtual functions don't suffice anyway.
In other words, if all you see in C++ is a not very pure OOP language, then you have missed all of the exiting parts.