Win32 API future ...?

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)

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

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.
:mad:

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

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

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.

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.

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?

Quote:

---

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??

Quote:

---

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.

Quote:

---

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 ...

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 :p]. People who try to treat it as a small incremental change dont get the concepts, and will continue to struggle, complain and probably fail.

Quote:

---

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 :p]. 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++ :rolleyes:

Quote:

---

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+

Quote:

---

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.

Quote:

---

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

---

:confused: Can someone tell what this means??

Quote:

---

Originally posted by NoHero
:confused: Can someone tell what this means??

---

Quote:

---

she·nan·i·gan ( P ) Pronunciation Key (sh-nn-gn)
n. Informal

A deceitful trick; an underhanded act.
Remarks intended to deceive; deceit. Often used in the plural.

A playful or mischievous act; a prank.
Mischief; prankishness. Often used in the plural.

---

In my context...there will not be a 'dying' out of the WIN32 api in 3 years, which was what I was calling shenanigans about.

Quote:

---

Originally posted by Mick
In my context...there will not be a 'dying' out of the WIN32 api in 3 years, which was what I was calling shenanigans about.

---

But if TheCPUWizard says is true, than that would severly decrease the usefulness of WinAPI. .NET would pretty much rule the Windows world. I would hate to have to uninstall Visual Studio and install .NET . I love Visual Studio.

And speaking of Longhorn, what is it exactly? I know that it's Microsoft's little new operating system, but is it completely new or something like XP except with more modifications?

Quote:

---

Originally posted by ats007spdou
But if TheCPUWizard says is true, than that would severly decrease the usefulness of WinAPI. .NET would pretty much rule the Windows world. I would hate to have to uninstall Visual Studio and install .NET . I love Visual Studio.

And speaking of Longhorn, what is it exactly? I know that it's Microsoft's little new operating system, but is it completely new or something like XP except with more modifications?

---

It should become something new ... :rolleyes: ... but the future is always unknown at microsoft ... ya know ...?!

Quote:

---

Originally posted by ats007spdou
But if TheCPUWizard says is true, than that would severly decrease the usefulness of WinAPI. .NET would pretty much rule the Windows world. I would hate to have to uninstall Visual Studio and install .NET . I love Visual Studio.

---

It is true to an extent. Why would you think that MS would not go the route of making a developers life easier. Of course many would say it is the dumbing down of developers (VB) (same thing can be said about C and C++) but it's only the dumbing down if you let it be. Take a look around at what you are doing, too many people take the words of others as gospel. Take a look, delve a bit deeper into the OS, the lanquage, the compiler, it is all laid out before you. And with that knowledge you can trick it out ;)

Quote:

---

And speaking of Longhorn, what is it exactly? I know that it's Microsoft's little new operating system, but is it completely new or something like XP except with more modifications?

---

IMHO it's just a couple of new layers to remove you from the resources. It is also an exploration of digital rights management and security. Though they have always been there (if you look) it is more an automation. But I reserve my judegements until around LongHorny sp 2 or so...until then, it is unstable as I deem all products to be unstable until they reach a certain 'risk' level.

I just hope that VS runs in Longhorn. But overall, I'm a little anxious if this .NET garbage starts taking hold and I'm primarily doing WinAPI, I'll be sort of out in the cold(and not to mention unemployed). But I'll take your advice and start learning more about Windows. Or better yet, migrate everything to Linux, that way I'll be unaffected by Microsoft's decisions.

Quote:

---

Originally posted by ats007spdou
But if TheCPUWizard says is true, than that would severly decrease the usefulness of WinAPI. .NET would pretty much rule the Windows world. I would hate to have to uninstall Visual Studio and install .NET . I love Visual Studio.

And speaking of Longhorn, what is it exactly? I know that it's Microsoft's little new operating system, but is it completely new or something like XP except with more modifications?

---

Googling for info we get....

I think we're going to be able to program on the API, altough it is well known that the API-model of programming will be not more supported by MS.

