Win32 API future ...?

[indiocolifa]

I'm very happy with my API learning. Every time I start a project, after looking to many programming perspectives, I end up with the good ol' Win32 API and C/C++... no MFC, no managed .NET, always loyal to the API, because I feel i've "more" control.

I want to hear some opinions on what to expect in the future (read: Longhorn) for us, crazy but happy API programmers. Will the API be there in the current form? It will be "emulated" through a compatibility layer?

And what about MFC (which I don't like, but I think it can be improved)?

Another question: In the MSDN documentation , GDI+ section, I saw a "GDI Plus Flat API" that seems to be programmable from C. This is true? Can I program the GDI+ subsystem with a C compiler?

Thank you very much.

(remove this post to another topic if posting here is incorrect)

[NoHero]

I thought Microsoft wants to reject MFC? I thought they only want to introduce the .NET for default programming and the WinAPI (so the lowlevel windows programming) for the hardcore coders and/or driver designers...

I'm only 15 so I think my expirience in WinAPI may be important in the future ... I will go on learning the WinAPI and some other stuff ... asp ... .net ... php and so on

I do not think that the api will be dead in the next 10 years. Why creating such a big API and then kill it from one day to another??? that does not make sense to me ...

ng flo

[hspc]

as far as I know LongHorn will be managed..as .net framework we won't need to call APIs..
maybe very rarely or not at all..They build it from scratch and I think we'll say good bye to Win32 APIs.

[indiocolifa]

Maybe, as I pointed above, the API is implemented as a layer which calls the underlying real API (managed .NET)... or viceversa!

[tomcant]

Ha! Nah... the WINAPI wont die just yet... not for a while I dont think.

[TheCPUWizard]

WinAPI is doomed!

But then again so is everything else in the long run. It is doubtful that ANY current technology will be intact in 30-40 years [at least for new development]

On the other hand, this specific issue was covered in the last telephone conference I had with the LongHorn server development team about 4 weeks ago. The Redmond team stated that there will still be support for programs that are built to access O/S features via the WinAPI. They were not able (willing?) to discuss the exact mechanism however.

This issue does bring out one important aspect of software development. Where ever possible code should remain platform independant. People who scatter WinAPI [or Linux System Calls, or Direct-X, or OpenGL, or..., or...] calls through out their application are going to have more problems than developers who isolate this type of functionallity within dedicated classes [or whatever construct is appropriate for the given language].

When discussing C++ specifically, this can usually be done with a set of fairly thin wrapper classes that implement all functionallity as inline methods. This technique isolates all of the operating system/compiler/platform specific issues within well defined boundaries, without any significant overhead at run-time.

[indiocolifa]

After all, the trend to a managed environment is here, and we cannot stop it -- and if we are to learn the new .NET thing, that's good I think.

[sephiroth2m]

So in this case what about C/C++? As the technology & internet grow up, peformance and effectiveness become minor, while less development time and platform-independent are more important. Just think about ASM many years before, will C/C++ be like its cousin in the future?

[NoHero]

Originally posted by sephiroth2m
So in this case what about C/C++? As the technology & internet grow up, peformance and effectiveness become minor, while less development time and platform-independent are more important. Just think about ASM many years before, will C/C++ be like its cousin in the future?

good point ...

I do not know because C/C++ is a good programming languages that is used in other areas too. It may dies at the home business but not generally. .NET is our future, if linux/unix go with us, if not microsoft will get stuck in this poo ... (sorry for my rude way) ... And MFC will die, thats the fact ... But I hope that the WinAPI will remain as it is ...

Another question: Whats with the coders that write depend software for windows? Like driver designers?? Will the use the lame .NET Framework too??

[TheCPUWizard]

Will the use the lame .NET Framework too??

1) The .Net framework is anything but lame. The CLR and all that it entails is probably one of the most comprehensive software development efforts ever.

2) The next version of Windows [LongHorn 2007] will be entirely based on the .NET framework from the ground up.

[NoHero]

Originally posted by TheCPUWizard
1) The .Net framework is anything but lame. The CLR and all that it entails is probably one of the most comprehensive software development efforts ever.
framework from the ground up.

but you cannot tell me that the .NET framework is faster than the WinAPI ... And your second point does not answer my question ...

[TheCPUWizard]

At present the .NET framework is definately NOT faster than WinAPI. There are a couple of reasons:

