Win32 API future ...?

Quote:

---

A perfect example of easy migration is migration from C to C++.
C++ maintains a quasi-full compatibility with C, and C++ compilers are generally also C compilers, so programmers can mix C code and C++ code.

---

Yes, it is a perfect example. This is also the reason why there's so much badly written, badly designed code out there - because the people who migrated from C to C++ didn't fully understand object orientation and started doing the same things in C++ (i.e. function-based programming) as they were doing for years in C.

This situation (I really hope) has changed now, and most companies have people who've taken object orientation on board in a big way and are improving the design of their software 10 fold.

I remember the first piece of commercially written C++ I ever worked on. It was an amalgum of C function-thinking with C++ and was horrible. One change to one base class meant that all 1,000,000 lines in the application needed to be recompiled. Encapsulation ? What's that ? Interfaces and weakly linked classes ? Huh ? You're having a joke. Extra classes means more lines of code doesn't it ? High reuse of code ? Hey, that's what the copy-and-paste systems for. I would laugh but I nearly had a nervous breakdown at the time.

C++ didn't guarantee good code. It gave the facility to design your application (if you wanted to). Most people didn't and wrote horrendous monsters that were little better than similar applications in C.

Again .NET doesn't guarentee good code. However if you foul up the design it will sting you with major performance hits. But it provides far more facility for good OO design than C++ ever did. That's why I like it so much.

Darwen.

And I have to re-iterate this :

I HATED THE IDEA OF .NET TOO !!!

I came to C++ in my University degree course from coding Z80 machine language for 7 years (I started young...). I have had C++ and OO design drummed into me from the very start. I came to Visual C++ 1.5/MFC in 1994. I've been coding in it every since.

Managed language ? Wow that's going to be slow - isn't it ?

Garbage collection ? What's the point ?

I argued everything that you are now arguing.

Then I decided that if I was going to justify my position, I had to learn C# - after all it was building momentum in the community (a C# forum set up here on CG). Just so that I could rip it to shreds afterwards.

The more I learned about .NET the better it got. I even got won over to garbage collection. Every time I needed to do something that I thought "oh, it won't do that..." it did. And in far fewer lines of code than C++ and in a far more readable and object oriented way.

Don't learn .NET by using C++.NET. This is a horrible language to write pure .NET code in, and to be honest where it's main purpose lies in tying .NET and native code together seemlessly it does fall down in the debugging department. These days if I need C++ to do something for me I write a COM object to do it (or a static dll - after all a static dll is more in keeping with side-by-side execution than COM is) and use the truly excellent interop capabilities of .NET to interface with it.

Strange that - going back a technology to move forwards (i.e. using static dlls instead of COM) but there you go.

Just give .NET a chance. I did, and I love it now.

Darwen.

Quote:

---

Originally Posted by darwen

What Microsoft is talking about with Longhorn is that the .NET framework won't go through Win32 as it does now, but instead talk to the OS directly. Even parts of the OS (rumoured) are being written in managed code.

---

Okay, so there is no real problem.
The migration to .NET will be done slowly, by convenience, not by need.

It looks like you really love .NET for OO.
It is true that the absence of garbage collection complicates the OO design, and can produce a more complicated and less effective design.

Be sure, that i will took an eye on .NET if i can.

Have a look at events and delegates. It enables classes to be seperated into smaller classes. UI no longer has to be dealt with in the same class (like C++/MFC). But that's just the tip of the iceberg.

It's effectively an observer pattern built into the language. I think it's extremely powerful. In actual fact it's my favourite facility (if you haven't already realised....).

Darwen.

And I'm not jumping off a cliff like a lemming... as WizBang suggested.

I love .NET because it allows me to do what I want to do. Write an elegant object oriented design with the minimum of fuss.

Most of my time these days is spent designing code rather than writing it.

Because I have time to do so.

Darwen.

Well, at least we can agree on one thing: Time will tell.

For me, I know that as long as .net is intermediate, managed code, which it must be to have the garbage collection, I won't be using it for my stuff. Obfuscation is of little or no value here. As long as the code can be managed, it can be decompiled. I've seen nothing to change this fact.

I'm sure there are plenty of people who will use it and like it and so forth, with or without the lemmings. I just don't see it as "the future of programming". As darwen stated, the industry is ever-changing. In a few years, some portion of us will look back and say "what were we thinking?". The ideas floating around regarding molecular computers and neuron imbedded chips and such might become reality sooner than we think, or not at all. The entire windows market is based on standards which many (including myself) think should have never been - the IBM PC and arguably the x86 architecture itself, just to name two. However, that's an entirely different discussion...