MFC will be in "bug-fix" mode, don't expect a refreshing MFC 9.0 release... IMHO, programming managed C++ with winforms is FAR better than dying MFC...

Quote:

---

Originally posted by ats007spdou
I would hate to have to uninstall Visual Studio and install .NET . I love Visual Studio.

---

Visual Studio .NET is still Visual Studio. It still has Visual C++, MFC, Win32 API, etc, but it also allows you to program using Managed C++, C#, etc.

Until Longhorn appears, we've two options (are both are good): Win32 API and .NET (both in C++ of course .. no that C# hybrid, plz)

MFC = :thumbd:

(altough MFC is Win32 API with horrid OOP design)

I never liked that MFC s**t

Quote:

---

Originally posted by RussG1
Visual Studio .NET is still Visual Studio. It still has Visual C++, MFC, Win32 API, etc, but it also allows you to program using Managed C++, C#, etc.

---

I know that, but I looked at a book of .NET and one of the things that I found was that the syntax is different(slightly). For the main function, it's something like this.....

Code:

---

int _main()
{
  return 0;
}

---

What's with the little dash in the front? One of the things that bug me is why can't they make the syntax look as close as possible to previous languages, so as not to make the learning curve so high? I'm not a professional programmer, hence the angst over the whole .NET thing and stuff.

yes, in Windows Forms is

Code:

---

_tWinMain (...)

---

Managed C++ is good, but the syntax is crap, you're right. For use managed types, you encounter all double-underscore prefixes....

__gc __value ,etc

MS must fix that in the new VS version, or at least, give a patch for us, .NET 2003 users. I would like to see GARBAGE_COLLECTED instead of __gc,

Quote:

---

Originally posted by indiocolifa
yes, in Windows Forms is

Code:

---

_tWinMain (...)

---

Managed C++ is good, but the syntax is crap, you're right. For use managed types, you encounter all double-underscore prefixes....

__gc __value ,etc

MS must fix that in the new VS version, or at least, give a patch for us, .NET 2003 users. I would like to see GARBAGE_COLLECTED instead of __gc,

---

take a look at this :
A first look at C++/CLI

What is "Managed Code" exactly? I see you guys throw that phrase around, but what does it mean exactly?

Is it possible to install Visual Studio .NET Academic version without those stupid updates? I don't have much hardrive space and I would really like to get around that annoying part, is there any way? Thanks in advance.

Quote:

---

Originally posted by ats007spdou
What is "Managed Code" exactly? I see you guys throw that phrase around, but what does it mean exactly?

---

With managed code , the cleaning of memory resources that the programmer allocates is done automatically by the OS (or a underlying framework such as NET). Imagine not using anymore delete[] and avoiding many (almost all) memory leaks.

Quote:

---

Originally posted by indiocolifa
With managed code , the cleaning of memory resources that the programmer allocates is done automatically by the OS (or a underlying framework such as NET). Imagine not using anymore delete[] and avoiding many (almost all) memory leaks.

---

But wouldn't that significantly reduce the programmer's level of control over the software that he's writing?

And what about stuff like OpenGL? Won't that become less useful, since much of that syntax is very similar to that of WinAPI?

Quote:

---

Originally posted by YourSurrogateGod
Is it possible to install Visual Studio .NET Academic version without those stupid updates? I don't have much hardrive space and I would really like to get around that annoying part, is there any way? Thanks in advance.

---

Which updates do you mean?
I do not know much about the academic version, but I imagine that the setup program (as with other versions) allows you choose what you want to install, so you can choose not to install C#, etc (although I think Managed C++ comes bundled with Visual C++ and thus cannot be left out of the installation).

One thing to note, there are some changes to the IDE, and the Class Wizard in .NET, that can be confusing at first.

BTW: I remember reading that Visual Studio .NET can co-exist with Visual Studio 6, so you can install it, and try it out without effecting your VS6 installation, if you want.

