• 0

.Net, worth it?


Question

Hello, I was wondering if anyone here could settle an argument.

At work, we code everything in delphi (using v7 because we didnt like how 'flaky' v8 was).

I was chatting to my manager here about moving our products up to .net, instead of win32 in order to future-proof our products.

His argument is that in a few years, .net would be redundant due to win32 still being supported until 64 bit instructions become the 'standard'.

He put forward a good argument that although Microsoft are pushing their .Net system to developers, they themselves havent started using .Net themselves in their consumer products, i.e. Microsoft Office etc.

I havent used Office 2003 in a while so i cant remember off the top of my head if this is based on .net, but I have a feeling that it isnt.

Also, when the next windows comes out (longhorn) that platform would still support win32, mainly because drivers need 32bit access to hardware registers etc, and .Net appears to be only a layer between programs and win32.

Link to comment
Share on other sites

Recommended Posts

  • 0

Your manager is wrong about several things. First, 64-bit computing doesn't make .NET redundant. Microsoft will ship a 64-bit version of the .NET Framework with 64-bit Windows. Because of the way .NET works, any .NET app that you write for a 32-bit machine will also run on a 64-bit .NET-enabled machine, most probably without even needing to be recompiled.

Regarding .NET being a "layer" above Win32... well of course it is. So is MFC, and so is VCL (Delphi's framework).

The fact that Microsoft isn't using .NET so far in their consumer programs isn't such a good argument, because it begs the question "so what?" .NET 1.0 wasn't even a year old when development would have started on Office 2003, so it's not surprising that there's no .NET in there. There probably will be in the next version, and we know for a fact that .NET will be a very significant part of Microsoft's next major consumer product (Longhorn).

Link to comment
Share on other sites

  • 0
Your manager is wrong about several things. First, 64-bit computing doesn't make .NET redundant. Microsoft will ship a 64-bit version of the .NET Framework with 64-bit Windows. Because of the way .NET works, any .NET app that you write for a 32-bit machine will also run on a 64-bit .NET-enabled machine, most probably without even needing to be recompiled.

Regarding .NET being a "layer" above Win32... well of course it is. So is MFC, and so is VCL (Delphi's framework).

The fact that Microsoft isn't using .NET so far in their consumer programs isn't such a good argument, because it begs the question "so what?" .NET 1.0 wasn't even a year old when development would have started on Office 2003, so it's not surprising that there's no .NET in there. There probably will be in the next version, and we know for a fact that .NET will be a very significant part of Microsoft's next major consumer product (Longhorn).

584760342[/snapback]

Cheers for your view on this. I suppose until .net is adopted by more software houses people tend to get either confused or simply refuse to follow a trend until it becomes the only way to go, then everyone moves towards it.

Link to comment
Share on other sites

  • 0
Your manager is wrong about several things. First, 64-bit computing doesn't make .NET redundant. Microsoft will ship a 64-bit version of the .NET Framework with 64-bit Windows. Because of the way .NET works, any .NET app that you write for a 32-bit machine will also run on a 64-bit .NET-enabled machine, most probably without even needing to be recompiled.

Regarding .NET being a "layer" above Win32... well of course it is. So is MFC, and so is VCL (Delphi's framework).

The fact that Microsoft isn't using .NET so far in their consumer programs isn't such a good argument, because it begs the question "so what?" .NET 1.0 wasn't even a year old when development would have started on Office 2003, so it's not surprising that there's no .NET in there. There probably will be in the next version, and we know for a fact that .NET will be a very significant part of Microsoft's next major consumer product (Longhorn).

584760342[/snapback]

good argument.

Link to comment
Share on other sites

  • 0

the argument of it not being used isn't really valid IMO.

Visual Studio is done in .net, for instance. longhorn will have major parts in .net. for instance, i saw on one of the avalon presentation videos that avalon right now is about 50/50 managed/unmanaged code. so you see, they are making software in .net :)

Link to comment
Share on other sites

  • 0

The next version of Windows (codename: Longhorn) is written in .NET, using the full value of managed code (which hopefully will reduce buffer overrun issues) and while your boss has some points, depending on your app, your clients and your staff's abilities moving to .NET could be of value.

Judging those three items is not an easy task. (at least not for me, as I dont know any of those) I liked Dephi (I use VB at work) and believe it to be a good product and if I remember correctly there is a Delphi.net coming.

Moving to a new language at a professional level should never be a quick think. Sitting down and mapping out where you are and where you are going, as well as the benefits of your technologies would be the way to go.

Link to comment
Share on other sites

  • 0
Moving to a new language at a professional level should never be a quick think.  Sitting down and mapping out where you are and where you are going, as well as the benefits of your technologies would be the way to go.

584760741[/snapback]

I agree. Perhaps it is wiser to delay the decision until Longhorn has some sort of beta released. And have you considered the other factors such as speed and cost? Is .NET fast enough for your needs (perhaps important if you are an animation company)? And are you going to upgrade all your office computers to new hardware; as it is often citied that Longhorn demands powerful hardware. And what about software licensing? Do you know how much a Longhorn license is going to cost? Or perhaps in the future, everyone would be moving to Linux and you will need to do research on Mono.

And what about the other languages? Perhaps writing a web based app (XML+XHTML+Javascript) would make it even more future proof since HTML is going to be here for a long time. And if you do it right, you might be able to port it to Longhorns XAML interface language by just using XSLT to do the translation.

Link to comment
Share on other sites

  • 0

Speed in .NET shouldn't be much of an issue. All IL code is compiled on the fly when the app is run anyway, so the end result is always naitive code; it's not run in a virtual machine like java.

Link to comment
Share on other sites

  • 0

Longhorn is written in C. You can't write an operating system in .NET or Java; it is impossible. Now, the UI, API, etc maybe written in .NET, but the kernel is not.

Just to clear that one up. :whistle:

Link to comment
Share on other sites

  • 0

No, when I use APIs, I'm going to use GTK+ or learn C++ then use wxWidgets. I want my programs to run on the most possible operating systems, not just Windows. And don't tell me about Mono and dotGNU, they aren't far enough.

But that is just if you (sn1p3t) aimed that comment at me.

Link to comment
Share on other sites

  • 0

Microsoft is and will be pushing C#. Its part of the .net family. From most of the things ive seen (Channel9 etc) most of the stuff for longhorn is coded in C#. Point is .net will be the major part of longhorn, support for .net is only growing, not going away.

Link to comment
Share on other sites

  • 0
The next version of Windows (codename: Longhorn) is written in .NET, using the full value of managed code (which hopefully will reduce buffer overrun issues) and while your boss has some points, depending on your app, your clients and your staff's abilities moving to .NET could be of value.

584760741[/snapback]

No, Operating Systems cannot be written in .Net. Windows Longhorn is written in 40% Assembly/60% C++. What is being written in .Net is some of the utlitlies and the user interface engine. But the core of the OS is, and always will be, written in native code. However, Microsoft has been incorporating .Net technology into almost every one of their products. Longhorn will be written to provide a .Net interface to applications while Win32 is only kep for legacy support. All of the new and cool features will be available only in .Net libraries.

.Net is a platform designed to make application development easier and quicker. You will still need to select a programming language (VB.Net, C+, C#, and J# ship with Visual Studio).

I think it is worth to begin developing new applications in .Net, but not worth it to make a huge project to convert older applications into .Net applications. That is redudant.

Link to comment
Share on other sites

  • 0
No, Operating Systems cannot be written in .Net.  Windows Longhorn is written in 40% Assembly/60% C++.  What is being written in .Net is some of the utlitlies and the user interface engine.  But the core of the OS is, and always will be, written in native code.  However, Microsoft has been incorporating .Net technology into almost every one of their products.  Longhorn will be written to provide a .Net interface to applications while Win32 is only kep for legacy support.  All of the new and cool features will be available only in .Net libraries.

.Net is a platform designed to make application development easier and quicker.  You will still need to select a programming language (VB.Net, C+, C#, and J# ship with Visual Studio).

I think it is worth to begin developing new applications in .Net, but not worth it to make a huge project to convert older applications into .Net applications.  That is redudant.

584761787[/snapback]

Just to comment on the 40/60 divide between assembly/C++. Unless you're crazy, you're not gonna write an OS in 40% assembly. Heck, you'll probably use less than 1% assembly. You only need assembly for some of the complex setup you can't do in C and for the few instruction that don't exist in a high level language such as LGDT, LIDT, RDTSC, INT, etc. And regarding C++, people generally don't use C++ when making an OS becasue it presents some difficulties (goto alt.os.development) such as name mangeling and that it uses too much stack space.

Link to comment
Share on other sites

  • 0
Meh, look at MenuetOS written in 100% assembly...  But writing it between C/ASM isn't to easy/smart/etc...

584762093[/snapback]

Well, the author's nuts :p And writing an OS between C/ASM is very smart and makes it much easier to write. You just need to know how the C and ASM will interact with each other and this is easy to find out. Just look at the linux source code. It's mostly C (like 99% ish). And it uses ASM where necessary. But anywho, I'm getting off topic. Gotta go...

Link to comment
Share on other sites

  • 0
No, when I use APIs, I'm going to use GTK+ or learn C++ then use wxWidgets.  I want my programs to run on the most possible operating systems, not just Windows.  And don't tell me about Mono and dotGNU, they aren't far enough.

But that is just if you (sn1p3t) aimed that comment at me.

584761718[/snapback]

No it wasn't. I posted my reply before I even read yours ;)

Mono is actually pretty far, at least with web applications. Forms support is next on their list. It remains to be seen what they come up with.

Link to comment
Share on other sites

  • 0
Speed in .NET shouldn't be much of an issue. All IL code is compiled on the fly when the app is run anyway, so the end result is always naitive code; it's not run in a virtual machine like java.

584761666[/snapback]

The native/non-native code is only part of the picture. The problem with IL's are that they are defined at a high level which doesn't give you the ability to program at a lower level. Processing-intensive programs typically require that they hand optimize certain parts of code at the machine level and to swap general instructions for processor-specific faster instructions. Also, programmers in this field usually maximize the amount of RAM that they can use and the .NET Framework itself takes up a large chunk of memory which they don't like. Also, the garbage collector is also an unnecessary bagage when optimized code typically tries to reuse the same memory space.

Link to comment
Share on other sites

  • 0
The native/non-native code is only part of the picture. The problem with IL's are that they are defined at a high level which doesn't give you the ability to program at a lower level. Processing-intensive programs typically require that they hand optimize certain parts of code at the machine level and to swap general instructions for processor-specific faster instructions. Also, programmers in this field usually maximize the amount of RAM that they can use and the .NET Framework itself takes up a large chunk of memory which they don't like. Also, the garbage collector is also an unnecessary bagage when optimized code typically tries to reuse the same memory space.

584763641[/snapback]

I agree with you there. For the low-level programming, nothing beats a language that compiles to native code. Although I don't know the topic starter's specific situation, most companies are worried about delivering high-end products to customers, where RAD and extendability are what matters.

Link to comment
Share on other sites

  • 0

Cheers for reading my topic and giving your views.

Personally I think it'll be best to embrace .net when it become more mainstream in programming.

At the moment, our software is being run on clients PCs that still run Windows98! although we do urge them to move to an NT based OS(prefably 2000 or higher) for stability and security purposes.

If we moved to .net now, the advantage would be that our clients would move to a more stable OS, reducing the number of tech support calls we receive when their systems break down, or something isnt compatible with their OS etc.

I suppose, on top of this, another advantage is that we can then streamline our code, and bring our software more up to date and that would increase it's performance.

The downside is, our software is designed to run over a range of networked systems, many of our clients arent IT businesses so they dont see the need to keep up to date and pay out for new computer systems to run our software, so by forcing people to move up, we are limiting our 'target audience'.

I think what it comes down to at the end of the day is that it's a balancing act where you need to see if it'd be worth moving over to the latest programming platforms, or still keep support for older systems. (If that made any sense)

Link to comment
Share on other sites

  • 0

office 2k3 is not build on .net.. else it will be required during the installation..

the problem is that MS itself is moving many of the new applications to the .NET platform, like, for example, sharepoint, biztalk 2004, SQL Server 2005, and many others.

a good thing of .NET FRMK is that you don't have to care about 32 / 64 bits at all, the FRMK will do it for you, so your application will run without problems on both systems.

the same thing is for the OS version, you don't have to care about it, everything is done by the FRMK...

the features are not only those, you must think that everything is defined as object and it is quite simple and fast to develop an application with a connection to a database, multithreading and many other features in few minutes.

Alex

Link to comment
Share on other sites

  • 0

Never ceases to amaze me how many people post with authority as though they have a real handle on "the truth"

LOL, funnies in this thread, Longhorn is 40% assembly LOL and Win32 is only being left around for legacy as if it were some aside or parallel bit of code.

Lets clear this up, Windows = C at its kernel.

Win32 sits underneath the CLR, all those calls to Windows Forms end up hitting Win32. MS won't redo Win32 as its a zillion lines of code, fast, and mega debugged, it works so they will not do too much to it.

The guys boss who started the thread should be fired if he truly believes dotnet is going away.

Now whether you should use it is another matter. You can stick with something with its own librbary like Delphi, use something platform neutral like Java OR you gotta go with the flow on Windows and use dotnet.

Personally for me dotnet makes sense because:

- As much as I like Linux, it sucks compared to XP, so coding to the GUI is better for me on Windows.

- Windows Forms Apps (ASP.Net) is AWESOME. Spend a week with code behind and datagrids and you will see just how powerful this stuff is.

- C# for me, means I can learn ONE language, then I can do sysadmin tools programming, GUI programming or even web programming. I can do it all with one language, and its an excellent language at that.

- Visual Studio owns eveything else, period :) And little baby Sharp Develop is also pretty neato, oh and free :)

Anyways, you need to read a book and be better prepared to debate this with your boss. I reckon a couple of magazine articles would put you ahead of him if he really thinks dotnet is going away.

Link to comment
Share on other sites

  • 0
- Windows Forms Apps (ASP.Net) is AWESOME. Spend a week with code behind and datagrids and you will see just how powerful this stuff is.

If you're talking about WinForms it's already being deprecated in favor of the Avalon API (XAML, the proprietary ripoff of XUL). If you're talking about ASP.Net it's not relevant to this debate over client app development.

- C# for me, means I can learn ONE language, then I can do sysadmin tools programming, GUI programming or even web programming. I can do it all with one language, and its an excellent language at that.

Try Python (not .Net's implementation, the original). Multi-platform, used to program system tools (like Gentoo's portage package management system), GUI programming through Tk or the excellent and stable wxWidgets library, and complete Web programming (Zope, for example). It also doesn't lock you into object-oriented development like C# and Java.

- Visual Studio owns eveything else, period :) And little baby Sharp Develop is also pretty neato, oh and free :)

VS.Net owns everything else... for .Net development. Looking beyond .Net there are IDEs like Eclipse and NetBeans that easily beat VS in usability and features if you happen to be using a language and platform they support, which is many.

Link to comment
Share on other sites

  • 0

Well..... ASP.NET may have a lot of power, but I know that it can't handle any uber heavly workloads without giving exception errors. JSP is really the most powerful, but hey, whatever floats your boat. :)

Oh and by the way. MenuetOS is the fastest OS I have ever seen. ASM owns all!

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.