I guess I'll just leave it right there.

Quote:

---

Originally Posted by darwen

And this is besides the fact that the network protocols and distributed application facilities in .NET go far beyond what C++ (or even Java) has.

---

Java has a huge collection of libraries based around internet programming. Somehow I doubt that .NET beats those...

Quote:

---

Originally Posted by darwen

Java is a hobbiest's language. .NET is a professionals language.

---

Even though that is flat out wrong I would enjoy hearing your argument...

Have you every actually used Java for serious programming?

Java has libraries. I.e. java has it 'bolted on' the same way that networking is 'bolted on' to C++.

In .NET it's integral to the language. The Class Library Reference (CLR) is a standard : i.e. the libraries are a part of the standard, not just added to it.

That's how we can have C++.NET, C# and VB.NET all using the same code.

As to your second point :

Can you name one commercial application written using Java on the desktop ?

OK, Sun has been pushing it hard and I'll bet that there's Java apps out there for Sun Workstations, SGI's etc.

However I'll cite one point. Corel decided to rewrite CorelDraw in Java and invested a huge amount of money in doing so about 7 years ago. That and other bad decisions nearly bankrupted them.

I will say that java (or rather javascript) is currently the predominant language for websites. Because it's free, as are the other website applications like Apache, PSP etc.

I don't consider IIS free because it doesn't come with XP home. You have to pay more money to get XP Professional.

I'm not going to go further into the area of websites because I know nothing about it. I know that Java has a role to play there, and I'm perfectly happy with that argument because I can't respond.

However with PCs I can't name one commercial java-based application. With .NET we already have Microsoft using it in their applications and if you talk to Norfy I think you'll find he's just implemented a huge commercial application in .NET.

It's still growing of course, but .NET is certainly starting to gain momentum.

Darwen.

Quote:

---

Originally Posted by darwen

Can you name one commercial application written using Java on the desktop ?

---

I have heard of many commercial java applications, but Java is not designed to be use to develop the sort of applications that you use on a desktop. Thousands of companies use Java to run their servers or huge commercial application. For example, my friend's son has a Java teacher who used to help maintain a huge java application for ETS.

The developer world extends far beyond the ordinary desktop application. There are thousands of small businesses out there which will develop and maintain enterprise applications for individual companies, providing technical support and maintenance.

Quote:

---

Originally Posted by darwen

I will say that java (or rather javascript)...

---

Javascript is not related to java in any way and they are two completely different languages. There is no way to relate the two.

Quote:

---

Originally Posted by darwen

In .NET it's integral to the language. The Class Library Reference (CLR) is a standard : i.e. the libraries are a part of the standard, not just added to it.

---

Java standard distribution comes with plenty of internet related classes.

Java also has plenty of xml related classes, see http://java.sun.com/j2ee/1.4/docs/api/index.html

In the end, Java is very useful for certain types of commercial development, and labeling it as a "hobbiests" language is unfair

EDIT:
Oh and I forgot to say that Java is the #1 language used in developing enterprise applications

.NET is hyped up to be popular by its supporters. In all reality barely anybody uses it yet

Quote:

---

Originally Posted by darwen

Can you name one commercial application written using Java on the desktop ?

---

Can you name one in .NET? The reason they are so hard to find is because they are easy to decompile.

Until disassembly of .NET is made reasonably difficult it will never replace C++ as a language because it will never become an option for many companies

I agree the disassembly issue is a problem. But as I said before there are several ways around it.

So what you're saying is Java is ok but it suffers the same sorts of issues that .NET does and that's not ok ?

True I don't really know enough about Java to really argue the point.

But then again I'd guess that most people here don't know enough about .NET to argue against it.

All I can do is keep re-iterating what I see are the benfits of .NET.

Actually no-one is ever going to win this argument. Only time will tell what happens to .NET and how widespread it becomes. Same with the other technologies.

Java died a death on the desktop because of speed. That's market forces at work.

We have C++ and object orientation these days because of market forces.

I firmly believe the market will adapt to .NET in future, but that's just a prediction. I may be wrong of course, but there you go. You pay your money, you take a chance.

Darwen.

Quote:

---

Originally Posted by darwen

I agree the disassembly issue is a problem. But as I said before there are several ways around it.

---

Please point out the ways around decompiling .net. The first site I came across to offer decompiling also handles the obfuscators, so you might want to try their demo before you respond: http://www.remotesoft.com/salamander/