1) Windows is currently native on the WinAPI. .NET must call the API. When the next round of windows comes out, this becomes inverted (The WinAPI calls will be routed to .Net

2) .Net is currently a version 1.x product. There are a number of areas where optimization was not done in order to ship a reliable product on-time. Much of this is addressed in Whidbey (.Net 2.0)

3) .Net performs run-time checks. Straight C/C++/WinAPI does not do this inherently. Look at all of the buffer overruns that have plagued windows. (Over)simply stated this was because programmers did not check everything for validity. When programming to a managed platform (.Net) this is all performed automatically, the user does not have to do this. In fact the user can NOT overrite a buffer even if they want to (unless they mark the code as unsafe and do a few other things). If every condition is validated in straight C/C++, then the performance becomes comparable.

4) Policy based Code Access Security models [and if you dont know what that means, then you have not even scratched the surface of .Net] can not be implemented without a framework.

5) People can write crap in any language. People who do not understand the ramifications of the .Net platform [I have probably logged close to 6000 hours of .Net programming and still rely heavily on references and am discovering things..] will write crap using .Net. If you think this makes it more difficult then C++, I invite you to give me a good explaination of Alexandrescau's "Modern C++ Design"]

6) I believe I did answer your second question. In about 3-5 years all programming for windows platforms will be done directly or indirectly to .NET. Programmers who do not wish to use .NET will not be programming on Windows [and possibly not on other systems that adopt the open CLR standards].

7) Moving to CLR from unmanaged applications is as big or bigger of a paradigm shift as the move from C to C++ was 14 years ago [NoHero...You remember those days don't you ]. People who try to treat it as a small incremental change dont get the concepts, and will continue to struggle, complain and probably fail.

[NoHero]

Originally posted by TheCPUWizard
At present the .NET framework is definately NOT faster than WinAPI. There are a couple of reasons:

1) Windows is currently native on the WinAPI. .NET must call the API. When the next round of windows comes out, this becomes inverted (The WinAPI calls will be routed to .Net

2) .Net is currently a version 1.x product. There are a number of areas where optimization was not done in order to ship a reliable product on-time. Much of this is addressed in Whidbey (.Net 2.0)

3) .Net performs run-time checks. Straight C/C++/WinAPI does not do this inherently. Look at all of the buffer overruns that have plagued windows. (Over)simply stated this was because programmers did not check everything for validity. When programming to a managed platform (.Net) this is all performed automatically, the user does not have to do this. In fact the user can NOT overrite a buffer even if they want to (unless they mark the code as unsafe and do a few other things). If every condition is validated in straight C/C++, then the performance becomes comparable.

4) Policy based Code Access Security models [and if you dont know what that means, then you have not even scratched the surface of .Net] can not be implemented without a framework.

5) People can write crap in any language. People who do not understand the ramifications of the .Net platform [I have probably logged close to 6000 hours of .Net programming and still rely heavily on references and am discovering things..] will write crap using .Net. If you think this makes it more difficult then C++, I invite you to give me a good explaination of Alexandrescau's "Modern C++ Design"]

6) I believe I did answer your second question. In about 3-5 years all programming for windows platforms will be done directly or indirectly to .NET. Programmers who do not wish to use .NET will not be programming on Windows [and possibly not on other systems that adopt the open CLR standards].

7) Moving to CLR from unmanaged applications is as big or bigger of a paradigm shift as the move from C to C++ was 14 years ago [NoHero...You remember those days don't you ]. People who try to treat it as a small incremental change dont get the concepts, and will continue to struggle, complain and probably fail.

Ok very good reasons though ... I will change to .NET ...

Yes I remember ... I was 1 year old ... And while I was pissing in my diapers, my guru introduced me to the issues of C++

[Mick]

Originally posted by TheCPUWizard


1) Windows is currently native on the WinAPI. .NET must call the API. When the next round of windows comes out, this becomes inverted (The WinAPI calls will be routed to .Net

Good point, much akin to using UNICODE for NT+

6) I believe I did answer your second question. In about 3-5 years all programming for windows platforms will be done directly or indirectly to .NET. Programmers who do not wish to use .NET will not be programming on Windows [and possibly not on other systems that adopt the open CLR standards].

shenanigans...it's just a standard, don't worship at the altar, which I believe you don't. Standards are there to give a common direction, there is always deviation...and I understand your point, just to be clear, but it's still obvious. To say ohh your using .NET because the native API is .NET is not the point, it is the interface. How and what you use to interface to the native API is the point. How many layers you inject is the point.

[NoHero]

Originally posted by Mick
... shenanigans.....

Can someone tell what this means??