Linked by Thom Holwerda on Thu 21st Jun 2007 15:43 UTC, submitted by moleskine
"The past 21 days have been some of the most intense hacking days that I have ever had and the same goes for my team that worked 12 to 16 hours per day every single day - including weekends - to implement Silverlight for Linux in record time. We call this effort Moonlight."
Thread beginning with comment 249881
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-02-17
When you consider that COM is used everywhere in Windows, especially for scripting (VBScript, Windows Scripting Host, etc., which both Python, Perl support) and allows for scripting all of Microsoft Office, Windows itself (Scripting.FileSystemObject, WMI, etc.), and a whole host of other applications...
COM is the only way to go. Forcing everyone who wants to use COM to go through JNI is a good way to keep people from using COM, and thus a good way to prevent any form of platform integration.
Perhaps you're fine with this (it's no longer cross platform! the agony!), but I assure you that for company-internal custom software development this support is required! (Unless you want to re-write everything, which was the Java mantra...)
COM is the only way to go. Forcing everyone who wants to use COM to go through JNI is a good way to keep people from using COM, and thus a good way to prevent any form of platform integration.
Perhaps you're fine with this (it's no longer cross platform! the agony!), but I assure you that for company-internal custom software development this support is required! (Unless you want to re-write everything, which was the Java mantra...)
Can you spell "lock-in"?
COM was fine when it was constrained to an inter-process communication on just one machine. When it grew into DCOM and .NET it became just another proprietary Microsoft communication protocol.
http://en.wikipedia.org/wiki/Component_Object_Model#Related_technol...
When you put the words "proprietary" and "communication protocol" together, especially when you put them in the same context as "monopoly", you are in effect spelling "anti-trust", "lock-in", "single vendor" and "lawsuit".
http://en.wikipedia.org/wiki/Anti-trust
Monopolization and attempted monopolization are offenses that may be committed by an individual firm, even without an agreement with any other enterprise. Unreasonable exclusionary practices that serve to entrench or create monopoly power can therefore be unlawful.
If Microsoft want this to be a inter-machine communication protocol, then they should open it up, and make it strictly non-proprietary. Then, once again, it would no longer be a "monopoly maintenance" technology, and it would become perfectly fine.
Edited 2007-06-22 12:55
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2005-07-29
Benefits to whom?
Benefits to every ISV and custom software developer that needs to support Windows and interact with other Windows programs through COM. This probably amounts to ~80% of all custom software (number pulled out of my ass).
When you consider that COM is used everywhere in Windows, especially for scripting (VBScript, Windows Scripting Host, etc., which both Python, Perl support) and allows for scripting all of Microsoft Office, Windows itself (Scripting.FileSystemObject, WMI, etc.), and a whole host of other applications...
COM is the only way to go. Forcing everyone who wants to use COM to go through JNI is a good way to keep people from using COM, and thus a good way to prevent any form of platform integration.
Perhaps you're fine with this (it's no longer cross platform! the agony!), but I assure you that for company-internal custom software development this support is required! (Unless you want to re-write everything, which was the Java mantra...)