Quote:

---

Originally Posted by darwen

Java died a death on the desktop because of speed. That's market forces at work.

---

Interesting, as I'm writing this in Netscape 7, built using Java. It's VERY fast, and pages load and render just as if not faster than with Opera or any of the 9 other browsers I currently have installed (NONE from m$). It is my browser of choice. There is however, a lag in the UI, which I'm guessing is because the rendering engine and such have processing priority. In any case, .net apparently suffers from speed problems too, so neither one can play a major part in the desktop market, if for no other reason than speed. Now, one way it seems m$ might try to change this is by making much of the system reliant on .net anyway, then the user won't notice the difference, because everything will be slower. It would only be the newer systems that could compensate for the slowdown, so in effect there'd be no speed improvement by "upgrading" to a newer system if it had this bottleneck (unless significantly fast enough to overcompensate).

Of course, if by the term "commercial" we imply a product which is sold rather than given away, then I echo the same words as Ben_Phillips: Can you name one in .net? Trying to sell either Java or .net apps would be like trying to sell a copy of this thread.

Quote:

---

Originally Posted by darwen

I firmly believe the market will adapt to .NET in future...

---

In what way would you say the market will adapt to it, and which market would that be? Or perhaps you meant to say "adopt", since "adapt" is totally different, and could mean that the market would work around it rather than embrace it.

The method of preventing assemblies from being decompiled is home grown. It involves using a C++ COM object encrypting the assemblies. I can't really divulge more than that, but eventually it boils down to 1 line of code you put in your application class before creating the main form.

I can't really divulge more than that because it's a solution I intend to sell in the near future.

Aha ! I hear you say ! You're using C++ to do it ! That is a fair point, but it's just 1 dll. And I did say that C++ would still have its uses far into the future. The rest of the code for my applications (except for the optimised assembler parts) is in C#.

I'm not going to try to criticise Java again. I don't know enough about it really.

I'll say it again. I've nothing against Win32, or C++ or MFC and have been using all three including all the surrounding technologies commercially very successfully for years.

I just feel from a design and ease of implementation standpoint .NET is better. Can't a man have his opinion ?

Darwen.

Quote:

---

Originally Posted by darwen

The method of preventing assemblies from being decompiled is home grown. It involves using a C++ COM object encrypting the assemblies. I can't really divulge more than that, but eventually it boils down to 1 line of code you put in your application class before creating the main form.

I can't really divulge more than that because it's a solution I intend to sell in the near future...

---

OK. That's fair, but did you try the decompiler to see if your protection works? If it can't be decompiled, then you might have something. But I have my doubts since the code still needs to be managed, so somewhere along the line it has to be readable.

You can't decompile it because the dll is encrypted.

Darwen.

I think the Win32 API future is dark. ;)

BTW. Does anybody ever heard about (a future) Win64 API?

Quote:

---

Originally Posted by darwen

You can't decompile it because the dll is encrypted.

---

I'm not referring to the dll, but the .net code which it's meant to protect. Are you saying that your .net code gets placed inside the encrypted dll? I don't expect you to reveal secrets, but it seems to me that if the .net code remains .net code, which it would in order to be run and managed, then it's vulnerable. I'm not familiar with what files you get when a .net application is "compiled", but I'm guessing you end up with an exe of sorts, right? The picture I get of your solution so far is a dll which is distributed with the program.

Maybe the dll has part of the code in it, and is extracted at runtime or something...

Again, don't think I'm after your secrets. That you need to keep to yourself, especially if it works.

Everything will become clear about how it works once I've released it. Knowing how it works isn't going to help anyone in decrypting the dlls... rather like knowing how any of the standard encryption methods works doesn't help decrypting information.

And it's going to be cheap too. Preliminary price tag for the software (including tools etc) is going to be $49.95 and it's client licence free - i.e. you can use the software as many times as you want once you've bought it.

I'm not saying that it's going to be unbreakable : no security measure is unbreakable. However I've done my upmost to try to deter most hackers from working out the algorithms.

As a cheap, no-nonsense and 1-line of code friendly solution I hope it'll attract interest.

Darwen.

I look forward to seeing it released.

Well there has to be some way of decrypting the file or else how would it run? I don't know the encryption scheme, so I really have no idea, but if it becomes too popular then somebody is bound to crack it (like they do with anything... :( )

Quote:

---

I'm not saying that it's going to be unbreakable : no security measure is unbreakable.

---

