- #Visual studio for mac preview review .dll#
- #Visual studio for mac preview review 32 bit#
- #Visual studio for mac preview review windows#
Microsoft had to do something about that to mitigate the success disaster of VBX, so they invented COM.Īt the time, Microsoft was transitioning from Win16 to Win32, so they came up with the 32 bit COM definition, also known as OCX's, or OLE Controls, which they later called ActiveX, because COM was so hard to search for, and they wanted to take the spotlight away from Java with a new buzzword. They were extremely popular and became a victim of their own success, after a whole industry grew up around them, and people started using them for all kinds of things they weren't intended for, and wanted to use them from other languages and frameworks like Borland. The original 16 bit version of Visual Basic version 1 through 3 had a plug-in extension mechanism called VBX - Visual Basic Extensions. It was the outcome of the C / C++ / Visual Basic language wars at Microsoft. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages. )ĬOM is essentially a formal way of using C++ vtables from C and other languages, so you can create and consume components in any language, and call back and forth between them. Glad you asked! One of my favorite topics. The COM system provided an approach to interoperability and reuse for a long time, but compared to our current generation of cross platform compatibility, the venerable COM system components are proving to be a significant legacy challenge for cross platform implementations. There are also extensive dot net facilities for repackaging and working with existing COM libraries through a Com Interop layer. Most COM components are native C and C++ based, exposing a standardized COM interface for component reuse.ĭot net was a new ecosystem, but much of the Win32 related dot net API is wrappers over existing native COM components.
#Visual studio for mac preview review .dll#
This is related to the re-use and versioning issues known informally as "DLL hell". These are usually in the form of a DLL (Dynamic Link Library), libraries of COM components, packaged as a ".dll" file.
#Visual studio for mac preview review windows#
This was how a lot of system and third party libraries provided large amounts of functionality in the windows ecosystem for quite some time. Like I said, just a crazy opinion based on what I've seen so far. If they can write suitable replacements for core functionality, let them bake and mature for some time, then BOOM! they can replace the VS components. I think the second is that they need a playground to figure out how to, excuse me here, "unfuck" the core architecture of Visual Studio. The first interest is to bring non-Microsoft users in the fold with the hopes that they may go "This ain't so bad, maybe I'll give other stuff a try".
So if you've lived with Visual Studio for years, you know that it's been COM based for a looonnnnggg time (since inception). I have an even crazier suspicion about what VSCode is really about. Given that you can now enable language support for around 470-ish languages, I don't think that their game here is to be a replacement for anything.
VSCode, albeit made by Microsoft, goes way beyond Microsoft's core interests. The next will be to begin bringing feature parity to the Mac version (My gut feeling is that VB.NET won't make the leap, but with Roslyn, maybe I'm wrong). This is only the first step for Visual Studio Mac. If I had to really take a guess here, this is what I'd speculate.
0 kommentar(er)
