Win32 API future ...?

Can I jump in here ?

Firstly : speed. .NET has been proven (by myself and others) after JITting to be around about 1.5 the speed of optimised C++. Not bad really.

The efficiency of .NET depends on how you write code. Small, well formed and highly re-used classes containing small methods are fast in .NET because once JITted they remain in memory.

Large, badly formed classes with huge methods and no code reuse (i.e. lots of copying and pasting) are slow in .NET because the JIT compiler has to recompile the same code over and over again.

I've seen apps (some done by people at my work) which take 20 seconds to fire up ! This is not a fault of the language (I find .NET surprisingly fast actually) but a fault of the programmer and their lack of object orientated methods.

For anything truly speed critical (i.e. raw bitmap manipulations) I just write a static dll or COM object in C++. Or more likely in machine language. My present application is starting to grow rather large and I don't believe it has more than about 200 lines of C++ in it (it's got about 500 lines of ML though).

So : right language for right job.

Secondly, I think we're missing the point of .NET here. What you lose in speed you infinately make up for in functionality.

.NET is a true object oriented language - i.e. everything is an object down to basic types such as int (System.Int32) etc.

In .NET we have things like events & delegates, reflection and a standardised class library which raise it so far above C++ in terms of the ease of implementation of a true object oriented design that I personally love it.

You can write truly elegant, reusable code in .NET. True you can do the same in C++ but let's face it it's somewhat of a pain.

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. Take these other instances of .NET over C++ :

(1) Databasing. Databasing in .NET is a breeze and in C++ is a pain. I suppose that's why so many people turned to VB6.

(2) XML support. The XML support in .NET is truly fantastic. It covers just about every single thing you could ever hope to want to do with XML, and then some. C++ has the XMLDOMDocument stuff which is (again) a pain.

(3) Encryption. .NET's encryption is simple and easy to use. C++'s encryption is a pain.

As more and more technologies emerge .NET will wrap them up nicely and only the underlying C method calls will be exposed to C++. If at all. Take Windows Messaging, the Windows Management functions. All take 2 or 3 lines in .NET to use but take massive amounts of code (usually taking hours to write) to get them to do anything simple in C++.

This is what .NET is. Microsoft have made it as fast as they possibly could, and have done a great job in my opinion, because if they didn't people wouldn't start using it until Pentium XI's had come out running at 10,000GHz.

But that is not the point. The point is that it's a truly object oriented language with some exceptionally powerful features. And in this respect I wholly support it.

I believe I said in a seperate thread that we are all working in a subject which changes rapidly. Why do we oppose change so much then ? Let's face it commercial computing on any kind of scale has only been around for about the last 20 or so years. In this respect it's extremely young. And so of course everything is going to change every 10 years or so. Only time will tell whether the change is good or not.

However I think .NET is a great step forwards, and I'm sure most other people motivated by good design will agree once they've given it half a chance.

Darwen.

Quote:

---

Originally Posted by WizBang

Performance has decreased with each new version of windows

---

That is why i am using Windows 98 (and not the XP thing that has a 32 bits user32.dll, but is slower than the 16 bits one!).
Moreover, i am lucky and Windows 98 never crashes without any reason (of course it crashes because of my code when i am debugging).

New OSes adds very few new features, and programmers who think that everybody has a recent computer with the last OS, use these features, and the program don't work on old OSes.

When i program, i try to use only the features of Windows 95, NT 3.1, so that it works an all windows.
I program Win32 programs, not Windows XP programs!

I think that the compatibility must not always be done in the sense of new OSes that can executes all code, but also new code that works on old OSes.

Quote:

---

Originally Posted by BlackWindzx

bad programmers will be bad programmers.
not beacuse you use a managed language means you wont know what you are doing. You can go and learn how to use it, and improve it. If you dont have the curiosity to learn more, it will be the same if you use c#, c/c++ , java, pascal...etc. You may do the things, but you wont know what is really happenning.

---

That is wrong, if you program in C/C++ without knowing what you do, your program will crash. You MUST understand POINTERS to use C.
The programmers that don't understand pointers are not recruted as C programmers, and cannot polute the universe with bad software.
But, with C#, more stupid programmers can program, but their code will correctly works on some machines, but will not be really good.

Moreover, since a C++ programmer must know how things works, he has learned how things works, and can program well, both in C++ and C#.
But if you want C# programmers to program correctly, they must start by using C++ and after they can use C# correctly (and gain in productivity of course.).

Finally, old C++ programmers that migrate to C#, can be happy to gain in productiviy.

For example:
I entered in the programmation world, by using BASIC (on a CPC computer, with a Z80 processor), and after i used Visual Basic.
After that, i programmed C++, and when i wanted to program interfaces, and fast coded applications, i reused Visual Basic.
But what i saw, is that before the C++ experience, my Visual Basic code was correct (i mean bug-free), but used big STATIC TABLES, no structures (instead of using a structure table i used many tables which correspond each to a field), and many, many GLOBAL variables.
My old code was ugly, it used very few functions, etc.

