TheBS wrote:
> But getting back "on-topic," if anyone wants to hear how
> adoption of the GNU Toolchain in Windows would be a
> win-win-win for consumer-developer-Microsoft, just say so.
Doug Koobs wrote:
> I, for one, would like to know. I'm not even sure what
> Toolchain is...
THE GNU TOOLCHAIN AND IEEE POSIX
First off, the term "toolchain" is just used to descript a set of
development tools (assemblers, compilers, linkers, debuggers,
etc...) and related utilities (binutils, shells, scripting
languages, etc...). It also usually covers the application
programming interface (API) and possibly the "standard library"
implementation, which is called by most programs developed under the
toolchain. In the UNIX world, much of the "open" API is governed by
the IEEE's POSIX (portable operating system interface <something>)
specification.
In the case of the GNU Toolchain, you have a cross-platform
development system -- i.e. it may be "hosted" on platform X, but you
can "target" your code to run on platforms Y, Z, A, etc... We call
the GNU Compiler Collection (GCC) a cross compiler because it can
target hundreds of platforms. The main "system library" is the GNU
C Library (GLibC), which is not only fully threaded as of 2.x, but
heavily POSIX compliant.
As of GCC 2.9, Cygnus became the official maintainer of GCC, merging
in its existing egcs compiler technology into the next release which
is now known as GCC 3.0. Although not the maintainer of GLibC,
Cygnus is very involved with its development as well.
WHAT IS POSIX/GCC-COMPATIBLE?
In the desktop/server development world, many different operating
systems are POSIX/GCC-compatible such as Linux, BSD, Solaris and,
increasingly, AIX, Irix and HP/UX (among other proprietary OSes).
Most of these OSes strive for POSIX compliance. One of the few
operating systems that do not are BeOS (Watcom cross-compiler -- not
sure about POSIX compliance of Be yet) and OpenVMS (first released
in 1977 as VMS, which is not completely POSIX-compliant nor
UNIX-like).
Windows NT 3.1, released in 1993, was originally designed to be
POSIX compliant. Unfortunately, most everything in the POSIX layer
barely scratched the surface, let alone was quite broken. As such,
NT (NT/2000/XP) offers little POSIX compliance and compatibility
with UNIX APIs. And MS-DOS 7.x (95/98/ME) offers none.
The first "open source success story" is Cygnus, founded in 1989
(now owned by RedHat), as it has released a "POSIX compatibility
DLL" for Windows, including MS-DOS 7.x (95/98/ME) in more recent
releases, that allows much of the current GCC code out there to
compile with little rewriting. This project is known as Cygwin, and
is far from completely largely because many Win32 APIs are
undocumented and constantly moving. Being that the Cygwin.DLL is a
"clean-room" design by Cygnus, it is dual-licensed GPL and
commercial, so GPL/non-commercial apps can freely use it and
commercial apps require a commercial license.
[ Side note: Some other projects exist which take the approach of
adding libraries to make the applications more "Windows native."
E.g., Cygwin applications don't have drive letters, you must "mount"
other drives into the "Cygwin root" so they can be used. Other
projects have developer tools to allow UNIX apps to work with drive
letters and other Windows'ism. Unfortunately, that means the
applications require modification, whereas Cygwin will often compile
UNIX apps with little to no modification. ]
In the embedded world, the great majority of embedded and real-time
OSes use GCC almost exclusively. One of the few that don't are QNX
(Watcom cross-compiler, non-POSIX message passing design). Most
others such as Cygnus' eCos, WindRiver's VxWorks, etc... all use the
GNU Toolchain. They use GCC to develop just about everything, from
system to application level. Several vendors have introduced GLibC
compatible libraries, such as Cygnus' EL/IX, so software can be
written for both these embedded platforms (like eCos, RTLinux,
embedded Linux) as well as full GLibC operating systems (like your
typical Linux distro) without modification.
For Microsoft Windows CE, Microsoft has a $500 add-on to Visual
Studio that allows Windows hosts to target some of the platforms
where CE runs -- although only at the "application level". If you
want to do systems-level CE development, much more costly software
(6+ figures) is required, as well as a written license agreement.
Code re-use between CE and 9x/NT is limited as the CE API is a very
restrictive subset of Win32 -- let alone system-level re-use is
virtually _nil_ (even between the 9x and NT desktop codebases!).
[ Side note: My favorite statement is that BSD and Linux are more
system-level code compatible than Windows 95/98/ME and NT/2000/XP.
so the "incompatible versions of Linux" comment we all see so often
is a joke to us developer-types. ;-PPP ]
THE PROBLEM WITH CURRENT, DEVELOPER-TYPE REMEDIES
Now most of the "developer-type" arguments I have heard for
"remedies" for Microsoft have revolved around the following:
- Publication of APIs
- Adherence to standards
In the case of the first, "publication of APIs," Microsoft has
signed several, legally binding agreements over the years. In
recent years, from Java to Kerberos, Microsoft has broken them, and
contract law, again and again. In the case of Kerberos, Microsoft
delivered its documentation 2 years past due date -- and it was
still incomplete. And many other companies such as PenComputing,
Micrografx, Bristol Technology, Citrix and others have suffered
further through broken agreements with Microsoft.
As such, regarding "publication of APIs," I don't see the government
getting any farther than these companies and organizations did. And
they could always do what they have done with Win32, SMB, XML
namespace and even the new .NET docs, publish one thing, implement
another. Years later, we'll realize the spec is completely
different from what is in the OS.
In regards to "adherence to standards," this one is my favorite.
Microsoft Internet Explorer is a _perfect_example_ of this.
Microsoft used to brag about the fact that, before the release of
Netscape 6, it was the "most standards-compliant web browser." What
Microsoft did not tell the world was that it created almost as many
new, proprietary tags in its content creation tools, and that MS IE
would use those tags by default (instead of the standards-based
tags)! Worse yet, all their tools, from J++ to FrontPage, produced
them by default, and you had to navigate through various menus to
get these tools to write out the standards-based tags in addition to
(or instead). And in many cases, only the proprietary tags could be
used -- because Microsoft failed to implement a standards-based tag
in their content tools (so their "92% compliant" statement was based
on only one or two standards, like HTML and CSS).
Which brings me to my final point, Microsoft could duck around the
issue of "standards compliance" to a point favorable to them, while
still implementing proprietary functions and features that are the
default. Heck, I've had to argue against people on Linux lists
about MS IE *NOT* really being "standards compliant" because they
fail to look at the underlying issues involved. As such, do you
think the government will?
Both are good remedies. Unfortunately, no one has put any "teeth"
behind how to do them.
In the case of APIs, no one has presented an idea to _force_
Microsoft to do them. I mean, with publication of APIs,
cross-platform applications will become a reality. Although WINE
has done much to go from Windows to UNIX, Cygwin is limited in what
can go the other way -- and even WINE ports don't look nor act "very
natural."
And in the case of standards, we all want Windows to continue to be
interoperable with non-Windows OSes. But Microsoft is trying its
damnest to force users and companies with new licensing agreements
to their newer OS versions where interfaces will take even more
years to reverse engineer. And the Internet is getting closer and
closer to being more and more Windows-only every day.
Again, What we need is something that will _force_ Microsoft to
comply -- _technically_.
THE GNU TOOLCHAIN REMEDY
Instead of targeting the protocols, the APIs and the documentation
that is supposedly "standard," we should be attacking the
development tools that create them. My remedy is that within 3
years, the following must happen:
- The Visual Studio, and all other Microsoft development, line of
products must use the GNU Toolchain as its "back-end" for
development
- The standard libraries for Windows must be IEEE approved
POSIX-compliant, and dual-licensed via GPL and commercial (with
Microsoft and its partners retaining copyright)
There will be objective, annual "milestones" that must be reached
during these first three years. And the term of this "requirement"
will be 10 years, including the first 3 years, and re-evaluated at
that time.
In the case of the first, this includes not only its C/C++, VB, and
other languages, but all its new .NET development tools, including
web-document creation. Regardless of whether or not it is
"released/documented," Microsoft will be "documenting in code"
because it will be _forced_ to release any "new back-end" compilers,
targets and tools as GPL. All the front-end IDEs, debuggers and
other end-user tools can be closed-source, proprietary. Since the
GPL allows linkage of "non-free software" against "system level
tools", Microsoft will be able to product proprietary applications
from these tools, as well as graphical tools themselves.
And since Microsoft themselves creates these "new back-end"
programs, they will retain copyright. As such, they can license
them to other companies and generate revenue for commercial
licensees in that regard, just like other GPL-based companies like
Cygnus, FSMLabs, MontaVista and others have been doing quite
successfully for quite awhile. It's quite profitable too!
In the case of the second, it is much of the same. Since Microsoft
will have to release its libraries as dual-licensed GPL and
commercial. As such, free software developers can write completely
Windows native software with no royalties, but Microsoft can still
charge royalties to commercial software developers. Again, a
win-win situation!
IS THIS REMEDY REALISTIC? YOU BETCHA!
Heck, it could be done in 18 months!
Cygnus has already done a "lot of the hard work" for Microsoft. All
Microsoft needs to do is work with Cygnus and others to get Win32
API internals into the standard libraries at the core of the OS --
which the Cygwin.DLL already does today, but now at the "core" with
all the additional Win32 functionality.
>From a developer's standpoint, ActiveState (parially funded by
Microsoft nowdays) has a wealth of talent who have dealt with OSS
tool adoption. It wouldn't be long before the Visual Studio tools
could be made to work with various GNU Toolchain capabilities.
HOW DOES THIS BENEFIT THE DEVELOPER?
First and foremost, the developer is the big winner here. He can
now cross-compile between Windows and any other POSIX/GCC-compatible
OS. Windows and UNIX app development will flourish, reducing the
number of redundant code creation to support both OSes. Even for
Windows-only developers, no longer will Microsoft be able to develop
applications specific to its OS without competitors being able to do
so at the same time.
HOW DOES THIS BENEFIT MICROSOFT?
Microsoft still maintains copyright control over its code. The only
"limitation" is that it must dual-license its software both GPL and
commercial, with all "hidden" APIs exposed. For commercial software
development, Microsoft can still demand the same royalties as today,
without question. And it can still "innovate" in the creation of
new tools and libraries not in use in competiting, commercial
efforts. Plus, since the freeware community will definately grab
and support these developments -- Microsoft can be _assured_ that
commercial competitors will be _forced_ to licensed since their IP
will continue to _lead_ in marketshare.
And, most importantly, Windows and other Microsoft software can
still be packaged like it is today. Heck, the GPL allows commercial
companies to freely bundle software with theirs. Microsoft will be
able to release a feature-complete OS with all kinds of goodies, and
there can be no argument of "product tying" anymore. The Windows
codebase and its programs stay closed source and commercial, and no
GUI API outside of the standard libraries are exposed. And I don't
see too many consumers leaving Microsoft if those programs are not
available, verbatim, on other platforms.
HOW DOES THIS BENEFIT THE CONSUMER?
The consumer can still buy and use Windows and Microsoft
applications like they are today. But the applications no longer
hold the user to the same proprietary formats and underlying
interfaces. Microsoft will be forced to innovate to attract new
buyers as well as upgraders in GUI/program features, rather than
force users to upgrade through file compatibility and underlying
interfaces. They will be able to read and write their older
document formats, instead of losing older document versions with
each upgrade. And the consumer will now see a wealth of UNIX
applications now available on Windows, and Windows applications on
UNIX.
Best of all, they will all be written with multiuser security in
mind -- because it is integrated into the open libraries and APIs
themselves.
HOW DOES EVERYONE BENEFIT?
The same "peer review" model of software code has been show to
produce software and even systems-level code (like drivers) with
fewer bugs, fewer crashes and, most of all, fewer security
exploits. Make no mistake, this is the best way to adopt the
superior OSS development model to a commercial software
organization, so that everyone benefits.
Just take a look at Cygnus, FSMLabs and other GPL-based commercial
software companies. Now multiply their marketshare by 100x.
-- TheBS
-- Bryan "TheBS" Smith mailto:b.j.smith@ieee.org chat:thebs413 Engineer AbsoluteValue Systems, Inc. http://www.linux-wlan.org President SmithConcepts, Inc. http://www.SmithConcepts.com
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:55:56 EDT