Quote:

---

Originally posted by YourSurrogateGod
But wouldn't that significantly reduce the programmer's level of control over the software that he's writing?

And what about stuff like OpenGL? Won't that become less useful, since much of that syntax is very similar to that of WinAPI?

---

I really do not know much about managed code, but from reading TheCPUWizard comments:

Quote:

---

Originally posted by TheCPUWizard
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).

---

It sounds like you will still be able to do certain things, provided you know what your doing.

Quote:

---

Originally posted by TheCPUWizard
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

---

The underlying .NET framework will basically be the new Windows API, and will have it's own functions in support of OpenGL, etc. Imagine learning to program windows later, without having ever learned the current Windows API, or MFC, etc, I imagine it will be much the same as learning the Windows API now (or learning to program using any new library, etc), but less error prone.

So pretty much .NET is a version of java or something? All of the little things are done for you, therefore reducing your wordload and dumbing you down?

If that is so, then why does C++ .NET need a destructor? Why not just simply get rid of all of the reserved memory when the program is done executing?

And please someone tell me that one can still program in normal C, that would make a very unhappy camper if I had to abandon that :mad: ?

One last thing that I forgot, does anyone know any good tutorials or books on C++ .NET?

I have this book...
Microsoft Visual C++ .NET Step by Step
ISBN: 0-7356-1907-7
By: Julian Templeman, Andy Olsen

... and frankly it just keeps telling you (click this button, click this checkbox, type this in the textbox that says "Program Name" and so on), that's quite irritating unless you've never programmed before in your life, and you want to learn the complete basics. I stated that before here(how childish this book is)...
http://www.codeguru.com/forum/showth...hreadid=277890 .

One more thing about C++ .NET, it has pointers, right? Don't you need to allocate memory for those things? How else can you use them(either that or assign the address of a different variable to it, but that has limited fun opportunities ;) ) without calling the malloc function or something?

Use references, not pointers! :D

Quote:

---

Originally posted by indioclifa
Use references, not pointers! :D

---

Looks like it.

altough, I must recognize that I prefer, in terms of syntax, the old pointer style... that scrambled "guru" look...

those function definitions...

VOID func (UINT* pp, void* sz, float* d, LPSTRUCTNAME** zf);

:D

anyway, I must also recognize that using references is FAR more cleaner and secure :rolleyes:

Quote:

---

Originally posted by ats007spdou
What is "Managed Code" exactly? I see you guys throw that phrase around, but what does it mean exactly?

---

check the link in my previous reply..
in brief it protects the programmer from himself..By manageing resources (memory) to disallow memory leaks..

Quote:

---

Originally posted by YourSurrogateGod
And please someone tell me that one can still program in normal C, that would make a very unhappy camper if I had to abandon that :mad: ?

---

Mmm... let's face it. I like C very much, but in the next years, the use of C will be reserved to very specific projects (such as ASM today).