After using C++, i programmed very well, and fastly in Visual Basic, and used all the powerful features of Visual Basic.

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 ?

You can't write good, efficient C or C++ without knowing what the stack is, how many registers there are etc etc.

Let's face it I can write applications in Assembler which are

(1) Faster
(2) Smaller
(3) I have more control over what's happening 'beneath the surface'.

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

Sorry SuperKoko, you're argument about C# programmers first learning C++ doesn't really hold water. That's like saying that every programmer in the world should start off with Asssembler.

As to using W98 and never upgrading... if we all had that attitude we'd still be using DOS. DOS is MUCH quicker that W98 - no graphics etc. Nothing to slow the processor down.

Darwen.

These discussions i.e.

(1) Speed.
(2) 'closeness' to the processor/operating system.

have already been covered in the last big technology shift - from assembler to 3rd generation languages.

Even to a certain extent from C to C++.

There's nothing new here which wasn't said 15 years ago.

The same arguements stand as do the same answers.

What I'm trying to get at are managed languages BETTER than statically compiled ones ?

I'd argue that they are : they are faster to write in and have considerably better support for object orientation and design. Besides the benefits of interopability/compatibility between platforms and even languages such as VB.NET and C#.

The shift towards Java has already demonstrated the readiness to move to managed object oriented languages. Microsoft have just taken it one stage further in .NET. I always considered Java to be more of an 'academic' language, the same way that smalltalk is an 'academic' language. Yes it's nice, and it's good at what it does but it's not GREAT and it's not designed for commercial use.

Microsoft have designed .NET with commercial use in mind : of course. Now people could say that it's "Microsoft trying to make more money" which undoubtably it is. But is that a bad thing ? They've done a great job in my opinion whatever their motives were.

Let's face it - we wouldn't have put a man on the moon if it wasn't for the Cold War. Most of man's greatest acheivements have been borne out of adversity, wars or shere need. Microsoft's need is to make money. Hence .NET was born, tested heavily, made commercially viable and more importantly designed to be USED in real applications.

The only way they could do that was to make it significantly better for the developer than existing languages. All the people arguing against are saying that it isn't better than C++. I am saying it is. A difference of opinion maybe, but don't base your judgements on the fact that your years of C++ code are going to have to be binned. Base your judgements on .NET on its own merits and whether it improves the development process of software. And I certainly think it does.

Darwen.

Quote:

---

Originally Posted by darwen

The shift towards Java has already demonstrated the readiness to move to managed object oriented languages. Microsoft have just taken it one stage further in .NET. I always considered Java to be more of an 'academic' language, the same way that smalltalk is an 'academic' language. Yes it's nice, and it's good at what it does but it's not GREAT and it's not designed for commercial use.

---

I think Sun would disagree with you here!

;)

ahoodin

Quote:

---

Microsoft have designed .NET with commercial use in mind : of course. Now people could say that it's "Microsoft trying to make more money" which undoubtably it is. But is that a bad thing ? They've done a great job in my opinion whatever their motives were.

---

How can you say that when all .net programs can be easily decompiled back to source code? How will this help developers of commercial software? It might be easier than C++ to write apps for in-house use, but the same can be said for Visual Basic. One argument I see all the time against vb is that it dumbs down the programmer, and to some extent that is true. What I see is that .net furthers this trend, and many including yourself seem to embrace the whole idea of taking the "easy way out".

Heck, we all like things to be easy, but time has proven that the more layers of fluff you put between the code and the heart of the underlying system, the less efficient it is. While .net can be "not so bad" if you optimize, it cannot help with the problems I cited earlier, namely poorly written, memory hogging, slower programs. If vb and Java are any indication, .net will only worsten these issues. You said it yourself that it will require the programmer to use good techniques to keep it from becoming inefficient, but there's no way it will improve performance over the same app being thoughtfully designed in C++ or other more efficient languages. Your main incentive to like it appears to be because it's easy. That's why so many C++ programmers hate vb!! There is a saying: "Nothing worthwhile is easy". Another saying is: "Everything comes with a price".

The reasons to upgrade a system should not include things like "because everybody writes crapola". Having a program not crash doesn't justify this.

Quote:

---

That is why i am using Windows 98 (and not the XP thing that has a 32 bits user32.dll, but is slower than the 16 bits one!).
Moreover, i am lucky and Windows 98 never crashes without any reason (of course it crashes because of my code when i am debugging).

---

I too use an older OS. I keep xp on another partition just for testing, and I can tell you with out any reservation that it is significantly slower. My system doesn't crash either, while everyone I know routinely upgrades and continues to experience problems. Everytime something goes wrong, they put in more "service packs", exchange hardware, etc.. It never seems to end for them.

You cannot tell me that .net will make better programmers or faster programs. I'm sure it will make programs less likely to take down a system because of bad code, however systems will tend to need even more upgrading because of the loss in performance, and this will cost the company money. Consumers will essentially remain uneffected by .net, accept for freely distributed apps, in the same way Java does now.

