Then maybe, like that troll CyricZ whom I refuse to address directly, you're missing the point - that a common object-based interface between heterogenous languages (not just C/C++, which skraps also seems to be missing) already existed and was applied to Java in J++, showing what Microsoft's inclusive vision for a Java like language was back in 97 (I think it was - that's when I used it).
OK, I agree that many languages eventually connected to COM, and Visual J++ was one of them. I don't think that invalidates my point that COM started as a convention for interoperating between C/C++ programs. If you look at how COM is actually implemented under the hood, it is very C++-like. You have what amounts to a vtable at the center of everything. Sure, several other languages use what amounts to a vtable, but the COM vtable is defined exactly the same as the C++ vtable. If you look at the rules for the ordering of the vtable, it is the same as C++. The ordering rules define how to deal with base class members, multiple inheritance, etc. In C++ those rules are actually defined. In Java and most other OOP languages, those decisions are implementation-dependent.
Another issue is the variety of data types. COM can handle anything C and C++ can handle. The basic inproc method invocation is just the thiscall convention. When you look at out of process method invocation, you'll see that IDL and the standard marshaller can do just about everything C and C++ can do.
When other languages began to interoperate with COM, there was a big problem with supported data types. Few languages are expressive enough to use all of the marshalling options of IDL, and fewer still if you include all possible C/C++ data types.
Some languages had such limited type systems that Microsoft went and intented the "automation" subset (using the OLEAUTOMATION attribute in IDL). This would limit you to the types that a VARIANT could hold. Quite a restriction!
After that, they had the brilliant idea of IDispatch for dynamically typed languages. This thing was just a nightmare.
It's not at all fair to say that you could write a C/C++ program using COM, and "seamlessly" interoperate with, say, a VBScript using COM. Yes, by some definition, they both use COM. But there was no solid abstration. To make it work, you had to know that you were going to be talking down to the automation subset.
You can't look at all of that and say Microsoft planned it all from the beginning. IDispatch, OLEAUTOMATION, and everything? If they planned that from the beginning, it was a horrible plan.
.NET isn't perfect with language interoperability, but it goes a heck of a lot further than COM.
I have never used JDBC, so I can't comment on how similar it may be to ADO. That stuff may very well have been ripped off.
You're as retarded as the grandparent to your post, with his 'COM is basically a convention for interoperating between C/C++ programs'.
My post. Care to back up your use of "retarded" here? What exactly do you disagree with?
COM, at its simplest level, defines:
a mechanism for locating DLLs using registry information
loading those DLLs and obtaining an instance of the class factory
how to call methods on an interface pointer
the IUnknown interface
At its core, that is all that makes up COM. All of the rest came later. Interprocess marshalling, which is the foundation of DCOM, came later.
All of the technologies commonly associated with COM are just services built using COM. ActiveX, DirectX, etc, are all things built using COM. They are not part of COM.
Actually, I was programming Windows when COM was originally developed. Back then it was called OLE. The first version of VB I used was in the 2.x series, IIRC. So, yes, I watched as VBX was replaced with ActiveX.
I was there when ADO was first released. But you are wrong about how that came about. ADO is not a wrapper for ODBC. ADO is built on top of OLEDB, and OLEDB has a compatibility provider that interoperates with ODBC. Unless you had to interoperate with an old ODBC provider, there was no reason to use the ODBC compatibility provider in OLEDB. There was a native SQL Server provider made specifically for OLEDB, that did not rely on ODBC.
ADO.NET is another from-scratch reimplementation. The ADO.NET object model only vaguly resembles the ADO object model. Neither ADO or ADO.NET are based on ODBC! They have compatibility providers that can talk to ODBC if you have a legacy data source that is only available as an ODBC provider.
If you don't understand that basic fact about ADO and ADO.NET, then you obviously haven't been around long.
And yes, I do remember when they came out with Visual J++, but I can't say I've ever had the displeasure of using it.
Sorry, I'm as big a Microsoft fanboy as any, but this is just wrong..NET and COM are completely different. COM is basically a convention for interoperating between C/C++ programs..NET is its own virtual machine and set of languages. ODBC may be similar to JDBC, but that has nothing to do with.NET!.NET uses something called ADO.NET, which is nothing at all like ODBC.
The argument is that his status quo predictions are pointless and are only there to raise his score. In the case of AMD/Intel, he may as well have put "sky will continue to be blue".
These IIS changes are directly in line with Microsoft's.NET architecture. They may sound similar to some Apache features, but that is probably not the driving force behind them.
I have quite a number of years experience with VS6, more specifically VB6[...]
VB6 and VS6 were packaged together, but they were completely different programs! VB6 and all previous versions of VB have their own completely different IDE. The Visual Studio IDE evolved from the Visual C++ series of IDEs. Your comparison is based on a faulty assumption.
I normally put the cursor in a keyword and hit F1 to use the help system. When I do that, it just takes me to the first hit -- which is usually the CE version. It seems to be only when using the index directly that the search hits box comes up.
Re:The biggest annoyance with DevStudio
on
Visual Studio Hacks
·
· Score: 2, Informative
A also agree that it is annoying, but in most cases the documentation is near identical for the CE version. I just use the CE docs unless I have reason to think they are different for some particular function.
Oceanstore is exactly what you described. From the website:
"OceanStore is a global persistent data store designed to scale to billions of users. It provides a consistent, highly-available, and durable storage utility atop an infrastructure comprised of untrusted servers."
Actually, what they meant to say was "HP Invest." Just one letter. Simple mistake, really.
Actually actually, I think it meant to say "HP Invert", as in Rectal-Cranial Inversion, which is what HP has collectively accomplished with moves like this.
Fact: they meant to say "HP Invect" -- that is, to issue invective.
Actual fact: they meant to say "HP Invebt" -- the meaning of which is unknown.
Slashdot Mirror
Everybody say it with me... NUKE-U-LER
OK, I agree that many languages eventually connected to COM, and Visual J++ was one of them. I don't think that invalidates my point that COM started as a convention for interoperating between C/C++ programs. If you look at how COM is actually implemented under the hood, it is very C++-like. You have what amounts to a vtable at the center of everything. Sure, several other languages use what amounts to a vtable, but the COM vtable is defined exactly the same as the C++ vtable. If you look at the rules for the ordering of the vtable, it is the same as C++. The ordering rules define how to deal with base class members, multiple inheritance, etc. In C++ those rules are actually defined. In Java and most other OOP languages, those decisions are implementation-dependent.
Another issue is the variety of data types. COM can handle anything C and C++ can handle. The basic inproc method invocation is just the thiscall convention. When you look at out of process method invocation, you'll see that IDL and the standard marshaller can do just about everything C and C++ can do.
When other languages began to interoperate with COM, there was a big problem with supported data types. Few languages are expressive enough to use all of the marshalling options of IDL, and fewer still if you include all possible C/C++ data types.
Some languages had such limited type systems that Microsoft went and intented the "automation" subset (using the OLEAUTOMATION attribute in IDL). This would limit you to the types that a VARIANT could hold. Quite a restriction!
After that, they had the brilliant idea of IDispatch for dynamically typed languages. This thing was just a nightmare.
It's not at all fair to say that you could write a C/C++ program using COM, and "seamlessly" interoperate with, say, a VBScript using COM. Yes, by some definition, they both use COM. But there was no solid abstration. To make it work, you had to know that you were going to be talking down to the automation subset.
You can't look at all of that and say Microsoft planned it all from the beginning. IDispatch, OLEAUTOMATION, and everything? If they planned that from the beginning, it was a horrible plan.
.NET isn't perfect with language interoperability, but it goes a heck of a lot further than COM.
I have never used JDBC, so I can't comment on how similar it may be to ADO. That stuff may very well have been ripped off.
My post. Care to back up your use of "retarded" here? What exactly do you disagree with?
COM, at its simplest level, defines:
At its core, that is all that makes up COM. All of the rest came later. Interprocess marshalling, which is the foundation of DCOM, came later.
All of the technologies commonly associated with COM are just services built using COM. ActiveX, DirectX, etc, are all things built using COM. They are not part of COM.
I was there when ADO was first released. But you are wrong about how that came about. ADO is not a wrapper for ODBC. ADO is built on top of OLEDB, and OLEDB has a compatibility provider that interoperates with ODBC. Unless you had to interoperate with an old ODBC provider, there was no reason to use the ODBC compatibility provider in OLEDB. There was a native SQL Server provider made specifically for OLEDB, that did not rely on ODBC.
ADO.NET is another from-scratch reimplementation. The ADO.NET object model only vaguly resembles the ADO object model. Neither ADO or ADO.NET are based on ODBC! They have compatibility providers that can talk to ODBC if you have a legacy data source that is only available as an ODBC provider.
If you don't understand that basic fact about ADO and ADO.NET, then you obviously haven't been around long.
And yes, I do remember when they came out with Visual J++, but I can't say I've ever had the displeasure of using it.
Sorry, I'm as big a Microsoft fanboy as any, but this is just wrong. .NET and COM are completely different. COM is basically a convention for interoperating between C/C++ programs. .NET is its own virtual machine and set of languages. ODBC may be similar to JDBC, but that has nothing to do with .NET! .NET uses something called ADO.NET, which is nothing at all like ODBC.
The argument is that his status quo predictions are pointless and are only there to raise his score. In the case of AMD/Intel, he may as well have put "sky will continue to be blue".
Yeah, sometimes I releive stress with "joint research" too.
This is a good idea.
You feel that sting, big boy, huh? That's pride fuckin' with you!
(source)
It's about time. The beta has been out for about a year I think.
Paid editors to approve the article? Voting would work just as well or better.
You're missing the GP's point. If the file is truly random bits, then it isn't a derivative work of anything.
These IIS changes are directly in line with Microsoft's .NET architecture. They may sound similar to some Apache features, but that is probably not the driving force behind them.
Naturally, there is at least one reciprocal benefit to the company -- it is easier to hire good people in a big city.
I normally put the cursor in a keyword and hit F1 to use the help system. When I do that, it just takes me to the first hit -- which is usually the CE version. It seems to be only when using the index directly that the search hits box comes up.
A also agree that it is annoying, but in most cases the documentation is near identical for the CE version. I just use the CE docs unless I have reason to think they are different for some particular function.
Alt+E+F+S. Check the boxes for "match case" and "match whole word". Not quite as accurate but it works the same for 99% of the cases.
Oceanstore is exactly what you described. From the website:
Actually, what they meant to say was "HP Invest." Just one letter. Simple mistake, really.
Actually actually, I think it meant to say "HP Invert", as in Rectal-Cranial Inversion, which is what HP has collectively accomplished with moves like this.
Fact: they meant to say "HP Invect" -- that is, to issue invective.
Actual fact: they meant to say "HP Invebt" -- the meaning of which is unknown.
Actually it would be 4,014,489,600 layers. :)e s+in+one+square+mile)
(http://www.google.com/search?hl=en&q=square+inch
Wires will be shorter. Shorter wires give off less heat.
I have no idea if that compensates for the decrease in surface area.
Hopefully there will be a parallel advance in cooling technology.
Microsoft's innovation in the tablet space has been handwriting recognition.