Like I tried to say,.NET is not a platform. Don't expect to write.NET applicaitons and be able to run them elsewhere without a lot of work.
The CLI is a development framework. You can write cross platform and non cross platform applications with the CLI. Just like with C.
When you write something in C you have to be careful about the libraries you use so that you don't sacrifice portability. The same thing applies to the CLI. Just stick with cross platform APIs and you'll be fine.
So why use C# over C? C# has important features C doesn't have. Improved type safety, unified OO type system, garbage collection, better set of standard classes/functions.
Microsoft software will use them, and other software will use that Microsoft software. Soon there will be a huge chunk of.NET software that won't run on non-Microsoft platform.
So? Microsoft uses non cross platform C APIs in their apps too..NET is not meant to be a cross platform meta platform like Java. It's a development framework.
It's a large and messy framework made with no understandable purpose other than "making another Java", therefore it's mental masturbation squared (because Java design is mental masturbation -- all its original goals are either abandoned or became irrelevant at the moment when semi-usable implementation was released).
You show your ignorance here. Try looking into.NET a bit more.
There is no CLIB, it's libc. And win32 has nothing to do with either, it's an API with its own library, and a horrible one at that.
CLIB/LIBC same thing. And Win32 has everything to do with it. Win32 is an example of a series of libraries written in C. If you write a C application that uses Win32, it will (usually) only run on. If you write an application in C# that uses Microsoft APIs (System.EnterpriseServices etc) if will (usually) only run on Windows. People seem to think the CLI is supposed to be a platform like Java. It's not. It's more like C with a bit more stuff (garbage collection, managed environment, etc).
It's a horrible framework -- it is very narrow in functionality and very broad in its stretch over all aspects of program's design and behavior -- basically such infrastructures are for software development what are "wizards" for system administration. Examples of good infrastructure are very rare, I can only name two -- Unix unified file descriptors and Berkeley sockets as a decent large-scale infrastructures that actually serve a valid purpose and improved the software design. The only point of bothering to port it somewhere can be to run software developed for it until people will realize how bad it is and rewrite that software in C or C++ with sanely designed libraries. Same applies to Java but at least Java can be made compatible on all platforms
Um. Can you please explain this statement. It sounds like (because it is) pure ignorant FUD.
You can have a Common Type System (which is the main component of CLI), but if you don't know which classes/functions on.net to access, what parameters they're expecting, etc., resolving to common types won't do much good
Uh. If there are undocumented classes (e.g. non public APIs) then they don't need to be implemented because noone uses them. If they're public they need to be documented for people to use them. You can also just call the methods and see the return values with various argument values.
Besides, who cares about Microsoft.NET APIs? The CLI is a good framework regardless of whether you use the Microsoft-only namespaces or not. GTK#, CsGL etc don't need to rely on any non-CLI classes.
The CLI is very much like C + CLIB. You can build proprietry non cross platform libraries on top of it (e.g. Win32) but you can also build open cross platform libaries with it (e.g. OpenGL). Noone is forcing you to use Windows only libraries (e.g. WinForms) when using.NET.
Mono may never be 100% compatible with MS.NET but that doesn't prevent it from being an extremely useful development framework.
Yes true, but there's no evidence that they won't either.
What about these facts?
- Mono has been around for over a year. - Mono has been featured on MSDN. - To the press, Microsoft has consistantly praised the Mono team. -.NET is an ECMA and soon to be ISO standard.
Last week, I took an old 200MHz Pentium Pro box that my brother was using, upgraded it to 128MB RAM, and installed W2K Advanced Server. While I wouldn't want to run Autocad or Photoshop on it, word processing and broadband web surfing were more than adequate.
Saved him upwards of $2000.
Not buying a license of W2K advanced server to do web surfing would have saved him over $2000 too.
A partial analogy would be Microsoft owning the default Yellow Pages distributed to everyone's door and selecting who can be in it -- say, virtually everyone but "Sun." Now, anyone can go get one of the other free directories, but will they? Advantage: Microsoft
Escuse me? Nothing in Windows prevents Java from running and Microsoft DOESN'T bundle every other software package in the world with Windows.
The way I see it, the GPL works well because it protects the code that's already been paid for through taxes from becoming proprietary and therefore causing the taxpayers to have to pay for it again.
Um. BSD does this. The code that was originally paid for is always available. Any code derived from it (e.g. that was never paid for) may become closed. What's wrong with that?
If vorbis was GPLed and I made a media player that played every audio and video format (including vorbis) I would have to release the source code to my player. Even though only a small part of it derived from GPL code. Does that seem fair? Luckily vorbis isn't GPLed for this very reason.
"Bloatware" does exist, but not all large programs are bloatware.
Would you call Quicksort "bloatware" because it uses more stack space than bubblesort?
The increase in size (both code and memory foorprint) of applications is usually accompanied by better reuse, extensibility, portability and speed (better algorithms).
I doubt the programs you had to hand code in asm for a 2kb machine could be extended very easily.
Today, we have so much memory and CPU power that we can 'waste' it on stuff like Java, COM, XML etc to make programming reusable components easier.
Until MS decides to change the libraries in such a way that will break them on non-Windows systems, as they are not a part of any standards body submissions.
I don't think it would be a problem if Microsoft managed to do something that prevents Windows based.NET apps from working on Linux.
Mono would essentially be incomptable with non 'pure' (ECMA).NET apps but it would still be a great platform for writing Linux/Gnome apps.
The implementations would essentially fork. Developers could still use non windows specific.NET libraries to develop.NET applications that would run on both Linux and Windows.
True. But my hope is that.NET and especially Mono will encourage users to let go of legacy components.
COM is very cool. But let's not encourage people to keep using COM over.NET/Mono;).
Anyone who needs to use COM will be runing Windows and MS.NET will have the best support for COM for some time to come. By the time Mono gets round to implementing support for COM, the need for it will (hopefully) be almost nill.
You're a fool. By your arguments and your comments I know you're not a programmer. You may have "tried" to program in C or VB but you really don't know what you're talking about. You like throwing about buzzwords or throw in references to "Knuth" but you've never done a computer science degree..NET allows you to access native code. But any code that does so (e.g. calls unmanaged code) can be disallowed from running.
BTW, Java also supports calling native code (JNI). Is it secure also?
I think you'll find that almost ALL high level programming languages support calling native code. e.g. Most implementations of Prolog (like SWI-Prolog) and Haskell (HUGS 98) include support for FFI.
You may call me ignorant, jerk or whatever. But you just don't launch "java" by loading an applet in your browser right? And the thing cannot format you HDD just like that because its infrastructure does not allow to directly interact with your machine without your knowledge
Well yes, the browser uses tjhe Java embeddding APIs and they launch "java". But applets run in a sandboxed enviornment. It was about ANYTHING we were talking about. Stop distracting the main argument. Java applets are almost as restricted as Flash animations. ".NET" controls can similarly be sandboxed. No difference.
With.NET, in a near future, you may really risk not only to format something but also get "Now all your data belong to us".
Why is this any more so than Java? Java currently processes more "data" than.NET. J2EE runs the web application world.
Java does not have such a deep interaction to other aplications or libraries as.NET. In fact, it is pretty isolated in its environment, interacting with databases and other stuff through tons of interfaces. On.NET, this frontier dissolves nearly to the impossible.
Fucking hell. Ok, you're a troll right? Jokes on me right?
Even if there are guidlines, even if the CLI is supposed to have all the security it can, even if these GTK# and VBs will have their own library infrastructure, separated from its classical GTK+ or VisualBasic DLLs, it will be impossible to get a guaranteed security
Uh, why? So what you're saying is "even if you write a secure environment, it'll be impossible to garuntee security because it has '.net' in its name"?
Please explain by defining a clear difference between.NET and Java why.NET is any less secure.
Java is exploitable and we all know about that. However to create real exploits, one has to dig up inside the forest of its virtual machine and interfaces. To reach an exploitable zone, one has to calculate several moments, from the interface level down to the zone where JVM acts with the real machine. Being an enclosed environment, Java makes this a lot too difficult to be done. On.NET I may see things quite to similar to Java and its world. However the loose interactivity of this thing breaks the shell of security like the one Java possesses.
What does "loose interactivity" mean? And are you saying that Java is more secure because everything is "hidden" e.g. obscure? You're a true troll. We're not talking about exploits are we? Exploits infer bugs in the VM. They can be fixed. I can still format your harddrive with a java application by using the standard APIs. I've just got to get you to run the application. No different from.NET.
Frankly I wouldn't be admired to see a new type of exploit - the worm tunnels, systems that break into a computer and create a more active and permanent presence in it, by using the.NET communication infrastructure. A small piece of code breaks the security, calls some central node for apps/control and actively uses the victim computer for its nefarious activities. Naivety? Let's wait and see.
WTF?
Get this through your thick brain..NET is EXACTLY like java. It's a specification for a "managed" runtime environment by compiling source code into high level byte-code/IL that can dynamically be verified and executed. I think you're confusing ".net" with "skynet". They're vastly different things.
There is NO.NET "communication" infrastructure at all. If you're talking about the "webservices" world, that's something Java is doing as well..NET won't be doing anything different from the rest of the world (including Java).
The argument is that support COM in Mono will promote Windows-only Mono apps. Supporting COM is useless unless it supports the windows version of COM, which would mean any Mono app that uses COM will only work on Windows.
His example is akin to saying that the following function doesn't rely on the registry:
LONG RegSetValue(
HKEY hKey,// handle to key to set value for
LPCTSTR lpSubKey,// address of subkey name
DWORD dwType,// type of value
LPCTSTR lpData,// address of value data
DWORD cbData// size of value data );
Well, no it *doesn't*. But the only platform it works on is windows and it DOES require the registry. And emulating it for mono is pretty pointless since most of the windows registry keys wouldn't exist.
uhm all windows developers? you are right in what you say, we dont want com to run on linux but there is an awful lot of com "legacy" code out there which is very valuable. maybe this is rightly not the focus for mono, but if you want to take away sales from MS then it would be good.
What!? I'm a windows developer. I don't want to use Mono to call COM objects. If a windows developers wants to access windows apis they should use windows or MS.NET. If they want to write cross platform apps they can use Mono.
There's a lot of legacy Win32 API based apps out there. Should Mono support those too?
You're pretty good at throwing around buzzwords but show extreme ignorance.
C didn't have such a plague because it is not a network system per se. But its system libraries demonstrated long ago how one can get into deep trouble, due to the loosy structure of the language.
Yes, but you can almost be certain that connect() is available on any computer connected to a network can't you?
Java on the contrary, was a system that was built for the network but with some concern on security
Yes. And please explain to me how.NET differs. In fact, in some areas,.NET has even more fine grained security. For example, you can give an appdomain access to *only* the files you choose. You can configure these policies programmatically or by using a config tool.
So exactly is the part of.NET that you think makes it more prone to exploits than C and Java again?
Any Java standard application that you run using "java" can format your harddisk.
No. You create references to assembly filesnames in your own assembly and with that also a version of the assembly so you can install multiple assemblies with the same filename. I can call my assembly FOO and the assembly file bar.dll. The compiler creates a reference to 'bar.dll' with a certain version. When I start the program with that reference, the CLR will look in the current directory for bar.dll to load the assembly objects I try to instantiate. If bar.dll is missing it will consult the GAC (Global Assembly Cache). If bar.dll is not found there, it's not loaded.
Uh. I am aware of that. I was trying to give a simple example of how.NET resolves types without a registry. Also,.NET checks the bin subdirectory before it checks the GAC.
Supporting COM in.NET was a wise decision. Leaving it out of Mono will developers limit to use DCOM enabled execution of COM objects on windows servers from Linux servers running Mono.
Uh opposed to what? Executing COM objects on Windows using Mono? Getting COM support in Mono isn't going to make COM objects work on Linux.
How many people are going to want to use Mono to execute COM objects running on Windows boxes? It would be easier to stick with the win32 app or port the objects they need to.NET.
Mono should concentrate on getting good support for.NET and.NET applications. It's not for supporting legacy WINDOWS applications. That's what MS.NET is for. Like I said before. Getting COM support into Mono isn't going to make Win32 COM objects work on Mono on all platforms.
If joe bloggs wants his.net app to be cross platform, he has to let go of his legacy COM objects..NET is a cross platform runtime. COM is not. You can't just 'wrap' your COM objects with.NET classes and then pretend it's going to be cross platform.
and one further note - about 'pure'.net applications (ones that don't call the win32 api and are thus potentially more portable) - the inability to do any multimedia stuff (even a simple beep) without resorting to win32 calls, makes it pretty much impossible for any reasonably large application:).
Not necessarily true. You can make 'purer'.NET applications by doing P/Invoke calls to cross platform C apis instead of Win32 APIs.
For example, if you use SDL instead of DirectSound your.NET application will run on Unix and Windows..NET makes it easy to access traditionall DLLs with P/Invoke but that doesn't mean they have to be Win32 DLLs:).
BTW, you're twisting the real meaning of my words.
COM is ONLY supported in Windows (with the exception of dead unix implementations) hence RELIES on the windows registry.
Unelss you're suggesting Mono support COM by first porting COM to linux. LOL. The only reason COM support on Linux would be needed is if (MS)COM already existed on Linux. There's no point in implementing a legacy technology just so you can do legacy interop with it.
.NET assembly names match the actual assembly file name..NET searchs the exe dir and bin sub dir.
An yes, COM _could_ be implemented on other platforms. But that's not the bloody point is it? Almost any technology can be implemented on other platforms. COM included. But Windows pretty much has the _ONLY_ useful implementation of COM. COM objects written for Windows will only work for windows. Mono is designed to be cross platform. The only good reason to support COM in any.NET runtime would be for interoperability with legacy components. But we're talking about supporting interop with windows only software. Why spend time encouraging people to write mono applications that will _ONLY_ work with windows (because they use com objects) when you can write cross platform apps/apis using pure.NET code or P/Invoke to cross platform C libraries (like CSGL)?
Supporting COM interop in Mono is stupid at this stage. It makes sense for MS because there are many COM objects that people would like to use in their new.NET apps while they migrate. Eventually those COM objects will be phased out. Adding COM support to Mono will only benefit windows only applications (remember, windows has the ONLY useful com implementation). Adding CORBA or Bonobo support to Mono will be great because both technologies can run on many, many platforms.
Slashdot Mirror
What has the international space station got to do with all of this?
The PDF problem is because of Acrobat. It looks like it contends for some resources and deadlocks.
You can unfreeze IE by going to the Task Manager and killing all instances of "acrobat.exe".
Like I tried to say, .NET is not a platform. Don't expect to write .NET applicaitons and be able to run them elsewhere without a lot of work.
The CLI is a development framework. You can write cross platform and non cross platform applications with the CLI. Just like with C.
When you write something in C you have to be careful about the libraries you use so that you don't sacrifice portability. The same thing applies to the CLI. Just stick with cross platform APIs and you'll be fine.
So why use C# over C? C# has important features C doesn't have. Improved type safety, unified OO type system, garbage collection, better set of standard classes/functions.
Microsoft software will use them, and other software will use that Microsoft software. Soon there will be a huge chunk of
So? Microsoft uses non cross platform C APIs in their apps too.
It's a large and messy framework made with no understandable purpose other than "making another Java", therefore it's mental masturbation squared (because Java design is mental masturbation -- all its original goals are either abandoned or became irrelevant at the moment when semi-usable implementation was released).
You show your ignorance here. Try looking into
There is no CLIB, it's libc. And win32 has nothing to do with either, it's an API with its own library, and a horrible one at that.
CLIB/LIBC same thing. And Win32 has everything to do with it. Win32 is an example of a series of libraries written in C. If you write a C application that uses Win32, it will (usually) only run on. If you write an application in C# that uses Microsoft APIs (System.EnterpriseServices etc) if will (usually) only run on Windows. People seem to think the CLI is supposed to be a platform like Java. It's not. It's more like C with a bit more stuff (garbage collection, managed environment, etc).
It's a horrible framework -- it is very narrow in functionality and very broad in its stretch over all aspects of program's design and behavior -- basically such infrastructures are for software development what are "wizards" for system administration. Examples of good infrastructure are very rare, I can only name two -- Unix unified file descriptors and Berkeley sockets as a decent large-scale infrastructures that actually serve a valid purpose and improved the software design. The only point of bothering to port it somewhere can be to run software developed for it until people will realize how bad it is and rewrite that software in C or C++ with sanely designed libraries. Same applies to Java but at least Java can be made compatible on all platforms
Um. Can you please explain this statement. It sounds like (because it is) pure ignorant FUD.
You can have a Common Type System (which is the main component of CLI), but if you don't know which classes/functions on .net to access, what parameters they're expecting, etc., resolving to common types won't do much good
.NET APIs? The CLI is a good framework regardless of whether you use the Microsoft-only namespaces or not. GTK#, CsGL etc don't need to rely on any non-CLI classes.
.NET.
Uh. If there are undocumented classes (e.g. non public APIs) then they don't need to be implemented because noone uses them. If they're public they need to be documented for people to use them. You can also just call the methods and see the return values with various argument values.
Besides, who cares about Microsoft
The CLI is very much like C + CLIB. You can build proprietry non cross platform libraries on top of it (e.g. Win32) but you can also build open cross platform libaries with it (e.g. OpenGL). Noone is forcing you to use Windows only libraries (e.g. WinForms) when using
Mono may never be 100% compatible with MS.NET but that doesn't prevent it from being an extremely useful development framework.
Yes true, but there's no evidence that they won't either.
What about these facts?
- Mono has been around for over a year.
- Mono has been featured on MSDN.
- To the press, Microsoft has consistantly praised the Mono team.
-
Hmmmm
Last week, I took an old 200MHz Pentium Pro box that my brother was using, upgraded it to 128MB RAM, and installed W2K Advanced Server. While I wouldn't want to run Autocad or Photoshop on it, word processing and broadband web surfing were more than adequate.
Saved him upwards of $2000.
Not buying a license of W2K advanced server to do web surfing would have saved him over $2000 too.
A partial analogy would be Microsoft owning the default Yellow Pages distributed to everyone's door and selecting who can be in it -- say, virtually everyone but "Sun." Now, anyone can go get one of the other free directories, but will they? Advantage: Microsoft
Escuse me? Nothing in Windows prevents Java from running and Microsoft DOESN'T bundle every other software package in the world with Windows.
What a fucked up analogy.
How are other Java vendors supposed to compete when Sun's VM is going to be bundled with Windows. What about IBM?
The ruling is screwed.
The way I see it, the GPL works well because it protects the code that's already been paid for through taxes from becoming proprietary and therefore causing the taxpayers to have to pay for it again.
Um. BSD does this. The code that was originally paid for is always available. Any code derived from it (e.g. that was never paid for) may become closed. What's wrong with that?
If vorbis was GPLed and I made a media player that played every audio and video format (including vorbis) I would have to release the source code to my player. Even though only a small part of it derived from GPL code. Does that seem fair? Luckily vorbis isn't GPLed for this very reason.
"Bloatware" does exist, but not all large programs are bloatware.
Would you call Quicksort "bloatware" because it uses more stack space than bubblesort?
The increase in size (both code and memory foorprint) of applications is usually accompanied by better reuse, extensibility, portability and speed (better algorithms).
I doubt the programs you had to hand code in asm for a 2kb machine could be extended very easily.
Today, we have so much memory and CPU power that we can 'waste' it on stuff like Java, COM, XML etc to make programming reusable components easier.
Until MS decides to change the libraries in such a way that will break them on non-Windows systems, as they are not a part of any standards body submissions.
I don't think it would be a problem if Microsoft managed to do something that prevents Windows based
Mono would essentially be incomptable with non 'pure' (ECMA)
The implementations would essentially fork. Developers could still use non windows specific
It won't be a problem. MS can't change the .NET APIs without breaking existing apps.
.NET won't dilute the usefulness of Mono as a great way to develop applications (especially on Linux).
Anything Microsoft does to
e.g. Gnome's bonobo is inspired by OLE, it's not compatible with OLE but it is still very useful non the less.
True. But my hope is that .NET and especially Mono will encourage users to let go of legacy components.
.NET/Mono ;).
COM is very cool. But let's not encourage people to keep using COM over
Anyone who needs to use COM will be runing Windows and MS.NET will have the best support for COM for some time to come. By the time Mono gets round to implementing support for COM, the need for it will (hopefully) be almost nill.
You're a fool. By your arguments and your comments I know you're not a programmer. You may have "tried" to program in C or VB but you really don't know what you're talking about. You like throwing about buzzwords or throw in references to "Knuth" but you've never done a computer science degree. .NET allows you to access native code. But any code that does so (e.g. calls unmanaged code) can be disallowed from running.
BTW, Java also supports calling native code (JNI). Is it secure also?
I think you'll find that almost ALL high level programming languages support calling native code. e.g. Most implementations of Prolog (like SWI-Prolog) and Haskell (HUGS 98) include support for FFI.
You may call me ignorant, jerk or whatever. But you just don't launch "java" by loading an applet in your browser right? And the thing cannot format you HDD just like that because its infrastructure does not allow to directly interact with your machine without your knowledge
Well yes, the browser uses tjhe Java embeddding APIs and they launch "java". But applets run in a sandboxed enviornment. It was about ANYTHING we were talking about. Stop distracting the main argument. Java applets are almost as restricted as Flash animations. ".NET" controls can similarly be sandboxed. No difference.
With
Why is this any more so than Java? Java currently processes more "data" than
Java does not have such a deep interaction to other aplications or libraries as
Fucking hell. Ok, you're a troll right? Jokes on me right?
Even if there are guidlines, even if the CLI is supposed to have all the security it can, even if these GTK# and VBs will have their own library infrastructure, separated from its classical GTK+ or VisualBasic DLLs, it will be impossible to get a guaranteed security
Uh, why? So what you're saying is "even if you write a secure environment, it'll be impossible to garuntee security because it has '.net' in its name"?
Please explain by defining a clear difference between
Java is exploitable and we all know about that. However to create real exploits, one has to dig up inside the forest of its virtual machine and interfaces. To reach an exploitable zone, one has to calculate several moments, from the interface level down to the zone where JVM acts with the real machine. Being an enclosed environment, Java makes this a lot too difficult to be done. On
What does "loose interactivity" mean? And are you saying that Java is more secure because everything is "hidden" e.g. obscure? You're a true troll. We're not talking about exploits are we? Exploits infer bugs in the VM. They can be fixed. I can still format your harddrive with a java application by using the standard APIs. I've just got to get you to run the application. No different from
Frankly I wouldn't be admired to see a new type of exploit - the worm tunnels, systems that break into a computer and create a more active and permanent presence in it, by using the
WTF?
Get this through your thick brain.
I think you're confusing ".net" with "skynet". They're vastly different things.
There is NO
I can't believe this got modded up so much.
// handle to key to set value for // address of subkey name // type of value // address of value data // size of value data
It's a decoy can't you mods see that?
The argument is that support COM in Mono will promote Windows-only Mono apps. Supporting COM is useless unless it supports the windows version of COM, which would mean any Mono app that uses COM will only work on Windows.
His example is akin to saying that the following function doesn't rely on the registry:
LONG RegSetValue(
HKEY hKey,
LPCTSTR lpSubKey,
DWORD dwType,
LPCTSTR lpData,
DWORD cbData
);
Well, no it *doesn't*. But the only platform it works on is windows and it DOES require the registry. And emulating it for mono is pretty pointless since most of the windows registry keys wouldn't exist.
uhm all windows developers? you are right in what you say, we dont want com to run on linux but there is an awful lot of com "legacy" code out there which is very valuable. maybe this is rightly not the focus for mono, but if you want to take away sales from MS then it would be good.
What!? I'm a windows developer. I don't want to use Mono to call COM objects. If a windows developers wants to access windows apis they should use windows or MS.NET. If they want to write cross platform apps they can use Mono.
There's a lot of legacy Win32 API based apps out there. Should Mono support those too?
You're pretty good at throwing around buzzwords but show extreme ignorance.
.NET differs. In fact, in some areas, .NET has even more fine grained security. For example, you can give an appdomain access to *only* the files you choose. You can configure these policies programmatically or by using a config tool.
.NET that you think makes it more prone to exploits than C and Java again?
C didn't have such a plague because it is not a network system per se. But its system libraries demonstrated long ago how one can get into deep trouble, due to the loosy structure of the language.
Yes, but you can almost be certain that connect() is available on any computer connected to a network can't you?
Java on the contrary, was a system that was built for the network but with some concern on security
Yes. And please explain to me how
So exactly is the part of
Any Java standard application that you run using "java" can format your harddisk.
No. You create references to assembly filesnames in your own assembly and with that also a version of the assembly so you can install multiple assemblies with the same filename. I can call my assembly FOO and the assembly file bar.dll. The compiler creates a reference to 'bar.dll' with a certain version. When I start the program with that reference, the CLR will look in the current directory for bar.dll to load the assembly objects I try to instantiate. If bar.dll is missing it will consult the GAC (Global Assembly Cache). If bar.dll is not found there, it's not loaded.
Uh. I am aware of that. I was trying to give a simple example of how
Supporting COM in
Uh opposed to what? Executing COM objects on Windows using Mono? Getting COM support in Mono isn't going to make COM objects work on Linux.
How many people are going to want to use Mono to execute COM objects running on Windows boxes? It would be easier to stick with the win32 app or port the objects they need to
Mono should concentrate on getting good support for
If joe bloggs wants his
They're right. He should've renamed it to "The Twin Towers".
and one further note - about 'pure'
Not necessarily true. You can make 'purer'
For example, if you use SDL instead of DirectSound your
What will happen when
Um. Do you know what
It's a fucking runtime and class library. Running a
YEESH.
BTW, you're twisting the real meaning of my words.
COM is ONLY supported in Windows (with the exception of dead unix implementations) hence RELIES on the windows registry.
Unelss you're suggesting Mono support COM by first porting COM to linux. LOL. The only reason COM support on Linux would be needed is if (MS)COM already existed on Linux. There's no point in implementing a legacy technology just so you can do legacy interop with it.
.NET assembly names match the actual assembly file name. .NET searchs the exe dir and bin sub dir.
.NET runtime would be for interoperability with legacy components. But we're talking about supporting interop with windows only software. Why spend time encouraging people to write mono applications that will _ONLY_ work with windows (because they use com objects) when you can write cross platform apps/apis using pure .NET code or P/Invoke to cross platform C libraries (like CSGL)?
.NET apps while they migrate. Eventually those COM objects will be phased out. Adding COM support to Mono will only benefit windows only applications (remember, windows has the ONLY useful com implementation). Adding CORBA or Bonobo support to Mono will be great because both technologies can run on many, many platforms.
An yes, COM _could_ be implemented on other platforms. But that's not the bloody point is it? Almost any technology can be implemented on other platforms. COM included. But Windows pretty much has the _ONLY_ useful implementation of COM. COM objects written for Windows will only work for windows. Mono is designed to be cross platform.
The only good reason to support COM in any
Supporting COM interop in Mono is stupid at this stage. It makes sense for MS because there are many COM objects that people would like to use in their new