TCL and .NET ?

32 views
Skip to first unread message

Bugs

unread,
Jun 22, 2005, 2:42:38 PM6/22/05
to
Can someone clear up for me the interaction between Tcl/Tk and Windows
and the impact of .NET in the future on Tcl/Tk?

The Windows port of Tcl/Tk is built on top of the Win32 API.

Question:
Now that Microsoft has .NET, is the Win32 API essentially "frozen"? In
other words, is any future new functionality to be added to Windows by
Microsoft only going to be done via the .NET libraries? If so, then
does that mean that if the Tcl/Tk Windows port ever needs to leverage
some future functionality in Windows, it would need to do so through the
.NET framework somehow?

Kevin Kenny

unread,
Jun 23, 2005, 9:53:49 AM6/23/05
to
Bugs wrote:
> Now that Microsoft has .NET, is the Win32 API essentially "frozen"? In
> other words, is any future new functionality to be added to Windows by
> Microsoft only going to be done via the .NET libraries? If so, then
> does that mean that if the Tcl/Tk Windows port ever needs to leverage
> some future functionality in Windows, it would need to do so through the
> ..NET framework somehow?

.NET is many things.

If your question is, "do we need to rewrite Tcl/Tk in C#?" the answer
has to be "no." Microsoft itself is not going to be able to redevelop
all its applications in C#, and so there are going to be rich C/C++
API's for the foreseeable future.

If your question is, "do we need to rehost Tcl/Tk on the Common Language
Runtime?" the answer is, "possibly, but that's a matter of compiling
it with VC.NET, and testing the port. No big deal."

If your question is, "do we foresee Microsoft creating interfaces that
aren't C/C++ callable," the answer is, "no." Even new C# interfaces
are likely to have COM interfaces (.NET is basically COM is basically
OLE) wrapped around them. We already use COM in several places in
Tk. A few more won't be a major problem.

If your question is, "will Microsoft once again work major changes to
its API's so that independent software vendors have to engage in
major redevelopment efforts?" the answer is, "Oh, probably. Let them.
Our abstractions are clean and fairly portable. Unless antitrustworthy
computing locks out ISV's altogether, we'll find a way."

--
73 de ke9tv/2, Kevin

keithv

unread,
Jun 23, 2005, 12:10:25 PM6/23/05
to

Kevin Kenny wrote:
> If your question is, "will Microsoft once again work
> major changes to its API's so that independent software
> vendors have to engage in major redevelopment efforts?"
> the answer is, "Oh, probably."

Joel On Software calls this "Fire and Motion" based on
the infantry concept of constantly firing your weapon
at your enemy. The firing forces him to keep his head
down so he can't fire at you.

To quote from his essay:
http://www.joelonsoftware.com/articles/fog0000000339.html

Think of the history of data access strategies to
come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB,
now ADO.NET - All New! Are these technological
imperatives? The result of an incompetent design
group that needs to reinvent data access every goddamn
year? (That's probably it, actually.) But the end result
is just cover fire. The competition has no choice but to
spend all their time porting and keeping up, time that
they can't spend writing new features.


Keith

Bugs

unread,
Jun 23, 2005, 2:13:39 PM6/23/05
to
GREAT answer Kevin, thanks.
And your 3rd and 4th paragraphs below are what I was driving at exactly!
Reply all
Reply to author
Forward
0 new messages