What surprizes me is how so many can be led like lemmings off the proverbial cliff. Will you be so eager to return to C++ after awhile being pampered by the .net easy street? That's something I'd say m$ is counting on - programmers becoming "hooked on the .net drug", like many who never progress past Visual Basic. It will be like asking you to loose the GUI and return to a command prompt.

Quote:

---

Let's face it commercial computing on any kind of scale has only been around for about the last 20 or so years. In this respect it's extremely young. And so of course everything is going to change every 10 years or so. Only time will tell whether the change is good or not.

---

Would you argue that the trend should be toward programs you can't possibly sell? How will this help the commercial software industry? Plainly, it cannot, but this I think m$ is counting on. How you ask? From the sound of things, you'll find out, along with quite a number of others. This was first reported years ago, but few actually caught on. Perhaps some will be able to connect the "dots".

Personally I hope that .NET will produce fewer better programmers rather than more worse ones.

I hated VB6. I still do. I approached .NET with grain of salt the size of Ayer's Rock. For a long, long time I slagged it off without actually knowing about it.

Now it's my language of choice.

I agree that being able to disassemble the code is a huge loophole - but there are ways to prevent this. I myself have written one which requires just one line of code in the application class.

The more I learned about .NET the more I kept thinking "that's nice". And it is - nice. It's a lovely language to work in.

It is easier of course than C++/MFC. However it shifts the difficulty of implementation over to the difficulty of design. Get the design wrong and you get SERIOUS speed implications.

I hated VB6 for pursuading some people that they were software engineers when in actual fact compared to C++ programmers they were the equivalent of the mail-boy. Cheap and plentiful.

Now we have .NET I hear VB6 programmers are having a serious problem moving to .NET. Good ! Maybe some people out there will learn that there's more to good software design than hacking something together which works.

As to not being able to sell it... that has yet to be proven. Isn't DevStudio 2003 written in .NET ? I'm not sure about that point but I'll put money on the fact that Office et al will be upgraded to using .NET and I bet that'll make Microsoft millions.

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

Anyway there's no way that I'll ever win this argument - no-one will. Only time will tell. And I think we're all going to find that in time .NET will take over from C++. If it doesn't, no-one has lost anything. .NET could just be another tool in the arsenal which you can use to develop software. Use it or not, like it or not it'll always be there for those of us that do.

Darwen.

darwen:
Yes, even if Visual basic is easy to implement a GUI, it has many stupid limitations, and promotes static structures, it is why i was programming badly with VB before using C++.

But, you are probably right about .NET.
Maybe in a few years i will use .NET as my main language.

But, what i hope, is that Longhorn will maintain a maximum compatibility with previous OSes.

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.

I asked a question about Longhorn on the general developer topics forums.

Basically the answer was : Windows was always designed to support multiple platforms communicating with the OS.

Win32 is called Win32 because it's an interface to the OS. When you use Win32 you're not talking to the OS directly : you're going through its interface.

Now, a lot of the OS is presently written using Win32. Win32 and the OS are heavily linked.

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.

Therefore the heavy linking between the OS and Win32 will end and instead .NET will replace it in this role.

So you'll have two ways instead of one to talk to the OS : Win32 and .NET.

So yes, Win32 will be supported but will gradually be phased out. Or rather support for new features, controls, protocols etc will be withdrawn.

I can't see Win32 going away just yet : but I would think that in about 5-10 years we'll see the role that Win32 has to play in the OS being drastically reduced whereas the role of .NET increasing exponentially.

Now to put your mind at rest Assembler will never not be supported by the OS. Parts of the OS will continue to be written in Assembler (device drivers, time-critical parts etc) and so therefore C++ compilers will still work. Presumably Win32 will continue to work well into the next decade too.

However with the potential enhancements in the UI engine, new standard controls, new management tools and APIs : these will only be supported by .NET.

You'll begin to find that your C++ applications are actually accessing .NET code instead of static C libraries and dlls, and at that point the purpose of writing application UIs in C++ starts to become rather silly. Again C++ will still be around for optimisations, time-critical and real-time code but more and more of the everyday tasks like interfacing with databases, serialization and certainly UI will be written using the .NET languages.

Personally I can see VB.NET being dropped too... especially if its pitiful takeup continues. After a few years if more programmers haven't turned to it I can't see that Microsoft will be able to justify the cost of keeping a minority language alive.

From what I've heard even VB6 programmers are turning to C# as their .NET language when they upgrade.

Let's face it : VB6 is now a dead duck. C++ will take considerably longer to die because of its multi-platform capabilities and the fact it's a standard. However as managed languages start to take over the programming community C++ will fade into the background (not go away all together I might add, just fade) to be used by the same kinds of people who still write Assembler today.

Maybe all of this is complete rubbish, but it's just my thoughts on the subject from what I've read so when the throwers turn on me, try to make sure the flames aren't too hot please.

I've tried to be very diplomatic so far, and I hope you appreciate it.

Darwen.

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.