As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
Jul 21 '05
142  4205 
If I had to guess, I'd say it's because Microsoft has way too much legacy
code in their major applications.
Microsoft Office probably has at least 30 million lines of code in it. I
wouldn't be surprised if it's 50 million. Imagine you are the manager in
charge of deciding what to do for the next version of Office. Whatever you
do, you know that you have to be done in three years, at most. Your
decision is, "do we spend three years re-implementing and re-testing all of
Office in managed code, to end up with a version that looks just like what
we have now, or spend three years working in our existing code adding
features that people might actually want to buy?"
If I were that manager, I know which one I'd choose. I'd be sad that I
wasn't working in managed code, but I'd understand the business reality that
I need to give people some reasons to upgrade. But I'd probably also set
three or four developers aside and say "hey, guys, see if you can't build
some sort of conversion tools to convert all that legacy code into C#"
because I'd know that I can't realistically work in unmanaged code forever.
And also, there is some code that just can't be written in managed code.
Windows, for example. After all, the CLR has to run _on_ something. So
until the essential features of managed code are implemented in hardware,
Windows is gonna continue to be written in unmanaged code.
"Hex" <He*@discussions.microsoft.com> wrote in message
news:06**********************************@microsof t.com... Why no?
For examlpe look this. Description on site wery shortly, but system realy
great!
http://medcon.com/windsurfer_e.htm
You have to think that Office is a huge code base currently. It would be very
expensive to rewrite that code base in managed C#, and what value would that
add?
My guess, is that the softies are writing a lot of new code in managed C#,
but they don't see any reason to rewrite exisiting applications.
"Herr Lucifer" <"\n" wrote: As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
Well, I doubt they would use C#... but rather Managed C++.
And the main point of the rewrite would be to lose the reliance on direct
Win32 API's and to gain the stability and security that the managed runtime
brings.
"Tony Antonucci" wrote: You have to think that Office is a huge code base currently. It would be very
expensive to rewrite that code base in managed C#, and what value would that
add?
My guess, is that the softies are writing a lot of new code in managed C#,
but they don't see any reason to rewrite exisiting applications.
"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
Actually, Visual Studio.NET 2005 as well as SQL Server 2005 are written using
the .NET framework.
Furthermore, to the others who replied: It is not possible to make informed
comments on the future of the .NET framework or Windows API without studying
the technologies, concepts, methodologies, and design of Microsoft’s project
codenamed “Longhorn”. WinFX, which you can [kind of] think of as being .NET
3.0 *will* replace the Win32 API as far as you are concerned. The Win16 API
replaced the MSDOS API, the Win32 API replaced the Win16 API, and the WinFX
API (which is .NET) replaces the Win32 API.
For more information on this topic there are MSDN TV episodes and other
*official* MSDN videos, webcasts, and audios clearly stating these exact
facts. To be even more specific, search for "Brad Abrams" in the Microsoft
website. His articles, documents, videos, and explanations will provide you
with all the answers you need to admit that a newsgroup is not the place to
ask these clearly black and white questions.
I restate: Microsoft does write applications in .NET, the WinFX API (which
is.NET) replaces the Win32 API, which demonstrated very clearly (and the
“Longhorn” team can explain this better) that .NET is *NOT* a framework,
platform, or generic programming system for custom business applications: it
is Microsoft Windows's full A to Z unified development and programming
environment.
I remind everyone that .NET is young as Microsoft's end game has not yet
come to fruition. Phase 1 brought the unification of Windows and
Web(server-side only of course) development, phrase 2 brings the unification
of data with the previous level of unification, and phase 3 brings the
unification of lower-level functionality with the previous two levels of
unification. It's rather analogous to the pursuit of unification in physics.
Given that .NET is still in its first phase of deployment (yes, it was
intended to be long term), it is easy to see why Microsoft has not released
many applications written in the .NET framework: phase one was the
introductory advent of the .NET framework. Its intent was, according to
marketing, to provide enterprise level XML web services and, according to the
development departments, to provide initial unification of Windows and Web
development.
In this regard and in this context, Microsoft has used the .NET framework
extensively: their website which is their primary web application is either
almost or entirely .NET based. I suspect that this is the largest
application Microsoft has ever deployed into production. This application of
the .NET framework is true to the spirit of the first phase of the .NET era:
the unification of Windows and Web (server-side) development.
Visual Studio.NET 2005 and SQL Server 2005 are both .NET applications which
are true to the spirit of phase 2 of the .NET era: the unification of data
and the previous level of unification.
Phase 3 is out of reach at this point, but its advent will probably bring
more than simply “Longhorn” and WinFX. It will most likely be the case that
more Microsoft applications will be written in .NET 2.0(given the data
unification) than Web applications were written in .NET 1.0. At that time
the momentum should be so strong that it will be natural for not only the
public to write all their applications using managed code, but also Microsoft
in their own endeavors. Among speculations of the third phase of the .NET
area are: Internet Explorer, Office, Mappoint, Money, as well as
semi-lower-level functionality all written in managed code. Microsoft has
taken a dramatic leap forward by releasing this new version of SQL Server,
SQL Server 2005, because of its base in the .NET framework. If an
application as astronomically powerful as SQL Server could be written in
managed code, then there are virtually no limits to the future of the .NET
framework. Furthermore, given SQL Server 2005's .NET foundation, visualizing
the next Windows API (WinFX, which is .NET) is not that hard to imagine.
I've said this multiple times already, but Microsoft's website will state
all these topics explicitly. In fact, reading my post is rather unbeneficial
because of how exhaustive their website is. Please just do your research.
I've directly you to the right places: Brad Abrams (and the entire BCL, that
is, Base Class Library team), the “Longhorn” team, and WinFX.
It would be a colossal waste of resources for MS to rewrite Office in any
language. If they were even considering it, it would make more sense for
them to spend those resources writing a new operating system...from
scratch...with a truly object oriented programming interface. Of course,
due to backward compatibility, that is something MS can't afford to do
anytime soon...but I digress...
My .02c USD
-sb
"CMM" <CM*@discussions.microsoft.com> wrote in message
news:40**********************************@microsof t.com... Well, I doubt they would use C#... but rather Managed C++.
And the main point of the rewrite would be to lose the reliance on direct
Win32 API's and to gain the stability and security that the managed
runtime
brings.
"Tony Antonucci" wrote:
You have to think that Office is a huge code base currently. It would be
very
expensive to rewrite that code base in managed C#, and what value would
that
add?
My guess, is that the softies are writing a lot of new code in managed
C#,
but they don't see any reason to rewrite exisiting applications.
"Herr Lucifer" <"\n" wrote:
> As the founder of .NET framework, Microsoft claims that it invention
> will be
> the next best platform for programming in a near future. Now it is
> 2005,
> ..NET is 5 years old, and can talk and walk for himself with some help
> of his
> mum.
> However, we see the same native office applications are coming out
> again,
> and many other tools in SP2 of XP which could be in managed code....but
> are
> not. So, as the inventor of .NET , why doesn't Microsoft itself use
> "DOTNET"
> in its applications? Is there any concern over the baby's runnung
> performance inside Microsoft itself, or they gonna teach the baby how
> to run
> like a C kinda guy in future, so that they'll be able to use it for
> themselves?
>
>
>
>
>
>
>
"SB" wrote: <snip> scratch...with a truly object oriented programming interface. Of course,
due to backward compatibility, that is something MS can't afford to do
anytime soon...but I digress...
Why not? That's what VM's are for. How do you think modern day Windows
supports Win16 and DOS?
SQL Server 2005 was actually written using .NET??? I doubt that. I know it
"supports" .NET extensions (sp's written with .NET), but I doubt SQL Server
itself is.
Also I should footnote that VS 2005 and SQL 2005 are not 100% managed. This
is not the intend of phase 2 of the .NET framework. A-Z development
including lower-level functionality is phase 3. That which part 2 unifies is
what these products use.
It has gone too far.... finally, do i have to be optimist or cynic for the
future of .NET ?
You do have to be optimist! Just look around - we are going to the future :)
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... It has gone too far.... finally, do i have to be optimist or cynic for the
future of .NET ?
You are in it too. Success depends on us all. Literally.
If you are a cynic, you have yourself to blame.
If you are an optimist, we all have you to thank.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... It has gone too far.... finally, do i have to be optimist or cynic for the
future of .NET ?
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... It has gone too far.... finally, do i have to be optimist or cynic for the
future of .NET ?
Cynic, of course. The perfect operating system, UNIX, and the perfect
programming language, C, were released 1/3 of a century ago. No further
progress in computing has ever occurred. :) :) :)
Excellent point...but that would be one heck of a VM. To be able to run
DOS, Win16, Win32, Win64 all by simulating the old WinAPI (since it would be
completely replaced with a new OO design). That would be a feat but it
could be done.
-sb
"CMM" <CM*@discussions.microsoft.com> wrote in message
news:56**********************************@microsof t.com... "SB" wrote: <snip> scratch...with a truly object oriented programming interface. Of
course,
due to backward compatibility, that is something MS can't afford to do
anytime soon...but I digress...
Why not? That's what VM's are for. How do you think modern day Windows
supports Win16 and DOS?
Eh, maybe not. I don't know. It doesn't have to be built "on top" of the new
framework. I mean, does the Win16 VM (a.k.a. WOW) in NT/2K/XP thunk up to
Win32. I don't think so. It runs in its own seperate "world" insulated from
the rest of Win32.... and like I said... the Kernel itself wouldn't change.
But, now that I think of it there are I/O (driver model) issues if the
driver model where to change dramatically in the new Framework. It would be
quite a feat. But, if Apple can do it... I really can't see why MS can't.
"SB" wrote: Excellent point...but that would be one heck of a VM. To be able to run
DOS, Win16, Win32, Win64 all by simulating the old WinAPI (since it would be
completely replaced with a new OO design). That would be a feat but it
could be done.
-sb
"CMM" <CM*@discussions.microsoft.com> wrote in message
news:56**********************************@microsof t.com... "SB" wrote: <snip> scratch...with a truly object oriented programming interface. Of
course,
due to backward compatibility, that is something MS can't afford to do
anytime soon...but I digress...
Why not? That's what VM's are for. How do you think modern day Windows
supports Win16 and DOS?
I don't think so either. It has CLR support however.
--
William Stacey, MVP http://mvp.support.microsoft.com
"CMM" <CM*@discussions.microsoft.com> wrote in message
news:A6**********************************@microsof t.com... SQL Server 2005 was actually written using .NET??? I doubt that. I know it
"supports" .NET extensions (sp's written with .NET), but I doubt SQL
Server itself is.
Hm. Yeah! I agree with you - C is perfect, UNIX is cool but it's not the
future :).
Are you still wanting to spend months and months coding and debugging
application you can easily create using C# or VB.NET and the greatest IDE we
ever had - Visual Studio? ;)
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote in message
news:OI**************@TK2MSFTNGP14.phx.gbl...
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... It has gone too far.... finally, do i have to be optimist or cynic for
the future of .NET ?
Cynic, of course. The perfect operating system, UNIX, and the perfect
programming language, C, were released 1/3 of a century ago. No further
progress in computing has ever occurred. :) :) :)
Just start using it and then let us know what you think.
--
William Stacey, MVP http://mvp.support.microsoft.com
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:#2**************@TK2MSFTNGP12.phx.gbl... It has gone too far.... finally, do i have to be optimist or cynic for the
future of .NET ?
What we've got in C is "quiet" like what we have in C#. Why? because both
languages don't do any "machine level" thing on their own. Well, C- the
great language- has the chance of having a compiler which translates the C
code into the native machine code directly. However, in C#, we have a layer
in between (an intermediate language) which is the reason for all these
troubles. I believe if there was a "Native Image Generator", which could
really generate native images, just like the final thing you make by using
C, there wouldn't be any more troubles over performance issues in .NET
desktop apps as we see now.
PS: I personally think the framework is great (and its modern oo design),
sth that you can never have when using C , nevertheless, this framework
could be harnessed in much better ways by much better compilers. For
example, imagine by third-party compilers that would compile your .NET code
(VB or C#) into machine level instruction directly.(just my idea)
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote : Cynic, of course. The perfect operating system, UNIX, and the perfect
programming language, C, were released 1/3 of a century ago. No further
progress in computing has ever occurred. :) :) :)
And don't forget that no one today uses binary programming any more.
Definitely binary is more powerful than C, but even "God" doesn't have time
to do that in the modern world of today, when you gotta make apps in a very
short time. And C# will be also a slow way of doing things in the next 10-15
years. May, just maybe, we see computers that programs themselves at that
time, who knows? ;)
"gaidar" <ga****@vbstreets.ru> wrote: Hm. Yeah! I agree with you - C is perfect, UNIX is cool but it's not the
future :).
Are you still wanting to spend months and months coding and debugging
application you can easily create using C# or VB.NET and the greatest IDE
we ever had - Visual Studio? ;)
you need to read up on the JIT compiler.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:u1*************@tk2msftngp13.phx.gbl... What we've got in C is "quiet" like what we have in C#. Why? because both
languages don't do any "machine level" thing on their own. Well, C- the
great language- has the chance of having a compiler which translates the C
code into the native machine code directly. However, in C#, we have a
layer in between (an intermediate language) which is the reason for all
these troubles. I believe if there was a "Native Image Generator", which
could really generate native images, just like the final thing you make by
using C, there wouldn't be any more troubles over performance issues in
.NET desktop apps as we see now.
PS: I personally think the framework is great (and its modern oo design),
sth that you can never have when using C , nevertheless, this framework
could be harnessed in much better ways by much better compilers. For
example, imagine by third-party compilers that would compile your .NET
code (VB or C#) into machine level instruction directly.(just my idea)
"Michael A. Covington" <lo**@ai.uga.edu.for.address> wrote : Cynic, of course. The perfect operating system, UNIX, and the perfect
programming language, C, were released 1/3 of a century ago. No further
progress in computing has ever occurred. :) :) :)
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> wrote in message
news:OZ*************@tk2msftngp13.phx.gbl... And don't forget that no one today uses binary programming any more.
Definitely binary is more powerful than C, but even "God" doesn't have
time to do that in the modern world of today, when you gotta make apps in
a very short time. And C# will be also a slow way of doing things in the
next 10-15 years. May, just maybe, we see computers that programs
themselves at that time, who knows? ;)
They were saying that 30 years ago. (Not C# but Fortran... but otherwise
the same claim.)
see NGEN
--
William Stacey, MVP http://mvp.support.microsoft.com However, in C#, we have a layer
in between (an intermediate language) which is the reason for all these
troubles. I believe if there was a "Native Image Generator", which could
really generate native images, just like the final thing you make by using
C, there wouldn't be any more troubles over performance issues in .NET
desktop apps as we see now.
Hello, CMM!
You wrote on Thu, 3 Mar 2005 10:17:03 -0800:
C> I agree... and I'm not saying it's a totally bad thing. But, I think at
C> some point MS has to show that they're true innovators and not just
C> evolutionary. .NET is probably the most ambitious and courageous thing
C> to come from Redmond since Windows 95. Now we have to wait to see if
C> that courage extends to the rest of the Windows world.
I do not see ANY reasons to deprecate any old technology/API. If API exists
and works fine why not put it into next release of Windows along with all
the new stuff?
I am glad that I can run most of old software under Windows XP and I am
really happy when I can use my old C++ code for Windows or even Windows
CE(!).
You see, deprecating any API usually only creates problems to developers,
and leads to creating proprietary solutions to avoid dependency on MS
libraries.
Say, using ADOCE&C++ to make calls to SQL Server CE is now deprecated, which
wiil force us to make a lot of work rewriting ADOCE wrappers to OLEDB
wrappers.
What is innovation here?
Why fo I need innovaton? Space? But flash/HDD storage is constantly growing.
Security? Cost of support? ADOCE is not supported for several years but we
use it without a problem.
Yes, I understand you ideas, but I think it will not pay its price. I
believe that the evolution is the best way for tecnology. It's good that
new technologies appear but let's not forget about real world, about real
long-term projects, about a lot of code writteng during last decade. Don't
force developers to use new technologies removing old ones. Better create
better technologies and developers will certainly use them!
There is no reason to deprecate anything that works. Just spend several
hours compiling it for new platform (if needed) and that's all!
Regards, Vyacheslav Lanovets
I would disagree. You say you don't see ANY reason...
Remember the Gopher security hole in IE from a couple of years ago? I mean,
who uses Gopher??? And if you really had to, I'm sure there's a nice 3rd
party solution out there for you. The rest of us 99.9999 don't need it.
Here are your reasons:
1) Security and stability. Old code is often not just "old" it's also BAD.
And it's not just the code... which would suggest that one could fix it...
it's that the whole technology that it's built on is BAD. Case-in-point...
DDE and the WM architecture. Cross window messaging in the Windows World is
extremely insecure and often unstable. Remember the Timer exploit (I think
that's what it was called) last year that allowed someone to elevate their
privileges on a machine by "injecting" certain running Services?
2) Programmers are lazy and will not abandon a technology until they're
forced to. For instance, for years programmers have been storing user
settings in the program's own folder in Program Files... despite User
Profiles being around since Windows 95. It wasn't until WinXP and it's
"limited user" mode and corporate Admins finally locking down their systems
in the past few years that programmers have finally started doing the RIGHT
THING and storing stuff in %USERPROFILE%.
"Vyacheslav Lanovets" wrote: Hello, CMM!
You wrote on Thu, 3 Mar 2005 10:17:03 -0800:
C> I agree... and I'm not saying it's a totally bad thing. But, I think at
C> some point MS has to show that they're true innovators and not just
C> evolutionary. .NET is probably the most ambitious and courageous thing
C> to come from Redmond since Windows 95. Now we have to wait to see if
C> that courage extends to the rest of the Windows world.
I do not see ANY reasons to deprecate any old technology/API. If API exists
and works fine why not put it into next release of Windows along with all
the new stuff?
I am glad that I can run most of old software under Windows XP and I am
really happy when I can use my old C++ code for Windows or even Windows
CE(!).
You see, deprecating any API usually only creates problems to developers,
and leads to creating proprietary solutions to avoid dependency on MS
libraries.
Say, using ADOCE&C++ to make calls to SQL Server CE is now deprecated, which
wiil force us to make a lot of work rewriting ADOCE wrappers to OLEDB
wrappers.
What is innovation here?
Why fo I need innovaton? Space? But flash/HDD storage is constantly growing.
Security? Cost of support? ADOCE is not supported for several years but we
use it without a problem.
Yes, I understand you ideas, but I think it will not pay its price. I
believe that the evolution is the best way for tecnology. It's good that
new technologies appear but let's not forget about real world, about real
long-term projects, about a lot of code writteng during last decade. Don't
force developers to use new technologies removing old ones. Better create
better technologies and developers will certainly use them!
There is no reason to deprecate anything that works. Just spend several
hours compiling it for new platform (if needed) and that's all!
Regards, Vyacheslav Lanovets
On Mon, 7 Mar 2005 17:07:02 -0800, CMM <CM*@discussions.microsoft.com>
wrote: 2) Programmers are lazy and will not abandon a technology until they're
forced to.
There are only 24 hours in a day, and (some) programmers have a life
besides coding.
Joe.
Did anyone know that MOST OF THE CODES OF AVALON IN MICROSOFT WINDOWS
LONGHORN IS WRITTEN IN C# (C# is one of the .net Language).
What is your source of this.
--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
------------------------------------------------------------
"Guruparan" <Gu*******@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com... Did anyone know that MOST OF THE CODES OF AVALON IN MICROSOFT WINDOWS
LONGHORN IS WRITTEN IN C# (C# is one of the .net Language).
Joe,
Amen to that. The marketplace can only absorb so much, so fast --
especially when there is no business reason to do so, or far more pressing
business reasons to do other things.
Having said that, there does eventually come a time and place where it
becomes compelling to rewrite any code base, even in the absence of
motivators like new technology platforms, changing requirements, difficulty
in locating or developing expertise, or the winds of politics. Any body of
code that has been through enough revisions can benefit tremendously from a
complete rewrite, lest it become like a bedroom closet full of miscellaneous
add-ons and false starts. The larger the body of code, and the more people
who have worked on it, and the less satisfactory the original architectural
decisions were, the truer this is. The trick is always how to decide where
that tipping point is.
--Bob
"Joe" <ju*******@if.you.want.to.contact.me> wrote in message
news:60********************************@4ax.com... On Mon, 7 Mar 2005 17:07:02 -0800, CMM <CM*@discussions.microsoft.com>
wrote:2) Programmers are lazy and will not abandon a technology until they're
forced to.
There are only 24 hours in a day, and (some) programmers have a life
besides coding.
Joe.
There is more to .Net than just Windows forms applications. There are a
number of companies creating, migrating and incorporating ASP.Net web
applications in their websites.
"Herr Lucifer" <"\n" wrote: As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
On Tue, 8 Mar 2005 10:07:26 -0700, "Bob Grommes" <bo*@bobgrommes.com>
wrote: Having said that, there does eventually come a time and place where it
becomes compelling to rewrite any code base, even in the absence of
motivators like new technology platforms, changing requirements, difficulty
in locating or developing expertise, or the winds of politics.
I agree. As to whether that requires 100MB of code while Delphi and VB
presented a highly productive OO interface to the underlying
procedural Win32 API in a couple of megabytes...
Joe.
In an excellent article by Richard Grimes, http://www.ddj.com/documents/s=9211/ddj050201dnn/, the ex-Microsoft guru
lambasts MS' seriousness to .NET and VB.NET as a redundant language. Truth
hurts.
At the same time, .NET isn't going away, it's just C++ remains superior for
destkop applications.
"Herr Lucifer" <"\n" wrote: As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
"Joe" <ju*******@if.you.want.to.contact.me> wrote in message
news:ch********************************@4ax.com... On Tue, 8 Mar 2005 10:07:26 -0700, "Bob Grommes" <bo*@bobgrommes.com>
wrote:Having said that, there does eventually come a time and place where it
becomes compelling to rewrite any code base, even in the absence of
motivators like new technology platforms, changing requirements,
difficulty
in locating or developing expertise, or the winds of politics.
I agree. As to whether that requires 100MB of code
The Framework is not 100MB. The install is 25MB and once installed they're
about 65 MB I believe.
while Delphi and VB
presented a highly productive OO interface to the underlying
procedural Win32 API in a couple of megabytes...
Our figures indicate that our developer productivity has gone up by 50%
since switching to .NET. Given an average developer salary of 25,000 South
African Rands and 4 developers that indicates a one-year saving of R600,000.
No contest as far as I'm concerned.
Joe.
i"TheBain" <Th*****@discussions.microsoft.com> wrote in message
news:E9**********************************@microsof t.com... In an excellent article by Richard Grimes,
http://www.ddj.com/documents/s=9211/ddj050201dnn/, the ex-Microsoft guru
lambasts MS' seriousness to .NET and VB.NET as a redundant language.
And many of his points have been refuted, even he concedes as much in the
comments in http://weblogs.asp.net/danielfe/arch...22/378343.aspx.
In any case his main thrust seems to be that VB.NET was just a marketing
ploy to get VB developers working on the .NET Framework. This is a point I
heartily agree with. However I see this as a good thing, since it has helped
spur adoption of the Framework. In addition he praises the C# language, his
only "complaint" being that it's remarkably similar to Java. This would be
no real surprise since both C# and Java are C-family languages targetting a
managed execution environment.
He does raise some good points about parts of the Framework having being
rushed though. Nonetheless his comments that MS is not using .NET to write
major revenue generating software seems to be incorrect (see
http://blogs.msdn.com/danielfe/archi...02/251254.aspx)
Truth hurts.
Truth? I didn't see anywhere in his article where he claimed he was
delivering truth. In fact he goes out of his way to say that this is merely
his opinion, several times. In addition, you say "ex-Microsoft guru", and
all I see is that he's stopping work in .NET, not on Microsoft products.
At the same time, .NET isn't going away, it's just C++ remains superior
for
destkop applications.
Which desktop applications exactly? In what way do you think C++ is superior
to .NET for these? Are you referring to speed? If so, then I can't disagree.
If you're referring to developer productivity then I can. If you're
referring to security and reliability, again, I disagree. Whilst *some* C++
developers are reliably able to write code that doesn't result in memory
leaks, dangling pointers and buffer overruns, their numbers are few indeed.
"Herr Lucifer" <"\n" wrote:
As the founder of .NET framework, Microsoft claims that it invention will
be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
On Wed, 9 Mar 2005 07:21:47 +0200, "Sean Hederman"
<us***@blogentry.com> wrote: The Framework is not 100MB. The install is 25MB and once installed they're
about 65 MB I believe.
Thanks for the correction. But still, it's _humongous_ compared to the
VB or Delphi runtimes.
Our figures indicate that our developer productivity has gone up by 50%
since switching to .NET.
Right, something VB and Delphi users have know all alolong :-)
Joe.
"Joe" <ju*******@if.you.want.to.contact.me> wrote in message
news:4b********************************@4ax.com... On Wed, 9 Mar 2005 07:21:47 +0200, "Sean Hederman"
<us***@blogentry.com> wrote:The Framework is not 100MB. The install is 25MB and once installed they're
about 65 MB I believe.
Thanks for the correction. But still, it's _humongous_ compared to the
VB or Delphi runtimes.
Yes, but...
- With VB you generally have to distribute many large OCX's with your
application.
- With Delphi the libraries are compiled into your application.
- The .NET libraries are FAR more comprehensive than the VB libraries.
It's a tricky path to walk. On the one side MS could offer a scaled down
version of the Framework, excluding things like System.Messaging,
System.Web, System.EnterpriseServices, System.Management and suchlike. The
thing is that then your programs that relied on those components would
sometimes work and sometimes not. People would have to know whether to
download the "Lite", "Regular", or Enterprise frameworks, depending on which
programs they wanted to run. I can just see people downloading the 15MB
"Lite", then being informed by one application that they need "Regular",
bang goes another 20MB download. A week later they get told by some other
app that it won't work without the 25MB "Enterprise".
The point that I'm trying to make is that the Framework provides a
completely reliable environment. If your programming is running on the right
version, all the services that your program uses are guaranteed to be there. Our figures indicate that our developer productivity has gone up by 50%
since switching to .NET.
Right, something VB and Delphi users have know all alolong :-)
Joe.
Hello, Bob!
You wrote on Tue, 8 Mar 2005 10:07:26 -0700:
BG> Having said that, there does eventually come a time and place where it
BG> becomes compelling to rewrite any code base, even in the absence of
BG> motivators like new technology platforms, changing requirements,
BG> difficulty in locating or developing expertise, or the winds of
BG> politics. Any body of code that has been through enough revisions can
BG> benefit tremendously from a complete rewrite, lest it become like a
BG> bedroom closet full of miscellaneous add-ons and false starts. The
BG> larger the body of code, and the more people who have worked on it, and
BG> the less satisfactory the original architectural decisions were, the
BG> truer this is. The trick is always how to decide where that tipping
BG> point is.
I agree with you but not completely :) From one point of view, complete
rewrite is cool - it's interesting to use new technologies from the latest
MSDN Magazine / C++ Users Journal issues :) The system developed looks like
Christmas Tree with all of the different stuff on it :) Then, when it
becomes too overloaded and new technologies become old and are going to die,
there is a time for complete rewrite.
But, besides of all obvious economical reasons not to spend time on complete
rewrite there are some more points from my developer's point of view.
One is that sometimes the greatest value of the code is not the code itself
but _what_ was coded - the logic and the algorithms. If some algorithm's
implementation in C was fine 10 years ago, still fine now, and will be fine
in 10 years, why it should be implemented in VB.Net? Reason of this is that
nobody made complete rewrite of linear algebra or discrete math recently:)
The second one is refactoring. I saw many projects where developers did only
what they were said to do. And in most straightforward way. On the top of
this some of them tried to use brand new technologies (just from recent MSDN
Mag issue). But I saw projects where developers tried to refactor to some
extent - in this case each revision added not only features but code
quality. While I understand why first projects should be completely
rewritten, second ones usually can live without it.
And the third one - after several revisions during _normal_ development
process the software becomes near-to-perfect. I mean it's hard to make it
better from the first try, particularly in new language and under new
platform.
I think about this every time when we find a bug in the code which worked
and was tested for years! With every new bug found the system becomes more
and more perfect, I can not believe it's possible to write such from
scratch.
So, when you say that revisions only make product worse then it means that
something wrong with development. The problem of such software products
where revisions just spoil the code lies in relationship between developers
and management. From my experience, it's enough to have several (10-20%)
good developers or good PM to avoid this.
For instance, I always note what files changed when I check out files from
VCS, and if I see incorrect decision made by my colleague, and this code
relates to my responsibilities, and I do not have time at the moment, then I
add new item to my Tasks in Outlook - to not to forget to fix that.
I would agree, that there are times when there is a need in complete
_refactor_ but not rewrite.
With best regards, Vyacheslav Lanovets. E-mail: xentrax_umail.ru
Java tried that route with swing. Look where it got them. Java fist started
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen what
a swing app looks like? Believe me it’s not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
"alejandro lapeyre" wrote: That is why I said there is a lot of work to do.
there is nothing done yet.
regards,
Alejandro Lapeyre
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> escribió en el mensaje
news:O5**************@tk2msftngp13.phx.gbl...
"alejandro lapeyre" <al**************@jotmail.com> wrote The .NET is great, but it needs a lot of work to replace the windows api.
Before asking that Office is written in .NET, the ListBox should be
written in .NET!
Replace the API? You're kidding! Dot Net doesn't really do anything on its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is
really there.
Download and use this disassembler: (Reflector)
"http://www.aisto.com/roeder/dotnet"
Anf that is why there is not a wrapper API for DDE. What is the harm of
supporting existing APIs and moving forward?
"CMM" wrote: I think that was the poster's point.
Back in 1996 MS was toying around with the idea of completely rewriting the
Win32 API and create a true object oriented OS (remember Cairo?). The .NET
Framework IS what Cairo was suppossed to be... minus the Win32 underlying
layer doing all the work though.
I strongly believe that for MS to remain competive in the long run they have
to strip out Win32 (and make it run as an on-the-side virtual machine for
compatibility) exactly the same way Apple did with MacOS. MS can keep the
Kernel (removing deprecated API's from it) but completely ditch Shell32 and
many of the other adjunct components completely. Unfortunately, MS has always
been hellbent on 110% backwards compatibility... which is why Windows suffers
from so many problems today. I mean, DDE is still there!!! (and some apps
including Windows Explorer still use it!!!!!).
"Herr Lucifer" <"\n" wrote:
"alejandro lapeyre" <al**************@jotmail.com> wrote The .NET is great, but it needs a lot of work to replace the windows api.
Before asking that Office is written in .NET, the ListBox should be
written in .NET!
Replace the API? You're kidding! Dot Net doesn't really do anything on its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is really
there.
Download and use this disassembler: (Reflector)
"http://www.aisto.com/roeder/dotnet"
So, it is important for the framework to include a ListBox.
Or, is it important for the framework to wrap the win32 api ListBox?
Against wrapped controls:
There are two controls that provide list support: the ListView and the
ListBox. The ListBox can handle rows of different height, something the
ListView does not. But the maximum row height is only 256 pixels. The update
routines for the ListBox are horrible (lots of flashing).
So i think it is good candidate for replacement.
We have been in this wrapping path for a very lon time (At least from vb3).
And there have *allways* been a lot of wrapping errors, missing features,
etc. And, I dont like to see a a hundred of internal calls just to add an
item to a ListBox.
Yes, we can write new controls, and that is very easy now! (compared to what
is was in VB5 or VB6). So can do framework. In case we need those wrappers,
we could also build them. So, what is neccesary: a wrapper to a win32
ListBox or a ListBox?
<
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
Note that updates to the underlying win32 implementation will not be
magicaly implemented in a previous framework wrapped control. If you care
about the fancy drawing details, then the framework could define a new class
that would wrap the painting of the controls (and you get the "system"
painting).
But I know there is a more important question here, what do I want the
framework to be? what do you? and finally what wants Microsoft?
I am happy that I can write programs using the .NET. And using Lutz Roeder's
Reflector I can (almost) allways see what the framework code is doing. For
me it is great advance over VB5 (or VB5.1 = VB6).
I have not read the full code for the framework. But the only thing I can
remember that was in the win32 api and was not wrapped is the URL class. So
there is at least something that is not wrapped (and could have been)!
Best Regards,
Alejandro Lapeyre
"palang" <pa****@discussions.microsoft.com> escribi en el mensaje
news:A6**********************************@microsof t.com...
Java tried that route with swing. Look where it got them. Java fist started
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen
what
a swing app looks like? Believe me it's not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which
is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net
framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
"alejandro lapeyre" wrote:
That is why I said there is a lot of work to do.
there is nothing done yet.
regards,
Alejandro Lapeyre
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> escribi en el mensaje
news:O5**************@tk2msftngp13.phx.gbl...
"alejandro lapeyre" <al**************@jotmail.com> wrote The .NET is great, but it needs a lot of work to replace the windows
api.
Before asking that Office is written in .NET, the ListBox should be
written in .NET!
Replace the API? You're kidding! Dot Net doesn't really do anything on
its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is
really there.
Download and use this disassembler: (Reflector)
"http://www.aisto.com/roeder/dotnet"
"Vyacheslav Lanovets" <xentrax_umail.ru> wrote in message
news:eg**************@TK2MSFTNGP12.phx.gbl... Hello, Bob!
You wrote on Tue, 8 Mar 2005 10:07:26 -0700:
BG> Having said that, there does eventually come a time and place where it
BG> becomes compelling to rewrite any code base
If some algorithm's implementation in C was fine 10 years ago, still fine
now, and will be fine in 10 years, why it should be implemented in VB.Net?
Nah, not in VB.NET, in C#.
Seriously, though, when I say "complete rewrite", I don't mean that so
literally that every single line of code will be rewritten. For example,
come the year 2020, let us suppose that Microsoft has decided that C# is a
thing of the past and we should use D# or E Flat or whatever they come up
with for Visual Studio 2020 and the Quantum.NET Framework running under
Windows HyperServer 2020 for AMD 256 bit processors. Now if I did a rewrite
of a project originally concieved way back in 2005, and I had a general
purpose routine in the original C# code that does matrix addition or token
parsing or something of a very basic nature, and I could call the old code
without a significant penalty, I would in most cases leave that code
completely alone. It's usually no individual routines that are the problem
so much as higher level things like where they are in the object hierarchy
and how objects are composited at runtime and the contracts they have with
each other.
While I understand why first projects should be completely rewritten,
second ones usually can live without it.
It's true that all things being equal, each subsequent system is better,
stabler, and longer-lasting than the previous one. But organizational,
budgetary, technological and political realities tend to conspire against
this. In my experience over more than two decades, taken as a whole, every
system is built with some compromises, some bad assumptions, and some lack
of anticipating what direction things are going to evolve in, no matter how
much talent, care and foresight is applied. Such systems acquire what I
call "system lint". These are regrettable artifacts that start out as
insignificant annoyances and slowly evolve into roadblocks. They will never
really go away without extensive revision or rewriting. Of course you have
to be careful not to introduce new problems in the same process!
Then, too, projects sometimes push the limits of current technology
platforms. I'm put in mind of a classic ASP project that evolved into a
painful mass of nested #includes and Response.Write statements and would be
able to be implemented so much cleaner and maintained so much more cheaply
in ASP.NET. But to do this would require an extensive rewrite.
I'm also currently working on a project that is itself a complete rewrite of
a FoxPro 2.6 application from 1991 or so; we're re-doing it in VB.NET and
SQL Server. Fox 2.x is pre-OOP, and porting it to FoxPro 9.0 would have
been quite a project, and then there is always the fear that all the
prophecies about the demise of Fox that have continued decade after decade
will finally become self-fulfilling one day soon, so we decided it was no
more work to just move it over to .NET. You can barely get the Fox 2.x
runtime to function under Win32, and the UI is sort of Win 3.1 in appearance
and rather atypical in the details of its behavior even aside from visuals.
The software is sold commercially to a vertical market. It's an
embarrassment to the client, and that's why they want to bring it up to
date. That, and have a code base that will take them through the next
couple of decades (or more if possible).
As we've reworked this application we have many times asked the client, why
does feature X work this way? Isn't that a little inconsistent? Well yes,
but we just didn't think of that at the time and it's been a problem ever
since -- by all means change it. What about feature Y, isn't Z a better
way? Sure, sure, use Z. We just couldn't do Z back in those days. It
wasn't available / didn't work / was too hard. So along the way, the
product is getting considerably better from a usability standpoint, yet with
minimal retraining issues for the user. These are all "WOW, this is a big
improvement / much more intuitive" kind of things.
And the third one - after several revisions during _normal_ development
process the software becomes near-to-perfect. I mean it's hard to make it
better from the first try, particularly in new language and under new
platform.
If an application is feature complete and stable and won't change much, yes.
But most applications evolve constantly as business needs change. Even when
they don't, technology changes can be a problem. For example, a text-based,
80 column by 24 line user interface written in COBOL may be perfectly
serviceable, but it's also a very atypical environment for users, it may not
integrate well with other technologies, and it may be expensive and
difficult to find or develop COBOL talent when it does need to be tweaked.
So, when you say that revisions only make product worse then it means that
something wrong with development.
But I don't say that revisions only make a product worse -- especially
individual revisions, taken individually. I only say that the overall
design becomes out of sync with current realities and becomes increasingly
expensive to maintain.
And please remember, I'm talking about time frames much longer than most
people contemplate in their IT planning. I'm talking about 10, 15, 20 year
old systems. Maybe in rare cases, 5 year old systems. I've been
architecting systems for 22 years; it tends to make me take a longer view of
things.
Best,
--Bob
Who cares about a ListBox if .NET allows me to write my apps faster since a
bunch of stuff is done for me by the FRAMEWORK.
It could be written or wrap whatever for all I care...
:-)
"alejandro lapeyre" wrote: So, it is important for the framework to include a ListBox.
Or, is it important for the framework to wrap the win32 api ListBox?
Against wrapped controls:
There are two controls that provide list support: the ListView and the
ListBox. The ListBox can handle rows of different height, something the
ListView does not. But the maximum row height is only 256 pixels. The update
routines for the ListBox are horrible (lots of flashing).
So i think it is good candidate for replacement.
We have been in this wrapping path for a very lon time (At least from vb3).
And there have *allways* been a lot of wrapping errors, missing features,
etc. And, I dont like to see a a hundred of internal calls just to add an
item to a ListBox.
Yes, we can write new controls, and that is very easy now! (compared to what
is was in VB5 or VB6). So can do framework. In case we need those wrappers,
we could also build them. So, what is neccesary: a wrapper to a win32
ListBox or a ListBox?
<
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
Note that updates to the underlying win32 implementation will not be
magicaly implemented in a previous framework wrapped control. If you care
about the fancy drawing details, then the framework could define a new class
that would wrap the painting of the controls (and you get the "system"
painting).
But I know there is a more important question here, what do I want the
framework to be? what do you? and finally what wants Microsoft?
I am happy that I can write programs using the .NET. And using Lutz Roeder's
Reflector I can (almost) allways see what the framework code is doing. For
me it is great advance over VB5 (or VB5.1 = VB6).
I have not read the full code for the framework. But the only thing I can
remember that was in the win32 api and was not wrapped is the URL class. So
there is at least something that is not wrapped (and could have been)!
Best Regards,
Alejandro Lapeyre
"palang" <pa****@discussions.microsoft.com> escribió en el mensaje
news:A6**********************************@microsof t.com...
Java tried that route with swing. Look where it got them. Java fist started
with an AWT which used the native OS API directly. Then Sun came out with
swing, which is a pure java implementation of the UI. Have you ever seen
what
a swing app looks like? Believe me it's not something to brag about. Almost
everybody I talk to that is currently using java is switching to SWT which
is
once again an API developed using the native OS UI API.
Also,
Why wouldn't Microsoft want to take advantage of the underlying Win32 API?
If the OS shell ever changes (hint Windows XP and themes), the .Net
framework
would be consistent out of the box.
Therefore, having the .Net framework utilize the Win32 API will give us a
consistent look and feel. Whereas having a pure managed implementation might
give us a consistent UI but would certainly have to be changed with every
release of the OS and framework version.
That is the beauty of the framework. It allows you to easily interop with
Win32 and COM.
"alejandro lapeyre" wrote:
That is why I said there is a lot of work to do.
there is nothing done yet.
regards,
Alejandro Lapeyre
"Herr Lucifer" <"\n"HerrLucifer\n@microsoft.com> escribió en el mensaje
news:O5**************@tk2msftngp13.phx.gbl...
"alejandro lapeyre" <al**************@jotmail.com> wrote
> The .NET is great, but it needs a lot of work to replace the windows
> api.
> Before asking that Office is written in .NET, the ListBox should be
> written in .NET!
Replace the API? You're kidding! Dot Net doesn't really do anything on
its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is
really there.
Download and use this disassembler: (Reflector)
"http://www.aisto.com/roeder/dotnet"
On Wed, 9 Mar 2005 16:14:41 +0200, "Sean Hederman"
<us***@blogentry.com> wrote: The point that I'm trying to make is that the Framework provides a
completely reliable environment. If your programming is running on the right
version, all the services that your program uses are guaranteed to be there.
Good points. Thx :-)
Joe.
The SQL Server 2005 Beta I have has certain amount of .NET integration and
requires the framework. Next year (hopefully) will be Longhorn. We're talking
about PRETTY BIG projects. I guess Exchange and Office go after that.
"Herr Lucifer" <"\n" wrote: As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
I would like to post a big round of thanks to Delphi developers. For
creating products that rely on a framework/ runtime that does not make
the upgrade from one major os change to the next. Therefore migrating
customers from a windows 98/pre 2k era to an xp/2k3 era is extremely
painful as one runs into major bugs that running 100 application
compatability wizards and patches is unable to solve. Thank you
developers for creating software that was not only crappy and bloated
but had a limited life cycle and had to be rebuilt.
And the VB4/5/6 runtimes were humongous and downright prohibitive compared to
the VB3 runtime (200k and side-by-side capable to boot!). Don't even get me
started on MFC.
Your point is without insight.
"Joe" wrote: On Wed, 9 Mar 2005 07:21:47 +0200, "Sean Hederman"
<us***@blogentry.com> wrote:The Framework is not 100MB. The install is 25MB and once installed they're
about 65 MB I believe.
Thanks for the correction. But still, it's _humongous_ compared to the
VB or Delphi runtimes.
Our figures indicate that our developer productivity has gone up by 50%
since switching to .NET.
Right, something VB and Delphi users have know all alolong :-)
Joe.
If DDE and its peripheral technology posed a constant security hole and very
few developers use it and MS has been warning to abandon it for 10+ years,
then it should be removed.
"palang" wrote: Anf that is why there is not a wrapper API for DDE. What is the harm of
supporting existing APIs and moving forward?
"CMM" wrote:
I think that was the poster's point.
Back in 1996 MS was toying around with the idea of completely rewriting the
Win32 API and create a true object oriented OS (remember Cairo?). The .NET
Framework IS what Cairo was suppossed to be... minus the Win32 underlying
layer doing all the work though.
I strongly believe that for MS to remain competive in the long run they have
to strip out Win32 (and make it run as an on-the-side virtual machine for
compatibility) exactly the same way Apple did with MacOS. MS can keep the
Kernel (removing deprecated API's from it) but completely ditch Shell32 and
many of the other adjunct components completely. Unfortunately, MS has always
been hellbent on 110% backwards compatibility... which is why Windows suffers
from so many problems today. I mean, DDE is still there!!! (and some apps
including Windows Explorer still use it!!!!!).
"Herr Lucifer" <"\n" wrote:
"alejandro lapeyre" <al**************@jotmail.com> wrote
> The .NET is great, but it needs a lot of work to replace the windows api.
> Before asking that Office is written in .NET, the ListBox should be
> written in .NET!
Replace the API? You're kidding! Dot Net doesn't really do anything on its
own. It only calls the unmanegd APIs (built in Win32) from a managed
environment. Take a look inside the framework yourslef to see what is really
there.
Download and use this disassembler: (Reflector)
"http://www.aisto.com/roeder/dotnet"
Is it really true? .Net apps take ages to load?
"Herr Lucifer" <"\n" wrote: Well, If it takes ages to load, then it is one!(kidding)
Ok: simply Use "Dependency Walker" which comes with VS 6 and VS 2003.
By Serious I mean sth like office. Sth that would be sold to customers.
"DHOLLINGSWORTH2" <DH*************@cox.net> wrote in message
news:LqeUd.18615$yr.13621@okepread05...
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
message news:eL*************@TK2MSFTNGP09.phx.gbl... Applications apart from Content Management Server and most of BizTalk
2004?
Where is the business case for completely destabilizing the Office
codebase with a total rewrite?
And as others have stated - .NET's been released for 3 years not 5.
Regards
Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
As the founder of .NET framework, Microsoft claims that it invention
will be
the next best platform for programming in a near future. Now it is 2005,
.NET is 5 years old, and can talk and walk for himself with some help of
his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but
are
not. So, as the inventor of .NET , why doesn't Microsoft itself use
"DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to
run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
Would you know if the app your running is a dotnet app?
What do you consider "Serious"?
"Amir The Ruler" <Amir The Ru***@discussions.microsoft.com> wrote in message
news:6D**********************************@microsof t.com... Is it really true? .Net apps take ages to load?
Weelll, they take longer than an equivalent C++ app to be sure, but I don't
think I'd term it ages. I figure that you could add about 0.5 to 1 seconds
to an application load time on average. Needless to say there are ways to
cut this down a bit.
"Herr Lucifer" <"\n" wrote:
Well, If it takes ages to load, then it is one!(kidding)
Ok: simply Use "Dependency Walker" which comes with VS 6 and VS 2003.
By Serious I mean sth like office. Sth that would be sold to customers.
"DHOLLINGSWORTH2" <DH*************@cox.net> wrote in message
news:LqeUd.18615$yr.13621@okepread05... >
> "Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
> message news:eL*************@TK2MSFTNGP09.phx.gbl...
>> Applications apart from Content Management Server and most of BizTalk
>> 2004?
>>
>> Where is the business case for completely destabilizing the Office
>> codebase with a total rewrite?
>>
>> And as others have stated - .NET's been released for 3 years not 5.
>>
>> Regards
>>
>> Richard Blewett - DevelopMentor
>> http://www.dotnetconsult.co.uk/weblog
>> http://www.dotnetconsult.co.uk
>>
>> As the founder of .NET framework, Microsoft claims that it invention
>> will be
>> the next best platform for programming in a near future. Now it is
>> 2005,
>> .NET is 5 years old, and can talk and walk for himself with some help
>> of
>> his
>> mum.
>> However, we see the same native office applications are coming out
>> again,
>> and many other tools in SP2 of XP which could be in managed
>> code....but
>> are
>> not. So, as the inventor of .NET , why doesn't Microsoft itself use
>> "DOTNET"
>> in its applications? Is there any concern over the baby's runnung
>> performance inside Microsoft itself, or they gonna teach the baby how
>> to
>> run
>> like a C kinda guy in future, so that they'll be able to use it for
>> themselves?
>>
>>
>
> Would you know if the app your running is a dotnet app?
>
> What do you consider "Serious"?
>
>
If there is an application in widespread use that needs extreme performance,
much more than Office, is video editing. If I am correct, Sony Vegas is a
..net application. I use another product for video editing, I just downloaded
the Vegas trial, but I would say that Vegas performance is excellent. Thus,
..net performance is not a concern even for very large and extreme projects.
I agree with those who say Office is still com just because migration costs
are huge. I wouldn't bet it won't become .net in a few years.
"Herr Lucifer" <"\n" wrote: As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for himself with some help of his
mum.
However, we see the same native office applications are coming out again,
and many other tools in SP2 of XP which could be in managed code....but are
not. So, as the inventor of .NET , why doesn't Microsoft itself use "DOTNET"
in its applications? Is there any concern over the baby's runnung
performance inside Microsoft itself, or they gonna teach the baby how to run
like a C kinda guy in future, so that they'll be able to use it for
themselves?
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: VlaR |
last post by:
As I got no reply to my first post ("Serious bug in ngen.exe") within few business days but having
MSDN Universal Subscription I posting this problem again (with just registered nospam alias).
I...
|
by: xixi |
last post by:
i have a very serious memory problem, we have db2 udb v8.1 load on a
HP titanium machine with 4 G memory, it is 64bit machine, currently on
DB2 instance , i have three databases, but only one is...
|
by: BBFrost |
last post by:
We just recently moved one of our major c# apps from VS Net 2002 to VS Net
2003. At first things were looking ok, now problems are starting to
appear.
So far ...
(1) ...
|
by: WJ |
last post by:
This post is a follow up from the original post dated Oct 16, 2004 "I have
this problem, pls help!" created by Paul FI.
These bugs are rather serious and we would like to know how to get around.
...
|
by: Herr Lucifer |
last post by:
As the founder of .NET framework, Microsoft claims that it invention will be
the next best platform for programming in a near future. Now it is 2005,
..NET is 5 years old, and can talk and walk for...
|
by: Spotnick |
last post by:
I have no idea why, but since I'm trying to recreate my website using
ASP.NET 2.0 I've encountered so many performance issues that I'm about to
give up and continue using v1.1
Seriously, how can...
|
by: vijay.db |
last post by:
Hi Team,
Very serious problem with my DB2 V8.1 Fixpack 6 running in AIX 5.1
machine. Every one hour my DB2 instance processes are killed and it's
going down. Several trap files are generated in...
|
by: pcloches |
last post by:
I'm having a very difficult time with some of our new pages. We've
moved to a web farm, and it seems in spurts it will come where parts
of my page think the user is logged in, and parts think the...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