Of course someone is going to break it. Let's face it even software like 3D Studio has been broken.

It's going to deter the general hacker though who knows how to decompile C# code.

It provides some protection - not 100% because no solution is 100% - but it'll offer the same kind of protection that you'd get with assembler if not better.

Darwen.

In the world of Hacking, .Net is a cheap date.

ahoodin

Quote:

---

Originally Posted by darwen

It provides some protection - not 100% because no solution is 100% - but it'll offer the same kind of protection that you'd get with assembler if not better.

---

All I can say is that I'll believe it when I see it. One line of code added to the source doesn't sound like encryption to me. Your dll might not be easy to decypher, but the source gets compiled to a seporate file, so I don't see any protection there. Seems to me that if the runtime ("framework") can read and manage the file, then nothing is encrypted.


The above arguments will be what you'll have to deal with when selling your solution. You might have to make a sample app that people can download and try, and that they can run through the various decompilers out there to see how it holds up.

I'm sure we'd all like to see what you've accomplished. When do you estimate your dll will be ready for use?

Getting back to the original point: will the relatively low-level Win32 API survive in future editions of Windows? Are all programmers destined to move to managed environments?

Historical evidence suggests no.

Managed environments is not a new concept. It has been around for as long as compilers. Any interpreter is essentially a managed environment, and interpreters and compilers evolved at around the same time.

Take Lisp. In the 80s, Lisp advocates claimed their environments to be superior. Although they didn't use the M-word at the time, their argument was essentially that Lisp was a managed environment. Yet, Lisp, powerful as it was, did not become the ubiquitous standard that its fans predicted.

The modern arguments rely on Moore's law and ever-faster hardware to excuse the extra overhead for a managed environment, but the hardware improvements have been on-going for decades. What is it about right now that makes it reach the threshold where users are ready to sink the cost?

The move from 2nd generation languages (like ASM) to 3rd generation (like C), or from procedural to OO languages, is not analogous. These moves were precipitated by improvements in compiler technologies, not faster hardware.

There is a class of software where managed environments are particularly well suited: Enterprise Solutions and server/thin-client based applications. For these types of apps, it turns out that the cost-savings from a well-managed environment, in support, maintenance, reduced outages, etc, outweighs the cost of improved hardware to get comparable performance. This advantage increases as the performance hit from the environment is reduced.

This is the space where Java, with J2EE, has done well, and where .Net is primarily aimed -- not coincidentally, since there is a lot of money in this space. (As an aside, .Net is going to blow J2EE out of the water, unless Sun gets its act together, but that is a different discussion).

For thick-client development, users will continue to prefer software that makes the most of the available hardware -- including, perhaps especially, peripherals. This is true for games, media-players, browsers, screen-savers, multmedia apps, and even to some extent productivity applications like spreadsheets and word-processors. This implies that there will always be a market for software that is written at a low level and unmanaged.

As another historical exhibit, consider Java. It has been argued here that Java is used to run thousands of commercial solutions. Correct, but that was not Javas original promise. The original promise was, "write once, run everywhere," implying that it was aimed at writing client applications that could run on any desktop. This promise has only delivered to a small extent, not because it wasn't possible, but because such apps were not competitive.

The users have spoken. When they buy a $1,000 computer, they don't want a $900 computer.

All that does not mean that Microsoft will not enforce managed environments. Avalon sure sounds managed, from what descriptions have been published. It is unclear whether client developers will have direct access to a lower level API.

If this is their approach, it will be a mistake. They will lose a competetive edge over other platforms. Business software may be where the money is, but as a software company that took over via the desktop, it seems odd they would give it up willingly.

Firstly, I wish I'd never mentioned my little solution. You'll have to wait around for it... it depends on various things like me writing the manual and setting up a company. I think you'll be pleasantly surprised...

Anyway back to the big posting by hankdane

Quote:

---

The move from 2nd generation languages (like ASM) to 3rd generation (like C), or from procedural to OO languages, is not analogous. These moves were precipitated by improvements in compiler technologies, not faster hardware.

---

I disagree. I could run Z80 machine language fine on my ZX Spectrum going back to 20 years ago and even though C compilers were available, no-one used them BECAUSE THE CODE THEY PRODUCED WAS TOO SLOW.

Quote:

---

Take Lisp. In the 80s, Lisp advocates claimed their environments to be superior.

---

First off, LISP is a functional language (no loops).

Secondly the language was deficient. How many millions of close brackets do you want at the end of your application ?

No-one (except NASA from what I hear) would consider writing anything but small applications in LISP.

LISP had the advantage of being mathematically provably correct. Which is why NASA used it for control systems. I think, don't quote me on that.

Quote:

---

If this is their approach, it will be a mistake. They will lose a competetive edge over other platforms.

---

Microsoft will for the forseeable future dominate the desktop OS market. Why ? Because there is no other graphical operating system which is as easy to install and configure.

Linux isn't graphical or easy to set up so let's discount that first.

To my knowledge there has only ever been one contender for a graphical operating system in direct competition with Windows : IBM's OS/2 in the early 90's. It was so bad, so buggy and generally so awful that IBM eventually gave up on it.

Bear in mind Microsoft haven't made a single penny out of .NET. And never will. It's a free technology which has been developed by Microsoft at I would bet a cost which runs into at least the tens of millions of dollars.

What is the purpose of Microsoft moving developers to using .NET ? They still have a commanding position in the desktop operating system market, they still produce the best selling development tool (DevStudio).

They could keep on using C++ ad infinitum. All of the new features of Longhorn could have been written using C++. People would still upgrade and buy it.

Maybe - just maybe - they want to make life easier for themselves development-wise. And if they're making their lives easier by using it, why shouldn't we ?

In actual fact can you imagine the ability to decompile the OS using things like Loetz Roeder's reflector to see exactly what is going on ? I already use this tool to find out how things are done in .NET (just like I use the MFC source in DevStudio to find out what's going on in MFC). This to me as a developer would be very, very useful.

Now you're going to say that that's going to allow someone to change operating system dlls. That's entirely up to them - if they want to be idiotic.

I really can't see how the development of .NET is going to make Microsoft any money.

Sales of DevStudio would certainly have continued just fine if it just supported VB and C++.

Maybe it is all about enterprise development - but as all the compilers etc are free and you have really good development environments like SharpDevelop if you want to develop .NET for free you definately can do.

Maybe we're all too cynical and it's just Microsoft saying "hey, we have more money than God, but rather than trying to make money out of .NET we really think you should have a look at it because we think it's really great".

Darwen.

I've just thought of something : maybe it really is Microsoft's answer to Java and they want to control the world.

At least this is good for us as developers - we have more languages to choose from when we're developing.

In my mind the difference between a software engineer and a software developer is that a software engineer considers the options available and picks the most appropriate.

A software developer sticks to one language and just uses that. They don't want to know about new technologies unless they are forced to.

If we have more tools to do the same job surely this is an advantage, not a disadvantage. Yes we have to learn more, and we'll have a greater seperation of the really good people from the ordinary but is this bad ?

I would say that the present situation is fantastic. Providing you're prepared to learn all the technologies in the field of development that you're working in (I'm primarily in desktop development) then you can pick the best tool for the job.

Yes we can always say that C++ is better at certain things than .NET. Yes we can say that Java is better than .NET at some things and .NET better at other things than Java. We can also say that Assembler is better at certain things than C++.

These are all tools which we now have at our disposal. It's really just up to us how we use them.

Darwen.

And if I were doing website development ? I'd use Apache with PHP and Java because it's free. OK ?

Darwen.

Quote:

---

Originally Posted by darwen

I disagree. I could run Z80 machine language fine on my ZX Spectrum going back to 20 years ago and even though C compilers were available, no-one used them BECAUSE THE CODE THEY PRODUCED WAS TOO SLOW.

---

Maybe I don't understand what you are saying, but this seems to confirm my point.

Stipulation: Developers will not move to a higher-level language until the compilers are good enough - regardless of processor speed.
Case in point: Developers preferred assembly to C-code for the Z80, because the C compilers were not good enough.

Quote:

---

Originally Posted by darwen

Secondly the language was deficient.

---

Picking on Lisp is not relevant. The point is they had a managed environment. They had garbage collection and advanced debuggers. Lisp programmers never had to worry about stack overflow, memory leaks or buffer end-runs. The environment took care of that stuff for them.

The result is that Lisp programmers spent more time thinking about their design, much like your experience is with .Net. The difference is that they did this several decades ago.

I don't think Lisp failed to become popular because programmers worried about too many parentheses. (Not brackets). I think it failed because of the overhead of the environment.

So Darwen, what you're saying is .NET beats C++ as a language, because you don't like some of the libraries that have been written for C++?

This is a bit like saying French is better than English, because you're read some books in English that you didn't like.

It's clear from your comments that you aren't differentiating between the language and the tools written in the language.

C++ as a language knows not one bit about databases or XML. The .NET language has no knowledge of these things either.

What both languages do is allow you as a programmer to use libraries written in these languages to leverage concepts beyond level of the compiler.

And yes, you're correct, 15 years ago people were engaging in language wars without knowing the difference between a language and a library. I was reading such stupid arguments almost 30 years ago also.

OS2 was nothing but Windows For WorkGroups, tweaked a bit and broken. It wasn't so much a contender as a gimp cousin.

As to Microsoft not making any money on .NET, how might I legally obtain a programming environment for it, for free? Doesn't Microsoft want money for the OS and the compiler environment?

What .NET does do is take us into OS incompatability. By pushing a non-standard language onto the market, they're insuring that code written in it, must run only on the Microsoft platform. This helps lock in a market for Microsoft and Microsoft compatible hardware. It's their attempt to stifle Open Source and block an easy migration to Linux or Unix.

The whole point is to minimize the free market in this respect and limit choices.

To deal with Jack's points first :

Quote:

---

C++ as a language knows not one bit about databases or XML. The .NET language has no knowledge of these things either.

---

.NET isn't a language. It's a technology. And as a technology it does know about database access. The Common Library Reference is a standard - and must be supported by all .NET compatible languages. This is a common misconception. C# is a language. VB is a language. C++ is a language. .NET is a standard technology which C#, VB.NET, C++.NET, Delphi.NET conform to.

Quote:

---

What .NET does do is take us into OS incompatability. By pushing a non-standard language onto the market, they're insuring that code written in it, must run only on the Microsoft platform. This helps lock in a market for Microsoft and Microsoft compatible hardware. It's their attempt to stifle Open Source and block an easy migration to Linux or Unix.

---

What about Mono then ? It's an open-sourced .NET implementation for Linux/Unix systems.

Also Microsoft are rumoured to be making the source code for .NET available soon. At any rate it's decompilable. So that's pretty open sourced if you ask me.

Quote:

---

So Darwen, what you're saying is .NET beats C++ as a language, because you don't like some of the libraries that have been written for C++?

---

No I'm not saying that at all. I'm saying that .NET is better at object orientation and other things than C++. C++ is better than .NET at other things : most importantly interfacing with existing technologies such as DirectShow, Win32 which will eventually be moved to .NET. C++ is faster than .NET, but not by as much a gap as you would expect.

.NET also supplies functionality which just plain doesn't exist in C++ : reflection is a typical example of this. I can look at a class type and get information about all of its members. This is a pretty simplistic view of reflection but it's a good start. Also .NET has the facility for attaching attributes to classes, methods, properties, events : something you can't do in C++ without writing a similar framework (because no reflection).

Now to hankdane's original point :

Quote:

---

The move from 2nd generation languages (like ASM) to 3rd generation (like C), or from procedural to OO languages, is not analogous. These moves were precipitated by improvements in compiler technologies, not faster hardware.

---

My point was these moves were made possible by faster hardware e.g. going from the ZX Spectrum to a 286.

Finally I said this :

Quote:

---

Yes we can always say that C++ is better at certain things than .NET. Yes we can say that Java is better than .NET at some things and .NET better at other things than Java. We can also say that Assembler is better at certain things than C++.

These are all tools which we now have at our disposal. It's really just up to us how we use them.

---

I will continue to use C++ for certain things. I will also continue to use Assembler for speed. But I love .NET for the vast majority of my programming and will continue to use it.

Darwen.

Quote:

---

Originally Posted by darwen

.NET isn't a language. It's a technology. And as a technology it does know about database access. The Common Library Reference is a standard - and must be supported by all .NET compatible languages. This is a common misconception. C# is a language. VB is a language. C++ is a language. .NET is a standard technology which C#, VB.NET, C++.NET, Delphi.NET conform to.

---

Then I don't see the point in comparing it to C++.

Why compare a non-language to a language? You lost me there.

I agree with you that some of Microsoft's technologies written in C++ are horrible, but I don't see that as a reasonable indictment of the language they were written in.

C++ interfaces with Win32. The .NET languages are built upon the .NET technology which presently calls Win32.

In Longhorn .NET will directly call the operating system. Win32 will still exist, but in parallel with .NET and not underneath .NET.

So therefore in discussing the future of Win32 you have to relate using C++ calls to Win32 to write applications with using .NET to write applications.

Darwen.

Quote:

---

Originally Posted by darwen

C++ interfaces with Win32. The .NET languages are built upon the .NET technology which presently calls Win32.

In Longhorn .NET will directly call the operating system. Win32 will still exist, but in parallel with .NET and not underneath .NET.

---

What's going on under the hood then? Has Microsoft simply refined the underlying C++ objects and exposed them directly to .NET, as opposed to converting them to C style Win32 calls?

Something like that. Win32 is built as an interface to the raw OS calls. In Longhorn .NET will make raw OS calls instead of calling through Win32. If anything the OS will be changed to make it easier for .NET to do so : I.e. rather than the OS favouring Win32 it'll favour the .NET framework.

As far as I can understand.

Darwen.

Quote:

---

Originally Posted by darwen

Something like that. Win32 is built as an interface to the raw OS calls. In Longhorn .NET will make raw OS calls instead of calling through Win32. If anything the OS will be changed to make it easier for .NET to do so : I.e. rather than the OS favouring Win32 it'll favour the .NET framework.

---

Once upon a time, and some years ago in a tech article long lost, a Microsoft developer discussed how much of the OS was being morphed from straight C into C++.

This sounds like the logical evolution of that effort.

I for one, won't miss the message pump when it is finally gone.

Quote:

---

Originally Posted by darwen

The same could be applied for the shift from Assembler to higher languages.

How can you possibly write in C++ without knowing the instructions that the compiler generates ?

than the equivalent C++. Why should I use C++ over Assembler ?

---

totally agree.....but....:

Quote:

---

Originally Posted by darwen

Java is a hobbiest's language. .NET is a professionals language.

---

why would yoy say that?, can yoy give some reasons??

Quote:

---

Originally Posted by WizBang

As for learning .net, I do think it would hurt in my case, as it simply cannot be used for commercially distributed software. That again is part of the m$ plan.

---

is this true?
where did you read that?.

With the Invoke method in the .NET framework you can really seperate yourself from the message pump : especially with the BeginInvoke (asynchronous) method too.

In theory if there is a message pump in future (which I'm sure there will be) it'll be so hidden away that people will just forget about it and think of things like SendMessage and PostMessage in terms of synchronous and asynchronous calls to methods.

I suppose what I really like about .NET is the design of it. It really is very well designed and thought through. After all it's taken a long time (over 7 years I believe) for the .NET framework to get to this point.

It didn't take that long for Visual C++/MFC to go from version 1.0 to version 6.0 after all.

Darwen.

Actually I'm sort of getting a little bored being the only one here arguing .NET's corner so I think I'll sign off now.

Nice discussion guys. Thanks a lot.

Darwen.

Hehe, well you cleared up some things for me. :)

Actually I'm still here. Stickler for punishment I suppose.

All I'm trying to say is give .NET a chance for what it is. It's a very good technology. In my opinion of course, but in many other people's opinion too. And if anyone gives it half a chance they'll realise that too.

As I've already said I thought it was an extension of VB6 (which I hate to high heaven) but it's not. Believe me when I say it's not. Or at least credit my opinion with a bit of respect until you find out enough about the technology to be able to argue against it.

What I have to say about VB6 is this : If I could go back in time and prevent something from happening it wouldn't be to kill Hitler - it'd be to stop Microsoft from producing VB version 1. That's how much I hate it. .NET is NOT an extension to VB.

Please stop all the 'on the offensive' posts here, all I'm trying to do is put its benefits across.

Maybe they're all 'on the defensive' posts : i.e. "Oh no, not another technology I need to learn as a developer".

I just like .NET. And even if you don't, please recognise that diversity isn't a bad thing to have.

Darwen.

I thought not that long ago, that .NET was just Microsoft's answer to Java.

Then I realized I had no idea what it really was. All of the noise about garbage collection and managed code, just muddied my understanding.

I think you've cleared up my misconceptions.

That's good to hear. In fact it seems like you actually want to learn more about it now.

Get a copy of C# - or rather get SharpDevelop for free (on www.sharpdevelop.com) - and try it.

To be honest working in C# has made my C++ much better designed. I can literally design and implement straight away in C#. And if I get the design wrong it's so easy and quick to change it.

I'm far more interested in good design of applications these days than the implementation details.

It can't hurt to start to learn it can it ?

Darwen.

Quote:

---

Originally Posted by jack.dingler

I thought not that long ago, that .NET was just Microsoft's answer to Java.

---

It is, its just not a copy of Java. Microsoft once tried to build a competitor to Sun's Java (something like Visual J++ or something like that), but Sun successfully sued them, and now the remanents are [an extremely trashy] J#, which is basically like Java 1.2

.NET, although not a copy of Java, inherits many ideas from Java such as garbage collection, portability (although .NET is not much more portable than an .exe), and, as darwen mentioned, and reflection (naturally these aren't unique to Java, but Java is the best known language with these features)

.NET is interesting to tinker around with, but I don't look at it [yet] as a competitive platform.

One thing I do have to rant about is how .NET is compiled into bytecode. This slows it down and barely makes it more portable (seriously how many people actually make applications for tablet pcs and palms?). I'm no guru on how .NET works, so for all I know this could be necessary to suport reflection, but currently I view the bytecode as a major disadvantage to .NET

Well Ben_Philips, have you read nothing about the next major stage of technology ?

Quote:

---

seriously how many people actually make applications for tablet pcs and palms

---

Are you having a laugh ? Or are you so short sighted that you will walk into the first wall that you meet ?

I am not being this cutting without reason.

Firstly, one of the advantages of .NET is that in the mobile world managed code rules. Because the framework has a specific size, and the applications are generally small because of that. And on diverse devices with limited memory it always will.

So no-one is developing applications for mobile devices ?

What about the games we have on our mobiles ? G3 introduces more bandwidth for that sort of thing.

Judging by speed and size improvements in the last 10 years in the next 10 years we'll have mobile phones with a 2.8GHz processor and 512 Mb of RAM.

With an equivalent increase in bandwidth.

You are assuming the world stays the same. It doesn't. Neither do programming languages, and neither does technology.

Darwen.

HEAVILY EDITED : PLEASE READ AGAIN.

And by "bytecode" I assume you mean Intermediate Language (IL).

The .NET specification - and I have to emphasise this - states that it is a JITted language.

I.e. the "bytecodes" that you state are actually compiled into machine language at runtime.

It is not interpreted as you seem to think.

So the first time you run a function it is compiled into ML (machine language) and then run. The second time the function is called it's already been compiled into ML and so the ML is run. And the third, fourth etc times.

.NET is not an interpreted technology. Please change your perception to take this into account.

Darwen.

Quote:

---

Originally Posted by darwen

And by "bytecode" I assume you mean Intermediate Language (IL)

---

Which, if I am not mistaken, is bytecode ;)

Also, I know exactly how bytecode works, I never said it was interpreted. JIT compiling produces less efficient (and hence slower) code (or do you want me to same machince code?) than the more advanced optimizing techniques performed by "compile once" languages. As I believe you said before, well written .NET code executes about 1.5 times (you may have said 50%, I'm not positive) slower than well written C++. This is a serious regression.

Also I believe that if you ask a random programmer chances are very high that they do not develop applications for portable devices (while the chance that they develop an application for windows is much much higher)

Quote:

---

Originally Posted by BlackWindzx

Quote:

---

Originally Posted by WizBang
As for learning .net, I do think it would hurt in my case, as it simply cannot be used for commercially distributed software. That again is part of the m$ plan.

---

is this true?
where did you read that?.

---

It's because of the decompiling issue. If your app becomes essentially open source, trying to sell it is pointless. That's still my argument against using it, aside from speed, and perhaps a few other more debatable aspects. As for the m$ plan, that's another topic altogether, so I won't go into it here.

Quote:

---

Originally Posted by WizBang

It's because of the decompiling issue. If your app becomes essentially open source, trying to sell it is pointless. That's still my argument against using it, aside from speed, and perhaps a few other more debatable aspects. As for the m$ plan, that's another topic altogether, so I won't go into it here.

---

So you think the same as java?
i guess (not sure) there must be a way that decompiling may not be THAT easy......
besides....how many people that will buy your software will know that can do that???...honestly i dont think that could be a problem.
The ones that doesnt want to pay for your software WONT pay for your software.....they can alwayas some serial or crack......

Quote:

---

Originally Posted by BlackWindzx

So you think the same as java?

---

Java has the enterprise application market in its full grasp, it is not meant for mass distributed commercial software (there are some great freeware apps though). Decompiling is not an issue because enterprise applications are generally not distributed to very many (or in many cases more than one) customer(s).

.NET is not viable for commercial desktop products, and I have severe doubts that it will gain much on Java in the enterprise market. It is less portable than Java, not as well known, and, as far as I can tell, not better than Java (even if it is slightly better then there is no reason for most companies to start from scratch and train their employees to become proficient in another language).

If Microsoft forces .NET onto us then the only advantage I can see is more freeware windows apps being developed (and for payware apps I guess more cracks)