C is NOT a .NET - supported language (I don't know any .NET compliant C compiler...)

go to C++, which is good because you can still use many C-ways of doing things (in managed C++ e.g, I still use a lot of structs, #defines, etc. :D :D )

IMHO, when you discover e.g std::vector and std::string you ask yourself how you done it for the past 10 years without those exciting and easy-to-program artifacts.

Please don't blame me, I know this is offtopic, but ...

anyone tried using Server 2003 as a development workstation? And in that case, how it compares (for development of course: compile times, response,etc) with WIndows XP and 2000?

thank you... and blame me if you want, my friends. :cry:

I BLAME YOU!!! YOU OFF TOPIC SETTER YOU!!! :mad:
just kidding
:D :D :D

You're right about the old way of pointers indio, it looks way cooler.

ok ok, just don't blame me.

Windows 2003 anyone?:rolleyes:

Quote:

---

Originally posted by YourSurrogateGod
I BLAME YOU!!! YOU OFF TOPIC SETTER YOU!!! :mad:
just kidding
:D :D :D

You're right about the old way of pointers indio, it looks way cooler.

---

I cannot understand how longhorn and .Net solve the performance issues without pointers. I found the programs written in C# very very slow in executing compared to C and C++. I did a few sample programs using C# in win2k and it took 5-6 seconds to print two strings.:o

Could anyone tell me the difference between Managed C++ and C#? They're both based on .NET, aren't they, but which one is the heir of our beloved C/C++? And why choose MC++ but not C#?

Quote:

---

cannot understand how longhorn and .Net solve the performance issues without pointers. I found the programs written in C# very very slow in executing compared to C and C++. I did a few sample programs using C# in win2k and it took 5-6 seconds to print two strings

---

I share the same concerns. It just doesnt make sense, how even if .NET is the "native" api for Longhrn, it will solve this issue. whenever you have intermediate code and garbage collection, you lose performace, and there is no way around it. I guess everything will be slower? and MS just doesnt care cuz we will all have good computers anyway. Or am I wrong about this?

I am pretty sure that Win32 API will still be around for Linghorn. MS will have to support it just for all the applications that are already written using it.
I dont think the Win32 API and MFC will "die" until at least ~5 years after Longhorn comes out.

Personally, I really dont like .NET Framework. Whenever I can I choose not to use it, or any of its languages, and opt to do things in C++.
Currently, using the framework is a huge performance hit. The difference is actually noticable in use of the program; even on modern hardware. And there are still many people who write performance oriented apps, albeit probably half would be for Linux. The whole .NET thing seems to be to dumb down programming, and make it easier.
Currently, any .NET app has dependancies, and you cant guarantee it will run on any given machine. So you need to redistribute dotnetfx.exe with it or get your users to dl and intall it. That's a pretty big overhead now, when you can have a much smaller Win32 or statically linked MFC app with no more than 500k overhead. And I know it will run on any Win95+ machine. I admit this will not be an issue once Longhorn comes out.
To me, it's a lot like MS trying to pull off the Java thing. You basically have a set of languages that run on a sort of virtual machine (the .NET Framework). There are many other comparisons. Such as they are both not fully compiled. They are both slow. They are both "safer". Except there is one great advantage that Java has over .NET (and it's the main selling point of Java). It is truly cross-platform.
Lastly VB syntax is disgusting and irrational at best. :)

There are advantages to .NET, but call me a purist, or old fashioned, or whatever, I like my true C++ better.

Just my 2 cents,

Latem

I say that we all get Gentoo and be rid of the Windows irritant. Any seconds on that? :)

First, we can't blame Microsoft for it's monopolistic policies. Altough this is not a political or socialeconomic forum, to criticize Microsoft without criticizing world capitalism: that's the base on which Microsoft operates and the base on which such monopolies are safe to do anything they want.

IMHO, if .NET become polished (let's see 2.0 in the future), it will become an alternative. In fact, using C++ with the .NET framework gives you the maximum flexibility, you can mix a lot of things, you can write in your own coding style without the lackluster performance and (in my point of view) the confuse C# syntax.

It's true than in terms of raw performance, today nothing beats raw API... .NET cannot be used today for, e.g, performance-critical scientific applications. Imagine Mathematica wrote on .NET...

WinAPI will be there , but it's true that the foundations of WinAPI are near 20-years old... That sometime will change.

Microsoft thinks that .NET is the future , and to promote .NET, their way to do it in the future will be nothing more that crush the old API at a slow pace, until all of us are converted to the .NET religion.

Ahh...

and about Linux, I don't feel comfortable developing with it. I'm not pro-Microsoft... but, nothing beats the Microsoft development tools for Windows. That's my experience.

Quote:

---

Originally posted by indiocolifa
Microsoft thinks that .NET is the future , and to promote .NET, their way to do it in the future will be nothing more that crush the old API at a slow pace, until all of us are converted to the .NET religion.

---

people fear change :D