Sponsored Content
Special Forums News, Links, Events and Announcements UNIX and Linux RSS News Microsoft and Incompatibility: 1991-2010 -- And a Novell Smoking Gun Post 302482150 by Linux Bot on Monday 20th of December 2010 05:30:02 PM
Old 12-20-2010
Microsoft and Incompatibility: 1991-2010 -- And a Novell Smoking Gun

Another gruesome exhibit is now finished as text in our collection of Comes v. Microsoft exhibits, Exhibit 1116 [PDF].
It's a Microsoft memo from 1991, regarding a suggested attack plan to beat out IBM's OS/2, written by Joseph Krawczak, currently group program manager for Outlook at Microsoft. Here are just three damning sentences from the confidential memo:
Pursue a product development strategy that prevents IBM from claiming Windows compatibility. Prevent Windows applications from running correctly on OS/2....
Reposition OS/2 as impractical and incompatible in the minds of customers.
Nice. First quietly create incompatibilities to make sure that Microsoft applications wouldn't run right on OS/2. Then tell the world that they shouldn't buy OS/2 because Microsoft applications wouldn't run right on OS/2.
But 1991 is a long time ago, I hear some of you say, and there is a new Microsoft. Oh? Let's see if that's so by highlighting one of the recent Novell filings with the SEC, its work agreement with Microsoft titled "Improving Microsoft-Novell Interoperability through Open XML" and dated March of this very year.
It's regarding work Microsoft was willing to pay Novell to do to make Microsoft's cynically misnamed Open XML seem like it allows interoperability. Novell has been at work since March to make Novell's version of OpenOffice.org interoperate, sort of, but as you will see not completely with Microsoft Office 2010 so that it would at least look like Open XML works and that somebody is implementing it.
What a role for Novell to agree to play. We've had our suspicions for years, since Microsoft and Novell entered into its patent peace agreement and technical work agreement, and now we know that everything we suspected Novell was doing with its version of OpenOffice.org, it was. It is. This is the smoking gun. And the work agreement runs through November of 2011, so this story isn't over yet.

More...
 
LWP::Authen::Ntlm(3)					User Contributed Perl Documentation				      LWP::Authen::Ntlm(3)

NAME
LWP::Authen::Ntlm - Library for enabling NTLM authentication (Microsoft) in LWP SYNOPSIS
use LWP::UserAgent; use HTTP::Request::Common; my $url = 'http://www.company.com/protected_page.html'; # Set up the ntlm client and then the base64 encoded ntlm handshake message my $ua = new LWP::UserAgent(keep_alive=>1); $ua->credentials('www.company.com:80', '', "MyDomain\MyUserCode", 'MyPassword'); $request = GET $url; print "--Performing request now...----------- "; $response = $ua->request($request); print "--Done with request------------------- "; if ($response->is_success) {print "It worked!->" . $response->code . " "} else {print "It didn't work!->" . $response->code . " "} DESCRIPTION
"LWP::Authen::Ntlm" allows LWP to authenticate against servers that are using the NTLM authentication scheme popularized by Microsoft. This type of authentication is common on intranets of Microsoft-centric organizations. The module takes advantage of the Authen::NTLM module by Mark Bush. Since there is also another Authen::NTLM module available from CPAN by Yee Man Chan with an entirely different interface, it is necessary to ensure that you have the correct NTLM module. In addition, there have been problems with incompatibilities between different versions of Mime::Base64, which Bush's Authen::NTLM makes use of. Therefore, it is necessary to ensure that your Mime::Base64 module supports exporting of the encode_base64 and decode_base64 functions. USAGE
The module is used indirectly through LWP, rather than including it directly in your code. The LWP system will invoke the NTLM authentication when it encounters the authentication scheme while attempting to retrieve a URL from a server. In order for the NTLM authentication to work, you must have a few things set up in your code prior to attempting to retrieve the URL: o Enable persistent HTTP connections To do this, pass the "keep_alive=>1" option to the LWP::UserAgent when creating it, like this: my $ua = new LWP::UserAgent(keep_alive=>1); o Set the credentials on the UserAgent object The credentials must be set like this: $ua->credentials('www.company.com:80', '', "MyDomain\MyUserCode", 'MyPassword'); Note that you cannot use the HTTP::Request object's authorization_basic() method to set the credentials. Note, too, that the 'www.company.com:80' portion only sets credentials on the specified port AND it is case-sensitive (this is due to the way LWP is coded, and has nothing to do with LWP::Authen::Ntlm) AVAILABILITY
General queries regarding LWP should be made to the LWP Mailing List. Questions specific to LWP::Authen::Ntlm can be forwarded to jtillman@bigfoot.com COPYRIGHT
Copyright (c) 2002 James Tillman. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. SEE ALSO
LWP, LWP::UserAgent, lwpcook. perl v5.12.1 2009-06-15 LWP::Authen::Ntlm(3)
All times are GMT -4. The time now is 06:57 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy