Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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?.
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
Hehe, well you cleared up some things for me. :)
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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)
Re: Win32 API future ...?
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.
Re: Win32 API future ...?
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......
Re: Win32 API future ...?
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)